La crescita della rete bot JDY consente una più rapida sfruttamento delle vulnerabilità IoT e SOHO

Riassunto

Black Lotus Labs ha identificato una rinnovata attività dal botnet JDY, una rete collegata alla Cina composta da oltre 1.500 dispositivi SOHO e IoT compromessi usati per scansioni e fingerprinting su larga scala. Il botnet riceve istruzioni da un sistema centralizzato di comando e controllo, effettua scansioni multi-protocol mirate e restituisce telemetria strutturata che aiuta gli operatori a sfruttare rapidamente le vulnerabilità di recente divulgazione. La sua infrastruttura è oscurata tramite Tor, mentre una piattaforma open-source chiamata Platypus è utilizzata per gestire i dispositivi infetti. L’attività è focalizzata su obiettivi militari statunitensi e infrastrutture critiche.

Investigazione

L’indagine ha tracciato il traffico JDY a un server di payload su 149.248.3.38, che ospitava un servizio Platypus sulla porta 13339, e ha scoperto un dropper basato su bash che recupera binari specifici per architettura tramite busybox, curl, o wget. I campioni di malware sono stati esaminati per identificare le opzioni della linea di comando, il comportamento di beaconing, il recupero di compiti tramite endpoint HTTPS crittografati e i metodi di scansione adattativa come il probing SYN a pacchetto grezzo. Il rapporto collega inoltre JDY al precedente KV-botnet e associa l’attività con il gruppo APT cinese Volt Typhoon.

Mitigazione

Le difese consigliate includono il seguire le linee guida del NCSC del Regno Unito e CISA per contrastare l’infrastruttura nascosta legata alla Cina, rafforzare il firmware di router e IoT, riavviare e correggere regolarmente i dispositivi e utilizzare SASE o controlli simili per ridurre l’esposizione esterna. I team di sicurezza dovrebbero anche monitorare le sessioni TLS in uscita insolite verso indirizzi IP sconosciuti e l’attività di scansione imprevista in origine dai dispositivi edge interni.

Risposta

Se viene rilevata un’attività JDY, isolare immediatamente il dispositivo interessato, bloccare il traffico in uscita verso l’IP e la porta di comando e controllo identificati e rimuovere qualsiasi binario maligno. Il contenuto di rilevamento dovrebbe includere il nome del processo auditdy e il servizio Platypus, seguito da una più ampia ricerca di rete per altri dispositivi IoT che mostrano lo stesso pattern di beaconing. Il firmware dovrebbe quindi essere aggiornato e applicate patch a qualsiasi prodotto vulnerabile esposto, inclusi i dispositivi Fortinet menzionati nel rapporto.

Esecuzione di simulazione

Prerequisito: il controllo pre-volo di Telemetria & baseline deve essere superato.

Motivazione: questa sezione dettaglia l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrativa DEVONO riflettere direttamente i TTP identificati e mirano a generare l’esatta telemetria attesa dalla logica di rilevamento.

• Narrazione dell’attacco & Comandi:
  L’operatore JDY vuole recuperare il payload di fase successiva dal suo server hardcoded (149.248.3.38). Per nascondere il canale C2, l’operatore tenta anche una connessione instradata tramite Tor, sperando che il regex “tor” lo segnali. Su un host Windows compromesso, l’attaccante esegue una one-liner PowerShell che apre un socket TCP al server di payload, quindi utilizza l’eseguibile Tor (tor.exe) per risolvere un servizio nascosto e connettersi a esso. Entrambe le azioni producono eventi di firewall in uscita che dovrebbero soddisfare la regola Sigma.

• Script di Test di Regressione:

  # Simulazione dell'attività del botnet JDY – attiva la regola Sigma
  # -------------------------------------------------------
  # 1. Connessione diretta al server di payload noto
  $payloadIp = "149.248.3.38"
  $payloadPort = 80
  try {
      $sock = New-Object System.Net.Sockets.TcpClient($payloadIp, $payloadPort)
      Write-Output "Connesso al server di payload JDY ($payloadIp:$payloadPort)"
      $sock.Close()
  } catch {
      Write-Error "Impossibile connettersi al server di payload: $_"
  }
  
  # 2. Connessione basata su Tor (simulata tramite hostname contenente 'tor')
  #    Si presume che tor.exe sia nel PATH e che un proxy TOR SOCKS sia in ascolto su 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 pratica, questo richiede un risolutore abilitato per Tor; qui emettiamo solo un evento registrabile
      Write-Output "Tentativo di connessione Tor a $torDest:$torPort tramite $torProxy"
  } catch {
      Write-Error "Connessione Tor fallita: $_"
  }
  
  # Fine simulazione – il firewall dovrebbe aver registrato due tentativi di uscita

• Comandi di Pulizia:

  # Rimuovi eventuali connessioni persistenti o file temporanei
  Get-NetTCPConnection -RemotePort 80,443 | Where-Object { $_.RemoteAddress -eq "149.248.3.38" } | Remove-NetTCPConnection -Force
  # (Se tor.exe è stato avviato, fermalo)
  Stop-Process -Name "tor" -ErrorAction SilentlyContinue