Manipolazione delle Trust: Trust Modification (T1484.002)

Il cuore della simulazione ruota attorno ad AADInternals (open source), il modulo PowerShell creato dal Dr. Nestori Syynimaa che espone le API interne di Microsoft Entra ID (ex Azure AD). In un laboratorio controllato, il primo passo è installarlo e autenticarsi con credenziali Global Admin del tenant di test:

Install-Module AADInternals -Scope CurrentUser Import-Module AADInternals Get-AADIntAccessTokenForAADGraph -SaveToCache

A questo punto si può convertire un dominio gestito in dominio federato, iniettando un certificato di firma SAML sotto il proprio controllo:

ConvertTo-AADIntBackdoor -DomainName lab.contoso.com

Questo singolo comando configura il dominio come federato e imposta un certificato di firma noto, permettendo poi di generare token SAML per qualsiasi UPN del tenant con:

Open-AADIntOffice365Portal -ByPassMFA $true -ImmutableID -Issuer

Per l'ambiente Active Directory on-premise, la catena è diversa. Si parte dall'enumerazione delle trust esistenti con:

nltest /domain_trusts /all_trusts /v

Oppure, tramite PowerShell con il modulo Active Directory (incluso in RSAT):

Get-ADTrust -Filter *

Per creare una nuova trust bidirezionale in laboratorio si usa netdom:

netdom trust child.lab.local /domain:attacker.local /add /twoway /password:TrustP@ss1

Sul versante AWS, la simulazione prevede l'uso della CLI per creare un SAML provider con un metadata XML contenente il proprio certificato:

aws iam create-saml-provider --saml-metadata-document file://evil-metadata.xml --name EvilIdP

Seguito dalla creazione di un ruolo che accetti asserzioni da quel provider, con la trust policy opportunamente configurata. Ogni federazione può poi essere sfruttata con aws sts assume-role-with-saml per ottenere credenziali temporanee.

In fase di reporting, il red team deve documentare ogni modifica alle trust con screenshot del "prima e dopo", i GUID degli oggetti modificati e i timestamp precisi. La remediation deve essere rapida: la permanenza di una trust malevola anche per poche ore può tradursi in data exfiltration massiva.

La detection di questa tecnica richiede visibilità su due piani distinti: l'infrastruttura Active Directory on-premise e il tenant cloud. Partiamo dal primo.

In ambiente Windows, le modifiche agli oggetti trust AD generano eventi nei log Security. L'EventCode 4706 segnala la creazione di una nuova trust, mentre l'EventCode 4707 ne indica la rimozione. Ancora più granulare è l'EventCode 4662, che registra operazioni su oggetti directory — filtrando per ObjectType trustedDomain e foreignSecurityPrincipal nei trust container, si intercettano modifiche ad attributi critici come trustPartner, trustDirection, trustType e msDS-TrustForestTrustInfo. Con Sysmon attivo, la process creation (EventCode 1) cattura l'uso di netdom.exe e nltest.exe con argomenti legati alle trust.

Una regola di correlazione efficace associa la modifica della trust a logon anomali entro una finestra temporale breve — ad esempio 30 minuti. Se un account raramente usato crea una trust e subito dopo compaiono autenticazioni Kerberos cross-realm insolite, la probabilità di attacco è elevata.

Sul piano cloud, i log di Microsoft 365 Unified Audit e gli Azure Sign-in Logs sono la fonte primaria. Le operazioni da monitorare con priorità critica sono:

• Set domain authentication — conversione da Managed a Federated
• Add federated identity provider — inserimento di un nuovo IdP nel tenant
• Invocazioni PowerShell come Update-MsolFederatedDomain o Set-MsolDomainAuthentication
• CreateSAMLProvider e CreateOpenIDConnectProvider in AWS CloudTrail

Il tuning è essenziale per contenere i falsi positivi. Le trust AD in ambienti enterprise cambiano raramente: qualsiasi modifica dovrebbe generare un alert ad alta severità. Per il cloud, separare le modifiche effettuate via GUI del portale da quelle via API o script (analizzando il campo UserAgent) aiuta a isolare le azioni automatizzate sospette. Correlare l'identità dell'iniziatore (InitiatedBy) con una whitelist di amministratori autorizzati riduce ulteriormente il rumore.

Come hardening preventivo, le Service Control Policy (SCP) di AWS Organizations possono bloccare esplicitamente le API di creazione IdP per tutti gli account tranne quello di gestione, trasformando un controllo detective in uno preventivo.

L'analisi forense di una Trust Modification richiede la ricostruzione precisa della catena: chi ha ottenuto i privilegi, quando ha modificato la trust, e quali accessi ne sono derivati.

In ambiente Active Directory on-premise, il punto di partenza è l'oggetto trust nel contenitore CN=System del dominio. Ogni trust è un oggetto di classe trustedDomain con attributi che registrano la configurazione. Il forensic analyst deve estrarre i metadati di replica con repadmin /showobjmeta sull'oggetto trust per determinare l'originating timestamp di ogni attributo modificato — questo rivela esattamente quando trustDirection o trustType sono stati alterati e da quale domain controller è partita la modifica.

