Manipolazione Accessi Condizionali: Conditional Access Policies (T1556.009)

In un ingaggio red team autorizzato, la simulazione di T1556.009 richiede il possesso di credenziali con ruoli privilegiati come Global Administrator, Conditional Access Administrator o Security Administrator in Entra ID, oppure il ruolo equivalente su Okta/JumpCloud, o iam:PutRolePolicy e iam:UpdateAssumeRolePolicy in AWS. La catena tipica parte da un initial access via phishing MFA-fatigue o SIM swap (patterns osservati in Scattered Spider), prosegue con enumerazione dei ruoli e culmina nella modifica delle policy.

Su Entra ID, il modulo Microsoft.Graph.Identity.SignIns (open source, PowerShell Gallery) espone i cmdlet per l'inventario e la modifica. Un red teamer può enumerare le policy esistenti con:

Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, Conditions

e aggiungere una named location fidata con l'IP dell'infrastruttura di test tramite New-MgIdentityConditionalAccessNamedLocation. La logica di bypass consiste nell'includere il range dell'attaccante nella lista trustedIps di una policy che esenta gli IP fidati dal requisito MFA.

Su AWS, la modifica di una IAM policy per introdurre una condizione permissiva si esegue con AWS CLI (open source):

aws iam put-role-policy --role-name TargetRole --policy-name Bypass --policy-document file://policy.json

dove il documento JSON contiene un blocco Condition con IpAddress che include il CIDR del red team, oppure rimuove un Bool su aws:MultiFactorAuthPresent.

Per l'enumerazione preliminare in ambienti cloud sono utili ROADtools (open source, GitHub dirkjanm/ROADtools) per Entra ID, ScoutSuite (open source, NCC Group) per audit multi-cloud e Pacu (open source, Rhino Security Labs) per moduli offensivi AWS. Il modulo iam__enum_permissions di Pacu identifica rapidamente i permessi disponibili sul principal compromesso.

La tattica di Storm-0501 merita replica in lab: registrazione di un metodo MFA controllato dall'attaccante sull'account vittima tramite Set-MgUserAuthenticationMethod, sfruttando poi un server hybrid-joined con Primary Refresh Token valido per aggirare policy device-based. Il tool AADInternals (open source, PowerShell) offre funzioni per manipolare PRT e simulare device compliance.

Ogni test deve essere preceduto da scope scritto, backup delle policy originali (esportazione JSON), finestra temporale concordata e canale di rollback immediato. La documentazione dell'ingaggio deve includere hash delle policy pre e post modifica per garantire ripristino integro.

La detection di T1556.009 si fonda sulla correlazione tra eventi di modifica policy e anomalie di logon successive. Le due detection analytic AN0087 (IaaS) e AN0088 (Identity Provider) formalizzano l'approccio comportamentale: non basta allertare sul cambio di configurazione, occorre agganciarlo a sign-in che sfruttano la nuova esenzione.

Per Entra ID, la sorgente primaria è azure:activity con focus sugli operation name Update conditional access policy, Add conditional access policy, Delete conditional access policy e Update policy all'interno della categoria Policy. Un alert efficace correla questi eventi con l'initiatedBy.user.userPrincipalName per identificare l'attore, quindi entro una finestra di 24-72 ore cerca nei SignInLogs accessi provenienti dall'IP o dalla regione appena aggiunti alle named location fidate. In KQL su Sentinel/Log Analytics, la query base filtra AuditLogs per OperationName contains "conditional access" e joina con SigninLogs sullo stesso TargetResources.

Per Okta, i log rilevanti sono in saas:okta con eventType policy.lifecycle.update, policy.rule.update e user.mfa.factor.update. La registrazione di un nuovo factor MFA da parte di un account privilegiato, seguita a breve distanza da un login da IP non abituale, è un pattern ad alta confidenza — corrispondente al TTP di Storm-0501.

Per AWS, CloudTrail registra PutRolePolicy, PutUserPolicy, AttachRolePolicy e UpdateAssumeRolePolicy. L'analisi deve estrarre il campo requestParameters.policyDocument e diffare il blocco Condition rispetto alla versione precedente, isolando l'aggiunta di IpAddress permissivi o la rimozione di Bool aws:MultiFactorAuthPresent = true. Tool come CloudTrail Lake (a pagamento, AWS) o Panther (freemium) semplificano il diffing automatico.

I parametri di tuning suggeriti nelle analytic sono critici: la lista PrivilegedAccounts deve essere mantenuta aggiornata via automazione dal directory service, la TimeWindow di correlazione non dovrebbe superare le 72 ore per evitare falsi positivi da attività amministrativa legittima, e le MonitoredIAMConditions vanno filtrate per environment (produzione vs sviluppo hanno soglie diverse).

I falsi positivi più frequenti derivano da progetti di rollout MFA, aggiunta di sedi aziendali reali, integrazione di nuovi partner con IP fidati e attività di IaC (Terraform, Bicep) che riscrivono policy in blocco. Mitigazione: whitelist di service principal noti per deployment automatizzati, correlazione con ticket di change management, e baseline settimanale del numero di modifiche policy per identificare picchi anomali. Un controllo D3FEND allineato è User Account Permissions monitoring, che verifica coerenza tra ruolo assegnato e azioni eseguite.

L'indagine forense su T1556.009 richiede acquisizione tempestiva dei log cloud, poiché la ritenzione predefinita di molte piattaforme è limitata (Entra ID conserva AuditLogs per 30 giorni nel tier gratuito, 90 giorni con Entra ID P1/P2). La prima azione è esportare integralmente l'intervallo temporale sospetto verso storage forense immutabile: Azure Storage con immutability policy, S3 Object Lock o bucket WORM equivalenti.

