ScreenConnect Attackers Hide Windows, Delete Installers and Masquerade as Software Updates

ScreenConnect is being systematically weaponized in the SMOKE#SCREEN campaign, where attackers hide execution windows, delete installers, and disguise malicious activity as routine software updates to plant fully functional, signed ScreenConnect agents across Windows and macOS endpoints.

The result is persistent, “legitimate-looking” remote access that blends into normal IT operations while silently bypassing user awareness and many endpoint defenses.

The actors rotate at least four social engineering themes Zoom updates, Adobe updates, business document reviews, and “system check” utilities to maximize victim coverage and align with common enterprise workflows.

Every path ends in the same outcome: a ScreenConnect client silently installed and beaconing to attacker-controlled relay servers, presenting as standard guest access sessions (e=Access&y=Guest) rather than obviously malicious RAT traffic.

The toolchain is notably diversified. Early waves rely on obfuscated VBScript droppers with XOR-encrypted payloads and environment checks designed to evade sandboxes and analysis VMs.

Later stages introduce batch loaders that dismantle Windows defenses, and compiled .NET executables that neutralize Microsoft Defender before delivery.

A polished Zoom-themed HTML phishing page and a simpler Adobe-themed page broaden coverage by moving the initial access into the browser, backed by trusted hosting like Dropbox and Cloudflare tunnels.

Across samples, the campaign consistently prioritizes invisibility on the endpoint. VBScript droppers abuse WMI’s Win32_Process and Win32_ProcessStartup classes to spawn processes with ShowWindow = 0, ensuring every child process runs completely hidden.

Batch installers execute via PowerShell with window styles suppressed, while compiled loaders immediately hide their own console windows via P/Invoke before touching the network.

In all paths, ScreenConnect installs silently; the user never sees a traditional setup UI or warning dialog.

The actor also aggressively erases the forensic trail. Batch loaders strip Mark-of-the-Web (Zone.Identifier) alternate data streams before execution, delete MSI installers after completion, and add Defender exclusions to TEMP paths so transient artifacts are less likely to be scanned.

Securonix Threat Research’s SMOKE#SCREEN investigation documents a multi-wave operation that abuses ConnectWise ScreenConnect as the primary remote access mechanism.

In one chain, the MSI is saved locally as “WindowsExplorerSupport.msi” even though the remote file is “SystemCheck.msi,” a naming tactic designed to camouflage the payload as a benign Windows support component if an administrator inspects the directory.

Masquerading as software updates is the core delivery strategy. Filenames and phishing content impersonate Zoom (zoom-update.vbs, ZoomUpdateInstaller.msi/pkg), Adobe Reader/Flash Player (AdobeReader_Update.exe, fake Flash update page), and business document viewers (RSKAdvGrpSupportingdocuments.vbs, DocumentReview.msi).

The Zoom phishing page uses authentic branding, a fake urgent version (6.5.1), and a JavaScript timer that auto-triggers the Dropbox-hosted download after two seconds, complete with a fake progress bar to sell the illusion of a legitimate client update.

The attackers anchor the campaign on a WsgiDAV-based staging server at 207.174.0.143:8080, which at one point exposed an open directory of 15 payloads a strong sign of operational convenience and active development.

The same host also runs the primary ScreenConnect relay on port 8041, meaning a single machine both delivers payloads and maintains command-and-control over compromised hosts.

By extracting relay configuration strings from MSI and EXE samples, Securonix mapped three distinct ScreenConnect relay clusters: 207.174.0.143:8041 (primary), 142.202.191.225:8041/80 (secondary, with port 80 fallback for firewall evasion), and blog.derrspecial-onlinedmin.live:8041 (tertiary, masquerading as an admin portal).

Earlier infrastructure on 207.189.11.170 and crestmarkhq.com has since gone offline, indicating rotation and burn management consistent with a capable, operationally secure actor.

Importantly, the campaign is not limited to Windows. A macOS package ZoomUpdateInstaller.pkg connects to the same primary relay as the Windows MSI files, confirming deliberate cross-platform coverage and an intent to compromise macOS endpoints through the same fake Zoom update narrative.

The use of Cloudflare Quick Tunnels and Dropbox as payload hosts further complicates detection by hiding downloads behind reputable, frequently allowed services.

One of the most notable aspects of SMOKE#SCREEN is the visible evolution of tradecraft over time. Early VBScript droppers employ heavy obfuscation, environment keying, and in-memory C# compilation via PowerShell to stay under the radar.

ScreenConnect Attackers Hide Windows

Subsequent batch loaders escalate to a nine-step Defender destruction sequence: AMSI bypass, UAC auto-elevation, SmartScreen registry tampering, broad Defender exclusions (up to C:$$, service stops, and startup disablement, leaving endpoints permanently degraded even if payload delivery fails.[1]

More recent loader variants pivot away from overt AV destruction toward stealth and anti-EDR timing.

The replacement of MemoryLoader.cs with loader.cs on the staging server removes the aggressive Defender tampering and introduces a coded three-minute delay between MSI installation and service start, explicitly commented as “BREAKS Elastic correlation”.

At the same time, payload hashes and filenames are actively rotated between sessions, rendering hash-based detection ineffective across sampling periods.

A polished HTML phishing page was found among the staging server’s files, serving as an alternative initial access vector.

Despite the sophistication of the loaders, the final payload is always a legitimate ConnectWise-signed ScreenConnect ClientSetup MSI, complete with Authenticode certificates chained to DigiCert and standard components like ClientService.dll and WindowsClient.exe.

This “living off the land” approach leverages enterprise trust in ScreenConnect and code signing to bypass many EDR heuristic thresholds; the maliciousness lies entirely in the configuration (relay endpoints, access parameters) rather than the binaries themselves.

Once installed, agents silently register as services and connect back to attacker-controlled relays using guest-access parameters, enabling full remote desktop and system management capabilities indistinguishable from authorized IT activity.

Other recent intelligence from Red Canary, Sophos, and independent researchers aligns with this pattern: phishing-driven ScreenConnect deployments, MSI masquerading as documents or updates, and commodity RMM clients repurposed as high-fidelity RATs.

For defenders, SMOKE#SCREEN underscores the need to treat unauthorized RMM installation and configuration changes as high-severity incidents.

Recommended actions include: inventorying all ScreenConnect instances and validating them against sanctioned IT lists, flagging ScreenConnect clients connecting to raw IPs or unknown domains, monitoring for Defender tampering and AMSI bypass patterns.

This campaign also sits within a broader trend of ScreenConnect abuse, including SILENTCONNECT-style phishing loaders and party-invitation or invoice lures that silently deploy signed ScreenConnect clients as RATs.

Why use the 2026 Agentic SOC Buyer’s Guide? 8 Best Platforms Compared – Download the 2026 Buyer’s Guide