Every enterprise security stack makes thousands of trust decisions each day. Signed software receives less scrutiny. Familiar cloud services move through reputation controls. Remote monitoring and management tools are allowed deep access because IT teams rely on them to support users and systems.
SMOKE#SCREEN stacks those ordinary decisions until malicious activity begins to resemble routine administration.
Securonix Threat Research tracked the active, multi-wave campaign across Windows and macOS. The operators used Zoom updates, business document reviews, system maintenance utilities and Adobe-themed lures to deliver ScreenConnect agents. An investigation that began with one VBScript sample expanded into 15 payloads, five distinct kill chains and three attacker-controlled ScreenConnect relay clusters. Every path was designed to silently install a legitimate RMM client and connect it to infrastructure controlled by the actor.
That infrastructure offers a revealing look at the operator’s habits. The IP address 207.174.0.143 hosted a live WsgiDAV staging server on port 8080, where an open directory exposed the campaign’s payload collection. The same machine ran the primary ScreenConnect relay on port 8041. This dual-purpose infrastructure handled both payload delivery and command-and-control over compromised hosts.
The operational overlap sat alongside deliberate compartmentalization. The campaign used three relay clusters, each provisioned with its own RSA key pair. A second relay supported ports 8041 and 80, giving the actor a fallback that could pass through environments blocking non-standard outbound traffic. A third used a domain designed to resemble an administrative portal. The actor combined redundancy and separation with the convenience of a primary host serving two critical roles.
The payload itself made the activity harder to judge at a glance. The final Windows packages were legitimate ConnectWise ScreenConnect installers signed with a valid Authenticode certificate chained to DigiCert. The macOS package connected to the same primary relay as several Windows payloads. A defender reviewing the binary alone could see a recognized vendor, a valid signature and software commonly found in enterprise environments.
The execution path supplied the missing context.
Early samples relied on heavily obfuscated VBScript, XOR encryption, low-memory checks and process blacklists targeting tools such as Wireshark, Process Monitor and Fiddler. Another script used WMI to create hidden processes, download an MSI and install it silently. A polished Zoom page placed the payload behind Dropbox and initiated the download automatically after two seconds. Other loaders used PowerShell, msiexec and a Cloudflare Quick Tunnel to blend delivery into trusted services and native system activity.
The campaign then became more aggressive. A SystemCheck lure disabled AMSI, requested elevation, weakened SmartScreen, added Microsoft Defender exclusions, removed Mark-of-the-Web metadata and silently installed the ScreenConnect package. The compiled MemoryLoader variant executed a nine-step Defender neutralization sequence before delivering the payload. Its actions included excluding the entire C drive, stopping the WinDefend service and disabling it at startup. Testing confirmed that the sequence could leave a machine degraded even when the MSI download failed.
The actor also rotated payload hashes between download sessions, making hash-based detection unreliable across investigative sampling periods. During the investigation, it replaced much of the staging server’s payload set and introduced loader.cs. The source contained an unusually candid instruction: “WAIT 3 MINUTES (Breaks Elastic correlation).” The loader inserted a 180-second pause between installation and service start, deliberately separating related events across an EDR correlation window.
The overt Defender destruction sequence disappeared, suggesting the actor was adapting to the visibility those behaviors created. At 50 megabytes, the compiled version of loader.cs also dwarfed the roughly 7-kilobyte loaders that preceded it. The package reflected a shift toward large, self-contained encrypted bundles, adding another evasion mechanism to the timing and anti-analysis techniques already in use.
SMOKE#SCREEN shows why software trust has to include provenance and behavior. A valid signature identifies the publisher while leaving the installation source, initiating actor, execution method and relay destination unresolved.
Security teams should treat RMM governance as a privileged-access discipline. They need an authoritative inventory of approved tools, expected relay destinations and sanctioned deployment methods. A ScreenConnect client installed through an established management platform should have a predictable process lineage. The same client arriving from a temporary directory through PowerShell or cmd, launched by msiexec with silent flags and connecting to a raw IP address warrants immediate investigation.
Application control can close several of the paths used in this campaign. AppLocker or Windows Defender Application Control policies can restrict MSI execution from Downloads, AppData and temporary directories. Detection logic should prioritize Defender exclusions, attempts to stop WinDefend, SmartScreen changes, Mark-of-the-Web removal and hidden PowerShell or WMI execution preceding an RMM installation.
Correlation windows also deserve scrutiny. Detection logic must preserve the relationship among an unusual installer, a newly created service and outbound ScreenConnect traffic even when execution pauses for several minutes. Detection engineering teams should test how long their platforms retain and connect endpoint, file, service and network events. The full sequence may unfold slowly because the attacker designed it that way.
The most durable detection opportunity lies in the chain. Lures, hashes and hosting services will continue to rotate. The relationship among delivery, execution, security-control tampering, RMM installation and outbound relay activity is harder to disguise. SMOKE#SCREEN makes that relationship visible, and defenders should build around it.
Join our LinkedIn group Information Security Community!
