Offerte di lavoro nascondono due sofisticate catene di attacco multi-stadio

Riepilogo

Due catene di attacco multi-stadio separate utilizzano ingegneria sociale a tema lavorativo per distribuire malware. La Campagna 1 si affida a un archivio ZIP per distribuire PureRAT tramite un loader basato su Python che utilizza il side-loading di DLL e diversi meccanismi di persistenza. La Campagna 2 consegna un file LNK che avvia mshta.exe, che recupera ed esegue un impianto personalizzato in memoria.

Indagine

L’indagine ha collegato la Campagna 1 a un cluster criminale connesso al Vietnam con sovrapposizioni infrastrutturali legate a una nota operazione PXA Stealer. La Campagna 2 sembrava essere una campagna personalizzata senza sovrapposizione pubblica identificata. Entrambe le catene di attacco utilizzano tecniche di evasione avanzate, inclusa la patch AMSI ed ETW, oltre al caricamento riflessivo del codice.

Mitigazione

I difensori dovrebbero monitorare i binari Microsoft firmati che caricano DLL non firmate da directory scrivibili dall’utente e rilevare mshta.exe esecuzioni che coinvolgono URL remoti. Il filtraggio di uscita per porte alte non standard e l’audit per la creazione di attività pianificate basate su COM possono aiutare a interrompere queste catene di infezione. Anche il rafforzamento del monitoraggio dell’integrità della memoria è importante.

Risposta

Se viene rilevata un’attività malevola, la bonifica dovrebbe tenere conto di molteplici meccanismi di persistenza, inclusi iscrizioni WMI e hijacking COM. La rimozione di un singolo file o attività pianificata potrebbe non eliminare completamente la Campagna 1 a causa del suo comportamento auto-riparante. Gli operatori devono esaminare le directory di staging e rimuovere in modo completo tutti gli artefatti di persistenza identificati.

Esecuzione Simulazione

• Narrazione & Comandi dell’Attacco: Un avversario ha ottenuto accesso iniziale e desidera eseguire un carico utile malevolo fingendosi una comune applicazione di produttività per evitare sospetti. L’attaccante copia il legittimo mshta.exe da System32 in una cartella locale e lo rinomina in WinWord.exe. Quindi posizionano una DLL malevola nella stessa cartella. Quando WinWord.exe (il MSHTA rinominato) viene eseguito, la telemetria del Caricamento Immagine del sistema registrerà un processo dove il Nome Immagine è WinWord.exe ma il NomeFileOriginale rimane mshta.exe. Questa discrepanza è il trigger specifico per la regola di rilevamento.

• Script di Test Regressivo:

  # Simulazione di Side-loading di DLL tramite Rinomina
  $workDir = "$env:TEMPSimulation_SideLoad"
  New-Item -ItemType Directory -Force -Path $workDir
  Set-Location $workDir
  
  # 1. Copia il binario legittimo
  Copy-Item "C:WindowsSystem32mshta.exe" -Destination "WinWord.exe"
  
  # 2. Crea una DLL fittizia/benigna per garantire che il processo possa effettivamente 'caricare' qualcosa 
  # (Nota: In un attacco reale, questa sarebbe la DLL malevola. 
  # Per attivare la telemetria, ci basta eseguire il binario rinominato.)
  
  # 3. Esegui il binario rinominato
  # Questo attiverà l'ID Evento Sysmon 7 per il caricamento dell'immagine del file rinominato
  Write-Host "[*] Esecuzione del binario rinominato per attivare il rilevamento..."
  Start-Process ".WinWord.exe" -ArgumentList "javascript:alert('Attack Triggered');close();" -Wait
  
  Write-Host "[+] Simulazione completata. Controlla SIEM per la discrepanza di Caricamento Immagine."

• Comandi di Pulizia:

  # Pulisci i file di simulazione
  $workDir = "$env:TEMPSimulation_SideLoad"
  if (Test-Path $workDir) {
      Remove-Item -Recurse -Force $workDir
      Write-Host "[+] Pulizia riuscita."
  } else {
      Write-Host "[-] Pulizia fallita: Directory non trovata."
  }