Relazioni Fidate: Trusted Relationship (T1199)

La simulazione di questa tecnica richiede un approccio metodico che riproduca il comportamento degli APT documentati. Iniziamo con l'identificazione delle relazioni di trust esistenti nell'ambiente target.

Per mappare le relazioni delegate in ambienti Microsoft 365, utilizza PowerShell con moduli MSOnline:

Get-MsolPartnerContract -All | Select-Object Name, TenantId, DefaultDomainName
Get-MsolRoleMember -RoleObjectId "62e90394-69f5-4237-9190-012177145e10"

Il primo comando elenca tutti i partner con accesso delegato, mentre il secondo mostra i membri del ruolo Global Administrator, spesso il target primario.

Su sistemi Linux, la ricognizione delle chiavi SSH autorizzate rivela potenziali percorsi di trust:

find /home -name authorized_keys -exec grep -l "contractor\|vendor\|msp" {} \;
grep -r "AllowUsers\|AllowGroups" /etc/ssh/sshd_config

Per AWS, enumera i ruoli cross-account che permettono assunzione da account esterni:

aws iam list-roles --query "Roles[?contains(AssumeRolePolicyDocument.Statement[].Principal.AWS, 'arn:aws:iam::')].[RoleName,Arn]"

La fase di exploitation può sfruttare tool come Impacket per muoversi lateralmente usando credenziali compromise del fornitore. Il comando psexec.py permette l'esecuzione remota mantenendo l'apparenza di attività legittima:

python3 psexec.py VENDOR/svcaccount:Password123@target-dc.victim.com

Per ambienti cloud, simula l'assunzione di ruoli cross-account come farebbe APT29:

aws sts assume-role --role-arn arn:aws:iam::VICTIM-ACCOUNT:role/VendorAccess --role-session-name pentest-simulation

Strumenti specializzati come ROADtools permettono di esplorare relazioni delegate in Azure AD, replicando le tecniche usate da HAFNIUM.

La detection efficace di abusi nelle relazioni fidate richiede correlazione multi-sorgente e baseline comportamentali precise. Il cuore della strategia sta nell'identificare pattern anomali che deviano dal comportamento normale dei fornitori.

Configura alert per login da range IP di terze parti seguiti da escalation di privilegi entro 30-120 minuti. In Splunk, questa correlazione appare così:

index=windows EventCode=4624 [| inputlookup third_party_cidrs.csv | fields src_ip] 
| join user [search index=windows EventCode=4672 earliest=-2h latest=now] 
| where _time2 > _time1 
| stats values(ComputerName) by user, src_ip

Per Azure AD, monitora la creazione o modifica di relazioni delegate con query KQL in Sentinel:

AuditLogs
| where OperationName contains "partner" or OperationName contains "delegated"
| extend InitiatorTenantId = tostring(InitiatedBy.user.homeTenantId)
| where InitiatorTenantId !in (TrustedPartnerTenantIDs)

I falsi positivi sono comuni quando MSP legittimi eseguono manutenzione pianificata. Riducili mantenendo un inventario aggiornato di ExpectedAdminHosts dove l'accesso di terze parti è autorizzato. Implementa logica di esclusione basata su ticket di change management aperti.

Configura threshold dinamici per azioni ad alto rischio. Se un account vendor normalmente accede a 5-10 server, un improvviso accesso a 50+ sistemi deve generare un alert immediato. Usa machine learning per stabilire baseline per volume di accessi, orari tipici e risorse normalmente consultate.

Per Linux, correla eventi auditd con flussi di rete per identificare SSH laterali anomali da account di terze parti. La combinazione di SYSCALL per privilege escalation con connessioni SSH verso nuovi host indica possibile compromissione.

La ricostruzione forense di attacchi attraverso relazioni fidate richiede attenzione particolare agli artefatti che dimostrano la transizione da accesso legittimo ad attività malevola.

