Wachstum des JDY-Botnets ermöglicht schnellere Ausnutzung von IoT- und SOHO-Schwachstellen

Zusammenfassung

Black Lotus Labs hat erneute Aktivitäten des JDY-Botnets identifiziert, einem mit China in Verbindung stehenden Netzwerk von mehr als 1.500 kompromittierten SOHO- und IoT-Geräten, das für großflächige Scans und Fingerprinting genutzt wird. Das Botnet erhält Anweisungen von einem zentralen Command-and-Control-System, führt gezielte Multiprotokoll-Scans durch und liefert strukturierte Telemetrie zurück, die den Betreibern hilft, neu veröffentlichte Schwachstellen schnell auszunutzen. Seine Infrastruktur wird durch Tor verschleiert, während eine Open-Source-Plattform namens Platypus zur Verwaltung der infizierten Geräte eingesetzt wird. Die Aktivitäten sind auf US-Militär- und kritische Infrastrukturziele ausgerichtet.

Untersuchung

Die Untersuchung verfolgte JDY-Verkehr zu einem PayLoad-Server bei 149.248.3.38, der einen Platypus-Dienst auf Port 13339hostete und ein auf Bash basierendes Dropper-Skript entdeckte, das architektur-spezifische Binärdateien über busybox, curl, oder wgetbezieht. Malware-Proben wurden untersucht, um Kommandozeilenoptionen, Beaconing-Verhalten, Aufgabrretrieval über verschlüsselte HTTPS-Endpunkte und adaptive Scanning-Methoden wie Raw-Packet-SYN-Probing zu identifizieren. Der Bericht verbindet JDY auch mit dem früheren KV-Botnet und assoziiert die Aktivitäten mit der chinesischen APT-Gruppe Volt Typhoon.

Abwehr

Empfohlene Abwehrmaßnahmen umfassen das Befolgen der Leitlinien des UK NCSC und der CISA zur Bekämpfung von China-gebundener verdeckter Infrastruktur, die Härtung von Router- und IoT-Firmware, das regelmäßige Neustarten und Patchen von Geräten sowie die Nutzung von SASE oder ähnlichen Kontrollen zur Reduzierung der externen Exposition. Sicherheitsteams sollten auch auf ungewöhnliche ausgehende TLS-Sitzungen zu unbekannten IP-Adressen und unerwartete Scanning-Aktivitäten von internen Edge-Geräten aus achten.

Reaktion

Wenn JDY-Aktivitäten erkannt werden, isolieren Sie das betroffene Gerät sofort, blockieren Sie ausgehenden Verkehr zu der identifizierten Command-and-Control-IP und dem Port und entfernen Sie alle bösartigen Binärdateien. Die Erkennungsinhalte sollten den auditdy Prozessnamen und den Platypus-Dienst umfassen, gefolgt von einem umfassenden Netzwerkscan nach anderen IoT-Geräten, die das gleiche Beaconing-Muster zeigen. Die Firmware sollte dann aktualisiert und Patches auf alle exponierten verwundbaren Produkte angewendet werden, einschließlich der im Bericht referenzierten Fortinet-Geräte.

Simulation der Ausführung

Voraussetzung: Der Telemetrie & Baseline-Pre‑flight-Check muss bestanden haben.

Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der Angreifertechnik (TTP), um die Erkennungsregel auszulösen. Die Befehle und Erzählungen MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffserzählung & Befehle:
  Der JDY-Operator möchte die Payload der nächsten Stufe von seinem hartcodierten Server (149.248.3.38) abrufen. Um den C2-Kanal zu verstecken, versucht der Operator auch eine über Tor geleitete Verbindung, in der Hoffnung, dass der ‚tor‘-Regex ihn markiert. Auf einem kompromittierten Windows-Host führt der Angreifer ein PowerShell-Einzeiler aus, der einen TCP-Socket zum Payload-Server öffnet, dann das Tor-Executable (tor.exe) verwendet, um einen versteckten Dienst aufzulösen und sich damit zu verbinden. Beide Aktionen erzeugen ausgehende Firewall-Ereignisse, die die Sigma-Regel erfüllen sollten.

• Regressionstest-Skript:

  # JDY Botnet Aktivitätssimulation – löst die Sigma-Regel aus
  # -------------------------------------------------------
  # 1. Direkte Verbindung zum bekannten Payload-Server
  $payloadIp = "149.248.3.38"
  $payloadPort = 80
  try {
      $sock = New-Object System.Net.Sockets.TcpClient($payloadIp, $payloadPort)
      Write-Output "Verbunden mit JDY Payload-Server ($payloadIp:$payloadPort)"
      $sock.Close()
  } catch {
      Write-Error "Fehler beim Verbinden mit dem Payload-Server: $_"
  }
  
  # 2. Tor-basierte Verbindung (simuliert über Hostname, der 'tor' enthält)
  #    Nimmt an, tor.exe ist im PATH und ein TOR-SOCKS-Proxy lauscht auf 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 der Praxis erfordert dies einen Tor-fähigen Resolver; hier geben wir nur ein protokollierbares Ereignis aus
      Write-Output "Versuche Tor Verbindung zu $torDest:$torPort über $torProxy"
  } catch {
      Write-Error "Tor Verbindung fehlgeschlagen: $_"
  }
  
  # Ende der Simulation – die Firewall sollte zwei ausgehende Versuche registriert haben

• Bereinigungskommandos:

  # Entfernen aller verbleibenden Verbindungen oder temporären Dateien
  Get-NetTCPConnection -RemotePort 80,443 | Where-Object { $_.RemoteAddress -eq "149.248.3.38" } | Remove-NetTCPConnection -Force
  # (Wenn tor.exe gestartet wurde, stoppen)
  Stop-Process -Name "tor" -ErrorAction SilentlyContinue