Anubis Ransomware: Citrix Bleed 2 (CVE-2025-5777) + RMM Abuse
Just reviewed the latest intelligence on the Anubis operation and their shift toward exploiting CVE-2025-5777 (Citrix Bleed 2). It’s concerning but not surprising that they are pivoting back to NetScaler gateways for initial access.
The tradecraft follows a disturbingly effective pattern: once they bypass the authentication layer via the vulnerability, they immediately drop legitimate RMM tools (like AnyDesk or ScreenConnect) to establish 'hands-on-keyboard' access. Because these binaries are signed, they often fly under the radar of basic EDR solutions.
For those hunting for this, I recommend checking for RMM process executions with unexpected parent processes. Here is a basic KQL query for Sentinel/Defender to flag anomalies:
DeviceProcessEvents
| where Timestamp > ago(3d)
| where FileName in~ ("anydesk.exe", "screenconnect.clientservice.exe", "splashtopbusiness.exe")
| where InitiatingProcessFileName !in~ ("explorer.exe", "services.exe", "userinit.exe")
| project DeviceName, FileName, InitiatingProcessFileName, AccountName, SHA256
The report also emphasizes lateral movement via harvested credentials. If you have Citrix ADCs, ensure you are checking for session token anomalies immediately.
Is anyone else noticing an increase in 'living-off-the-land' binaries being used for lateral movement immediately after public disclosure of VPN vulnerabilities? How are you handling RMM software whitelisting without breaking ops?
Solid query. We actually caught a similar attempt last month using a correlation rule. We looked for RMM installation scripts (msiexec) originating from non-admin shares. In our case, the attacker used PowerShell to download the AnyDesk MSI directly from a public CDN after getting a shell via the VPN. We've since blocked those specific CDN hashes at the proxy level.
The Citrix patching cycle is always a nightmare. We often see delays because these gateways are treated as 'set and forget.' The Anubis group is smart to target this; they know orgs are slow to patch NetScaler. I'd advise checking your ns.log files specifically for session ID enumeration patterns. If you see a surge in 401s followed by 200s on the same session ID within seconds, you're likely being hit.
From a pentester's perspective, once the RMM tool is inside, it's usually game over for traditional AV. I've used similar techniques in red team exercises—dropping ScreenConnect creates a persistent channel that looks like legitimate admin traffic. I'd suggest focusing more on egress traffic analysis. If an RMM tool is phoning home to an IP that isn't in your vendor's whitelist, kill it immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access