Upload Tool: Upload Tool (T1608.002)

Trattandosi di una tecnica pre-compromise in Resource Development, l'obiettivo in un esercizio red team non è "bucare" un bersaglio ma predisporre in modo lab-safe l'infrastruttura di staging che ospiterà i tool da distribuire alla macchina vittima. Il principio replica i comportamenti osservati: Threat Group-3390 ha collocato gsecdump e WCE su siti web compromessi, mentre Medusa Group ha caricato un archivio ZIP contenente l'agente RMM ConnectWise su un servizio di file hosting.

In laboratorio conviene simulare più canali di staging isolati dalla produzione. Alcune opzioni realistiche:

• Un web server locale con python3 -m http.server 8000 (open source) per esporre i binari su HTTP e misurare la detection del successivo download.
• Un repository privato ospitato su una Gitea self-hosted (open source), che replica lo scenario del "repo GitHub controllato dall'avversario" senza toccare piattaforme pubbliche.
• Un bucket o container su un ambiente PaaS di test, per esercitare il rilevamento del traffico verso servizi cloud legittimi.

La catena d'attacco tipica prevede: staging del tool sul server, generazione dell'URL di download, e sul lato endpoint la fase di Ingress Tool Transfer. Su Windows il trasferimento si prova con

certutil.exe -urlcache -split -f tool.exe

oppure con PowerShell tramite Invoke-WebRequest -Uri -OutFile C:\Windows\Temp\tool.exe. Su Linux e macOS l'equivalente è curl -s -o /tmp/tool o wget . Su host ESXi, dove l'ambiente è minimale, si osserva l'uso di wget o scp verso il datastore per posizionare payload.

Per emulazione strutturata e ripetibile è utile:

• Atomic Red Team (open source), che include test mappati alle tecniche di trasferimento e staging.
• Caldo/Sliver (open source) come framework C2 per orchestrare il download dal server di staging in un range controllato.
• MinIO (open source) per simulare uno storage S3-compatibile self-hosted.

La regola d'oro del laboratorio è mai usare hosting pubblici reali (filemail, Dropbox, Pastebin) per payload offensivi, anche innocui: ogni artefatto va confinato in reti segmentate. Documentare hash, URL e timestamp di ogni tool caricato permette poi al team difensivo di validare le proprie regole di detection sul traffico di Ingress Tool Transfer.

La difficoltà operativa di questa tecnica è strutturale: il caricamento dello strumento avviene su infrastruttura esterna, fuori dalla telemetria aziendale. Come indicato dalla detection DET0834, la visibilità diretta è quasi nulla e lo sforzo di rilevamento va spostato sulle fasi post-compromise, in particolare sul momento in cui il tool viene scaricato nella rete vittima (Ingress Tool Transfer).

L'analitica AN1966 suggerisce un approccio esterno: se pattern di tooling o infrastrutture sono già stati identificati, la scansione Internet può rivelare quando un avversario ha messo in staging strumenti resi accessibili per il targeting. La log source primaria in questo caso è l'Internet Scan, cioè dati di scansione della superficie esposta piuttosto che log endpoint.

Sul lato interno il SOC deve costruire detection comportamentale sul download. Fonti di log utili:

• Proxy web e Secure Web Gateway, per intercettare richieste GET verso servizi di file hosting o repository sospetti.
• DNS query log, per identificare risoluzioni verso domini di staging come servizi di condivisione file.
• Sysmon su Windows, in particolare EventID 3 (Network Connection) e EventID 1 (Process Creation) su processi come certutil.exe, powershell.exe con Invoke-WebRequest, bitsadmin.exe.
• Log di EDR sui binari appena scritti su disco ed eseguiti da percorsi temporanei.

Gli indicatori concreti emergono dalle campagne note: traffico verso servizi di file hosting come quello utilizzato da Medusa Group per archivi ZIP contenenti RMM, o verso piattaforme cloud come Dropbox e Pastebin sfruttate negli attacchi wiper contro la Polonia del 2025. La presenza inattesa di agenti RMM come ConnectWise in ambienti che non li usano è un segnale forte di abuso di tool leciti.

I falsi positivi sono un rischio reale: file hosting, GitHub e servizi PaaS hanno un uso legittimo diffuso. Per ridurre il rumore conviene correlare il download con l'esecuzione immediata del binario, con la scrittura in directory anomale e con l'assenza di firma o reputazione del file.

Sul fronte preventivo, la mitigazione M1056 (Pre-compromise) raccomanda l'uso di threat intelligence — piattaforme come MISP, Recorded Future o Anomali — per tracciare infrastrutture e tool avversari, e monitoraggio esterno con Shodan o Censys per osservare la propria superficie d'attacco. Il controllo applicativo che blocca l'esecuzione di tool non autorizzati (application allowlisting) resta il freno più efficace a valle.

Per l'analista forense la sfida di T1608.002 è che l'evento primario — il caricamento del tool — non lascia tracce sugli endpoint della vittima, perché accade su infrastruttura esterna. La ricostruzione richiede quindi di combinare fonti esterne con gli artefatti che emergono solo dopo il contatto con l'infrastruttura malevola.

