Compromissione di Account: Compromise Accounts (T1586)

Trattandosi di una tecnica pre-compromise (TA0042), l'obiettivo del red team non è violare account reali di terzi — pratica illegale e fuori scopo — ma simulare in laboratorio il ciclo di acquisizione e riuso di identità legittime in un ambiente controllato e autorizzato dalle regole d'ingaggio.

Il primo passo è la ricognizione delle superfici di identità esposte. Con theHarvester (open source) si enumerano email e profili collegati a un dominio bersaglio:

theHarvester -d azienda-target.local -b bing,linkedin

Per correlare persone, alias e account social si usa Recon-ng (open source) con i suoi moduli di profiling, oppure Maltego CE (freemium) per la visualizzazione dei grafi relazionali.

La verifica dell'esposizione da breach passata è il cuore della simulazione di credential compromise. In laboratorio si interroga il servizio Have I Been Pwned (freemium, con API a pagamento) per capire quali indirizzi risultano in dump noti, e si validano le ipotesi di password reuse contro account fittizi creati ad hoc. Per il test di riutilizzo credenziali su un'infrastruttura di lab si impiega Hydra (open source):

hydra -L utenti.txt -P dump-passwords.txt http-post-form

oppure CrackMapExec/NetExec (open source) per lo spray su domini Windows di test:

nxc smb -u utenti.txt -p 'Password123!'

Una volta "acquisito" l'account di laboratorio, la fase di sviluppo dell'identità replica ciò che fa l'avversario: arricchimento del profilo, invio di richieste di connessione verso account amici (sempre fittizi) e preparazione del pretesto. Il ponte verso l'operazione reale è GoPhish (open source) per orchestrare campagne di phishing controllate che partono dall'account compromesso simulato.

La catena logica da dimostrare al cliente è chiara: identità legittima ereditata → fiducia preesistente sfruttata → messaggio di phishing partito da un mittente credibile → Initial Access. Documentare questa sequenza serve a giustificare gli investimenti in MFA resistente al phishing, monitoraggio dei breach e formazione.

Ogni attività deve rispettare due paletti: nessun account reale di terzi va toccato e tutta l'infrastruttura di test (mailbox, credenziali, profili) deve essere creata e posseduta dal team. La simulazione ha valore solo se resta lab-safe e tracciabile.

La compromissione di account per il targeting avviene quasi interamente fuori dalla visibilità aziendale, quindi il SOC deve accettare un principio: qui non si intercetta l'acquisizione, ma le sue conseguenze osservabili. Gli artefatti digitali rilevanti sono essenzialmente due, come indicato nei log di riferimento: la Persona (l'identità online) e il Network Traffic generato quando l'account compromesso entra in azione.

Sul fronte persona, il monitoraggio va spostato verso l'esterno. Conviene sorvegliare l'attività sui social media legata al brand aziendale: profili che dichiarano di lavorare per l'organizzazione, account recentemente modificati che inviano numerose richieste di connessione a dipendenti, oppure identità note che cambiano improvvisamente comportamento. Piattaforme di Digital Risk Protection e OSINT monitoring come SpiderFoot (open source) o Recon-ng (open source) aiutano a intercettare questi segnali deboli.

Il segnale più concreto arriva però nelle fasi successive del ciclo d'attacco, in particolare durante Initial Access via Phishing. Qui il SOC lavora sui log che possiede davvero:

• Log del gateway email e delle protezioni come Microsoft Defender for Office 365, Proofpoint o Mimecast, per messaggi che provengono da mittenti legittimi ma con contenuti anomali.
• Log di autenticazione (Azure AD Sign-in, Windows EventCode 4624/4625, VPN) per accessi da account validi ma con geolocalizzazione, ASN o pattern orari incoerenti — il classico impossible travel.
• Network traffic: analisi dei flussi per protocolli che deviano dagli standard attesi, pacchetti estranei ai flussi consolidati, sintassi o strutture anomale. La correlazione con il monitoraggio dei processi e delle command line aiuta a individuare processi che normalmente non aprono connessioni per un dato protocollo.

Sul versante preventivo (harden), M1056 suggerisce di irrobustire proprio ciò che rende un account compromesso utile: applicare SPF, DKIM e DMARC per contrastare lo spoofing, imporre MFA resistente al phishing, forzare reset su password comparse in breach e monitorare domini lookalike con servizi come DomainTools.

Sui falsi positivi serve prudenza: un dipendente in viaggio, un tool SaaS che si autentica da IP cloud, o campagne marketing legittime dai profili aziendali possono innescare alert. La discriminante è la correlazione tra anomalia dell'identità e comportamento successivo (nuove regole di inoltro mailbox, invio massivo, accessi a repository sensibili). Senza questa correlazione, il singolo indicatore raramente basta a confermare l'abuso di un account legittimo.

L'analisi forense di T1586 si scontra con un limite strutturale: la compromissione dell'account avviene su infrastrutture di terzi (provider email, social network) sulle quali l'analista non ha giurisdizione né accesso ai log nativi. Di conseguenza l'indagine si articola su due binari: fonti esterne per ricostruire la storia dell'identità e artefatti endpoint che emergono solo dopo il contatto con l'account malevolo.

