VENOMOUS#HELPER: Abuse of SimpleHelp & ScreenConnect in Active Phishing Campaign
Has anyone else dug into the Securonix report on VENOMOUS#HELPER yet? It’s a stark reminder of how attackers are pivoting from deploying malware to simply 'living off the land' by abusing trusted remote administration tools.
In this campaign, threat actors are using SimpleHelp and ScreenConnect (ConnectWise) to establish persistence on compromised hosts after a successful phishing attack. Since these are legitimate RMM tools, they often fly under the radar of standard EDR solutions—which are typically configured to trust these binaries. With 80+ organizations already hit, mostly in the U.S., this isn't a theoretical risk; it's an active threat.
The real challenge here is distinguishing between legitimate admin activity and malicious use. If you aren't strictly allowlisting specific RMM vendors, you're vulnerable.
Here is a KQL query to help hunt for unexpected RMM process executions in your environment, specifically targeting executables associated with these tools:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("SimpleRemote.exe", "ScreenConnect.ClientService.exe", "RemoteControl.exe")
| where InitiatingProcessAccountName != "SYSTEM"
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, AccountName
You should also audit what is actually installed on your endpoints. Here is a quick PowerShell snippet to check for the presence of these specific RMM agents:
Get-CimInstance Win32_Product | Where-Object {
$_.Name -like "*SimpleHelp*" -or
$_.Name -like "*ScreenConnect*" -or
$_.Name -like "*ConnectWise*"
} | Select-Object Name, Version, InstallDate
How is everyone handling RMM software in their environments? Are you strictly blocking everything not pre-approved, or do you have a behavioral detection setup for 'admin' tools?
Great query. One thing we've noticed in our SOC is that attackers often rename the binaries to look like system updates if they think they're being watched. You might want to add a hash lookup to that KQL query to ensure it's the signed vendor version. We also geo-fence our RMM traffic; if ScreenConnect tries to call home to an IP not in our MSP's specific range, it triggers an instant block.
As an MSP owner, this is terrifying. We use ScreenConnect daily internally. We've enforced 'Zero Trust' access on our RMM dashboards—no VPNs, strict MFA, and conditional access policies based on device compliance. If the admin portal isn't locked down tighter than the endpoints themselves, the attackers don't even need to phish the end-user; they just phish the tech.
This tracks with what we saw during the 'SolarWinds' aftermath—supply chain and trusted tool abuse is the new normal. We started using AppLocker to restrict execution of these specific binaries to only C:\Program Files\VendorName. If they try to run it from C:\Users\Public\Downloads, it gets killed immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access