I log Security del domain controller completano il quadro: l'EventCode 4706 fornisce il SID dell'account che ha creato la trust e il nome del dominio partner. Se l'attaccante ha usato netdom o nltest, i log Sysmon (EventCode 1) registrano la command line completa, il parent process e l'utente effettivo.

Per le compromissioni cloud — come accaduto durante la SolarWinds Compromise (C0024) — gli artefatti si trovano negli audit log del tenant. In quella campagna, APT29 utilizzò permessi amministrativi Azure AD per configurare un dominio affinché accettasse token SAML firmati con un proprio certificato. La timeline forense deve quindi includere:

1. L'evento di modifica della federation nel Microsoft 365 Unified Audit Log, con il campo ModifiedProperties che mostra il passaggio da Managed a Federated
2. Il certificato di firma iniettato, estraibile dal campo FederationSettings dell'oggetto dominio
3. I successivi sign-in con token SAML anomali, visibili negli Azure Sign-in Logs filtrando per authentication protocol = SAML e issuer non riconosciuto
4. L'eventuale lateral movement verso risorse cloud accessibili tramite le identità federate

L'analisi del certificato malevolo merita attenzione dedicata: il thumbprint, il periodo di validità e il subject name spesso rivelano se è stato generato con tool come AADInternals (che usa valori predefiniti riconoscibili) o con strumenti custom. Confrontare il certificato con quello legittimo precedente — recuperabile dai backup di configurazione AD FS o dalla cronologia dell'oggetto dominio — stabilisce il punto esatto di compromissione.

Per AWS, CloudTrail registra le chiamate CreateSAMLProvider e AssumeRoleWithSAML: correlare le due sequenze cronologicamente rivela quanto rapidamente l'attaccante ha sfruttato la trust dopo averla creata.

La Trust Modification è una tecnica adottata da gruppi con elevata sofisticazione e obiettivi strategici. I profili da monitorare raccontano storie operative molto diverse.

Scattered Spider (G1015) si distingue per un approccio orientato all'identità cloud. Il gruppo aggiunge un identity provider federato al tenant SSO della vittima e attiva l'automatic account linking, una funzionalità che associa automaticamente le identità federate agli account esistenti senza verifica manuale. Questo meccanismo è particolarmente insidioso perché non richiede la creazione di nuovi account — l'attaccante si "aggancia" a identità già esistenti. Il pattern operativo di Scattered Spider suggerisce un'attenzione prioritaria ai tenant Okta e alle configurazioni SSO di organizzazioni con ampia superficie SaaS.

Storm-0501 (G1053) opera con un approccio più tradizionale ma altrettanto efficace: dopo aver ottenuto accesso a livello Global Administrator nel tenant Microsoft Entra, crea un nuovo dominio federato come backdoor persistente. La sequenza è lineare — compromissione di credenziali privilegiate, escalation a GA, configurazione della federation — ma la backdoor risultante è estremamente resiliente, perché sopravvive al reset delle password e alla revoca delle sessioni.

La SolarWinds Compromise (C0024) rappresenta il caso studio di riferimento per questa tecnica. APT29, attribuito all'SVR russo, ha sfruttato le trust modification come componente di una catena d'attacco supply-chain che ha colpito circa 18.000 organizzazioni tra enti governativi, aziende tecnologiche e di consulenza in Nord America, Europa, Asia e Medio Oriente. La modifica delle impostazioni di federazione del dominio — con iniezione di un certificato SAML controllato dall'attaccante — ha permesso l'accesso persistente senza necessità di compromettere ulteriormente le credenziali.

Il trend strategico è chiaro: la Trust Modification sta migrando dall'AD on-premise ai tenant cloud. Scattered Spider e Storm-0501 operano entrambi su Microsoft Entra ID, mentre la descrizione della tecnica include esplicitamente AWS IAM Identity Center e Okta. Il TI officer dovrebbe monitorare le configurazioni federation dei propri tenant con cadenza almeno settimanale e mantenere un inventario aggiornato degli IdP autorizzati, trattando qualsiasi aggiunta non documentata come indicatore di compromissione ad alta confidenza.

Il tool AADInternals (S0677) è il denominatore comune: open source, ben documentato e capace di automatizzare l'intera catena dalla conversione del dominio alla generazione di token. La sua presenza in un ambiente — anche solo come modulo PowerShell importato — è un forte indicatore di attività malevola o di red teaming non autorizzato.

Framework MITRE ATT&CK v16: T1484.002, TA0005, TA0004, G1015, G1053, S0677, C0024, M1026, M1018. Detection: analisi AN1259 (Windows), AN1260 (Identity Provider). Integrato con conoscenza professionale per tool e procedure operative.