New Chaos Variant: Pivoting from Routers to Cloud Misconfigs & SOCKS Proxying
Saw the Darktrace report highlighted on HackerNews regarding the new Chaos malware variant. It seems the authors are shifting focus from purely targeting routers/IoT to exploiting exposed cloud deployments.
The most concerning addition is the built-in SOCKS proxy module. This essentially turns compromised cloud instances into pivot points for their C2 infrastructure, making attribution and blocking significantly harder. The entry point is almost always misconfigurations—exposed services (MongoDB, Redis, Docker APIs) without authentication.
I've updated our hunting queries to look for the anomalous outbound traffic typically associated with this behavior. Here is a KQL query I'm running to detect potential SOCKS proxying activity from unverified processes on Linux cloud hosts:
DeviceNetworkEvents
| where ActionType == "NetworkConnectionSuccess"
| where InitiatingProcessFileName !in ("sshd", "systemd", "apt", "yum")
| where RemotePort between 1024 and 65535
| summarize dcount(RemoteIP), TotalBytes=sum(SentBytes + ReceivedBytes) by DeviceName, InitiatingProcessFileName, RemotePort
| where TotalBytes > 5000000 // Filter for significant data transfer
Since this relies on misconfigurations, simple nuke-and-patch isn't enough. We need to verify our cloud ingress rules. How is everyone else auditing for these exposed services? Are you using automated CSP tools or custom scripts?
We rely heavily on Terraform Sentinel policies to prevent those exact exposures (public MongoDB/Redis ports) during deployment. However, for legacy workloads, I run a nightly nmap scan against our VPCs from a central bastion to catch anything that slipped through.
nmap -sV --open -p 27017,6379,9200,11211,2375 10.0.0.0/8
The new Chaos variant is just another reason why default-deny ingress is the only way to go.
From a SOC perspective, the SOCKS proxy addition is the real headache. It masks the true destination of the traffic. I recommend correlating the network events with process creation logs (Sysmon for Linux or Auditd). If you see curl or wget spawning a shell, followed by high-volume connections on random ports, you're likely owned.
Good catch on the KQL query. I'd add a filter for processes running from /tmp or /dev/shm, as these malware droppers often drop payloads there to evade AV.
| where InitiatingProcessFolderPath contains "/tmp" or InitiatingProcessFolderPath contains "/dev/shm"
Also, check for connections to IPs with poor reputation scores immediately after service startup.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access