Post-JackSkid Adaptation: Dysphoria Botnet Embraces Blockchain C2s
Has anyone been tracking the Dysphoria activity following the JackSkid takedown? The CNCERT and XLab report on their shift to blockchain-based C2s is concerning. It appears they have adopted decentralized name services (likely akin to ENS) to resolve C2s dynamically, circumventing standard DNS sinkholing. Additionally, they are routing traffic through infected device relays, effectively using victims as a P2P proxy network.
This architecture is a direct response to law enforcement disruption. By moving the 'address book' to a blockchain and using other compromised devices as relays, they eliminate the single point of failure—a standard IP or domain—that made JackSkid vulnerable.
While the report focuses on the C2 evolution, the initial compromise vectors remain typical IoT weaknesses (default creds, unpatched firmware). However, detecting the beaconing is now harder. If they are hitting public JSON-RPC endpoints to resolve the C2, we might catch them via outbound traffic to non-web ports.
Here’s a KQL query to hunt for IoT devices hitting common blockchain RPC ports:
DeviceNetworkEvents
| where RemotePort in (8545, 30303, 9944) // Common Ethereum/Polkadot RPC/P2P
| where DeviceCategory == "IoT" or OSPlatform contains "Linux"
| where ActionType == "ConnectionSuccess"
| project Timestamp, DeviceName, SrcIp, RemoteIp, RemotePort, InitiatingProcessFileName
| summarize Count = count() by DeviceName, RemoteIp
| where Count > 5
The shift to decentralized infrastructure implies we need to move from blocking IPs to behavioral analysis. Is anyone else seeing anomalous traffic to public RPC nodes from their smart devices, or is this still largely theoretical for most networks?
Solid query. We've noticed a similar trend with Mozi variants lately. The key issue is that many of these RPC calls look like web traffic if you're just doing basic port inspection. If the IoT devices are on a flat network, they're essentially golden tickets for botmasters. We've started segmenting all 'headless' devices into a VLAN with strict egress rules, blocking access to public RPC nodes entirely to break the C2 chain.
The relay aspect is the scary part. It's not just command-and-control; it's hiding the origination of attacks. In our last IoT engagement, we found that 80% of the compromised devices had no specific CVE exploited—it was just Telnet default creds. I recommend checking logs for busybox connections. If you see busybox hitting an external IP on a high port, it's usually game over.
Blockchain C2 is definitely the next evolution in resilience. We started blocking DNS-over-HTTPS (DoH) at the firewall for our IoT subnet because many of these decentralized resolvers hide behind standard HTTPS. It breaks some 'smart' features on newer TVs, but it's better than being part of a DDoS relay. Firmware patching is the only real fix for the initial entry vector.
The reliance on public gateways for resolution actually gives us a detection opportunity. We've been hunting for IoT assets hitting common Web3 RPC ports that they shouldn't be touching. If you have access to firewall logs, look for non-server IPs connecting to ports like 8545 or 30303.
Here's a quick script to parse for these anomalies in your logs:
grep -E ':8545|:30303' /var/log/firewall.log | awk '{print $1}' | sort -u
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access