Abuso di Relazioni Fidate: Trusted Relationship (T1199)

La simulazione di un abuso di relazione fidata in un esercizio red team non richiede di compromettere un vero MSP: si tratta di emulare il profilo d'accesso che un partner esterno avrebbe legittimamente e dimostrare come quel profilo possa essere escalato. L'obiettivo è testare se i controlli dell'organizzazione distinguono effettivamente tra un'attività partner legittima e un'attività malevola che ne abusa le credenziali.

Il primo passo consiste nell'enumerare le relazioni di delega esistenti nel tenant Azure AD / Entra ID. Il modulo PowerShell Partner Center (gratuito, modulo Microsoft ufficiale) permette di interrogare le partnership attive:

Get-PartnerCustomer | Select-Object Name, Domain, RelationshipToPartner

Se il red team opera dal punto di vista del tenant vittima, il portale di amministrazione Microsoft 365 espone la pagina "Partner Relationships" con i dettagli di ogni delega attiva. Da riga di comando, il modulo MSOnline (gratuito) consente di verificare i ruoli assegnati:

Get-MsolPartnerInformation

Per simulare il pivoting da una rete partner a quella del cliente, l'approccio più realistico è configurare nel laboratorio un segmento di rete "terza parte" con un tunnel VPN site-to-site verso l'ambiente target. Da quel segmento, si verifica cosa è raggiungibile senza credenziali aggiuntive — spesso molto più di quanto il cliente immagini.

Su ambienti cloud AWS, la simulazione prevede la creazione di un ruolo cross-account con trust policy verso un account esterno controllato dal red team, seguito dall'assunzione del ruolo:

aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_VITTIMA:role/PartnerRole --role-session-name RedTeamTest

Una volta ottenuta la sessione, si enumera l'ampiezza dei permessi con strumenti come Pacu (open source), il framework di exploitation AWS:

run iam__enum_permissions

Per il contesto Azure, ROADtools (open source) di Dirk-jan Mollema permette di acquisire un dump completo del tenant dal punto di vista dell'account partner e analizzare relazioni, ruoli e permessi delegati. L'enumerazione dei service principal e delle app registration con permessi elevati rivela spesso percorsi di escalation non intenzionali.

Il risultato atteso dell'esercizio è una mappa documentata dei percorsi di accesso che un partner compromesso potrebbe sfruttare, con evidenza delle risorse raggiungibili e dei controlli assenti o aggirabili.

La sfida della detection su T1199 è che l'attività malevola si maschera da traffico legittimo di un partner autorizzato. Non esiste un singolo evento che gridi "compromissione del fornitore": serve una catena comportamentale che correli accesso, escalation e azione anomala all'interno di una finestra temporale.

La detection principale si articola su sei superfici analitiche distinte. Su Windows, la catena da monitorare parte da un logon remoto (EventCode 4624, Logon Type 3 o 10) originato da un CIDR di un fornitore noto, seguito da un'elevazione di privilegio (EventCode 4672 o EventCode 4648) e infine da un accesso a risorse ad alto valore — share di rete, oggetti Active Directory, server critici — atipico per quell'account. Le sorgenti essenziali sono WinEventLog:Security e WinEventLog:Sysmon. Il tuning richiede quattro elementi: i range CIDR dei partner (ThirdPartyCIDRs), gli host amministrativi autorizzati (ExpectedAdminHosts), una finestra di correlazione tra 30 e 120 minuti (TimeWindow), e la lista delle risorse ad alto valore (HighValueResources).

Su Linux, il pattern equivalente si basa su sessioni SSH o SSO federate da identità di terze parti, seguite da sudo/su in rapida successione e accesso a percorsi sensibili o SSH est-ovest. Le sorgenti auditd:SYSCALL e linux:syslog sono complementate dai flussi di rete per tracciare il lateral movement. Il tuning si basa su account POSIX assegnati ai vendor (ThirdPartyUsers), bastion host autorizzati (AllowedJumpHosts) e un flag che indica se l'MFA PAM è atteso sulla sessione.

