Entra ID AiTM Token Replay e Viaggi Impossibili

Entra ID AiTM Token Replay, Rilevamento Viaggi Impossibili: Perché È Importante Ora

L'autenticazione multifattore blocca gli attacchi basati solo su password. Non ferma un attaccante che fa da proxy all'intero flusso di accesso e se ne va con un cookie di sessione valido dopo che l'utente ha completato la MFA. È esattamente questo che fanno i kit di phishing adversary-in-the-middle (AiTM), ed è proprio la lacuna che Entra ID AiTM Token Replay, Rilevamento Viaggi Impossibili e i segnali di fatica da notifiche MFA sono pensati per colmare. Microsoft è stata esplicita sul fatto che questa classe di attacco rappresenta una quota crescente delle compromissioni di identità: il blog sicurezza di Microsoft sull'evoluzione delle tecniche di attacco all'identità, insieme a diversi report di incidenti, descrivono kit AiTM come Evilginx che distribuiscono un reverse proxy tra la vittima e la vera pagina di accesso Microsoft 365, servendo il contenuto legittimo mentre catturano nome utente, password e — cosa fondamentale — il token di sessione/refresh emesso dopo il successo della MFA. Deepwatch documenta l'uso dello stesso kit da parte di attori malevoli che vanno dal prolifico operatore di phishing Storm-0485 all'attore di spionaggio russo Star Blizzard, per intercettare silenziosamente sessioni Microsoft 365.

Microsoft Entra ID Protection trasforma questo tipo di attività in segnali di rischio, ma questi segnali sono dispersi tra diverse rilevazioni distinte, tabelle di log e livelli di licenza. Questo articolo è una guida sul campo per leggerne cinque insieme:

Replay di token AiTM — un token di sessione o refresh rubato viene riutilizzato da un'infrastruttura che l'utente reale non ha mai toccato
Viaggio impossibile / atipico — due accessi per la stessa identità, troppo distanti geograficamente per essere entrambi legittimi
Abuso di approvazione MFA push — un attaccante con una password valida cerca di convincere o spingere un utente ad approvare una notifica push non richiesta
Picchi di accesso dei service principal — un'identità di workload si autentica improvvisamente molto di più, o in modo molto più esteso, rispetto alla propria baseline
Geografia insolita per gli account admin — un'identità privilegiata accede da una posizione o un dispositivo mai usato prima

ℹ️

ℹ️ Nota: Questo articolo copre in profondità i segnali di AiTM/replay di token, anomalia di viaggio, service principal e geografia admin. L'abuso di approvazione MFA riceve qui un riepilogo mirato — per la catena di attacco completa, la sequenza di rilevamento e la checklist di hardening, vedi MFA Fatigue: Rilevamento e Prevenzione in Microsoft Entra ID. La configurazione delle policy di rischio di accesso e utente si trova in Azure Identity Protection: Bloccare le Credenziali Compromesse.

Come Ogni Segnale Compare Nella Telemetria di Entra ID

Proxy AiTM e replay di token

MITRE classifica il furto di cookie di sessione sotto T1539 (Steal Web Session Cookie). Un kit AiTM si posiziona tra l'utente e il vero endpoint di accesso Microsoft, inoltra ogni fase dell'autenticazione — incluso il challenge MFA — e poi cattura l'artefatto di sessione risultante. Poiché la vittima ha effettivamente completato la MFA, il token rubato porta con sé quella dichiarazione. L'attaccante lo riutilizza dalla propria infrastruttura, non dal dispositivo o dalla rete della vittima.

Microsoft Entra ID Protection dispone di diverse rilevazioni che catturano frammenti di questo scenario:

Token anomalo (riskEventType: anomalousToken) — si attiva su caratteristiche anomale del token: una durata di vita insolita, oppure un token usato da una posizione, applicazione, indirizzo IP o user agent che non corrisponde alla cronologia dell'utente. La documentazione Microsoft indica esplicitamente questo segnale come indicatore diretto di un possibile replay di token. È in tempo reale o offline, e richiede Entra ID P2.
Attacker in the Middle (attackerinTheMiddle, una rilevazione di rischio utente) — una rilevazione ad alta precisione attivata quando una sessione di accesso è collegata a un reverse proxy malevolo noto, proveniente dalla telemetria di Microsoft Defender for Cloud Apps. Porta direttamente l'utente a rischio alto e richiede Microsoft 365 E5 con Enterprise Mobility + Security E5 — a differenza della maggior parte delle altre rilevazioni provenienti da Defender for Cloud Apps, Microsoft non indica un percorso di licenza autonomo Entra ID P2 + Defender for Cloud Apps per questa.
Proprietà di accesso non familiari (unfamiliarFeatures) — confronta un accesso con la cronologia appresa dell'utente (IP, ASN, posizione, dispositivo, browser, subnet del tenant). Le indicazioni Microsoft segnalano espressamente questo: quando si attiva su un accesso non interattivo, merita attenzione extra, perché quel pattern è coerente con un token di refresh riutilizzato silenziosamente in background piuttosto che con un accesso interattivo.
Anomalia dell'emittente del token (tokenIssuerAnomaly) — per i token SAML, segnala dichiarazioni dell'emittente insolite o corrispondenti a pattern di attaccanti noti.

