JDY Botnet Resurfaces: Weaponizing 1,500+ SOHO Devices for Cyber Reconnaissance
Just reviewed the latest report from Lumen's Black Lotus Labs regarding the resurgence of the JDY botnet. While a botnet of 1,500+ SOHO and IoT devices might seem modest compared to the massive Mirai variants we've seen in the past, the intent here is far more concerning. These devices aren't just being used for DDoS; they are functioning as a high-performance scanner to discover and fingerprint exposed services for future exploitation.
This highlights a critical blind spot in our perimeter defenses. We spend millions securing corporate endpoints, yet a neglected IoT device in a home office becomes a node for state-sponsored cyber reconnaissance.
If you're hunting for this type of activity, you're looking for scanning behavior originating from residential IP ranges. Specifically, watch for single IPs hitting multiple distinct ports on your external-facing assets in rapid succession.
Here is a basic KQL query for Microsoft Sentinel to help identify potential scanning sources focusing on port diversity:
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionAllowed"
| summarize PortCount = dcount(RemotePort), PortList = make_set(RemotePort) by SourceIP, bin(Timestamp, 1h)
| where PortCount > 20
| project SourceIP, Timestamp, PortCount, PortList
| order by PortCount desc
Default credentials on SOHO routers are still the primary entry point. How is everyone handling the security of remote employee routers? Are you enforcing hardware standards, or are we just accepting this risk as the new normal?
Solid query. We’ve been seeing similar patterns in our honeypots—scans that hit SSH, RDP, and SQL ports in a specific sequence. To expand on this, you might want to correlate these IPs with known threat intel feeds for 'SOHO Router compromise'. We've had success auto-blocking IPs that trigger the port diversity rule you mentioned, provided they aren't major VPN exit nodes.
This is exactly why I advocate for corporate-provided Wi-Fi equipment for remote staff. You can't patch what you don't manage. For smaller clients where that's not feasible, we've been deploying Edge firewalls (like Ubiquiti or MikroTik) with remote management locked down and Intra-Default-Deny enabled. It's a pain to set up, but it stops the device from becoming part of a botnet C2.
Interesting that they are focusing on reconnaissance rather than throughput. From a pentester's perspective, 'living off the land' with residential IP space makes blocking significantly harder for defenders. Geo-blocking won't help much if the attacker is sourcing traffic from the same country as the target. Layer 7 filtering with behavioral analysis seems to be the only viable defense right now.
Great point on the blind spot. To catch this reconnaissance phase early, we often focus on failed connection spikes from unique sources. In Azure Sentinel, we query for distinct IPs hitting multiple ports within a short window to flag potential scanners.
DeviceNetworkEvents
| where ActionType == "ConnectionFailure"
| summarize dcount(LocalPort), makelist(LocalPort) by RemoteIP, bin(Timestamp, 5m)
| where dcount_LocalPort > 10
This helps separate noise from targeted scanning campaigns.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access