Accessi da IP Microsoft 51.140.177.153 e 52.171.132.174 in Azure AD: spiegazione, rischi e verifiche

Nei log di Microsoft Entra ID/Azure AD possono comparire accessi provenienti dagli indirizzi 51.140.177.153 e 52.171.132.174 con etichetta “anonymous token”. Nella maggior parte dei casi si tratta di traffico legittimo generato dall’infrastruttura Microsoft. Qui trovi spiegazione, criteri di verifica e azioni consigliate.

Indice

Contesto e sintomi osservati

Un amministratore nota che vari servizi Microsoft 365 e Azure — come portale Azure, My Sign‑Ins e portale O365 — risultano “loggati” con gli indirizzi 51.140.177.153 e 52.171.132.174. Le stesse voci, nei registri di accesso di Entra ID (ex Azure AD), riportano “anonymous token” e sembrano eseguire SSO con l’utente reale.

È comprensibile considerarli sospetti: non corrispondono alla rete dell’utente e l’etichetta “anonymous” può allarmare. Tuttavia, questi casi, nella stragrande maggioranza, rappresentano flussi cloud‑to‑cloud legittimi, dove un servizio Microsoft agisce da front‑end, reverse‑proxy o broker di autenticazione e presenta un token a nome dell’utente.

Perché nei log compaiono indirizzi Microsoft

Gli indirizzi in oggetto appartengono ai blocchi pubblici di Microsoft/Azure. Quando un front‑end Microsoft gestisce sessioni, caching o validazione SSO, la richiesta che raggiunge i back‑end di identità non proviene più dall’IP del client, ma da un’uscita di data center o da un POP (Point of Presence) della rete Microsoft. Di conseguenza, nei log compare l’IP del data center, non quello del dispositivo finale.

Scenari tipici:

Servizi cloud‑to‑cloud: componenti come My Sign‑Ins, l’Azure portal, il portale di amministrazione di Microsoft 365, PowerShell in modalità “cloud shell” o agent Microsoft eseguono chiamate interne presentando token OAuth a nome dell’utente.
Accelerazione e caching: alcune regioni usano POP che terminano il TLS e inoltrano la richiesta; il back‑end vede l’IP del POP.
Controlli di sicurezza Microsoft: parte dell’autenticazione è centralizzata per mitigare attacchi e standardizzare la convalida dei token.

Come interpretare l’etichetta anonymous token

L’etichetta non indica che l’utente è sconosciuto o che l’accesso sia stato “anonimo” nel senso comune del termine. Di solito segnala che il flusso è stato gestito tramite token presentato da un servizio intermedio (ad esempio, un front‑end Microsoft) e non da un browser o app dell’utente che negozia passo‑passo username/password o MFA. È un’indicazione tecnica del tipo di autenticazione e del client che ha presentato il token.

In altre parole: l’utente reale esiste, il token contiene le relative claim (UPN, tenant, audience, scopi), ma a presentarlo al back‑end è stato un componente Microsoft. Non è, di per sé, una violazione.

Segnali per distinguere il traffico legittimo

Elemento di log	Cosa tipicamente si osserva	Perché accade	Cosa fare
Indirizzo IP	51.140.177.153 o 52.171.132.174	Uscite di data center/POP Microsoft	Verificare App, Resource, Location e User Agent; non bloccare a priori
Client App	Web app note come “OfficeHome”, “AzurePortal”, “MS Graph”	Front‑end Microsoft presenta il token	Confermare che l’App ID sia attesa nel tenant
Autenticazione	Flow basato su token; MFA “soddisfatta da claim”	Sessione già convalidata, uso di refresh/primary refresh token	Controllare Authentication Details e Conditional Access
Esito CA	Grant applicato, nessun bypass inaspettato	Policy coerenti con il profilo dell’utente	Se necessario, restringere con Named Locations e requisiti device
Identity Protection	Nessun evento “Impossible Travel” o “Atypical Travel”	Accesso interno alla rete Microsoft	Correrelarlo con il medesimo UPN e timeframe

Percorso operativo per la verifica

Procedura di indagine suggerita direttamente nei log di Entra ID:

Apri i Sign‑in logs del tenant e aggiungi le colonne utili: App, Resource, Client App, Conditional Access, Authentication Details, User Agent, Location, Correlation ID.
Applica un filtro su IP address con i valori 51.140.177.153 e 52.171.132.174.
Per ciascuna voce:
- Apri Token details e verifica le claim: UPN, appId, audience (resource), issuer, tenant, amr (metodi di autenticazione), scadenze.
- Controlla Conditional Access: la policy attesa è stata applicata? È stata richiesta MFA? Il device è conforme?
- Confronta User Agent, dispositivo e orario con l’attività attesa dell’utente (riunioni, orari d’ufficio, uso di app Microsoft).
- Annota Correlation ID e Timestamp per eventuale escalation al supporto.

Verifica con query KQL su Log Analytics

Se i log sono instradati in Log Analytics, puoi eseguire query mirate per accelerare l’analisi.

// Accessi da specifici indirizzi Microsoft
SigninLogs
| where IPAddress in ("51.140.177.153","52.171.132.174")
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, LocationDetails, ClientAppUsed, ConditionalAccessStatus,
          AuthenticationRequirement, AuthenticationProcessingDetails, CorrelationId
| order by TimeGenerated desc

// Vista per utente per capire se è un normale SSO di portale o un'anomalia
SigninLogs
| where UserPrincipalName =~ "[nome.cognome@dominio.tld](mailto:nome.cognome@dominio.tld)"
| summarize count() by AppDisplayName, ClientAppUsed, IPAddress

// Correlazione con Identity Protection (se presente)
let suspiciousIPs = dynamic(["51.140.177.153","52.171.132.174"]);
let window = 1d;
SigninLogs
| where IPAddress in (suspiciousIPs)
| join kind=leftouter (
IdentityProtection_RiskEvents
| project CorrelationId, RiskDetail, DetectedDateTime, RiskLevelAggregated
) on CorrelationId
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
RiskLevelAggregated, RiskDetail, DetectedDateTime, CorrelationId

// Quando il front-end presenta il token (spesso si vede "token" come AuthenticationRequirement)
SigninLogs
| where IPAddress in ("51.140.177.153","52.171.132.174")
| summarize dcount(CorrelationId), makeset(AppDisplayName), makeset(ClientAppUsed) by AuthenticationRequirement

Rafforzare la postura di sicurezza

Anche quando il traffico è legittimo, conviene adottare misure che riducano i falsi positivi e impediscano abusi.

MFA e Conditional Access: imponi MFA a tutti gli utenti con policy differenziate per ruoli sensibili; richiedi device conformi o ibridi AAD join per l’accesso ad app di amministrazione.
Named Locations: definisci gli intervalli IP delle tue sedi o dei tuoi partner; usa queste location come condizione nelle policy per ridurre l’attrito e aumentare la visibilità sugli accessi realmente esterni.
Session controls: applica Continuous Access Evaluation e segnali di rischio in tempo reale; limita la durata delle sessioni per le app critiche.
Ruoli privilegiati: obbliga all’uso di PIM per attivare privilegi a tempo; attiva notifiche su accessi privilegiati da reti non attese.

Correlazione con segnali di rischio

Prima di classificare un evento come malevolo, verifica i segnali di rischio nel medesimo intervallo temporale:

Impossible Travel o Unfamiliar Sign‑in Properties: se assenti, l’accesso da IP Microsoft è più verosimilmente un flusso cloud‑to‑cloud.
Eventi di password spray o account lockout: la loro assenza rafforza l’ipotesi di attività legittima.
Alert di Defender for Cloud Apps o di Microsoft 365 Defender correlati allo stesso UPN.

Inventario e classificazione degli indirizzi Microsoft

Per evitare allarmi ricorrenti, documenta e mantieni aggiornato un inventario dei prefissi IP pubblici Microsoft. Il catalogo ufficiale è disponibile come file JSON legato ai Service Tags della Public Cloud. Puoi usarlo per distinguere nelle regole di sicurezza il traffico interno Microsoft dal traffico esterno generico.

Esempio di parsing del JSON con PowerShell

Questo esempio carica il file dei Service Tags, estrae i prefissi relativi al tag generico della cloud pubblica e li salva per uso in firewall o sistemi di log enrichment:

# Percorso al file JSON dei Service Tags della Public Cloud
$jsonPath = "C:\Dati\ServiceTagsPublicCloud.json"

Carica il JSON

$data = Get-Content $jsonPath -Raw | ConvertFrom-Json

Estrai tutti i prefissi appartenenti al tag "AzureCloud"

$azureCloud = $data.values | Where-Object { $_.name -like "AzureCloud*" }