La superficie Identity Provider è forse la più critica. In Azure AD/Entra ID, le sessioni di amministrazione delegata (DAP/GDAP), gli account guest B2B e i trust SAML/OAuth generano eventi nei log azure:signinlogs e azure:audit. La catena da rilevare: sessione stabilita da un partner → assegnazione di ruolo o consent applicativo → azioni privilegiate downstream nel tenant. Il tuning impone di mantenere aggiornati i Tenant ID dei partner approvati e di definire una lista esplicita di ruoli ammessi per le terze parti (ad esempio solo Helpdesk Admin), alertando su qualsiasi scope più ampio.

Per ambienti IaaS (AWS, GCP), l'attenzione si concentra su AssumeRole cross-account e su chiamate API privilegiate in rapida successione. I log CloudTrail e gcp:audit devono essere correlati con geolocalizzazione e velocità di spostamento (impossible travel) tra l'azione nel contesto partner e quella nel tenant vittima.

Sul versante SaaS e Office 365, due analitiche completano il quadro. La prima monitora app OAuth di terze parti con scope elevati e azioni anomale come export massivi. La seconda, specifica per M365, traccia la creazione o modifica di delegated administration offers da parte di tenant partner, l'abilitazione di delega o impersonation su mailbox, e l'accesso successivo da IP partner. Il tuning della lista di mailbox gestibili (MailboxDelegateAllowList) riduce il rumore sulle operazioni di routine.

La gestione dei falsi positivi richiede una fase iniziale di baselining di almeno 30 giorni, durante la quale si catalogano le attività standard di ciascun partner, costruendo profili comportamentali per account, orario, risorse accedute e volume di operazioni.

L'analisi forense di un accesso tramite relazione fidata è complessa perché le credenziali usate sono tecnicamente legittime e il traffico di rete proviene da sorgenti autorizzate. La chiave è ricostruire la catena temporale che lega l'accesso iniziale del partner al comportamento anomalo successivo, distinguendo l'attività routinaria del fornitore dall'abuso delle sue credenziali.

Su Windows, il punto di partenza sono gli eventi di logon nei Security Event Log. Gli EventCode 4624 con Logon Type 3 (network) e 10 (remote interactive) vanno filtrati per gli account assegnati ai partner e correlati con le sorgenti IP documentate nei contratti. Un accesso dallo stesso account ma da un IP fuori dai range del fornitore è il primo indicatore di compromissione. Gli EventCode 4672 — assegnazione di privilegi speciali — su account di terze parti segnalano un'escalation potenziale. Sysmon aggiunge profondità: l'Event ID 1 (process creation) cattura i tool lanciati durante la sessione, mentre l'Event ID 3 (network connection) traccia le connessioni laterali originate dall'host dove il partner ha effettuato il logon.

Il filesystem offre ulteriori artefatti. I file Prefetch (in C:\Windows\Prefetch) documentano l'esecuzione di binari — se durante una sessione partner compaiono tool di ricognizione come AdFind o SharpHound, il contesto è inequivocabile. Le ShimCache entries nel registro di sistema (SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache) registrano anche esecuzioni storiche che il Prefetch potrebbe aver già ruotato.

Su Linux, i log auth.log / secure contengono le sessioni SSH con dettagli di utente, IP sorgente e metodo di autenticazione. I log auditd con syscall execve catturano ogni comando eseguito da un account vendor post-autenticazione. La sequenza sshd accepted → sudo → accesso a percorsi sensibili su un arco temporale ristretto costruisce una sotto-timeline ad alta priorità.

Per gli ambienti cloud, i log di Azure AD Sign-in mostrano sessioni di amministrazione delegata con il campo crossTenantAccessType che identifica le sessioni partner. I log di Azure Audit registrano ogni modifica a ruoli, consent e permessi. Su AWS, gli eventi AssumeRole in CloudTrail con il campo sourceIdentity espongono l'account esterno che ha assunto il ruolo, e la catena di API call successive documenta cosa è stato fatto con quei privilegi.

