Sviluppo di Capacità Offensive: Develop Capabilities (T1587)

Per un red team, simulare la T1587 significa riprodurre in laboratorio il ciclo di sviluppo di capacità offensive senza appoggiarsi a payload pubblici già firmati dagli antivirus. L'obiettivo è testare la maturità difensiva contro strumenti mai visti prima.

Sul fronte malware e loader, l'ambiente naturale è un lab isolato con Sysinternals e macchine virtuali snapshot-abili. Per generare artefatti custom si usano framework di post-exploitation come Sliver (open source) o Mythic (open source), che permettono di compilare beacon con configurazioni uniche. Per la manipolazione degli artefatti di compilazione su Windows, la toolchain MinGW-w64 (open source) e MSVC consente di variare compilatore e flag, alterando così le firme statiche.

Per la generazione di certificati auto-firmati, elemento esplicitamente citato nella tecnica, la sintassi OpenSSL è diretta:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Su Windows lo stesso obiettivo si raggiunge in PowerShell con:

New-SelfSignedCertificate -Subject "CN=Test" -CertStoreLocation Cert:\CurrentUser\My

Uno scenario particolarmente attuale, ispirato ai gruppi mappati su questa tecnica, è la creazione di pacchetti npm malevoli. In laboratorio si può costruire un pacchetto con uno script postinstall che esegua codice al momento dell'installazione, pubblicandolo poi su un registry privato interno (mai su npm pubblico) per validare le difese della supply chain.

Sul versante spearphishing, replicare un mailing toolkit richiede la costruzione di template e infrastruttura di invio: strumenti come Gophish (open source) permettono di orchestrare campagne di simulazione controllate all'interno del programma di security awareness.

Una catena d'attacco realistica prosegue così: sviluppo del loader custom, firma con certificato auto-generato per superare i controlli di reputazione, incapsulamento in un pacchetto o allegato, consegna e attivazione del canale C2 tramite Sliver.

Per l'analisi e il fingerprinting dei propri artefatti — utile per capire cosa il blue team potrà osservare — sono validi DiE (Detect It Easy) (open source) per l'ispezione di header e compilatore, e CFF Explorer (gratuito) per esaminare la struttura PE. Ricordate che la fase di sviluppo è invisibile alla vittima: il valore del test emerge quando lo strumento entra in contatto con l'ambiente bersaglio.

Per un SOC, la difficoltà della T1587 è strutturale: lo sviluppo delle capacità avviene interamente fuori dal perimetro monitorabile. La rilevazione diretta è quindi impraticabile, e la strategia corretta è spostare l'attenzione sulle fasi in cui lo strumento sviluppato viene effettivamente impiegato — tipicamente Defense Evasion e Command and Control.

Il primo pilastro è il detonation e sandboxing dei payload sospetti. Analizzando un campione si estraggono dati contestuali preziosi: timestamp di compilazione, hash del file, watermark e informazioni di configurazione che tradiscono un pattern di sviluppo ricorrente. Una sandbox come Cuckoo (open source) o il tier gratuito di Any.Run (freemium) consente di osservare il comportamento a runtime e correlare campioni apparentemente diversi ma prodotti dalla stessa toolchain.

Un'area di detection concreta riguarda i certificati: monitorare l'uso di certificati auto-firmati o code-signing anomali su connessioni TLS uscenti aiuta a smascherare capacità sviluppate internamente. Sui log di rete e proxy conviene creare alert per certificati con catene di fiducia incomplete, validità sospetta o subject generici.

Data la rilevanza dei gruppi che sviluppano pacchetti npm malevoli, il SOC dovrebbe integrare la telemetria della supply chain: log di installazione dei package manager, esecuzione di script postinstall, e processi figli anomali generati da node o npm. Su endpoint, eventi di creazione processo (EventCode 4688 di Windows o Sysmon Event ID 1) che mostrano node.exe che lancia PowerShell o shell sono un forte indicatore.

Le log source più utili in questo contesto sono i repository malware interni e i dati di scansione Internet, cui si aggiungono feed di threat intelligence per correlare hash e configurazioni note ad attori specifici.

Sul fronte dei controlli preventivi — coerenti con la mitigazione Pre-compromise (M1056) — il SOC può contribuire monitorando la superficie esterna con piattaforme come Shodan (freemium) e Censys (freemium), e alimentando una piattaforma di threat intelligence come MISP (open source) per tracciare infrastrutture e strumenti avversari.

Attenzione ai falsi positivi: molti certificati auto-firmati sono legittimi in ambienti di sviluppo interni, e numerosi pacchetti npm con script postinstall sono benigni. La regola d'oro è correlare l'indicatore con il contesto — reputazione della sorgente, comportamento di rete successivo e coerenza con la baseline aziendale — prima di elevare la severità dell'alert.

Per l'analista forense, la T1587 lascia poche tracce sull'endpoint durante la fase di sviluppo, perché questa si consuma sull'infrastruttura dell'avversario. Il lavoro investigativo si concentra quindi su due fronti: le fonti esterne che documentano la capacità e gli artefatti residui che emergono quando lo strumento sviluppato viene eseguito nella vittima.