Il playbook sul furto di token di Microsoft elenca i trigger concreti su cui un SOC dovrebbe allertarsi per le indagini sul furto di token: token anomalo, proprietà di accesso non familiari, accessi non interattivi da fonti sconosciute, tentativo di accesso al Primary Refresh Token (PRT) (via Defender for Endpoint), e URL sospetti coerenti con una pagina di atterraggio AiTM.

⚠️

⚠️ Avvertenza: Nessuna di queste rilevazioni garantisce di intercettare un proxy AiTM ben gestito al primo accesso. La stessa documentazione Microsoft sul rilevamento del rischio nota che la rilevazione di token anomalo può restare rumorosa, con un tasso di falsi positivi superiore al normale ai livelli di rischio basso e medio — trattate un singolo segnale a rischio basso come una pista da indagare, non come una compromissione confermata.

Viaggio impossibile e viaggio atipico

Entra ID Protection offre in realtà due rilevazioni correlate ma distinte, e confonderle porta a assunzioni sbagliate su licenze e strumenti:

Viaggio impossibile (mcasImpossibleTravel) — identifica attività da posizioni geograficamente distanti entro una finestra temporale più breve del viaggio fisicamente possibile tra di esse. Proviene da Microsoft Defender for Cloud Apps, calcolato offline, e richiede Entra ID P2 più una licenza autonoma Defender for Cloud Apps (o Microsoft 365 E5).
Viaggio atipico (unlikelyTravel) — una rilevazione nativa di Entra ID Protection (senza dipendenza da Defender for Cloud Apps) che segnala due accessi da posizioni distanti dove almeno una è anche atipica per la cronologia di quello specifico utente. Tiene conto del tempo di viaggio tra le posizioni e sopprime deliberatamente i falsi positivi comuni come i punti di uscita VPN e gli IP condivisi all'interno dell'organizzazione. I nuovi utenti attraversano un periodo di apprendimento di 14 giorni o 10 accessi (quale dei due arriva prima) prima che la rilevazione si attivi.

Entrambe richiedono Entra ID P2. Se il vostro tenant ha solo P1 o Free, si attivano come la rilevazione generica Additional risk detected, senza dettagli.

Abuso di approvazione MFA push, in breve

Qui contano due segnali nativi di Entra: Suspicious MFA authentication approval (authenticatorPhishing) è una rilevazione in tempo reale, esclusiva P2, che correla incongruenze di ASN, browser, dispositivo e GPS tra il dispositivo che richiede l'accesso e quello che approva via Microsoft Authenticator, segnalando direttamente l'abbinamento come rischio alto. User reported suspicious activity (userReportedSuspiciousActivity) si attiva quando un utente rifiuta una richiesta MFA che non ha avviato e la segnala esplicitamente — Microsoft tratta questo come una prova ad alta confidenza, confermata dall'utente, e porta immediatamente l'account a rischio utente alto. Solo quest'ultima dipende dall'attivazione della funzionalità Report suspicious activity; authenticatorPhishing si attiva automaticamente dalla telemetria di accesso e non richiede alcuna attivazione separata. Per la catena di attacco completa e la sequenza di hardening (number matching, MFA resistente al phishing per gli admin, workflow di risposta), vedi l'articolo dedicato alla fatica MFA collegato sopra.

Picchi di accesso dei service principal

Le identità di workload non compaiono nella stessa tabella SigninLogs degli utenti — vengono registrate in AADServicePrincipalSignInLogs (chiamata anche ServicePrincipalSignInLogs a seconda del nome del workspace/tabella). Le indicazioni di audit di Thomas Naunheim per identità gestite e service principal raccomandano di raggruppare per ServicePrincipalName e IPAddress, quindi aggregare il conteggio dei fallimenti (ResultType != "0") e la diversità delle risorse accedute (dcount(ResourceDisplayName)) — un picco in una delle due dimensioni, specialmente da un IP o ASN mai usato dal service principal, è il segnale da investigare. Microsoft Entra ID Protection dispone anche di una superficie di rilevamento dedicata al rischio delle identità di workload per esattamente questo scenario, separata dal rischio utente.

