I2P Under Siege: Kimwolf Botnet's C2 Evasion Tactics & Network Impact

Has anyone else noticed the latency spikes in I2P tunnels over the last week? It looks like the Kimwolf IoT botnet is aggressively pivoting to I2P to hide its C2 infrastructure, effectively DDoSing the anonymity network in the process.

While using anonymity networks isn't new for sophisticated actors, seeing a massive Mirai-variant like Kimwolf swamp I2P is a significant escalation. It seems they are flooding the network with garbage data—likely malformed NTCP or SSU handshake packets—to obfuscate their actual command traffic.

For those monitoring outbound traffic, keep an eye on your edge firewalls for unusual non-HTTP traffic on default I2P ports (often 8887 or 8888) originating from IoT segments. Since this is a Mirai derivative, standard default-credential brute-forcing is likely the initial infection vector.

I've put together a basic Snort rule to catch the specific packet size anomalies associated with this campaign:

snort alert udp $HOME_NET any -> $EXTERNAL_NET 8887 (msg:"Kimwolf I2P Flood Activity"; dsize:1000; sid:1000001; rev:1;)

And a YARA rule to help spot the binary if you are doing endpoint sweeps:

yara rule Kimwolf_IoT_Botnet { meta: description = "Detects Kimwolf Mirai variant binaries" author = "SecurityArsenal" strings: $m1 = "kimwolf" nocase $m2 = "/bin/busybox" $m3 = "TABLE_I2P" condition: 2 of them }

Is anyone else seeing degradation in their own anonymity services, or are we strictly looking at this as an external intel issue right now? How are you handling IoT segmentation to prevent these devices from phoning home to anonymity networks?