Kimwolf Takedown: Dissecting the AISURU Variant & Booters
Saw the news this morning about the DoJ announcement regarding the arrest of Jacob Butler (aka "Dort") in Canada. It's good to see some traction against DDoS-for-hire services, specifically the Kimwolf botnet.
For those who haven't dug into the IoCs yet, Kimwolf is an assessed variant of the AISURU botnet family. These operators typically lean heavily on IoT exploits to build their armies. If you're defending a network edge, now is a good time to review your ACLs for non-essential inbound ports.
Based on previous AISURU campaigns, we often see C2 communication attempts over non-standard ports to bypass basic firewall rules. I've whipped up a quick Snort rule to catch potential heartbeat anomalies associated with this family:
snort alert udp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Potential Kimwolf/AISURU C2 Heartbeat"; content:"|48 45 4c 4c 4f|"; depth:5; offset:0; sid:9000023; rev:1;)
While arrests like these are a win, the infrastructure often persists long after the operator is in cuffs. The DOJ mentioned offenses related to development, which suggests custom binaries rather than just off-the-shelf loaders.
How is everyone else handling the "booter" proliferation lately? Are you seeing more Layer 7 (HTTP Flood) activity or are we still dealing mostly with volumetric reflection attacks?
It's almost always Layer 7 HTTP floods for us these days. The volumetric stuff is easy to scrub at the ISP level, but the slow POST attacks that keep connections open are killing our ingress controllers.
We've had some luck mitigating this by enforcing stricter timeout limits in Nginx. Here is a snippet we pushed out:
nginx client_body_timeout 5s; client_header_timeout 5s; keepalive_timeout 10s;
It doesn't stop the attack, but it drops the sockets faster so we don't run out of file descriptors.
Good catch on the AISURU connection. We saw a spike in traffic originating from compromised MikroTik routers late last year that looked very similar to this TTP.
For detection on the internal LAN, we've been using this PowerShell script to hunt for devices making high-volume outbound connections on suspicious ports:
Get-NetTCPConnection | Where-Object {$_.State -eq 'Established' -and $_.RemotePort -gt 1024} | Group-Object -Property RemoteAddress | Where-Object {$_.Count -gt 100} | Select-Object Name, Count
It usually identifies the compromised IoT devices pretty quickly.
Arrests are great for headlines, but I'll be impressed when they take down the bulletproof hosting providers facilitating these C2s.
From a pentester perspective, we still find default credentials on SOHO devices in almost every engagement. Until manufacturers stop shipping with admin/admin, these botnets will just rebuild themselves under a new name after Kimwolf fades away.
Valid points on the ACLs. For anyone doing incident response on compromised IoT devices, the C2 IP is often hardcoded in the binary but obfuscated. You can grep the raw binary for potential IP candidates if the XOR key is simple:
strings -n 15 sample.elf | grep -E '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$'
Solid points all around. Beyond ACLs, I recommend inspecting ESP/AH headers if you suspect traffic tunneling. AISURU sometimes attempts to masquerade floods as VPN traffic to bypass scrubbing. You can spot these anomalies using tcpdump on your gateways:
tcpdump -i eth0 -n 'udp and port 500 and length < 100'
This catches IKE attempts that are often too small for legitimate handshakes, signaling a potential scan.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access