Per Entra ID, gli artefatti chiave sono i DirectoryAuditLogs filtrati per categoria Policy e ConditionalAccess. Ogni record contiene initiatedBy (utente o service principal), targetResources (policy modificata con GUID), additionalDetails e — cruciale — modifiedProperties che elenca il valore precedente e quello nuovo di ogni campo alterato. La ricostruzione della timeline procede estraendo tutti i cambi sulla stessa policyId e ordinandoli per activityDateTime. Il campo correlationId permette di collegare la modifica alla sessione di autenticazione originante l'azione, tracciabile nei SignInLogs dello stesso attore.

Per AWS, i CloudTrail event PutRolePolicy e affini contengono requestParameters.policyDocument con lo stato completo post-modifica, ma non il precedente. Il diff va ricostruito confrontando con snapshot storici di AWS Config (a pagamento) se attivo, oppure con export periodici della configurazione IAM. L'assenza di AWS Config in un tenant compromesso è essa stessa un indicatore, poiché alcuni attaccanti disabilitano il servizio prima della manipolazione.

Su Okta, il System Log espone eventi policy.rule.update con debugContext.debugData che riporta i cambiamenti dettagliati. Gli eventi user.mfa.factor.activate con client.userAgent inconsistente rispetto al pattern storico dell'utente segnalano la registrazione di factor da parte dell'attaccante — pattern documentato in Storm-0501.

Sul lato endpoint, in scenari hybrid come quello di Storm-0501, l'analisi del server hybrid-joined compromesso richiede raccolta di Security.evtx (EventID 4624 con LogonType 3 da IP interni), Microsoft-Windows-AAD/Operational per eventi di token brokering, e artefatti di PRT nel Credential Manager. Il tool KAPE (gratuito per uso non commerciale, Eric Zimmerman) con target EntraIDArtifacts automatizza la raccolta.

La timeline consolidata deve incrociare quattro assi: momento della modifica policy, identità dell'attore, IP e ASN dell'origine, e primi utilizzi della nuova esenzione. Strumenti come Timesketch (open source, Google) o Splunk (a pagamento) con dashboard custom facilitano la visualizzazione. Il report finale include hash SHA-256 dei JSON policy esportati pre e post incidente, catena di custody dei log cloud e mappatura MITRE degli step osservati.

L'adozione di T1556.009 è ancora limitata a un ristretto gruppo di attori sofisticati, ma il trend è in crescita netta con la migrazione delle infrastrutture verso identity provider cloud-first. I due gruppi documentati offrono profili operativi complementari.

Scattered Spider (G1015), noto anche con alias attribuiti a UNC3944 e Octo Tempest nella nomenclatura di altri vendor, ha integrato la manipolazione di conditional access policy nel proprio arsenale contro tenant Azure AD. Il pattern documentato è l'aggiunta di trusted locations nelle policy di Entra ID, tipicamente inserendo range IP che l'attaccante controlla tramite VPS o servizi VPN commerciali. Questa mossa segue l'ottenimento di privilegi elevati via social engineering dell'help desk — vettore per cui il gruppo è particolarmente noto — e precede fasi di estrazione dati o deployment di ransomware. L'obiettivo è rendere le credenziali rubate utilizzabili anche da geografie che le policy originali bloccavano.

Storm-0501 (G1053), tracciato principalmente da Microsoft Threat Intelligence in campagne ransomware contro settori sanitario, government e manufacturing, adotta un approccio più raffinato. Il gruppo registra un proprio metodo MFA sull'account compromesso, ottenendo così il secondo fattore controllato dall'attaccante, e sfrutta server hybrid-joined della vittima per aggirare policy device-based. La logica è elegante: se una policy richiede "device compliant o hybrid joined", basta autenticarsi transitando da un server che soddisfa il requisito per neutralizzare il controllo. Questa TTP indica maturità nella comprensione dell'architettura ibrida Entra Connect ed è indicativa di attori con tempo di dwell prolungato per studiare l'ambiente.

Entrambi i gruppi condividono alcune caratteristiche strategiche: targeting di Global Administrator o ruoli equivalenti nelle fasi iniziali, uso di living-off-the-cloud con strumenti amministrativi legittimi (PowerShell Graph, Azure CLI) invece di malware custom, e tempi di dwell che permettono modifiche graduali difficili da individuare. La sovrapposizione con altre sub-tecniche di T1556 (Modify Authentication Process) è frequente: entrambi combinano manipolazione policy con abuso di federazione, token forgery o registrazione applicazioni malevole.

Il trend prospettico indica espansione dell'adozione da parte di gruppi con motivazioni finanziarie — dove il ROI di persistenza silenziosa in tenant enterprise è elevato — e da parte di attori state-sponsored interessati a raccolta intelligence prolungata. Settori più esposti risultano SaaS provider, MSP e organizzazioni con adozione recente di Zero Trust dove le policy sono numerose ma non ancora consolidate. La mitigazione M1018 (User Account Management) rimane centrale, ma va integrata con controlli tipo break-glass account protetti da FIDO2 e PIM just-in-time per il ruolo Conditional Access Administrator.

MITRE ATT&CK T1556.009 (Conditional Access Policies), gruppi G1015 Scattered Spider e G1053 Storm-0501, mitigazione M1018, detection DET0030 con analytic AN0087 e AN0088. MITRE D3FEND per controlli User Account Permissions e Authentication Event Thresholding. Documentazione ufficiale Microsoft Entra ID, AWS IAM, Okta System Log. Contenuti operativi su tool (ROADtools, Pacu, ScoutSuite, AADInternals, KAPE, Timesketch) derivano da conoscenza professionale di cybersecurity e documentazione pubblica dei rispettivi progetti.