SEO Poisoning Rampant: ScreenConnect as an AsyncRAT Loader
SEO Poisoning Rampant: ScreenConnect as an AsyncRAT Loader
Just saw the report regarding the massive campaign abusing ScreenConnect to distribute AsyncRAT. It seems threat actors have stepped up their SEO game, spoofing sites for popular tools like OBS Studio, DNS Jumper, and DS4Windows.
The mechanics are insidious: users download a compromised installer, which unpacks a legitimate-looking ScreenConnect client. This client acts as the loader for AsyncRAT, granting the attackers full remote access. Since ScreenConnect is a standard administrative tool, firewall rules often permit its traffic, making detection tricky.
I've whipped up a quick PowerShell snippet to help identify these specific malicious installers by checking for known fake file names in the Downloads folder and verifying their digital signatures (or lack thereof):
$MaliciousApps = @("OBS-Studio-Setup.exe", "DNSJumper.exe", "DS4Windows.exe", "Bandicam_Setup.exe")
$DownloadsPath = Join-Path $env:USERPROFILE "Downloads"
Get-ChildItem -Path $DownloadsPath -Filter *.exe | Where-Object {
$MaliciousApps -contains $_.Name
} | ForEach-Object {
$sig = Get-AuthenticodeSignature $_.FullName
if ($sig.Status -ne 'Valid') {
Write-Host "Potential Threat Found: $($_.FullName) - Signature Status: $($sig.Status)" -ForegroundColor Red
}
}
It's a bit of a shotgun approach, but useful for triaging user workstations.
How is everyone else handling software supply chain risks for end-user tools? Are you relying purely on allow-listing, or do you have automated verification for downloaded binaries?
As an MSP, this is terrifying. We use ScreenConnect (ConnectWise Control) legitimately every day. Blocking it isn't an option for us.
We've implemented strict geo-fencing on our management agents; if a ScreenConnect instance tries to phone home outside our known IP ranges, it triggers an immediate alert. It's a false positive nightmare sometimes, but better than being breached.
Great write-up. Just a heads up, Kaspersky mentioned that the malicious installers are often 7-Zip SFX archives. You can add a check for the 7z.sfx signature in your scanner.
Also, validating the certificate thumbprint against the vendor's official hash is a good move. Most of these spoofed binaries either have no sig or a self-signed one that doesn't match the actual vendor.
Validating the certificate is smart, but I've found checking the parent process chain helps differentiate malicious loaders from legit service installs. If ScreenConnect.ClientService.exe is spawned by a user profile process (like from Temp or AppData) rather than services.exe, it's a huge red flag.
You can hunt for suspicious parentage with this PowerShell snippet:
Get-WmiObject Win32_Process | Where-Object {$_.Name -eq "ScreenConnect.ClientService.exe"} | Select-Object Name, ParentProcessId, @{Name="ParentName";Expression={(Get-Process -Id $_.ParentProcessId).Name}}
This usually exposes the droppers running under user context.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access