Inizia dall'analisi dei log di autenticazione Windows. Gli EventID 4624 (logon riuscito) e 4648 (logon esplicito) rivelano quando account di terze parti hanno stabilito sessioni. Correlali temporalmente con EventID 4672 che indica assegnazione di privilegi speciali:

Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624,4648,4672} | 
Where-Object {$_.Message -match "VENDOR\\" -or $_.Message -match "MSP-"} |
Sort-Object TimeCreated

Gli artefatti di lateralizzazione includono chiavi di registro per servizi remoti, file prefetch per psexec e tracce in ShimCache. La sequenza tipica mostra prima l'accesso vendor, poi l'installazione di tool di remote access, infine il movimento verso sistemi critici.

Per campagne come SolarWinds, cerca certificati anomali in Personal Certificate Store che potrebbero essere stati usati per autenticazione. APT29 ha utilizzato certificati Mimecast compromessi, lasciando tracce nel Event Log di CAPI2.

Su Linux, analizza /var/log/auth.log per sequenze di su/sudo da account vendor, correlando con modifiche a /root/.ssh/authorized_keys che indicano persistenza. Il timestamp di modifica di questi file spesso marca l'inizio della compromissione effettiva.

In ambienti cloud, le API audit log mostrano chiaramente la progressione. Per AWS CloudTrail, cerca eventi AssumeRole da account esterni seguiti da chiamate API sensibili come CreateAccessKey o PutBucketPolicy. POLONIUM ha mostrato questo pattern esatto nella compromissione di una società di aviazione attraverso il loro fornitore IT.

La timeline reconstruction deve evidenziare il "pivot moment" - quando l'attività passa da legittima a malevola. Spesso coincide con accessi fuori orario, volume anomalo di query LDAP, o download massivi di dati che il fornitore non dovrebbe necessitare.

L'analisi delle campagne storiche rivela pattern distintivi nell'uso di relazioni fidate da parte di specifici gruppi APT.

APT28 ha dimostrato sofisticazione tattica nel caso DCCC/DNC, usando l'accesso iniziale a un'organizzazione come trampolino verso il target primario. Il gruppo mantiene presenza minima nel primo ambiente, focalizzandosi sul furto di credenziali per il salto successivo. La loro preferenza per target politici suggerisce monitoraggio aumentato durante periodi elettorali per organizzazioni con collegamenti governativi.

APT29 rappresenta l'apice della sofisticazione in questo dominio. La SolarWinds Compromise ha mostrato capacità di compromettere la supply chain software stessa, ma il gruppo ha anche dimostrato abilità nel compromettere direttamente cloud service provider. Il loro modus operandi include lunghi periodi di dormienza - fino a 6 mesi - prima dell'exploitation attiva. Privilegiano accessi a lungo termine rispetto a smash-and-grab.

HAFNIUM si distingue per il targeting di Privilege Access Management provider. Rubando API key e credenziali PAM, ottengono accesso praticamente illimitato agli ambienti downstream. La loro velocità operativa è notevole: dalla compromissione iniziale all'esfiltrazione in meno di 48 ore in molti casi documentati.

Sandworm Team mostra preferenza per provider di telecomunicazioni e ISP, sfruttando connessioni dedicate tra organizzazioni. Il loro focus su infrastrutture critiche ucraine fornisce indicazioni geografiche chiare per prioritizzazione del threat hunting.

Pattern emergenti includono l'aumento di targeting verso Identity Provider cloud. LAPSUS$ ha pionerato attacchi diretti ad Azure AD e Okta, mentre Sea Turtle si focalizza su DNS registrar per controllo upstream.

L'overlap nei tool è limitato - questi gruppi tendono a usare capacità native e "living off the land" per mantenere stealth. Il futuro probabilmente vedrà maggior focus su compromise di piattaforme IaC e DevOps service provider per accesso ancora più ampio.

Analisi basata su framework MITRE ATT&CK T1199 e intelligence su campagne APT documentate inclusa SolarWinds Compromise (APT29). Riferimenti per detection engineering e architetture zero-trust da pubblicazioni CISA e NSA su supply chain security.