Un artefatto spesso trascurato sono i certificati: nella campagna SolarWinds Compromise (C0024), APT29 ha utilizzato certificati compromessi emessi da Mimecast per autenticarsi ai sistemi dei clienti. L'analisi dei log di autenticazione basata su certificato — in particolare il campo del certificato presentato e la sua catena di trust — è essenziale quando la relazione fidata si basa su mutual TLS o SAML signing.

La timeline finale dovrebbe mappare su un asse temporale unificato: logon partner → escalation → discovery/enumerazione → lateral movement → accesso ai dati → eventuale esfiltrazione, annotando per ogni step la sorgente log, l'account coinvolto e l'host.

L'abuso delle relazioni fidate è un vettore che attraversa confini geografici e motivazionali. Con 11 gruppi documentati, il panorama degli attori rivela pattern chiari su targeting, metodologia e settori colpiti.

APT29 rappresenta il caso più emblematico. L'operazione SolarWinds Compromise (C0024), condotta tra il 2019 e l'inizio del 2021 e attribuita dal governo statunitense e britannico all'SVR russo, ha dimostrato la potenza distruttiva dell'abuso della supply chain. APT29 ha compromesso account presso cloud solution partner e utilizzato certificati Mimecast compromessi per autenticarsi ai sistemi dei clienti. La campagna ha colpito circa 18.000 clienti della piattaforma Orion di SolarWinds, con un sottoinsieme più ristretto soggetto ad attività di follow-on. Vittime nei settori governo, consulenza, tecnologia e telecomunicazioni distribuite tra Nord America, Europa, Asia e Medio Oriente. Il gruppo ha dimostrato una chiara predilezione per la compromissione di provider IT, servizi cloud e MSP come moltiplicatore d'accesso.

Sandworm Team ha adottato un approccio infrastrutturale: connessioni di rete dedicate tra organizzazioni vittime per muoversi dall'una all'altra, con accesso documentato a ISP ed entità di telecomunicazione che forniscono connettività mobile. Il targeting suggerisce un interesse primario per infrastrutture critiche e la capacità di sfruttare relazioni di peering e interconnessione tra operatori.

Sul versante finanziario, GOLD SOUTHFIELD ha violato MSP per distribuire malware direttamente ai loro clienti, un modello one-to-many che massimizza il ritorno dell'investimento iniziale nella compromissione. menuPass ha seguito un pattern simile, sfruttando accessi legittimi concessi agli MSP per raggiungere obiettivi specifici di interesse. LAPSUS$ ha operato con un approccio diverso, puntando direttamente a identity provider esposti su internet come Azure Active Directory e Okta, trasformando la compromissione dell'IdP in un vettore per colpire organizzazioni specifiche.

Nel contesto mediorientale, POLONIUM ha compromesso credenziali di una società IT per colpire a valle uno studio legale e un'azienda dell'aviazione, mentre HAFNIUM ha rubato chiavi API e credenziali associate a sistemi PAM, cloud app provider e piattaforme di gestione dati cloud per accedere agli ambienti dei clienti downstream. Sea Turtle ha scelto un angolo unico, prendendo di mira DNS registrar, telco e ISP come ponte verso i bersagli primari, un approccio che dimostra come anche le relazioni fidate a livello di infrastruttura internet possano essere weaponizzate.

Threat Group-3390 e RedCurl completano il quadro con compromissioni rispettivamente di service provider e contractor come trampolino verso le vittime designate.

Il pattern emergente è chiaro: la catena del valore dei servizi IT — MSP, cloud provider, identity provider, DNS registrar — è diventata il bersaglio primario non per il suo valore intrinseco, ma per l'accesso transitivo che garantisce. Le organizzazioni che valutano il rischio solo in base al proprio perimetro ignorano il vettore più sfruttato da attori sofisticati.

Framework MITRE ATT&CK v16 — T1199 (Trusted Relationship), TA0001 (Initial Access). Campagna: C0024 (SolarWinds Compromise). Mitigazioni: M1032, M1018, M1030. Detection: DET0488, AN1344–AN1350. Tool citati: Partner Center PowerShell Module, MSOnline, Pacu, ROADtools. Integrato con conoscenza professionale per tool e procedure operative.