One Click, Full Access: How MagicSword Prevents Malicious ScreenConnect Installs
A real phishing email. A real ScreenConnect installer. No malware, no exotic exploit, just a signed, legitimate file that hands an attacker a persistent shell on your endpoint. Here's exactly how the attack works, and how MagicSword stops it before the installer ever runs.
The email
Last week a real email landed in a real inbox. It wasn't sophisticated. No zero-day, no macro payload, no exotic exploit chain. Just a simple pretext and a single link:
Subject: Immediate Action Required: Lost Shipment – April 18, 2026
I am writing regarding a shipment under your handling that was reported lost on April 18, 2026. This matter is now urgent and requires your immediate attention.
To proceed with the investigation and claims process, you are required to provide the necessary documentation without delay. Please use the secure link below to upload all relevant documents:
[Click here to upload and complete the required documents]
Failure to submit the requested documentation promptly will leave us no choice but to escalate this matter further, including pursuing formal action through the appropriate authorities.
Sender name, recipient domain, and the prospect's subdomain have been redacted. Everything else is exactly what the victim saw.
That's the whole lure. Urgency, consequences, one link. No attachment for a gateway to scan. No shady .exe. A logistics employee reads this at 9:04am, clicks the link before they've finished their coffee, and without MagicSword, their endpoint is now an unattended remote-access session owned by the attacker.
Let's walk through exactly how, and then exactly how we stop it.
The link
Here's the URL behind "Click here to upload and complete the required documents," with the subdomain scrubbed:
https://[REDACTED].screenconnect.com/Bin/ScreenConnect.ClientSetup.msi
?e=Access
&y=Guest
&t=Need%20carrier%20doc
&c=covenant
&c=Law%20enforcement%20in%20the%20United%20States
&c=&c=&c=&c=&c=&c=
Read that again. There is no payload staging, no dropper, no exploit. The link points directly at a legitimate, signed Microsoft Installer (.msi) hosted on a legitimate ScreenConnect SaaS instance. The file the victim downloads is the real ScreenConnect client, the same one thousands of MSPs push to their managed endpoints every day.
The weaponization is in the query string. ScreenConnect's installer accepts URL parameters that pre-bake the session configuration into the binary the user downloads. Every one of these parameters is documented. None of them are exotic.
- e=Access - install mode. Access is the unattended, persistent background mode, not the short-lived "Support" screen-sharing session. This is the one that survives reboots, runs as a Windows service, and waits quietly for the attacker to dial in.
- y=Guest - connect the endpoint to the attacker's tenant as a guest session. No authentication on the victim side.
- t=Need%20carrier%20doc - the session title the attacker sees in their console when this endpoint phones home. Note that it matches the phishing pretext; they're running campaigns and tagging inboxes by theme.
- c=covenant, c=Law%20enforcement%20in%20the%20United%20States - custom fields baked into the client for later use as on-screen copy or session metadata. The empty &c= slots pad out the field schema.
The installer is signed. The domain is screenconnect.com. The TLS cert is valid. The file downloads over HTTPS. At the byte level, this is indistinguishable from a sysadmin pushing a tool to a fleet.
The only difference between this and a legitimate ScreenConnect rollout is who's on the other end of the session.
Why this class of threat is hard
Signed, legitimate software isn't malware. It won't be quarantined. It won't fire a YARA rule. It won't trip a behavioral heuristic, because installing a remote management tool isn't behaviorally anomalous, MSPs, IT departments, and help desks do it constantly.
This is the entire premise of LOLRMM (Living-Off-the-Land Remote Monitoring and Management). Adversaries don't need to bring their own tools anymore. They bring yours.
A few numbers from public data that frame the stakes:
- 82% of detections in 2025 were malware-free, up from 51% in 2020. (CrowdStrike)
- Average eCrime breakout time: 29 minutes. Fastest observed: 27 seconds. (CrowdStrike)
- CHATTY SPIDER: initial access to exfiltration attempt in 4 minutes.
- SCATTERED SPIDER: full intrusion from help-desk call to NTDS extraction in 3 hours.
- One adversary was documented deploying 30+ different RMM tools in a single environment, so that "if one got caught, the others would survive."
The takeaway isn't that detection is bad. It's that the clock is brutal. A 29-minute breakout window against a SOC queue measured in hours means the endpoint has to refuse the install itself, on its own, in the moment. Anything that lets the MSI hit disk is already operating in a race it's statistically likely to lose.
That's the problem MagicSword is built to remove entirely.
The demo
Two takes, same email, same link, same click. Only the endpoint configuration changes.
Take 1 - with MagicSword + LOLRMM rules loaded
The user clicks the link. MagicSword stops the install at the gate, before the attacker ever gets a session. Two independent mechanisms catch it:
Default LOLRMM rule set - ScreenConnect is named in our out-of-the-box LOLRMM policy as an unsanctioned remote management tool. The binaries related to Screenconnect are blocked upon installation. No service registered. No process started.
End state: the endpoint is exactly as it was three seconds before the click. No service, no autorun, no beacon, no session in the attacker's console. Nothing to triage. Nothing to clean up. Nothing to investigate.
This is prevention at the gate. The ScreenConnect client never runs, so there's no post-install behavior for anyone to detect, correlate, or respond to.
Take 2 - default endpoint, no MagicSword
The user clicks the link. The MSI downloads. Installer runs. No prompt. No SmartScreen hold. No popup. A few seconds later the window closes on its own.
Where did it go?
- Installed Programs: "ScreenConnect Client (xxxxxxxxxxxxxxxx)".
- Services: a persistent Windows service, registered to phone home to the attacker's ScreenConnect tenant every few seconds.
- Task Manager: ScreenConnect.ClientService.exe and ScreenConnect.WindowsClient.exe, low CPU, quietly resident.
The victim sees nothing. The endpoint is waiting. The attacker's console shows a new row labeled Need carrier doc - and from there, they have a shell on the machine. From that point on, every minute that elapses favors the attacker: 29-minute average breakout, 27-second fastest observed, and a SOC queue that almost certainly can't match either.
Side by side
| With MagicSword + LOLRMM | Without | |
|---|---|---|
| MSI download | Blocked on execution / write | Succeeds |
| ScreenConnect service install | Prevented | Registered, auto-starts |
| Outbound beacon to attacker tenant | Never occurs | Active within seconds |
| Endpoint post-click state | Unchanged | Owned, awaiting operator |
| Required analyst action | None | Investigate, contain, remediate |
| Time window the defender has to react | Not applicable - nothing happened | Measured against a 29-minute breakout clock |
The left column isn't "we detected it faster." The left column is there was nothing to detect. The ScreenConnect binary did not run. The attacker's tenant never saw this endpoint come online. The intrusion did not begin.
How MagicSword does this
Three things working together:
1. Default LOLRMM coverage, shipped on day one. MagicSword ships with an opinionated LOLRMM policy covering the RMM tools most commonly abused in the wild, ScreenConnect, AnyDesk, SimpleHelp, NetSupport Manager, TeamViewer, Atera, Quick Assist, and others. You don't have to research the list, build the rules, or hunt down the installer signatures yourself. It's there when the agent lands.
2. A live intel feed, not a static ruleset. RMM abuse patterns shift, new installer paths, new staging directories, new hosting domains. Our intel feed keeps the block rules current so a campaign that retools next week doesn't get a free shot at your fleet.
3. Allowlist, not blocklist. If your IT team genuinely uses ScreenConnect for sanctioned remote support, we don't turn it off, you explicitly allow the approved tenant, signing cert, or service configuration. Everything else gets stopped. That inversion is what makes LOLRMM prevention tractable: you don't have to know every phishing campaign in advance, you only have to know what belongs on your endpoints.
The result is the demo above. Click the link, nothing happens. No race against a 29-minute clock. No 3am page. No forensic reconstruction of which employee clicked what at 9:04 on Tuesday. The install simply didn't occur.
If you run endpoints that could plausibly receive an email like the one above - which is to say, if you run endpoints - you already have the LOLRMM problem. The question is whether the answer on your network is "block at the gate" or "hope someone notices."
We'd rather show you than tell you. Book a demo, bring your own suspicious installer URL, and watch the rule fire.
Related reading: The top 10 techniques haven't changed in a decade, why the attack patterns behind emails like this one have been stable and preventable for years.
Written by
Michael Haag
Threat Researcher
In the intricate chessboard of cybersecurity, my role oscillates between a master tactician and a relentless hunter. As an expert in detection engineering and threat hunting, I don't just respond to the digital threats, I anticipate them, ensuring that the digital realm remains sovereign.