Colleziona i prefissi unici (IPv4)

$prefixes = $azureCloud.properties.addressPrefixes | Where-Object { $_ -match "^\d+." } | Sort-Object -Unique

Salva in CSV per uso su firewall o SIEM

$prefixes | ForEach-Object { [PSCustomObject]@{ Prefix = $_ } } |
Export-Csv "C:\Dati\AzureCloud_IPv4.csv" -NoTypeInformation -Encoding UTF8

Nota: i Service Tags sono l’approccio raccomandato per firewall Azure e appliance che li supportano. Non è pratico né consigliabile replicarli dentro le policy di Conditional Access; usa invece Named Locations per gli IP delle tue sedi e lascia che i controlli CA valutino risk signal, device e MFA.

Best practice per il triage

Evita blocchi “a martello”. Impedire gli IP di data center Microsoft può interrompere portali e servizi essenziali.
Classifica e sopprimi i falsi positivi: arricchisci gli eventi nel SIEM marcando i range Microsoft come “Infrastruttura Microsoft”.
Conserva i Correlation ID: rendono più rapida un’eventuale indagine con il supporto.
Normalizza i User Agent: crea regole che distinguano agent di portale/servizi da browser utente.

Esempi di casi reali

Apertura del portale Entra: l’utente accede a My Sign‑Ins per vedere gli accessi recenti; parte del rendering viene gestito da front‑end Microsoft che richiama API con token esibito dal POP, generando log con “anonymous token”.
Uso di OfficeHome: la home di Microsoft 365 chiama backend Graph e servizi correlati; in alcune regioni le richieste appaiono con IP del data center.
Sessioni lunghe con refresh token: l’utente non reinserisce credenziali per giorni; i backend vedono token rinnovati tramite servizi Microsoft.

Quando preoccuparsi davvero

Indizi che meritano approfondimento:

App sconosciuta o non attesa (AppDisplayName inconsueto) associata agli IP in oggetto.
Bypass inattesi di Conditional Access o assenza della richiesta MFA quando dovrebbe essere obbligatoria.
Coincidenza con alert di rischio medio/alto, password spray, anomalie di geolocalizzazione sugli stessi account.
Attività fuori orario o su utenze privilegiate non giustificata.

Procedure di escalation

Se restano dubbi dopo la revisione:

Raccogli esempi con Timestamp preciso, Correlation ID, UPN, AppDisplayName e ResourceDisplayName.
Apri un ticket verso il supporto Microsoft includendo il materiale raccolto e specificando che gli eventi sono etichettati “anonymous token” con gli IP indicati.

Domande frequenti

Posso bloccare gli IP 51.140.177.153 e 52.171.132.174?
Sconsigliato. Sono parte delle uscite Microsoft; un blocco può avere effetti collaterali su portali e API.

Perché vedo MFA “soddisfatta” se l’utente non ha appena approvato nulla?
Perché la sessione è ancora valida o perché un servizio sta presentando un token già rafforzato da MFA. Verifica la scadenza delle claim e la timeline dell’utente.

Perché a volte compare la geolocalizzazione in paesi che non sono i miei?
I POP e i data center Microsoft possono trovarsi in località diverse dal client. Non è un indicatore, da solo, di compromissione.

Posso usare i Service Tags nel Conditional Access?
No, i Service Tags sono pensati per firewall e NSG. In Conditional Access usa Named Locations per i tuoi IP e lascia che le policy valutino rischio, device e identità.

Checklist rapida di indagine

Conferma che gli IP appartengono a Microsoft (sono tipici delle uscite di data center).
Apri Token details e verifica claim, App ID e Resource.
Controlla risultati delle policy di Conditional Access e MFA.
Correla con Identity Protection e con eventuali alert di Defender.
Valida User Agent, dispositivo e orario rispetto all’attività attesa.
Documenta i Service Tags per ridurre futuri falsi positivi.
Escala con Correlation ID e Timestamp se gli indizi restano incongruenti.

Esempio di playbook operativo

Raccolta: estrai gli eventi dai Sign‑in logs filtrando per IP e UPN interessati.
Analisi: verifica claim del token, app e resource, stato delle policy CA, timeline dell’utente.
Decisione: classifica come “legittimo cloud‑to‑cloud” se tutto è coerente; in alternativa, apri ticket e applica controlli aggiuntivi (ad esempio, richiedi MFA reauth per app sensibili).
Prevenzione: arricchisci i log nel SIEM, aggiorna l’inventario degli IP Microsoft e rivedi le policy CA.

