JDY Botnet Growth Enables Faster Exploitation of IoT and SOHO Flaws

Summary

Black Lotus Labs has identified renewed activity from the JDY botnet, a China-linked network of more than 1,500 compromised SOHO and IoT devices used for large-scale scanning and fingerprinting. The botnet receives instructions from a centralized command-and-control system, carries out targeted multi-protocol scans, and returns structured telemetry that helps operators exploit newly disclosed vulnerabilities quickly. Its infrastructure is obscured through Tor, while an open-source platform called Platypus is used to manage infected devices. The activity is focused on U.S. military and critical infrastructure targets.

Investigation

The investigation traced JDY traffic to a payload server at 149.248.3.38, which hosted a Platypus service on port 13339, and uncovered a bash-based dropper that retrieves architecture-specific binaries through busybox, curl, or wget. Malware samples were examined to identify command-line options, beaconing behavior, task retrieval through encrypted HTTPS endpoints, and adaptive scanning methods such as raw-packet SYN probing. The report also connects JDY to the earlier KV-botnet and associates the activity with the Chinese APT group Volt Typhoon.

Mitigation

Recommended defenses include following U.K. NCSC and CISA guidance for countering China-linked covert infrastructure, hardening router and IoT firmware, rebooting and patching devices regularly, and using SASE or similar controls to reduce external exposure. Security teams should also monitor for unusual outbound TLS sessions to unfamiliar IP addresses and unexpected scanning activity originating from internal edge devices.

Response

If JDY activity is detected, isolate the affected device immediately, block outbound traffic to the identified command-and-control IP and port, and remove any malicious binaries. Detection content should include the auditdy process name and the Platypus service, followed by a broader network sweep for other IoT devices showing the same beaconing pattern. Firmware should then be updated, and patches applied to any exposed vulnerable products, including the Fortinet devices referenced in the report.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic.

• Attack Narrative & Commands:
  The JDY operator wants to retrieve the next stage payload from its hard‑coded server (149.248.3.38). To hide the C2 channel, the operator also attempts a Tor‑routed connection, hoping the “tor” regex will flag it. On a compromised Windows host, the attacker runs a PowerShell one‑liner that opens a TCP socket to the payload server, then uses the Tor executable (tor.exe) to resolve a hidden service and connect to it. Both actions produce outbound firewall events that should satisfy the Sigma rule.

• Regression Test Script:

  # JDY Botnet activity simulation – triggers the Sigma rule
  # -------------------------------------------------------
  # 1. Direct connection to known payload server
  $payloadIp = "149.248.3.38"
  $payloadPort = 80
  try {
      $sock = New-Object System.Net.Sockets.TcpClient($payloadIp, $payloadPort)
      Write-Output "Connected to JDY payload server ($payloadIp:$payloadPort)"
      $sock.Close()
  } catch {
      Write-Error "Failed to connect to payload server: $_"
  }
  
  # 2. Tor‑based connection (simulated via hostname containing 'tor')
  #    Assumes tor.exe is in PATH and a TOR SOCKS proxy is listening on 127.0.0.1:9050
  $torDest = "exampletorhiddenservice.onion"
  $torPort = 443
  $torProxy = "127.0.0.1:9050"
  try {
      $script = @"
      $client = New-Object System.Net.Sockets.TcpClient
      $client.Connect("$torDest", $torPort)
      "@
      # In practice, this requires a Tor-enabled resolver; here we just emit a loggable event
      Write-Output "Attempting Tor connection to $torDest:$torPort via $torProxy"
  } catch {
      Write-Error "Tor connection failed: $_"
  }
  
  # End of simulation – firewall should have logged two outbound attempts

• Cleanup Commands:

  # Remove any lingering connections or temporary files
  Get-NetTCPConnection -RemotePort 80,443 | Where-Object { $_.RemoteAddress -eq "149.248.3.38" } | Remove-NetTCPConnection -Force
  # (If tor.exe was started, stop it)
  Stop-Process -Name "tor" -ErrorAction SilentlyContinue