Policy Condizionali Sovvertite: Modify Authentication Process – Conditional Access Policies (T1556.009)

La simulazione di questa tecnica richiede un ambiente lab con un tenant Entra ID di test (un piano gratuito P2 trial è sufficiente per le conditional access) oppure un account AWS con policy IAM configurabili. L'obiettivo è dimostrare come, partendo da un account con privilegi di Conditional Access Administrator o IAM admin, sia possibile indebolire le difese in modo silenzioso.

Scenario 1 — Entra ID: aggiunta di trusted location. Con il modulo Microsoft Graph PowerShell (open source), si può creare una named location attendibile e poi associarla come eccezione a una policy esistente. La sequenza inizia con l'autenticazione:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

Si enumera la configurazione attiva:

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

Si crea una nuova named location contenente un range IP controllato dall'attaccante:

New-MgIdentityConditionalAccessNamedLocation -DisplayName "VPN Backup" -OdataType "#microsoft.graph.ipNamedLocation" -IsTrusted:$true -IpRanges @(@{OdataType="#microsoft.graph.iPv4CidrRange"; CidrAddress="203.0.113.0/24"})

Infine si modifica la policy target per escludere quella location dalla verifica MFA. Questo replica esattamente il comportamento documentato per Scattered Spider, che ha aggiunto trusted locations alle policy Azure AD.

Scenario 2 — AWS: modifica di IAM policy condition. Con la CLI AWS si può iniettare un range IP nella condition aws:SourceIp di una policy esistente. Prima si estrae il documento corrente:

aws iam get-role-policy --role-name AdminRole --policy-name ConditionedAccess

Si modifica il JSON aggiungendo il range desiderato nel blocco Condition.IpAddress.aws:SourceIp, poi si ripubblica:

aws iam put-role-policy --role-name AdminRole --policy-name ConditionedAccess --policy-document file://modified-policy.json

Per lo scenario MFA, si può registrare un nuovo metodo MFA su un account compromesso usando ROADtools (open source), il toolkit di Dirk-jan Mollema per l'analisi di Entra ID. Il tool roadrecon consente di esplorare la configurazione del tenant, mentre l'interazione diretta con le API Graph permette la registrazione di authenticator aggiuntivi — comportamento analogo a quello di Storm-0501.

Stratus Red Team (open source) di DataDog include moduli pre-confezionati per simulare manipolazioni di policy IAM AWS in ambiente controllato e rappresenta il riferimento più immediato per esercitazioni purple team su questa tecnica.

Il cuore della detection per questa tecnica sta nel monitorare le modifiche alle policy condizionali e correlare queste modifiche con attività di login anomale nelle ore successive. Non si tratta di cercare un singolo evento, ma una sequenza: modifica privilegiata seguita da accesso da un contesto precedentemente bloccato.

Log source primari. Per ambienti AWS, i log CloudTrail catturano le chiamate API PutRolePolicy, CreatePolicyVersion e AttachRolePolicy. L'analytic AN0087 suggerisce di filtrare specificamente le modifiche che coinvolgono le condition key aws:SourceIp, aws:RequestedRegion e aws:MultiFactorAuthPresent. Un alert efficace correla la modifica con login successivi da IP o regioni non presenti nella baseline storica dell'account.

Per Entra ID e Okta, l'analytic AN0088 indica i log azure:activity e saas:okta come fonti. In Entra ID gli eventi rilevanti sono le operazioni sulla risorsa ConditionalAccessPolicy nel log di audit, in particolare le azioni di tipo Update conditional access policy e Add named location. In Okta, le modifiche alle sign-on policies generano eventi nel System Log con eventType policy.lifecycle.update.

Tuning per ridurre i falsi positivi. La configurazione efficace richiede tre livelli di contesto:

• Account privilegiati monitorati: una lista esplicita di Conditional Access Administrator, Global Administrator e IAM admin il cui operato va sempre correlato.
• Finestra temporale: correlare la modifica della policy con login anomali entro 2-6 ore — un tempo sufficiente perché l'attaccante sfrutti la modifica, ma abbastanza stretto da limitare il rumore.
• Contesto utente e applicazioni: definire per ciascun gruppo utenti quale pattern MFA è atteso e quali applicazioni SaaS sono sensibili alla rimozione delle restrizioni.

Un segnale ad alta fedeltà è la registrazione di un nuovo metodo MFA su un account seguita dalla disabilitazione del requisito MFA su una policy: questa sequenza non ha quasi mai giustificazione operativa legittima. In Microsoft Sentinel (freemium) esistono regole analitiche preconfigurate per rilevare modifiche alle conditional access policy, mentre Splunk (a pagamento) può ingerire i log Okta tramite il Splunk Add-on for Okta.

