SURIQ
The useful lesson from the SMOKE#SCREEN campaign is not that attackers reach for a remote-access tool. It is that they picked one your defenses are built to trust. Securonix Threat Research documented an active operation that walks a target through fake software updates, quietly disables the endpoint's protections, and then installs ConnectWise ScreenConnect using a Microsoft Installer package carrying a valid code-signing certificate issued to ConnectWise. Signature allowlisting sees a legitimate vendor and steps aside. Reputation filtering sees Dropbox and Cloudflare and steps aside. Every control that decides by who signed it or where it came from is defeated at the same time.
That is the shift worth planning around. When the final payload is a genuinely signed, genuinely legitimate product, the place to catch the intrusion is not the tool and not the emailed lure. It is the tampering in the middle, where the attacker has to break something to make room for the tool.
What Securonix found
The campaign starts with spear-phishing that impersonates routine updates: a fake Zoom update, an Adobe notice, a document to review, a system maintenance utility. The lure delivers an obfuscated VBScript dropper. Before it does anything loud, the dropper checks its surroundings and quits if it sees analyst tools running, including wireshark.exe, procmon.exe, fiddler.exe, and the service processes for VirtualBox, VMware, and Citrix. If the coast looks clear, it decrypts a set of PowerShell commands that pull down .NET payloads from attacker infrastructure, from Dropbox links, or through a Cloudflare Quick Tunnel. Security Affairs reported that the installer packages are signed with a valid Authenticode certificate issued to ConnectWise.
Some samples then run a batch script whose only job is to clear a path for the remote-access agent. It disables the Antimalware Scan Interface (AMSI) by patching it in memory, walks through a User Account Control prompt to gain administrator rights, turns off SmartScreen through registry edits, adds the entire C:\ drive as a Microsoft Defender exclusion, and stops the WinDefend service outright. Only after the endpoint is blinded does the signed ScreenConnect installer land. The agent connects back to one of three attacker-run relay clusters, and its request parameters (e=Access&y=Guest) make the session look like an ordinary guest connection. A macOS build ships the same idea inside a package named to look like a Zoom updater.
| Detection signal | Where it shows up | Why it is high-fidelity |
|---|---|---|
| WinDefend service stopped | Service control / System log 7036 | Almost never benign on a managed endpoint |
| C:\ added as Defender exclusion | Defender config / registry | A whole-drive exclusion has no legitimate use |
| AMSI patched in memory | Process memory / script-block logs | Signals in-memory evasion, not normal software |
| MSI run from %TEMP% or AppData | Process creation (msiexec parent) | Vendor installers run from Downloads or SCCM |
| RMM agent dials a raw IP | Network / DNS logs | Real ScreenConnect uses vendor domains |
Why a signed remote-access tool defeats allowlisting
Application allowlisting that trusts a publisher signature has no answer here, because the signature is real. The ScreenConnect MSI is signed by ConnectWise through a trusted certificate chain, so a policy that permits "software signed by known vendors" permits this. The tool is not malware, it is a commercial product being used against you, and that is exactly why it slips past controls tuned to spot bad files.
The control that still works is an inventory decision, not a signature check. Your organization authorizes a specific set of remote-management tools, usually one. Everything else is an anomaly regardless of who signed it. A detection that fires on any ScreenConnect, AnyDesk, or similar agent that is not your sanctioned tool will catch this class of intrusion where a publisher allowlist never will. If you do run ScreenConnect as your sanctioned tool, pin the alert to agents connecting to relay hosts that are not your own instance.
The attacker is coding against a named EDR
The detail that should change how you tune detections is buried in the code. Earlier waves of SMOKE#SCREEN leaned on loud evasion: full Defender teardown, AMSI patching, drive-wide exclusions. Newer samples pivot to something quieter. They insert a deliberate three-minute pause, Thread.Sleep(180000), and a source comment states the delay exists to break Elastic's correlation window. The operator is not guessing. They tested against a specific commercial detection product and coded a delay long enough to age their earlier actions out of its correlation logic before the next step runs.
Treat that as a design note for your own rules. Correlation that stitches events together inside a fixed few-minute window is now a target an attacker will measure and step over. On high-value chains, where a tampering event is followed later by an install and then a callback, anchor the correlation on the sequence of behaviors and on the endpoint identity, and widen the window so a coded sleep does not carry the attacker across a gap in your logic. A detection that only holds for two minutes is a detection an adversary can wait out.
Detect the tampering, not the lure
The lure rotates and the remote-access tool looks legitimate, so neither is a stable thing to detect. The tampering in the middle is. Turning off the WinDefend service, excluding the whole C:\ drive from Defender, patching AMSI, and running an MSI out of %TEMP% or AppData are all rare in normal operation and hard for the attacker to skip, because the signed agent needs the endpoint blinded first. Those events are the choke point. Alert on them directly, and treat a cluster of them on one host inside a short span as an incident, not a set of unrelated warnings.
This is the same pattern behind other recent intrusions that abuse trusted tooling rather than a vulnerability. It echoes the Cavern C2 operations that ride an IT provider's own tools to get in, and it reinforces the point we made about ClickFix delivery: the lure is shared, rotating infrastructure, so tying detection to a particular pretext ages out fast. The durable signal is behavior. It also rhymes with malware that hides behind valid trust anchors, from an Apple-notarized macOS stealer to signed npm packages that shipped malware with valid provenance. A signature tells you who signed something, not what it will do.
What to do this week
Build the RMM inventory rule first. Decide which remote-management tool your organization sanctions, then write a detection that flags every other RMM agent by process name and by outbound connections to relay hosts you do not own. If ScreenConnect is your sanctioned tool, alert on agents whose relay is not your instance.
Next, wire the tampering signals in the table above into a single correlation that raises severity when more than one lands on the same host. Watch for WinDefend being stopped, whole-drive Defender exclusions, and msiexec launched from user-writable paths. Confirm your security-product-tampering telemetry is on and forwarded, since these attacks assume Defender is quiet after the batch script runs. Finally, review your correlation windows on privilege-escalation and defense-evasion chains, and lengthen the ones that a few minutes of attacker patience would defeat. For teams without the staff to keep these detections tuned as attackers iterate, a managed SOC carries that work, with analysts mapping the tampering-then-install sequence to MITRE ATT&CK and escalating the chain rather than the isolated alerts.