Policy Access Bypass: Conditional Access Policies (T1556.009)

Per testare la resilienza delle conditional access policy nel tuo ambiente, inizia identificando le policy esistenti. In Azure AD, puoi enumerare le policy tramite PowerShell con Get-AzureADMSConditionalAccessPolicy dopo aver ottenuto accesso con credenziali privilegiate. Questo comando restituisce tutte le policy attive con i loro ID e condizioni.

Una volta identificate le policy target, il passo successivo è modificarle per permettere accesso più permissivo. Ad esempio, per aggiungere un range IP trusted:

$policy = Get-AzureADMSConditionalAccessPolicy -PolicyId "policy-guid" $policy.Conditions.Locations.IncludeLocations += "trusted-ip-range" Set-AzureADMSConditionalAccessPolicy -PolicyId "policy-guid" -Conditions $policy.Conditions

Per AWS IAM, la modifica delle condition policies richiede l'update del documento JSON della policy. Prima recupera la policy esistente con aws iam get-policy-version, poi modifica le condizioni per includere il tuo IP:

"Condition": {
  "IpAddress": {
    "aws:SourceIp": ["10.0.0.0/8", "attacker-ip/32"]
  }
}

Applica la modifica con aws iam create-policy-version --policy-arn arn:aws:iam::account:policy/PolicyName --policy-document file://modified-policy.json.

Un approccio alternativo consiste nel registrare un nuovo metodo MFA sotto controllo dell'attaccante. In ambienti hybrid, sfrutta server joined al dominio per bypassare le policy che verificano lo stato del dispositivo. Storm-0501 ha dimostrato questa tecnica registrando il proprio MFA e sfruttando server hybrid per aggirare completamente le verifiche.

Per Okta, utilizza l'API per modificare le policy rules aggiungendo eccezioni per specifici user agent o geolocation. Il comando curl per aggiungere una location exception:

curl -X PUT https://domain.okta.com/api/v1/policies/{policyId}/rules/{ruleId} -H "Authorization: SSWS token" -d '{"conditions":{"network":{"connection":"ANYWHERE"}}}'

La detection efficace delle modifiche alle conditional access policy richiede monitoraggio multi-layer. Configura alert specifici per DET0030 che catturano modifiche anomale alle policy IAM in AWS CloudTrail, cercando eventi come PutPolicy o CreatePolicyVersion che modificano attributi condition.

Per Azure, monitora il log azure:activity per eventi di tipo "Update conditional access policy". Crea regole di correlazione che collegano la modifica della policy con login successivi da IP precedentemente bloccati entro una finestra temporale di 4 ore. Questo approccio riduce i falsi positivi causati da modifiche legittime.

Implementa detection comportamentale che identifichi pattern sospetti: modifica di policy seguita da login da nuove location geografiche, rimozione di requisiti MFA seguita da accessi notturni, o aggiunta di range IP che non corrispondono alle subnet aziendali conosciute.

Per Okta (saas:okta logs), cerca eventi policy.rule.update e policy.rule.deactivate. Correla questi eventi con user.authentication.auth_via_mfa mancanti per lo stesso utente nelle ore successive. Mantieni una baseline delle modifiche normali per ridurre il rumore: tipicamente le policy vengono modificate durante change window pianificate.

Configura threshold dinamici basati sul contesto aziendale. Ad esempio, se la tua organizzazione opera solo in specifiche regioni, qualsiasi modifica che permette accesso da altre aree geografiche dovrebbe generare un alert ad alta priorità. Utilizza liste di PrivilegedAccounts per dare priorità agli alert quando account amministrativi sono coinvolti nelle modifiche.

Durante l'analisi forense di un incidente che coinvolge conditional access policy manipulation, inizia raccogliendo i log di audit da tutti gli identity provider. In Azure AD, i log di audit contengono dettagli granulari su chi ha modificato quale policy e quando, inclusi i valori precedenti e nuovi.

Ricostruisci la timeline cercando prima l'evento di compromissione iniziale dell'account privilegiato. Scattered Spider tipicamente ottiene accesso tramite social engineering, quindi cerca comunicazioni anomale o reset password nei giorni precedenti la modifica della policy. Una volta identificato il punto di ingresso, mappa tutte le modifiche successive alle policy.

Gli artefatti chiave includono: export delle policy prima e dopo la modifica (conservati nei backup di configurazione), log di autenticazione che mostrano accessi riusciti da IP precedentemente bloccati, e registrazioni di nuovi metodi MFA nel periodo sospetto. In ambienti AWS, CloudTrail conserva 90 giorni di eventi per default - assicurati di preservare questi log immediatamente.

Correla le modifiche alle policy con altre attività sospette. Ad esempio, dopo aver modificato una policy per permettere accesso da nuove region, l'attaccante potrebbe accedere a risorse sensibili o creare nuovi account backdoor. Cerca pattern di accesso a risorse mai toccate prima dall'utente compromesso.

Documenta meticolosamente ogni modifica alla policy identificata, inclusi timestamp precisi, account utilizzato per la modifica, IP sorgente della richiesta, e impatto della modifica sulle capacità di accesso. Questa documentazione sarà critica per determinare l'scope completo della breach e per eventuali azioni legali.

Scattered Spider rappresenta il gruppo più attivo nell'uso di questa tecnica, specializzandosi nell'aggiungere location trusted alle policy di Azure AD dopo aver compromesso account amministrativi tramite sofisticate campagne di social engineering. Il gruppo opera primariamente contro organizzazioni nel settore tecnologico e telecomunicazioni, mirando specificamente a ambienti cloud-heavy.

Storm-0501 adotta un approccio più tecnico, sfruttando server hybrid-joined per aggirare completamente le conditional access policy. Questo gruppo registra metodi MFA sotto il proprio controllo dopo la compromissione iniziale, dimostrando una comprensione profonda delle architetture ibride Azure AD. La loro targeting preference include organizzazioni con infrastrutture legacy integrate con cloud moderni.

Entrambi i gruppi mostrano una tendenza verso la persistenza a lungo termine piuttosto che smash-and-grab operations. Dopo aver stabilito l'accesso tramite policy modification, tipicamente mantengono un profilo basso per settimane o mesi, raccogliendo intelligence e preparando movimenti laterali.

I pattern emergenti suggeriscono un'evoluzione verso l'automazione di queste tecniche. Mentre inizialmente le modifiche alle policy erano manuali e mirate, osserviamo tool che automatizzano l'identificazione e modifica di policy permissive. Prevediamo che futuri attacchi incorporeranno machine learning per identificare le modifiche minime necessarie per mantenere l'accesso evitando detection.

Le organizzazioni nei settori financial services e healthcare dovrebbero prepararsi per un aumento di questi attacchi, dato che questi settori stanno rapidamente adottando identity provider cloud-based senza necessariamente implementare monitoring adeguato delle policy modifications.

Documentazione basata su MITRE ATT&CK framework T1556.009. Riferimenti alle campagne di Scattered Spider e Storm-0501 derivano da incident response documentati. Detection guidance allineata con DET0030 per ambienti cloud e identity provider. Risorse aggiuntive disponibili presso i security advisory dei principali cloud provider.