Geografia insolita per gli account admin

La guida operativa di sicurezza di Microsoft per gli account privilegiati è esplicita: gli accessi admin meritano un monitoraggio più rigoroso e separato rispetto agli utenti standard — nuovo dispositivo o posizione, accessi fuori dagli orari di lavoro previsti, e qualsiasi rilevazione di rischio di Entra ID Protection (a qualunque livello di rischio) su un'identità privilegiata dovrebbero generare un allarme ad alta priorità. La stessa guida raccomanda di trattare qualsiasi attività Unfamiliar sign-in o proveniente da TOR contro un ruolo privilegiato come meritevole di revisione immediata, invece di attendere che scali a rischio alto.

Rilevamento: Cosa Estrarre Dai Log

Il playbook sul furto di token di Entra di Microsoft fornisce query di partenza concrete per SigninLogs, AADUserRiskEvents e AuditLogs. Adattate qui per l'insieme di segnali AiTM/viaggio/geo-admin:

Trovare rilevazioni di rischio etichettate come non familiari o anomale da un IP specifico (punto di partenza una volta ottenuto un IP sospetto da una segnalazione di phishing o un avviso EDR):

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "<suspect-ip>"

Estrarre tutti gli accessi dallo stesso IP sorgente per delimitare il raggio d'impatto:

SigninLogs
| where IPAddress == "<suspect-ip>"

Stabilire la baseline di geografia e dispositivi di accesso per un'identità specifica — questa è la query che il playbook raccomanda prima di decidere se un accesso segnalato è realmente anomalo per quell'utente:

SigninLogs
| where UserId == "<user-object-id>"
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| extend city_ = tostring(LocationDetails.city)
| extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
| summarize min(TimeGenerated), max(TimeGenerated)
  by IPAddress, ResultDescription, deviceId_, city_, countryOrRegion_, AppDisplayName

Il playbook nota esplicitamente che non ogni avviso di rischio Entra ha una riga corrispondente in SigninLogs — le rilevazioni di token anomalo in particolare a volte sono visibili solo tramite AADUserRiskEvents o l'API delle rilevazioni di rischio di ID Protection, non il flusso di accesso grezzo.

Picco di service principal, adattato dalla guida di audit di cloud-architekt.net:

AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(1d)
| where ResultType != "0"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated),
    count(), applicationCount = dcount(ResourceDisplayName),
    applicationSet = make_set(ResourceDisplayName)
  by ServicePrincipalName, IPAddress, ResultType

Per la geografia degli account privilegiati e il monitoraggio dei rifiuti MFA, Microsoft fornisce contenuti Sentinel pronti all'uso invece di un'unica query da copiare — la guida operativa di sicurezza per account privilegiati rimanda a modelli denominati tra cui SuspiciousSignintoPrivilegedAccount.yaml, MFARejectedbyUser.yaml e AADPrivilegedAccountsFailedMFA.yaml nel repository GitHub Azure-Sentinel, una fonte di verità migliore rispetto a ricostruire qui la logica esatta dei filtri.

💡

💡 Suggerimento: Se un accesso segnalato è non interattivo (nessun utente presente), trattatelo con priorità maggiore rispetto a un segnale interattivo equivalente. Le stesse indicazioni Microsoft isolano specificamente questo pattern perché è coerente con un replay di token in background piuttosto che con un accesso utente attivo (e potenzialmente legittimo).

Remediation / Rimedio

Per il replay di token / AiTM:

Migrate gli account privilegiati e ad alto valore verso una MFA resistente al phishing (chiavi di sicurezza FIDO2 o autenticazione basata su certificati) — un cookie di sessione proxati diventa molto meno utile per un attaccante se la cerimonia di autenticazione originale non può essere semplicemente ripetuta. Vedi Sicurezza delle Identità Azure: Perché l'MFA da Solo Non Basta per capire perché la MFA push standard non basta da sola.
Attivate Continuous Access Evaluation e la protezione dei token del Conditional Access dove supportata, affinché un token legato a un dispositivo non possa essere semplicemente ripetuto dall'infrastruttura dell'attaccante. Il catalogo di EtcSec traccia questa lacuna direttamente come CA_TOKEN_PROTECTION_DISABLED — vedi Accesso Condizionale Azure: Bypass MFA e Auth Legacy per la revisione delle policy più ampia.
Attivate le rilevazioni Attacker in the Middle e Anomalous token (richiede P2, e Defender for Cloud Apps per la prima) e instradatele verso una policy di Conditional Access basata sul rischio di accesso invece di lasciarle come semplice visibilità da dashboard.
Trattate qualsiasi rilevazione AiTM confermata come un incidente di furto di token, non come un semplice reset della password: seguite i passi di contenimento del playbook sul furto di token di Microsoft — revocare le sessioni, bloccare l'IP dell'attaccante, e verificare metodi MFA registrati di recente o regole della casella di posta lasciate dopo l'uso della sessione.

