Scoperta delle Relazioni di Trust: Domain Trust Discovery (T1482)

Il bello di questa tecnica è che non servono privilege escalation o tool esoterici: quasi tutto si fa con utility native di Windows, il che la rende perfetta per testare la maturità difensiva del SOC.

Il punto di partenza classico è Nltest (open source, nativo Windows), lo stesso strumento usato da gruppi come FIN8, Chimera e Magic Hound. Da un prompt con credenziali di dominio:

nltest /domain_trusts /all_trusts

Questo comando restituisce tutti i trust, inclusi quelli non transitivi e cross-forest. Per un output più granulare, focalizzato sui domain controller:

nltest /dclist:<nome_dominio>

Se vuoi simulare l'approccio di Akira o dell'operazione SolarWinds Compromise, affianca Nltest con AdFind (gratuito), un tool a riga di comando per query LDAP su Active Directory. La sintassi per estrarre gli oggetti trust è:

AdFind -f "(objectClass=trustedDomain)" -dn

Per chi preferisce restare nel mondo PowerShell — approccio usato da APT29 durante la SolarWinds Compromise — il modulo Active Directory offre il cmdlet nativo:

*Get-ADTrust -Filter **

In alternativa, PowerSploit (open source) fornisce funzioni più granulari dal modulo PowerView:

Get-NetDomainTrust Get-NetForestTrust

Questi comandi mappano trust a livello di dominio e di foresta rispettivamente, restituendo direzione, tipo e transitività.

Per una visione grafica e relazionale, BloodHound (open source) resta lo standard de facto. Dopo aver raccolto i dati con il collector SharpHound, la sezione "Domain Trusts" nel grafo mostra visivamente ogni relazione di fiducia e i percorsi di attacco derivanti. Rubeus (open source) può poi validare operativamente la sfruttabilità dei trust tramite richieste Kerberos cross-domain.

Sul versante dei framework C2, sia Empire (open source) che PoshC2 (open source) includono moduli dedicati all'enumerazione dei trust. Brute Ratel C4 (a pagamento) combina query LDAP e invocazioni di Nltest nella stessa catena operativa.

Un approccio LDAP puro, utile quando i tool non sono disponibili, sfrutta dsquery (nativo Windows):

*dsquery * -filter "(objectClass=trustedDomain)" -attr **

Durante l'esercizio, documenta ogni trust scoperto con direzione e tipo: il report finale dovrebbe evidenziare quali trust sono eccessivi o non più necessari, offrendo al blue team un deliverable concreto per la riduzione della superficie d'attacco.

La sfida principale nel rilevare questa tecnica è la sua legittimità apparente: Nltest e le query LDAP sui trust sono operazioni che anche gli amministratori di dominio eseguono quotidianamente. La differenza sta nel contesto.

Le log source primarie sono tre: Sysmon (EventLog Sysmon), PowerShell Script Block Logging (EventLog PowerShell) e il Security Event Log di Windows. La detection analytic DET0007 si focalizza proprio su questa triade per intercettare enumerazioni via API, script e CLI.

La prima regola da implementare monitora le esecuzioni di nltest.exe con argomenti sospetti. In Sysmon, cerca eventi con EventCode 1 (Process Create) dove il campo CommandLine contiene stringhe come /domain_trusts, /all_trusts o /trusted_domains. Il tuning è fondamentale: crea una whitelist basata su ParentImage per escludere le invocazioni da script di gestione legittimi e da account amministrativi noti.

Per la componente PowerShell, abilita il Script Block Logging (EventID 4104) e cerca pattern come Get-ADTrust, Get-NetDomainTrust, Get-NetForestTrust o GetAllTrustRelationships. La presenza di questi cmdlet in script eseguiti da utenti non amministratori è un segnale forte.

Il vero salto di qualità nella detection viene dalla correlazione temporale. L'enumerazione dei trust, isolata, è rumore; l'enumerazione dei trust seguita da attività Kerberos anomala (richieste TGS cross-domain, EventCode 4769 con nomi di servizio inusuali) o da connessioni verso domain controller di domini diversi entro una finestra di 15-30 minuti è un indicatore composito ad alta fedeltà. Questo approccio correla la fase Discovery con il successivo Lateral Movement.

Monitora anche le query LDAP verso oggetti trustedDomain: nei log del domain controller, gli eventi EventCode 4662 con accesso a oggetti di classe trust possono rivelare enumerazioni via API DSEnumerateDomainTrusts() o via tool come AdFind. Presta attenzione al contesto utente: un account di servizio o un utente standard che interroga i trust merita un'indagine immediata.

Per i falsi positivi — inevitabili — il tuning suggerito dalla detection analytic raccomanda di prioritizzare gli alert per account non amministrativi e di flaggare le chiamate API a bassa prevalenza come DSEnumerateDomainTrusts, che un amministratore legittimo invoca raramente direttamente.

L'enumerazione dei trust lascia tracce distribuite su più artefatti, e ricostruire la sequenza richiede di incrociare fonti endpoint con log di Active Directory.

Il primo artefatto da cercare è il Prefetch di nltest.exe. Il file NLTEST.EXE-XXXXXXXX.pf nella directory C:\Windows\Prefetch documenta l'ultima esecuzione e le ultime otto esecuzioni dell'utility. La sola presenza di un Prefetch per Nltest su un workstation non amministrativa è anomala e merita approfondimento. Estrai i timestamp con tool come PECmd (open source, di Eric Zimmerman) per posizionare l'evento nella timeline.

