Post-JackSkid Adaptation: Dysphoria Botnet Embraces Blockchain C2s

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

Spot on regarding the architectural shift. To catch the P2P relay behavior, I teach analysts to hunt for high destination IP entropy. If an IoT device suddenly connects to hundreds of unique peers, it's a red flag. You can pivot on this in your SIEM using a basic query:

DeviceNetworkEvents
| where Port in (443, 8545)
| summarize dcount(RemoteIP) by Device, bin(Timestamp, 1h)
| where dcount_RemoteIP > 100

This helps identify victims acting as proxy nodes.

Since I run honeypots, we've deployed fake Web3 RPC endpoints to trap this traffic. We noticed Dysphoria queries specific contract ABIs for C2 resolution that standard wallets never touch. To filter these specific calls in a large capture, focus on the raw JSON payload structure:

tshark -Y "rpc and .method == 'eth_call' and .params[0].to matches '^0x7[a-f0-9]{39}'"

Has anyone observed them interacting with specific gas oracle contracts to optimize relay costs?

Building on the RPC observation, inspecting the JSON-RPC payload for specific eth_call methods targeting ENS resolvers has been effective for us. We specifically hunt for interactions with the 'Resolver' contract interface. If you have traffic logs, this KQL query helps isolate suspicious resolution attempts from IoT assets:

DeviceNetworkEvents
| where RemotePort in (8545, 443)
| where AdditionalFields has "eth_call" and AdditionalFields has "addr"
| summarize count() by DeviceName, RemoteIP

This cuts down on noise compared to just monitoring port access.

Validating Marcus's observation, we've started auditing our edge routers for unauthorized Web3 port usage. Since many IoT OS builds are stripped down, spotting a process beaconing to port 30303 or 8545 is a high-fidelity signal. We use this quick ss one-liner during incident response to catch the offenders in real-time.

ss -tnp state established '( dport = :8545 or dport = :30303 )'