L'analisi principale è il malware analysis del campione recuperato. Da un binario PE si estraggono elementi che raccontano la storia dello sviluppo: il timestamp di compilazione nell'header, la stringa di versione del compilatore, i simboli di debug (percorso PDB) e watermark di configurazione. Strumenti come pefile (open source) in Python permettono di leggere l'header, mentre YARA (open source) consente di scrivere regole che catturano pattern di codice riconducibili a una stessa officina di sviluppo. Il comando tipico è:

yara -r regola.yar /percorso/campione

Correlare hash e caratteristiche su repository di campioni come VirusTotal (freemium) o MalwareBazaar (gratuito) aiuta a ricostruire la timeline evolutiva di una famiglia di malware, individuando varianti precedenti e identificando pattern di sviluppo nel tempo.

Per i certificati auto-firmati, l'artefatto forense è duplice: il certificato stesso nei magazzini di Windows (esaminabile con certutil -store) e le tracce nei log TLS o nei metadati del file firmato. Il campo subject, il seriale e la validità diventano pivot per collegare più intrusioni allo stesso attore.

Nel caso dei pacchetti npm malevoli, gli artefatti chiave sono nel filesystem: la cartella node_modules, il file package.json con lo script postinstall, e i log del package manager in ~/.npm/_logs su Linux e macOS. La timeline di creazione di questi file, incrociata con i log di esecuzione di node, colloca l'evento di installazione nella sequenza dell'intrusione.

Sul versante delle fonti esterne utili a ricostruire l'infrastruttura di supporto allo sviluppo, l'analista può interrogare i registri Certificate Transparency tramite servizi come crt.sh (gratuito) per individuare certificati correlati, e consultare dati di passive DNS e WHOIS storico per mappare i domini associati.

Dal punto di vista della catena di custodia, ogni campione va acquisito con hashing (sha256sum) e conservato in ambiente isolato. La ricostruzione della timeline combina i timestamp di compilazione (potenzialmente falsificati e da trattare con cautela), i tempi di creazione file sull'endpoint (MACB dai record MFT su Windows) e i dati di prima osservazione nei repository pubblici, per distinguere lo sviluppo dalla successiva distribuzione.

Dal punto di vista dell'intelligence, la T1587 è una lente sulla maturità operativa di un attore: chi sviluppa capacità in proprio dimostra risorse, competenze e intenzione di operare nel lungo periodo. I dati MITRE associano tre gruppi a questa tecnica, con un filo conduttore geografico e tattico evidente.

Kimsuky (G0094) ha creato e utilizzato un mailing toolkit dedicato agli attacchi di spearphishing. Questo dettaglio racconta un attore che non si limita a inviare email malevole, ma industrializza la fase di consegna costruendo strumentazione su misura per il phishing mirato, tipica di operazioni di raccolta informativa persistente.

Moonstone Sleet (G1036) ha sviluppato pacchetti npm malevoli destinati a essere consegnati alle vittime o recuperati da esse. Si tratta di un chiaro esempio di attacco alla supply chain del software, che sfrutta la fiducia degli sviluppatori negli ecosistemi open source per veicolare codice ostile.

Contagious Interview (G1052) ha adottato una strategia quasi identica, sviluppando anch'esso pacchetti NPM malevoli con la stessa logica di consegna e retrieval. La convergenza tra Moonstone Sleet e Contagious Interview è il pattern più significativo emerso dai dati: due attori distinti che investono nello stesso vettore — l'avvelenamento dei registry di pacchetti JavaScript — puntando in particolare sulla comunità degli sviluppatori come bersaglio.

Il tool overlap attorno all'ecosistema npm suggerisce una tendenza consolidata: la scelta di colpire pipeline di sviluppo e catene di dipendenze, dove un singolo pacchetto compromesso può propagarsi a valle verso numerose organizzazioni. Contagious Interview, come indica il nome stesso associato dai dati, orienta la propria ingegneria sociale verso contesti di reclutamento e colloquio, un aggancio che si sposa naturalmente con la distribuzione di pacchetti mascherati da test tecnici o librerie di progetto.

Il trend strategico che l'intelligence deve monitorare è quindi duplice. Da un lato la persistenza del toolkit di phishing come capacità sviluppata internamente, incarnata da Kimsuky. Dall'altro l'ascesa dello sviluppo di pacchetti malevoli come vettore preferenziale, condiviso da più attori. Per un team di threat intelligence, ciò implica prioritizzare il monitoraggio dei registry pubblici, la caccia a pattern di sviluppo ricorrenti nei campioni e la costruzione di profili basati su artefatti di compilazione, che permettono di attribuire nuove capacità a officine di sviluppo già note.

MITRE ATT&CK: tecnica T1587 (Develop Capabilities), tattica TA0042 (Resource Development). Gruppi: Kimsuky (G0094), Moonstone Sleet (G1036), Contagious Interview (G1052). Mitigazione: Pre-compromise (M1056). Detection: DET0853, analytic AN1985. Tool di detection e analisi citati: Cuckoo, YARA, pefile, MISP, Shodan, Censys, MalwareBazaar, VirusTotal. Parte del contenuto operativo (comandi, tool, artefatti forensi) deriva da conoscenza professionale di cybersecurity verificata su documentazione ufficiale.