Key Takeaways
- The SMOKE#SCREEN campaign abused trusted remote‑monitoring‑and‑management (RMM) tools by disguising malicious installers as legitimate, signed software.
- Attackers used a dual‑purpose server (payload staging + ScreenConnect relay) and three separate relay clusters with unique RSA keys for redundancy and traffic‑blending.
- Payloads were delivered via multi‑stage loaders (VBScript, PowerShell, WMI, msiexec, Cloudflare Quick Tunnel) that employed obfuscation, anti‑analysis checks, and deliberate timing gaps to evade correlation.
- Early stages included aggressive Windows Defender neutralization (AMSI disable, SmartScreen weakening, service stop, exclusions); later versions shifted to large, self‑contained encrypted loaders with built‑in waits to break EDR correlation windows.
- Effective defense requires treating RMM as privileged access: maintain an approved‑tool inventory, enforce application‑control policies on MSI/PowerShell execution, monitor Defender tampering, service changes, and outbound RMM traffic, and engineer detection logic that preserves relationships across delayed events.
Overview of SMOKE#SCREEN Campaign and Trust Exploitation
Every day enterprise security stacks make thousands of trust decisions: signed software receives lighter scrutiny, familiar cloud services pass reputation checks, and remote monitoring and management (RMM) tools are granted deep access because IT teams depend on them for user and system support. The SMOKE#SCREEN campaign weaponized this implicit trust by chaining ordinary administrative actions until malicious activity blended seamlessly with routine operations. Threat researchers at Securonix observed an active, multi‑wave effort spanning Windows and macOS, where attackers leveraged seemingly benign lures—Zoom updates, business‑document reviews, system‑maintenance utilities, and Adobe‑themed prompts—to deliver ScreenConnect agents. What began as a single VBScript sample expanded into fifteen distinct payloads, five kill chains, and three attacker‑controlled ScreenConnect relay clusters, each engineered to silently install a legitimate RMM client and bind it to infrastructure under the actor’s control.
Infrastructure and Relay Clusters Details
The attacker’s infrastructure revealed a deliberate mix of overlap and compartmentalization. A single IP address, 207.174.0.143, hosted both a live WsgiDAV staging server on port 8080 (exposing an open directory of payloads) and the primary ScreenConnect relay on port 8041. This dual‑purpose host streamlined delivery and command‑and‑control (C2) functions. To increase resilience, the operator provisioned three separate relay clusters, each assigned its own RSA key pair. A second relay listened on ports 8041 and 80, offering a fallback capable of slipping through environments that block non‑standard outbound traffic. A third relay used a domain crafted to mimic an administrative portal, further masquerading malicious traffic as legitimate admin communication. By combining redundancy with separation, the actor ensured continuous availability while keeping each component isolated enough to hinder straightforward attribution.
Payload Characteristics and Legitimate Signing
The final Windows payloads were genuine ConnectWise ScreenConnect installers bearing a valid Authenticode certificate chained to DigiCert, giving them the appearance of trusted software. The macOS package connected to the same primary relay as several Windows variants, reinforcing the illusion of legitimacy. A defender examining only the binary would see a recognized vendor, a proper digital signature, and a tool commonly found in enterprise environments—factors that normally lower suspicion. However, the execution path surrounding these binaries supplied the critical context that revealed malicious intent. The signed installers were merely the vehicle; the real threat lay in how they were delivered, what system changes preceded their installation, and where they ultimately communicated.
Initial Delivery Mechanisms
Early infection vectors relied heavily on obfuscated VBScript that employed XOR encryption, low‑memory checks, and process blacklists targeting analysis tools such as Wireshark, Process Monitor, and Fiddler. Another script used Windows Management Instrumentation (WMI) to spawn hidden processes, download an MSI package, and install it silently. A particularly polished lure presented a fake Zoom update page hosted on Dropbox; after a two‑second delay, it automatically triggered the download of the malicious payload. Additional loaders leveraged PowerShell, msiexec, and Cloudflare Quick Tunnel to blend their activity with trusted services and native Windows behavior, making network traffic appear innocuous. These techniques demonstrated the actor’s focus on stealth during the initial foothold stage, using layered obfuscation and legitimate‑looking channels to bypass perimeter defenses.
Evolution to Aggressive Defender Neutralization
As the campaign matured, the actors adopted a more aggressive approach aimed at disabling host‑based defenses before installing the RMM client. A SystemCheck lure disabled Antimalware Scan Interface (AMSI), requested elevation, weakened SmartScreen, added Microsoft Defender exclusions, removed the Mark‑of‑the‑Web (MotW) flag, and silently installed the ScreenConnect package. A later MemoryLoader variant executed a nine‑step Defender neutralization sequence: it excluded the entire C: drive, stopped the WinDefend service, and disabled the service from starting at boot. Testing confirmed that even if the MSI download failed, the Defender‑tampering steps alone could leave a machine in a degraded state, reducing the likelihood of detection. This progression illustrated the attacker’s willingness to sacrifice stealth for persistence when initial evasion techniques risked exposure.
Loader.cs Insertion of Wait and Larger Payload
During the investigation, the operator replaced much of the staging server’s payload set and introduced a new component, loader.cs. The source code contained an unusually candid comment: “WAIT 3 MINUTES (Breaks Elastic correlation).” The loader inserted a 180‑second pause between installation and the start of the ScreenConnect service, deliberately separating related events across typical endpoint detection and response (EDR) correlation windows. At approximately 50 megabytes, the compiled loader.cs dwarfed the earlier ~7‑kilobyte loaders, reflecting a shift toward large, self‑contained encrypted bundles. This size increase served as an additional evasion mechanism, complicating signature‑based scanning while the built‑in delay thwarted timing‑based correlation rules that expect malicious actions to occur in rapid succession.
Detection Challenges and Recommendations
SMOKE#SCREEN underscores why software trust must extend beyond signatures to include provenance and behavior. A valid Authenticode certificate confirms the publisher but leaves unresolved the installation source, initiating actor, execution method, and ultimate relay destination. Security teams should treat RMM governance as a privileged‑access discipline: maintain an authoritative inventory of approved RMM tools, expected relay destinations, and sanctioned deployment methodologies. Any ScreenConnect instance appearing from atypical locations (e.g., temporary directories, PowerShell‑launched msiexec with silent flags) or connecting to raw IP addresses warrants immediate investigation. Application‑control solutions such as AppLocker or Windows Defender Application Control can restrict MSI execution from high‑risk folders like Downloads, AppData, and temp directories, thereby closing several of the paths abused in this campaign.
Application Control and Correlation Window Considerations
Detection logic should prioritize observable indicators of the attack chain: Defender exclusions, attempts to stop or disable WinDefend, SmartScreen alterations, removal of the Mark‑of‑the‑Web, and hidden PowerShell or WMI execution preceding an RMM installation. Because the actor deliberately inserted delays to break correlation, defenders must ensure their platforms retain and can link endpoint, file, service, and network events across extended windows—potentially several minutes. Testing the retention and stitching capabilities of EDR/SIEM tools is essential; if the platform discards older events too quickly, the multi‑stage nature of SMOKE#SCREEN will evade alerts. Prioritizing detection of the relationship among delivery, execution, security‑control tampering, RMM installation, and outbound ScreenConnect traffic—rather than relying solely on isolated IoCs—provides a more resilient defense.
Conclusion: Building Detection Around the Attack Chain
Lures, file hashes, and hosting infrastructure will continue to rotate as the adversary adapts. What remains harder to disguise is the causal chain that links a deceptive lure to the execution of a malicious loader, the systematic weakening of endpoint defenses, the silent installation of a legitimate RMM client, and the establishment of outbound communication to attacker‑controlled relay clusters. By focusing detection engineering on preserving the temporal and logical connections between these stages—accounting for deliberate pauses, encrypted loaders, and trusted‑service abuse—security teams can turn the attacker’s reliance on stealth into a detectable pattern. SMOKE#SCREEN makes that relationship visible; defenders should build their monitoring, correlation, and response strategies around it to catch future iterations before they achieve persistent access.