Per il viaggio impossibile / atipico:

Confermate il licensing — il viaggio atipico è nativo di ID Protection P2, ma il viaggio impossibile richiede in più Defender for Cloud Apps connesso. La mancanza di quella connessione fa scomparire silenziosamente il segnale mcasImpossibleTravel.
Lasciate completare la finestra di apprendimento di 14 giorni/10 accessi per gli account nuovi o migrati di recente prima di regolare le soglie su dati rumorosi dei primi giorni.
Inserite il rischio di accesso in una policy di Conditional Access che richieda MFA o blocchi a rischio medio/alto, invece di limitarvi a rivedere in modo reattivo il report degli accessi a rischio.

Per l'abuso di approvazione MFA: attivate il number matching e la funzionalità Report suspicious activity, e richiedete una MFA resistente al phishing per gli amministratori — vedi l'articolo dedicato alla fatica MFA per la sequenza completa.

Per i picchi di service principal:

Rivedete AADServicePrincipalSignInLogs per confrontare comportamento base e picchi su base ricorrente, non solo durante la risposta agli incidenti.
Evitate ruoli ad alto privilegio permanenti sui service principal; ruotate segreti/certificati client secondo un calendario definito e preferite le identità gestite quando possibile.
Attivate le rilevazioni di rischio delle identità di workload di Entra ID Protection se la licenza lo consente — le policy di rischio utente non coprono i service principal.

Per la geografia admin insolita:

Iscrivete tutti i ruoli privilegiati in Privileged Identity Management (PIM) con attivazione a tempo limitato, e richiedete una nuova autenticazione all'attivazione.
Allertate su qualsiasi rilevazione di rischio ID Protection contro un'identità privilegiata, indipendentemente dal livello di rischio assegnato da Microsoft — le stesse indicazioni Microsoft per gli account privilegiati raccomandano questo standard più rigoroso per gli admin rispetto agli utenti standard.
Limitate l'elevazione admin a dispositivi approvati (PAW/SAW) quando possibile, e allertate quando l'elevazione avviene al di fuori di quella popolazione.

Come EtcSec Rileva Questo

Le categorie Risk Protection e Conditional Access di EtcSec verificano se un tenant dispone dell'impalcatura di policy e licenze da cui dipendono queste rilevazioni, non solo se Entra ID Protection è attivo. I controlli di catalogo rilevanti includono MFA_SUSPICIOUS_ACTIVITY (attività MFA / pattern di accesso sospetto) e MFA_UNUSUAL_LOCATION (accesso MFA da una geolocalizzazione insolita) a livello di segnale, più RISK_NO_SIGNIN_RISK_POLICY (nessuna policy di rischio di accesso in vigore) e RISK_SIGNINS_NOT_INVESTIGATED (accessi a rischio che si accumulano senza revisione), e CA_TOKEN_PROTECTION_DISABLED (nessun binding del token per frenare il replay) a livello di risposta.

Un tenant che mostra accessi a rischio nel portale ma non ha alcuna policy che agisce su di essi, e nessuna protezione dei token davanti ai cookie di sessione, è esattamente la lacuna che questi controlli sono progettati per rivelare.

Controlli Correlati

Leggete questo insieme a Azure Identity Protection: Bloccare le Credenziali Compromesse per la configurazione delle policy di rischio di accesso e utente, MFA Fatigue: Rilevamento e Prevenzione in Microsoft Entra ID per la catena di attacco dell'abuso di approvazione, Accesso Privilegiato Azure: Troppi Admin Globali e Come Auditare la Sicurezza di Microsoft Entra ID per il lato PIM e hardening admin, e OAuth Consent Phishing e App Malevole e Device Code Phishing in Entra ID per tecniche di phishing dell'identità adiacenti che alimentano gli stessi segnali di rischio.

Entra ID AiTM Token Replay: Rilevamento Viaggi Impossibili e Fatica MFA