Manipolazione dei Trust di Dominio: Trust Modification (T1484.002)

La simulazione di Trust Modification in un red team engagement richiede accesso pre-esistente a un principal con privilegi elevati: Global Administrator o Application Administrator in Entra ID, oppure membership in Enterprise Admins per AD on-premise. Il valore dell'esercizio sta nel dimostrare quanto sia difficile distinguere le modifiche legittime da quelle malevole.

Sul fronte Active Directory on-premise, l'enumerazione dei trust esistenti si effettua con strumenti nativi. nltest /domain_trusts /all_trusts elenca le relazioni configurate, mentre Get-ADTrust -Filter * in PowerShell (modulo ActiveDirectory, incluso in RSAT) restituisce gli attributi rilevanti come trustDirection, trustType e trustAttributes. La creazione di un nuovo trust avviene tramite netdom trust con le opzioni di aggiunta, ma in laboratorio è più istruttivo modificare gli attributi di un trust esistente per osservare come si propagano nelle repliche.

Per scenari cloud, il tool di riferimento è AADInternals (S0677, open source), PowerShell module di Nestori Syynimaa disponibile su GitHub. Consente di convertire un dominio managed in federated tramite il cmdlet ConvertTo-AADIntBackdoor, iniettando un certificato di firma controllato dal red team. Il risultato è un backdoor che permette di autenticarsi come qualsiasi utente del tenant senza toccare le loro credenziali. AADInternals espone anche funzioni per manipolare le informazioni DesktopSSO, utili a simulare scenari di identity federation avanzati.

Su AWS l'equivalente operativo è la creazione di un identity provider malevolo tramite AWS CLI (open source): il comando aws iam create-saml-provider con un metadata document controllato dall'attaccante, oppure aws iam create-open-id-connect-provider per federazioni OIDC. Una volta creato il provider a livello di Organization, il red team può federarsi in tutti gli account membri assumendo ruoli con trust policy permissive.

Per Okta e altri IdP SaaS, la simulazione richiede l'uso delle API amministrative (documentate ufficialmente) per aggiungere un IdP secondario e attivare l'automatic account linking, replicando il modus operandi osservato per Scattered Spider (G1015).

Regola d'ingaggio fondamentale: queste modifiche devono essere eseguite solo in tenant di laboratorio dedicati o con esplicita autorizzazione scritta, e ogni artefatto (certificati, IdP, trust) va rimosso al termine dell'esercizio con procedura documentata e verificata.

La detection di Trust Modification si basa su due domini di telemetria distinti ma complementari: eventi Active Directory on-premise ed eventi di audit dei tenant cloud. La rarità di queste operazioni in ambienti stabili è il principale alleato del SOC: un trust legittimo si crea forse una o due volte l'anno, mentre una modifica non pianificata deve generare un incident ad alta priorità.

Per Active Directory, le fonti primarie sono WinEventLog:Security e WinEventLog:Sysmon sui domain controller. Gli EventID chiave riguardano la creazione e modifica di oggetti trustedDomain e foreignSecurityPrincipal nei container di trust. La detection deve monitorare specificamente gli attributi trustPartner, trustDirection, trustType e msDS-TrustForestTrustInfo: qualsiasi variazione di questi valori merita ispezione. Va inoltre correlato l'uso di utility come netdom.exe, nltest.exe o cmdlet PowerShell del modulo ActiveDirectory con account che normalmente non svolgono attività di trust management. Un pattern ricorrente negli attacchi reali è l'assegnazione di SeEnableDelegationPrivilege subito prima della modifica del trust, spesso accompagnata da injection di certificati.

Per gli ambienti Microsoft 365 ed Entra ID, le sorgenti sono m365:unified (Unified Audit Log) e azure:signinlogs. Le operazioni da flaggare sono Set domain authentication, Add federated identity provider e cmdlet legacy come Update-MsolFederatedDomain. La transizione di un dominio da Managed a Federated è un evento estremamente sensibile e deve produrre alert immediati indipendentemente dall'identità dell'esecutore. Nel campo InitiatedBy vanno segnalati service principal sconosciuti, token con user agent anomali o interazioni via API in orari non lavorativi. Un pattern osservato è la correlazione temporale ravvicinata tra una trust modification e login federati o SAML token injection provenienti da IP mai visti prima.

Sul fronte AWS, CloudTrail espone le chiamate CreateSAMLProvider e CreateOpenIDConnectProvider: entrambe rare e ad alto valore. In ottica D3FEND, le tecniche difensive di riferimento sono User Account Permissions (D3-UAP) e Authentication Event Thresholding (D3-AET) per rilevare comportamenti amministrativi anomali.

I falsi positivi principali derivano da attività di merge aziendali, migrazioni di tenant o onboarding di nuovi partner federati: per gestirli, è essenziale mantenere un change advisory board che pre-autorizzi queste operazioni e permetta al SOC di correlare gli alert con ticket approvati. Le playbook di risposta devono prevedere la revoca immediata del trust sospetto, la rotazione dei certificati SAML e la revisione di tutti i sign-in avvenuti dopo la modifica.

L'analisi forense di un incidente Trust Modification richiede la ricostruzione di due timeline parallele: quella delle modifiche di configurazione (chi ha cambiato cosa e quando) e quella dell'uso abusivo del trust (quali autenticazioni sono state effettuate sfruttandolo). La difficoltà principale è che, una volta stabilito il trust malevolo, le autenticazioni successive appaiono perfettamente legittime.