Sul versante esterno, la timeline si costruisce a partire da:

• WHOIS storico e passive DNS, per datare la registrazione e l'attività dei domini di staging.
• Certificate Transparency, ad esempio il database pubblico di crt.sh, per correlare certificati emessi sui server che ospitavano i tool.
• Analisi delle piattaforme di hosting note dalle campagne: il servizio di file hosting usato da Medusa Group, oppure Dropbox e Pastebin negli attacchi wiper polacchi del 2025.

Sul versante endpoint, gli artefatti utili compaiono nel momento in cui il binario viene scaricato ed eseguito. Su Windows l'analista si concentra su:

• I marker Zone.Identifier nei flussi ADS (Alternate Data Stream), che registrano la provenienza Internet del file scaricato.
• Artefatti di esecuzione come Prefetch, Amcache.hve e ShimCache, che datano la prima esecuzione di tool come gsecdump o WCE, coerenti con l'operato di Threat Group-3390.
• Il log BITS e i record di certutil nella cronologia di PowerShell (ConsoleHost_history.txt) per identificare il metodo di trasferimento.
• Cache del browser e cronologia dei download, quando lo scaricamento è avvenuto interattivamente.

Su Linux contano la history della shell, i timestamp MAC sul filesystem dei binari collocati in /tmp o /dev/shm, e i log di wget/curl eventualmente presenti in syslog. Nel caso di infrastrutture ESXi, i log del datastore e i comandi shell registrati aiutano a datare il posizionamento dei payload.

Le campagne documentate offrono riferimenti temporali per ancorare la timeline. Il C0010 condotto da UNC3890 (dicembre 2020 – agosto 2022) prevedeva lo staging di tool sull'infrastruttura dell'attaccante per il download diretto sul sistema compromesso. In Operation Dream Job (C0022, settembre 2019 – agosto 2020) Lazarus Group ha usato più server per ospitare strumenti malevoli. Negli attacchi wiper polacchi del 2025 (C0063) i tool erano distribuiti tramite GPO malevole dopo essere stati messi in staging su servizi cloud.

L'obiettivo finale è correlare hash dei binari recuperati con feed di intelligence, ricostruendo l'intera catena dal server di staging fino all'esecuzione sull'host.

Il quadro di intelligence su questa tecnica è compatto ma geograficamente eterogeneo, con due gruppi mappati e tre campagne che coprono un arco che va dal 2019 al 2025.

Threat Group-3390 (G0027) rappresenta il modello classico del riuso di tool leciti a scopo offensivo. Il gruppo ha collocato gsecdump e WCE — due dumper di credenziali dual-use — su siti web precedentemente compromessi, sfruttando la tattica del Compromise Infrastructure per ridurre l'attribuzione e abbattere i costi. La scelta di ospitare gli strumenti su infrastruttura di terze parti già violata è un tratto distintivo di attori maturi e resource-conscious.

Medusa Group (G1051) illustra invece la tendenza più recente all'abuso di servizi legittimi: il gruppo ha usato un servizio di file hosting per ospitare un archivio ZIP contenente un agente RMM come ConnectWise. L'impiego di software di remote monitoring and management legittimo è un pattern in forte crescita, perché consente persistenza e controllo remoto eludendo i controlli che cercano malware tradizionale.

Sul piano delle campagne emergono tre profili con matrici geopolitiche differenti:

• C0010 (2020–2022), attribuita a UNC3890, era un'operazione di cyber spionaggio contro obiettivi israeliani — shipping, governo, aviazione, energia, sanità — con connessioni tecniche a interessi iraniani, tra cui stringhe PDB e artefatti in lingua farsi. Gli attori mettevano in staging i tool sulla propria infrastruttura per il download diretto.
• C0022 – Operation Dream Job (2019–2020), probabilmente condotta da Lazarus Group, colpiva difesa, aerospazio e governo in Stati Uniti, Israele, Australia, Russia e India, usando più server per ospitare strumenti malevoli. È considerata un termine ombrello che include Operation Interception e Operation North Star.
• C0063 – 2025 Poland Wiper Attacks, campagna russa state-sponsored contro infrastrutture energetiche polacche, con oltre 30 impianti eolici e fotovoltaici colpiti. Gli attori hanno usato Dropbox e Pastebin per lo staging di tool e file, distribuendo i wiper DynoWiper e LazyWiper tramite GPO malevole. L'attività è ricondotta in parte a Dragonfly/STATIC TUNDRA (FSB) e in parte a ELECTRUM/Sandworm Team (GRU).

Il trend è chiaro: dallo staging su siti compromessi si è passati all'abuso sistematico di servizi cloud e file hosting legittimi, una scelta che complica il blocco perché confonde traffico malevolo e traffico ordinario.

MITRE ATT&CK: tecnica T1608.002 (Upload Tool), tattica TA0042. Gruppi G0027, G1051. Campagne C0010, C0022, C0063. Mitigazione M1056. Detection DET0834 e analitica AN1966. Per comandi, tool e artefatti forensi è stata integrata conoscenza professionale di cybersecurity verificabile (Atomic Red Team, Sysmon, MISP, Shodan, Censys, Gitea, MinIO).