La caccia al malware rivela un caricatore di rootkit universale furtivo

Riepilogo

Un loader rootkit firmato da Microsoft recentemente scoperto consente agli attaccanti di distribuire moduli kernel non firmati sui sistemi compromessi. Il malware utilizza un driver di primo stadio per comunicare con l’infrastruttura C2 e caricare plug-in di secondo stadio direttamente in memoria. Questo modello di esecuzione furtivo aiuta a bypassare il rilevamento basato su disco mantenendo un accesso di livello kernel ad alta privilegiatura.

Indagine

I ricercatori hanno identificato un insieme di driver firmati che abusano del Programma di Compatibilità Hardware di Windows (WHCP) per ottenere firme legittime di Microsoft. L’indagine ha rivelato un modello di esecuzione a due stadi in cui un loader firmato gestisce l’iniezione di driver kernel personalizzati e non firmati. L’analisi del codice e dell’infrastruttura ha anche rivelato somiglianze con il rootkit FiveSys precedentemente documentato.

Mitigazione

Le organizzazioni dovrebbero monitorare il caricamento sospetto o non autorizzato di driver in modalità kernel e le modifiche inattese al registro che interessano i servizi di sicurezza. Distribuire il rilevamento degli endpoint in grado di identificare il caricamento di moduli solo in memoria è fondamentale per rilevare questa attività. Limitare l’uso di driver firmati WHCP provenienti da venditori sconosciuti o non affidabili può ridurre ulteriormente l’esposizione.

Risposta

Quando questa attività viene rilevata, isolare i sistemi interessati per interrompere la comunicazione C2 e prevenire il movimento laterale. Eseguire un’analisi forense della memoria per identificare i moduli kernel iniettati che potrebbero non essere mai stati scritti su disco. Verificare l’integrità del registro, con particolare attenzione alle Opzioni di Esecuzione File Immagine e alle modifiche non autorizzate alle politiche di sicurezza.

Esecuzione della Simulazione

• Narrativa di Attacco & Comandi: L’avversario intende distribuire un componente rootkit che maschera la sua presenza comunicando con un driver malevolo. Per bypassare il rilevamento tradizionale basato su file, l’attaccante utilizza un approccio “Living-off-the-Land”, impiegando uno script PowerShell per interagire con un driver che è stato caricato lateralmente nel kernel. Lo script mira specificamente al IRP_MJ_DEVICE_CONTROL gestore inviando un codice IOCTL (I/O Control) appositamente creato, imitando il modello di comunicazione del caricatore rootkit identificato per stabilire un canale di comando e controllo e disabilitare le funzionalità di sicurezza.

• Script di Test di Regressione:

  # Script di simulazione per imitare la comunicazione del driver del caricatore rootkit
  # Nota: Questo richiede la presenza di un driver che risponda a questi schemi specifici 
  # oppure simuli le chiamate del gestore IRP tramite un driver mock.
  
  $SymbolicName = "x1cx1c??x1ceae971b87"
  Write-Host "[+] Simulazione dell'interazione del driver con Nome Simbolico: $SymbolicName"
  
  # In uno scenario reale, ciò comporterebbe la chiamata a DeviceIoControl tramite P/Invoke
  # Per scopi di simulazione/test, simuliamo il trigger della telemetria
  $signature = @{
      SymbolicName = "x1cx1c??x1ceae971b87"
      IOControlHandler = "IRP_MJ_DEVICE_CONTROL"
      ShutdownHandler = "IRP_MJ_SHUTDOWN"
  }
  
  Write-Host "[+] Invio di IOCTL creato per attivare il rilevamento..."
  # Logica per simulare la generazione di eventi del kernel per il Nome Simbolico specifico
  # Questa parte è concettuale per l'agente BAS per attivare la specifica voce di log
  New-EventLog -LogName "Microsoft-Windows-Sysmon" -Source "Sysmon" # Simulazione di trigger

• Comandi di Pulizia:

  # Rimuovere eventuali file temporanei o artefatti del driver simulato
  Remove-Item -Path "$env:TEMProotkit_sim.tmp" -ErrorAction SilentlyContinue
  Write-Host "[+] Pulizia completata."