Su Active Directory, gli artefatti primari risiedono nel database NTDS.dit e nei log di sicurezza dei domain controller. La replica AD conserva metadati di modifica accessibili tramite repadmin /showobjmeta sugli oggetti trust, che espongono il timestamp e il DC originario della modifica. L'analisi degli attributi whenChanged e uSNChanged dei trustedDomain object permette di stabilire l'istante preciso dell'alterazione. Vanno inoltre esaminati i log Security con EventID 4662 (accesso a oggetti directory) filtrando per GUID delle classi trust, e EventID 4670/5136 per modifiche di permessi e attributi. La presenza di SeEnableDelegationPrivilege assegnato a utenti non standard è un indicatore forte.

Per ambienti Entra ID e Microsoft 365, l'Unified Audit Log conserva 90-180 giorni di eventi (a seconda della licenza). Le operazioni Set-MsolDomainFederationSettings, Add-MsolFederatedDomain e le loro equivalenti Graph API sono i record da estrarre prioritariamente. Ogni evento contiene InitiatedBy (utente o service principal), ClientIP, UserAgent e i valori pre/post della configurazione — inclusi i thumbprint dei certificati SAML, elemento cruciale per identificare certificati controllati dall'attaccante.

La timeline tipica di un incidente segue questo schema: compromissione iniziale di un account privilegiato, escalation a Global Admin o Domain Admin, modifica del trust o aggiunta dell'IdP, seguita da autenticazioni federate provenienti da infrastruttura attaccante. Nel caso SolarWinds Compromise (C0024), APT29 ha modificato le impostazioni di federazione con permessi amministrativi Azure AD per accettare token firmati con proprio certificato SAML, mentre Storm-0501 (G1053) ha creato un nuovo dominio federato nel tenant Entra vittima come backdoor persistente. Scattered Spider (G1015) ha invece aggiunto un IdP federato al tenant SSO attivando l'account linking automatico.

L'analisi dei sign-in log deve identificare autenticazioni con claim insoliti, ClientIP appartenenti a range associati agli attaccanti e sessioni prolungate di account amministrativi. Su AWS, CloudTrail conserva gli eventi CreateSAMLProvider e la successiva AssumeRoleWithSAML che rivela quali ruoli sono stati assunti tramite il provider malevolo. La conservazione dei metadata document XML degli IdP è essenziale per l'attribuzione: contengono i certificati X.509 usati per firmare le asserzioni, comparabili con IOC pubblicati dalla threat intelligence.

Trust Modification è una tecnica ad alto valore strategico, adottata da attori con obiettivi di persistenza a lungo termine e accesso trasversale a ecosistemi cloud complessi. La barriera d'ingresso è alta — richiede privilegi amministrativi pre-esistenti e conoscenza approfondita di identity provider — ma il payoff è enorme, motivo per cui è appannaggio di gruppi state-sponsored e criminali sofisticati.

APT29 (attribuito dalla comunità di intelligence al servizio SVR russo) rappresenta il caso di studio più documentato. Durante la SolarWinds Compromise (C0024, agosto 2019 – gennaio 2021), il gruppo ha combinato compromissione della supply chain di SolarWinds Orion con manipolazione dei trust federativi Azure AD. Dopo aver ottenuto privilegi amministrativi tramite token theft e password spraying, APT29 ha configurato i domini vittima per accettare token SAML firmati con certificati controllati dagli attaccanti — tecnica poi soprannominata Golden SAML dalla comunità. L'operazione ha colpito organizzazioni governative, tecnologiche e di consulenza in Nord America, Europa, Asia e Medio Oriente. L'attribuzione ufficiale è arrivata nell'aprile 2021 da parte dei governi USA e UK.

Storm-0501 (G1053) rappresenta l'evoluzione ransomware-oriented della tecnica: il gruppo, attivo contro settori enterprise, ha creato nuovi domini federati all'interno dei tenant Microsoft Entra delle vittime sfruttando account Global Administrator compromessi. L'obiettivo è stabilire un backdoor persistente che sopravviva alla rotazione delle credenziali e ai reset di password, garantendo la capacità di rientrare nell'ambiente per l'eventuale detonazione del ransomware o per operazioni di doppia estorsione.

Scattered Spider (G1015), noto anche come UNC3944 nella tassonomia di altri vendor, ha dimostrato un approccio differente e più agile: aggiunge un identity provider federato al tenant SSO della vittima e attiva l'automatic account linking. Questo permette di collegare identità controllate dall'attaccante ad account legittimi senza necessità di rubarne le credenziali. Il gruppo è noto per l'uso intensivo di social engineering telefonico verso helpdesk IT per ottenere l'accesso iniziale, spesso rivolto a settori telco, hospitality e servizi finanziari nordamericani.

Il tool AADInternals (S0677) ha democratizzato molte di queste tecniche: nato come strumento di ricerca, è ora osservato in campagne reali. La sua funzione ConvertTo-AADIntBackdoor replica esattamente la tecnica Golden SAML resa celebre da APT29.

Il trend osservato è una progressiva estensione da AD on-premise verso identity provider cloud (Entra ID, Okta, AWS IAM Identity Center), con attori che investono in conoscenza specifica dei protocolli SAML e OIDC. La convergenza tra operazioni state-sponsored e criminali finanziariamente motivati sull'abuso di trust rappresenta uno degli sviluppi più significativi degli ultimi anni.

MITRE ATT&CK T1484.002 (Trust Modification), tattiche TA0004 e TA0005. Gruppi G1015 (Scattered Spider), G1053 (Storm-0501). Software S0677 (AADInternals). Campagna C0024 (SolarWinds Compromise). Mitigazioni M1018, M1026. Detection DET0458 (AN1259, AN1260). Framework MITRE D3FEND per mapping controlli difensivi. Parti operative su comandi AD, AWS CLI, PowerShell e artefatti forensi derivano da conoscenza professionale di cybersecurity verificabile tramite documentazione ufficiale Microsoft, AWS e repository open source dei tool citati.