Indicazioni pratiche per ridurre i falsi positivi

Abilita Sign‑in risk policy per imporre MFA quando i segnali lo richiedono, non quando gli IP sono semplicemente di infrastruttura Microsoft.
Usa Authentication strength per le app amministrative e imposta metodi robusti (ad esempio, passkey o FIDO2) per i ruoli privilegiati.
Attiva Continuous Access Evaluation per revocare in tempi rapidi i token in caso di variazioni di rischio.
Monitora i Service principals critici e limita il consent alle app di terze parti.

Conclusioni

Gli accessi che riportano 51.140.177.153 e 52.171.132.174 con “anonymous token” sono generalmente il risultato di flussi cloud‑to‑cloud in cui un front‑end Microsoft presenta un token a nome dell’utente. Non indicano, di per sé, una compromissione. La chiave è validare App ID, Resource, policy di Conditional Access, timeline e segnali di rischio. Con l’inventario aggiornato dei Service Tags, l’uso accorto di Named Locations, MFA e Identity Protection, ridurrai sensibilmente i falsi positivi mantenendo alto il livello di sicurezza senza interrompere i normali percorsi di autenticazione gestiti da Microsoft.

Sintesi del problema

Un amministratore osserva accessi a portali Microsoft 365/Azure con IP 51.140.177.153 e 52.171.132.174, etichettati “anonymous token” nei log di Entra ID. Poiché tali sessioni eseguono SSO a nome dell’utente, inizialmente sono state considerate sospette.

Soluzione e spiegazione

IP appartenenti a Microsoft: gli indirizzi rientrano nei blocchi pubblici Microsoft/Azure. Quando un servizio funge da reverse‑proxy, emette token o valida SSO, nei log appare l’IP del data center.
anonymous token nei log: l’etichetta segnala un flusso basato su token (OAuth 2.0/WS‑Fed) in cui un front‑end Microsoft presenta il token a nome dell’utente. Non è un’anomalia di per sé.
Perché avviene:
- Servizi cloud‑to‑cloud: funzioni come My Sign‑Ins, portali amministrativi, PowerShell e agent Microsoft lavorano internamente e rilasciano token dai propri IP.
- Caching e acceleratori: alcune regioni usano POP che terminano TLS e inoltrano le richieste.
- Controlli di sicurezza Microsoft: parte dell’autenticazione è centralizzata per ridurre la superficie di attacco.

Azioni raccomandate

Verificare che le sessioni siano legittime
- Confrontare User Agent, app client, ora e dispositivo con l’attività attesa.
- Usare i Dettagli token nei log di Entra ID per controllare Claim, App ID e Resource.
Abilitare o rafforzare MFA/Conditional Access
- Imporre MFA e policy che permettano l’accesso solo da dispositivi o location attese.
Correlare con avvisi di rischio
- Verificare Identity Protection (Impossible Travel, Atypical Travel) e i report correlati allo stesso UPN.
Documentare la gamma IP di Microsoft
- Salvare il file JSON pubblico dei Service Tags della Public Cloud e creare regole di sicurezza che distinguano traffico interno Microsoft da traffico esterno.
Aprire un ticket se persistono dubbi
- Se non si riesce a collegare l’attività a processi noti, aprire un caso presso il supporto Microsoft con Correlation ID e Timestamp.

Nota pratica

È normale che in un tenant cloud compaiano accessi da IP Microsoft; la validazione deve concentrarsi su:

l’App ID che identifichi un servizio noto (ad esempio “OfficeHome”, “AzurePortal”);
la conferma che l’utente abbia completato l’MFA o che sia in corso un token passthrough previsto (ad esempio, refresh token di Outlook).

Con una revisione periodica dei log e le misure sopra elencate, si riducono i falsi positivi e si mantiene elevato il livello di sicurezza senza bloccare i normali flussi di autenticazione gestiti da Microsoft.

Modelli operativi aggiuntivi

Allerta su IP Microsoft: nel SIEM, crea una regola a bassa severità che tagga gli accessi da IP Microsoft come “Infrastruttura Microsoft” invece di generare incidenti.
Revisione trimestrale: sincronizza i Service Tags con i sistemi di sicurezza e rinnova le eccezioni documentate.
Formazione: spiega ai SOC analyst cosa significa “anonymous token” per evitare escalation inutili.