Sul piano esterno, quando l'account compromesso è collegato a domini o infrastrutture, gli strumenti classici sono il WHOIS storico, il passive DNS e i Certificate Transparency logs (consultabili tramite il database crt.sh). Questi permettono di datare cambi di registrazione, correlare alias e ricostruire quando un'identità legittima ha iniziato a comportarsi in modo anomalo. Per gli account social, la timeline utile si costruisce raccogliendo evidenze pubbliche: data di modifica del profilo, ondate di nuove connessioni, cambi di foto o descrizione — tutti indicatori che l'artefatto Persona è stato "sviluppato" dall'avversario dopo la presa di controllo.

Gli artefatti endpoint diventano rilevanti nel momento in cui l'account compromesso viene usato contro la vittima. Se l'abuso passa da una mailbox aziendale, in ambiente Microsoft 365 il Unified Audit Log conserva eventi preziosi: creazione di regole di inoltro occulte, accessi da nuovi client, invii massivi. Con PowerShell e il modulo Exchange Online si estraggono le regole sospette:

Get-InboxRule -Mailbox | Format-List Name,ForwardTo,DeleteMessage

Su endpoint Windows, se il phishing partito dall'account fidato ha prodotto un allegato o un link cliccato, la timeline si ricostruisce con Autopsy (open source) o la Plaso/log2timeline suite (open source), incrociando artefatti come cronologia browser, cache, EventCode 4624 per i logon e le entry di esecuzione. Per la memoria, Volatility 3 (open source) aiuta a individuare processi figli anomali generati dopo l'apertura del messaggio.

Nell'analisi email il campione va esaminato con attenzione agli header: mittente legittimo, allineamento SPF/DKIM/DMARC, catena Received. Un messaggio proveniente da un account realmente compromesso spesso supera i controlli di autenticazione proprio perché parte da un'infrastruttura genuina, il che lo distingue dallo spoofing e ne aumenta la pericolosità.

Il consiglio pratico è non forzare la ricerca di artefatti sull'atto di compromissione — che resta invisibile all'organizzazione — ma concentrare la timeline sul primo contatto documentabile: il messaggio ricevuto, l'accesso anomalo, la regola creata.

I dati MITRE per T1586 – Compromise Accounts non associano alcun gruppo APT, software o campagna specifica alla tecnica. Questa assenza non va letta come irrilevanza, ma come conseguenza diretta della natura pre-compromise dell'attività: l'acquisizione di account legittimi avviene in ambienti opachi (marketplace di credenziali, breach dump, ingegneria sociale mirata) dove l'attribuzione formale è estremamente difficile e raramente confermabile con evidenze tecniche solide.

Per un Threat Intelligence Officer, il valore operativo sta quindi nel modello di comportamento più che nel profilo del singolo attore. Il pattern ricorrente è la preferenza per identità con storico credibile: account email di dipendenti, profili LinkedIn di figure senior, utenze di fornitori nella supply chain. La logica è economica e strategica — ereditare fiducia costa meno che costruirla, e un account con relazioni preesistenti aumenta drasticamente il tasso di successo del phishing successivo.

Sul piano dei pattern di sourcing, l'intelligence deve tracciare tre serbatoi principali: i breach dump riutilizzati per credential stuffing (favoriti dal password reuse), i marketplace dove le credenziali vengono vendute, e l'insider threat monetizzato, ovvero dipendenti o partner pagati per cedere accessi. Il monitoraggio di questi ecosistemi si appoggia a piattaforme di threat intelligence come MISP (open source), Recorded Future (a pagamento) o Anomali (a pagamento), utili per correlare la comparsa di credenziali aziendali in dataset criminali con successive anomalie di accesso.

Il trend più rilevante da comunicare al CISO è lo spostamento del baricentro dall'account creation verso l'account takeover di identità reali, spinto dalla crescente disponibilità di credenziali trapelate e dalla maturità dei mercati che le rivendono. Questo rende la difesa reattiva insufficiente: l'organizzazione può essere colpita tramite un account di un partner mai direttamente compromesso.

L'azione di intelligence più concreta è il collegamento tra fasi: poiché T1586 alimenta Initial Access, ogni indicatore di credenziali aziendali esposte va trattato come precursore di una possibile campagna di phishing da mittente fidato. Integrare il monitoraggio dei breach con la sorveglianza dei domini lookalike (tramite servizi come DomainTools) e con l'analisi delle persone sui social costruisce un quadro predittivo, unico approccio efficace contro una tecnica che, per definizione, matura fuori dal perimetro difeso.

MITRE ATT&CK: tecnica T1586 (Compromise Accounts), tattica TA0042, mitigazione M1056 (Pre-compromise), detection DET0876 e analytic AN2008. Nessun gruppo, software o campagna associato nei dati forniti. Tool di detection e OSINT citati: SpiderFoot, Recon-ng, theHarvester, Maltego CE, Have I Been Pwned, Hydra, NetExec, GoPhish, Autopsy, Plaso, Volatility 3. Parte dei comandi operativi, degli artefatti forensi e delle procedure deriva da conoscenza professionale di cybersecurity, verificata rispetto a tool reali e documentati.