Lo ShimCache (AppCompatCache) nel registro di sistema offre un'ulteriore conferma: la chiave HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache registra i binari eseguiti, incluso nltest.exe. Anche AmCache (C:\Windows\appcompat\Programs\Amcache.hve) può confermare l'esecuzione e fornire l'hash SHA1 del binario, utile per verificare che non si tratti di un Nltest trojanizzato.

Per ricostruire i parametri esatti usati, i log Sysmon EventCode 1 sono la fonte primaria. Se Sysmon non era installato, controlla il Security Event Log per EventCode 4688 (Process Creation) — a patto che l'audit della command line fosse abilitato. In campagne come C0015, il comando registrato era esattamente nltest /domain_trusts /all_trusts; nella campagna SolarWinds Compromise (C0024), APT29 ha usato sia il cmdlet Get-AcceptedDomain via Exchange Management Shell sia AdFind per enumerare trust federati.

Sul domain controller, cerca gli eventi EventCode 4662 che documentano accessi agli oggetti trustedDomain in Active Directory. Correla il SID dell'account richiedente con la timeline endpoint per costruire una catena completa: esecuzione tool → query LDAP → risposta con trust mapping.

Se l'attaccante ha usato BloodHound, cerca artefatti del collector SharpHound: file JSON o ZIP con naming pattern riconoscibile nelle directory temporanee dell'utente, e connessioni LDAP massive verso la porta 389/636 del domain controller in un breve arco temporale. Nella campagna Leviathan Australian Intrusions (C0049), l'enumerazione Active Directory è stata parte di una più ampia fase di discovery che ha preceduto l'esfiltrazione di credenziali.

Infine, correla gli artefatti di trust discovery con quelli delle tecniche successive: ticket Kerberos anomali nei log EventCode 4769, accessi cross-domain in EventCode 4624 con LogonType 3, e artefatti di lateral movement verso i domini scoperti.

L'enumerazione dei trust Active Directory è un denominatore comune trasversale a gruppi con motivazioni, geografie e livelli di sofisticazione radicalmente diversi. Questo la rende un punto di osservazione privilegiato per comprendere pattern operativi ricorrenti.

FIN8 è un gruppo a motivazione finanziaria che utilizza il comando nltest.exe /domain_trusts come parte di una catena operativa che include il malware BADHATCH, il quale esegue autonomamente lo stesso comando. La convergenza tra operatore umano e malware automatizzato sullo stesso tool nativo segnala una dottrina operativa matura: FIN8 codifica le proprie procedure manuali direttamente nei payload. BADHATCH esegue la discovery come routine post-infezione, riducendo il tempo tra compromissione iniziale e movimento laterale.

Akira (G1024) combina Nltest con AdFind, un pattern che condivide con la campagna SolarWinds Compromise (C0024) di APT29. Questo overlap di tooling tra un gruppo ransomware e un APT statale russo è significativo: non indica necessariamente collaborazione, ma piuttosto la convergenza su un toolkit di enumerazione AD che rappresenta lo standard operativo de facto. Chi monitora l'uso congiunto di Nltest e AdFind nello stesso ambiente dovrebbe considerare entrambi i profili di minaccia.

Chimera (G0114) e Magic Hound (G0059) rappresentano il versante asia-pacifico e mediorientale della minaccia. Chimera usa il comando nltest /domain_trusts in modo diretto, mentre Magic Hound lo invoca tramite web shell con la variante /trusted_domains — un dettaglio che tradisce un approccio più opportunistico, dove l'enumerazione avviene da un punto d'accesso web già stabilito piuttosto che da un endpoint compromesso.

Earth Lusca (G1006) e Lotus Blossom (G0030) completano il quadro asiatico. Earth Lusca usa Nltest specificamente per ottenere informazioni sui domain controller, suggerendo che il trust discovery è funzionale a un targeting preciso dell'infrastruttura AD piuttosto che a una ricognizione generica. Lotus Blossom si affida ad AdFind per le query Active Directory.

Storm-0501 (G1053) e BlackByte (G1043) operano nel panorama ransomware, dove la velocità di enumerazione dell'ambiente è critica per massimizzare l'impatto prima della detection. Storm-0501 usa Nltest nativo, mentre BlackByte enumera trust e informazioni Active Directory come fase sistematica delle operazioni. La campagna C0015, attribuita a operatori non identificati che hanno seguito il playbook Conti, conferma che nltest /domain_trusts /all_trusts è il comando canonico nel ransomware ecosystem.

Il trend dominante è chiaro: Nltest è il tool universale per questa tecnica, adottato dalla maggioranza dei gruppi indipendentemente da sofisticazione e motivazione. AdFind rappresenta la seconda scelta, spesso usato in combinazione. Per il threat intelligence, questo significa che il monitoraggio dell'uso anomalo di questi due binari copre la quasi totalità dei threat actor che praticano domain trust discovery.

Framework MITRE ATT&CK v16 — T1482 (Domain Trust Discovery), TA0007 (Discovery). Campagne: C0049 (Leviathan Australian Intrusions), C0024 (SolarWinds Compromise), C0015. Mitigazioni: M1047 (Audit), M1030 (Network Segmentation). Detection: DET0007, AN0016. Integrato con conoscenza professionale per tool e procedure operative.