L'analisi forense di una compromissione basata su T1556.009 si sviluppa quasi interamente su artefatti cloud: log di audit degli identity provider, record di autenticazione e, dove disponibili, log di accesso alle risorse downstream.

Entra ID — ricostruzione della sequenza. Il punto di partenza sono gli Audit Log del tenant, dove ogni modifica a una conditional access policy genera un record con l'identità dell'operatore, il timestamp, e — elemento cruciale — un campo che contiene il valore precedente e quello nuovo della policy. Confrontando i due JSON si identifica esattamente cosa è cambiato: un IP range aggiunto a una named location, un requisito MFA rimosso, un'esclusione di gruppo inserita. Questi log si esportano verso un Log Analytics Workspace e si interrogano in KQL.

La correlazione chiave è tra la modifica della policy e i Sign-in Log: si cerca il primo login riuscito che sarebbe stato bloccato dalla policy originale. L'attributo ConditionalAccessResult nei Sign-in Log mostra se una policy è stata applicata, non applicata, o non soddisfatta. Un passaggio da failure a success per lo stesso utente/IP è il marcatore temporale che definisce l'inizio dell'accesso non autorizzato.

AWS — ricostruzione da CloudTrail. Gli eventi PutRolePolicy e CreatePolicyVersion contengono il documento IAM completo nel campo requestParameters. Confrontando la versione precedente (recuperabile via GetPolicyVersion) con quella nuova, si identificano le condition key modificate. Il passo successivo è cercare in CloudTrail eventi ConsoleLogin o chiamate API da IP che corrispondono ai range appena aggiunti.

Artefatti da preservare. Durante l'acquisizione forense, è essenziale esportare immediatamente:

• Gli Audit Log e Sign-in Log di Entra ID (retention default di 30 giorni nel tier gratuito)
• I trail CloudTrail (verificare che il trail copra tutte le regioni, incluse quelle "inusuali" che l'avversario potrebbe aver sbloccato)
• I System Log di Okta con filtro su eventi policy.* e user.mfa.*

Per la ricostruzione della timeline, CDIR Collector (open source) può assistere nella raccolta strutturata dei log cloud, mentre i log vanno normalizzati e inseriti in una timeline unificata usando strumenti come Timesketch (open source) per la visualizzazione temporale degli eventi.

La manipolazione delle conditional access policies è una tecnica che riflette un livello di maturità operativa significativo: l'avversario non si limita a compromettere credenziali, ma comprende l'architettura IAM del target e la modifica chirurgicamente per garantirsi accesso prolungato.

Scattered Spider (G1015) è un gruppo noto per l'uso aggressivo di social engineering e SIM swapping per ottenere accesso iniziale a tenant cloud aziendali. Il profilo si distingue per la profonda familiarità con gli ambienti Microsoft: l'aggiunta di trusted locations alle conditional access policy di Azure AD è coerente con un modus operandi che punta a mantenere l'accesso anche dopo che il team di incident response ha resettato le password e revocato le sessioni. L'aspetto più insidioso è che una named location aggiunta con un nome plausibile — come "VPN Backup" o "Branch Office" — può sfuggire a un audit superficiale.

Storm-0501 (G1053) porta la tecnica un passo avanti: non solo manipola le policy, ma registra i propri metodi MFA sull'account compromesso e sfrutta server hybrid-joined per aggirare le restrizioni di device compliance. Questo indica un avversario che opera con una comprensione completa della catena di trust Entra ID — dal dispositivo all'identità alla policy — e che sa dove intervenire per neutralizzare ciascun anello.

Il pattern emergente è chiaro: entrambi i gruppi operano in ambienti hybrid cloud dove l'identità è il perimetro. La manipolazione delle conditional access policy diventa il complemento naturale di tecniche come il token theft e la registrazione di dispositivi rogue. Per il threat intelligence, il segnale da monitorare nei report futuri è l'evoluzione verso la manipolazione di policy IAM in AWS e GCP, dove le condition attribute (aws:SourceIp, aws:RequestedRegion) offrono superficie analoga ma con meccanismi di audit meno maturi nelle organizzazioni che non hanno ancora centralizzato il logging multi-cloud.

Il consiglio operativo è costruire una matrice di "policy integrity" per ciascun identity provider in uso, documentando lo stato atteso delle conditional access policy e verificandolo periodicamente con script automatizzati — trasformando la detection reattiva in un controllo di configurazione proattivo.

Framework MITRE ATT&CK v16 — T1556.009 (Conditional Access Policies), TA0003, TA0005, TA0006, G1015, G1053, M1018, DET0030 (AN0087, AN0088). Tool di detection e simulazione: Microsoft Sentinel, Splunk, ROADtools, Stratus Red Team, Timesketch. Integrato con conoscenza professionale per tool e procedure operative.