Vous voyez des connexions à Azure/Office 365 depuis 51.140.177.153 ou 52.171.132.174 avec l’alerte « Anomalous Token » ? Voici comment déterminer s’il s’agit d’une activité Microsoft légitime ou d’un vrai incident, et quelles actions appliquer immédiatement.
Contexte et symptômes
Un administrateur découvre dans les journaux Microsoft Entra ID (ex‑Azure AD) des connexions aux portails Microsoft (Azure, Microsoft 365, My Sign‑Ins, etc.) depuis les adresses IP 51.140.177.153 et 52.171.132.174. Les événements sont parfois classés comme Single Sign‑On (SSO) ou signalés dans Identity Protection comme Anomalous Token. Ce scénario est courant : la difficulté est de distinguer service Microsoft agissant pour l’utilisateur d’une utilisation malveillante d’un jeton.
Ce que signifient ces adresses IP
Les plages 51.140.x.x et 52.171.x.x appartiennent à l’infrastructure Microsoft Azure. Elles peuvent apparaître comme origine d’authentification lorsqu’un service Microsoft :
- valide ou renouvelle un jeton OAuth/PRT/Refresh pour le compte de l’utilisateur ;
- exécute un flux SSO fédéré (par exemple via un relais de jeton) ;
- applique des contrôles de sécurité (Identity Protection, Smart Lockout, stratégies d’accès conditionnel, détection de risque) ;
- opère des processus non interactifs (applications de service, Managed Identity, Service Principal).
Il est donc attendu de voir parfois des adresses IP Microsoft dans les journaux de connexion, y compris lorsque l’utilisateur est physiquement ailleurs : c’est la conséquence normale d’architectures cloud distribuées et de relais de jetons.
Pourquoi l’alerte « Anomalous Token » apparaît
Identity Protection déclenche ce signal quand un jeton (ou son refresh token) est utilisé dans un contexte inattendu. Exemples typiques :
- réutilisation d’un jeton depuis un autre réseau ou une autre région peu après l’émission ;
- écart entre la télémétrie du client (navigateur/appareil) et les métadonnées du jeton ;
- activité non interactive qui reprend un jeton très longtemps après l’authentification initiale ;
- renouvellement de jeton par un service Microsoft hébergé dans un datacenter différent de la position habituelle de l’utilisateur.
Ce signal n’implique pas automatiquement une compromission ; il doit être corrélé aux autres indicateurs : MFA, résultats d’accès conditionnel, échecs de connexion, création de sessions persistantes, etc.
Grille de décision rapide
| Situation observée | Interprétation probable | Action conseillée |
|---|---|---|
| IP Microsoft, SSO non interactif, CA = success, MFA récent | Renouvellement de jeton par service Microsoft | Considérer bénin, surveiller la fréquence |
| IP Microsoft + « Anomalous Token » + refus MFA | Jeton possiblement volé ou réutilisation suspecte | Révoquer sessions, forcer réauthentification, MFA |
| IP Microsoft depuis pays inattendu, utilisateur inactif | Job de service / application de fond… ou pivot malveillant | Vérifier Service Principal / Managed Identity, limiter la portée |
| Multiples non-interactive sign-ins à cadence élevée | Application ou script utilisant un refresh token | Auditer l’app, régénérer secret/consentements |
| Connexion interactive inattendue + nouveaux appareils enregistrés | Risque d’intrusion utilisateur | Reset mot de passe, invalider refresh tokens, enquête complète |
Vérifications essentielles pas‑à‑pas
Examiner les journaux de connexions
- Dans le portail, ouvrez Sign‑ins et filtrez par IP address =
51.140.177.153ou52.171.132.174. - Contrôlez Client app (Interactive, Browser, Modern Auth, Non‑interactive), App display name (Exchange Online, SharePoint, Microsoft Teams…), et Conditional Access (appliquée, contournée, échouée).
- Ouvrez le détail d’authentification pour voir les étapes (MFA, fédération, session persistante).
Contrôler les sign‑ins à risque
- Dans Identity Protection, vérifiez Risky sign-ins et Risky users. Un cumul « Anomalous Token » + « Impossible travel » + échecs MFA est un indicateur fort.
- Si le risque est moyen/élevé, déclenchez réinitialisation mot de passe et revocation des sessions.
Rechercher des activités non interactives
- Inspectez Non‑interactive sign‑ins et Service principal sign‑ins. La présence de balises Service Principal ou Managed Identity indique une authentification de service.
- Vérifiez l’application (ID, propriétaire, consentements, permissions) et sa dernière rotation de secrets/certificats.
Valider la MFA et l’accès conditionnel
- Confirmez que la MFA est obligatoire pour les comptes à privilèges et enrôlée pour tous les utilisateurs.
- Mettez en place des Named Locations (plages d’IP de confiance) et des stratégies d’accès conditionnel adaptées (device compliant, sign‑in frequency, session persistante).
Comparer les IP aux plages officielles Microsoft
Microsoft publie un Service Tag IP Ranges JSON listant toutes ses plages. Téléchargez-le périodiquement et comparez vos journaux à ce référentiel pour lever les doutes. Cette vérification peut être automatisée (exemple plus bas).
Champs de journal à lire en priorité
| Champ | Ce qu’il indique | Comment l’interpréter |
|---|---|---|
| UserPrincipalName / AppDisplayName | Qui s’authentifie, vers quelle appli | Une app Microsoft (Exchange, SharePoint) + non‑interactive → probable renouvellement de jeton |
| ClientAppUsed | Type de client (Browser/Modern/Non‑Interactive) | Non‑interactive fréquent ≠ anormal si lié à une app/service connu |
| RiskDetail / RiskLevelAggregated | Signal de risque (Anomalous Token…) | À corréler avec MFA et CA ; isolé, il peut être bénin |
| ConditionalAccessStatus | Résultat des stratégies | « Failure » prévu ? Sinon, revoir les conditions et les emplacements nommés |
| IPAddress / Location | Origine réseau | IP Microsoft + pays inattendu : peut provenir d’un datacenter Microsoft |
| AuthenticationDetails | Étapes d’authentification | Présence/absence MFA, PRT, session persistante, claims anormales |
Scripts utiles pour accélérer l’enquête
PowerShell Microsoft Graph : filtrer les connexions
# Modules requis : Microsoft.Graph (Identity.SignIns)
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All","IdentityRiskEvent.Read.All","Policy.Read.All"
# Filtrer les sign-ins par IP
\$ips = @("51.140.177.153","52.171.132.174")
\$filter = (\$ips | ForEach-Object { "ipAddress eq '$\_'" }) -join " or "
Get-MgAuditLogSignIn -Filter \$filter -All |
Select-Object createdDateTime,userDisplayName,userPrincipalName,ipAddress,appDisplayName,clientAppUsed,conditionalAccessStatus,riskDetail,riskLevelAggregated |
Format-Table -AutoSize
# Non-interactive sign-ins (applis/services)
Get-MgAuditLogSignIn -Filter \$filter -All |
Where-Object { $\_.IsInteractive -eq \$false } |
Select-Object createdDateTime,userPrincipalName,appDisplayName,clientAppUsed,ipAddress
# Révoquer les sessions/refresh tokens d’un utilisateur
# Méthode moderne (Graph)
Invoke-MgInvalidateUserRefreshToken -UserId [user@contoso.com](mailto:user@contoso.com)
# Ancienne commande (AzureAD) si encore utilisée
# Revoke-AzureADUserAllRefreshToken -ObjectId \<ObjectId>
Sentinel / Log Analytics : requêtes KQL prêtes à l’emploi
// Connexions depuis les IP Microsoft signalées
SigninLogs
| where IPAddress in ("51.140.177.153","52.171.132.174")
| project TimeGenerated, UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, Location, ResultType, ResultDescription, ConditionalAccessStatus, RiskDetail, RiskLevelAggregated, IsInteractive
// Activité non-interactive inhabituelle
AADNonInteractiveUserSignInLogs
\| summarize count() by bin(TimeGenerated, 1h), IPAddress, AppDisplayName
\| order by count\_ desc
// Service Principals à l’origine d’authentifications depuis ces IP
AADServicePrincipalSignInLogs
\| where IPAddress in ("51.140.177.153","52.171.132.174")
\| project TimeGenerated, ServicePrincipalName, AppId, IPAddress, ResourceDisplayName, Status Comparer automatiquement vos logs au JSON des Service Tags
# Exemple de comparaison locale : journal CSV <-> Service Tag IP Ranges JSON
# $serviceTagsJson = Get-Content ".\ServiceTags_Public_<date>.json" | ConvertFrom-Json
# $signIns = Import-Csv ".\signins.csv" # export des Sign-in logs
function Test-IPInRanges {
param(\[string]\$Ip, \[array]\$Ranges)
foreach (\$r in \$Ranges) {
if (\$Ip -as \[ipaddress] -and \$r) {
\# Support CIDR
if (Test-CidrMatch -Ip \$Ip -Cidr \$r) { return \$true }
}
}
return \$false
}
# Implémentation simple de correspondance CIDR
function Test-CidrMatch {
param(\[string]\$Ip, \[string]\$Cidr)
\$parts = \$Cidr.Split("/")
\$network = \[System.Net.IPAddress]::Parse(\$parts\[0]).GetAddressBytes()
\$maskBits = \[int]\$parts\[1]
\$ipBytes = \[System.Net.IPAddress]::Parse(\$Ip).GetAddressBytes()
\$mask = \[byte\[]]@(0,0,0,0)
for (\$i=0;\$i -lt 4;\$i++) {
\$bits = \[Math]::Min(\[Math]::Max(\$maskBits - (8\*\$i), 0), 8)
\$mask\[\$i] = \[byte]\(0xFF -shl (8 - \$bits))
}
for (\$i=0;\$i -lt 4;\$i++) {
if ((\$ipBytes\[\$i] -band \$mask\[\$i]) -ne (\$network\[\$i] -band \$mask\[\$i])) { return \$false }
}
return \$true
}
# Exemple de récupération des plages Azure Public (filtrer sur Service Tag 'AzureActiveDirectory')
# \$aadRanges = \$serviceTagsJson.values | Where-Object { \$*.name -like "*AzureActiveDirectory*" } | ForEach-Object { \$*.properties.addressPrefixes }
# Marquer les entrées CSV
# \$signIns | ForEach-Object {
# $\_ | Add-Member -NotePropertyName "IsMicrosoftIP" -NotePropertyValue (Test-IPInRanges -Ip $\_.IPAddress -Ranges \$aadRanges)
# } | Export-Csv ".\signins\_enrichis.csv" -NoTypeInformation
Mesures préventives et correctives
- MFA obligatoire pour tous, avec méthodes robustes (application d’authentification, FIDO2, Passkeys) ; renforcez la Sign-in frequency selon la sensibilité.
- Accès conditionnel : exiger appareil conforme pour les ressources clés, bloquer les pays/locations non pertinents, créer des Named Locations correspondant à vos sites/SD‑WAN/VPN.
- Rotation des secrets et certificats d’applications ; appliquez la Managed Identity quand c’est possible.
- Supervision continue via Microsoft Defender for Cloud Apps et/ou Sentinel ; mettez des alertes sur Anomalous Token, Impossible travel et pics de non‑interactive sign‑ins.
- Hygiène de session : révoquez périodiquement les refresh tokens lors de changements sensibles (départs, incidents, renforcement MFA).
Quand faut‑il s’inquiéter ?
- Les adresses IP ne figurent pas dans les plages Microsoft officielles ou apparaissent en plus d’IP inconnues d’hébergeurs tiers.
- Des tentatives proviennent d’un pays sans lien avec vos opérations, et aucun service Microsoft n’est censé initier des connexions au départ de ce pays pour vos utilisateurs.
- Le signal « Anomalous Token » est accompagné de refus MFA, de réinitialisations forcées de jetons, d’inscriptions d’appareils inattendus ou de création de sessions persistantes inconnues.
Exemples concrets de scénarios bénins
- Un utilisateur s’authentifie au bureau, puis son navigateur garde une session active ; un service Microsoft renouvelle le jeton depuis un datacenter : l’IP source est Microsoft, sans action requise.
- Une application d’entreprise utilisant un daemon effectue des connexions non interactives régulières vers Exchange Online : IP Microsoft, fréquence stable, mêmes claims : attendu.
- Une stratégie d’accès conditionnel force une nouvelle MFA après X heures : le renouvellement peut être orchestré par un service Microsoft et générer un signal « Anomalous Token » isolé.
Plan d’intervention en 30 minutes
- Isoler le compte suspect : invalider les refresh tokens et exiger un reset de mot de passe.
- Corréler tous les événements de l’utilisateur sur 7/14 jours (Sign‑ins, Non‑interactive, Service Principals).
- Comparer les IP aux plages Microsoft (Service Tags JSON) et à vos emplacements nommés.
- Auditer les applications consenties (permissions, propriétaire, secrets/certs).
- Durcir MFA/CA (sign‑in frequency, session persistante désactivée sur les comptes sensibles).
Checklist d’administration
- Accès conditionnel : emplacements nommés définis et maintenus.
- Politiques de fréquence de connexion et de session persistante documentées.
- Rotation automatique des secrets/certificats d’applications.
- Alertes Sentinel sur IP Microsoft anormales + corrélation sur résultat CA/MFA.
- Procédure de révocation de jetons testée et connue des équipes.
FAQ rapide
Pourquoi vois‑je une IP Microsoft alors que l’utilisateur est en France ?
Parce qu’un service Microsoft peut renouveler ou valider un jeton depuis un datacenter différent. L’emplacement géographique de l’IP ne reflète pas forcément la position de l’utilisateur.
« Anomalous Token » implique‑t‑il une compromission ?
Pas nécessairement. C’est un signal. Seule la corrélation avec MFA, accès conditionnel, volume/rythme des événements, et d’autres indices (nouveaux appareils, applications consenties) permet de conclure.
Comment puis‑je réduire les faux positifs ?
Stabilisez les emplacements nommés, appliquez « device compliant » pour les applis sensibles, cadrez la fréquence d’authentification, et documentez les applications de service légitimes.
Procédure détaillée d’analyse avec exemple
Objectif : qualifier deux événements marqués « Anomalous Token » depuis 51.140.177.153 et 52.171.132.174.
- Extraction : exportez 14 jours de Sign‑ins (CSV). Filtrez sur les deux IP. Repérez les colonnes IsInteractive, ClientAppUsed, RiskDetail, ConditionalAccessStatus, AppDisplayName.
- Contexte utilisateur : vérifiez l’heure locale de l’utilisateur, son activité (Outlook, Teams), les MFA récents.
- Profil d’application : si AppDisplayName = « Exchange Online » et Non‑interactive toutes les 60–90 min, on est sans doute face à un refresh normal.
- Risque : si RiskLevelAggregated = none/low, ConditionalAccessStatus = success, et pas d’échec MFA, classez bénin et ajoutez une règle de surveillance.
- Escalade : si cumul de signaux (échecs MFA, nouveaux appareils, apps inconnues), lancez révocation de jetons, réinitialisation mot de passe, puis enquête élargie sur 30 jours.
Bonnes pratiques de configuration
- MFA au premier jour : mettez en place des méthodes modernes et éliminez le SMS quand c’est possible.
- Session management : désactivez « Rester connecté » sur les comptes à privilèges, réduisez la Sign‑in frequency pour les applications critiques.
- Accès conditionnel granulaire : créez des politiques spécifiques par rôle (administrateurs, VIP, comptes service) et par type d’application.
- Inventaire des applications : appliquez admin consent workflow, auditez périodiquement les permissions Graph, tournez les secrets <= 90 jours.
- Surveillance : alertez sur la combinaison « IP Microsoft + Anomalous Token + Non‑interactive + nouvel appareil ».
Modèles de requêtes additionnels
// Événements à risque « Anomalous Token » corrélés à des échecs MFA
SigninLogs
| where RiskDetail has "Anomalous Token"
| extend Mfa = tostring(parse_json(AuthenticationDetails)[0].authenticationStepResultDetail)
| where Mfa has "MFA denied" or Mfa has "MFA failure"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ConditionalAccessStatus, Mfa
// Pics de connexions par IP Microsoft (pour tuning de seuils)
SigninLogs
\| summarize count() by IPAddress, bin(TimeGenerated, 1h)
\| where IPAddress in ("51.140.177.153","52.171.132.174")
\| order by TimeGenerated desc
// Détection de nouveaux devices proches d'un Anomalous Token
DeviceInfo
\| join kind=innerunique (
SigninLogs | where RiskDetail has "Anomalous Token"
\| project UserPrincipalName, TimeGenerated
) on UserPrincipalName
\| where DeviceJoinTime between (TimeGenerated-1d .. TimeGenerated+1d) Pièges et faux positifs fréquents
- CDN/edge Microsoft : certaines proxifications peuvent modifier l’IP source apparente.
- VPN d’entreprise : une bascule de tunnel peut simuler un « voyage impossible ».
- Navigateurs mobiles : rotation d’IP par l’opérateur, entraînant un jeton réutilisé ailleurs.
- Synchronisation Outlook/Teams : activités non interactives légitimes souvent mal interprétées.
Conclusion
Voir 51.140.177.153 ou 52.171.132.174 dans vos journaux n’est pas, en soi, un signe de compromission : ces adresses appartiennent à Azure et sont souvent liées à des flux SSO ou à des renouvellements de jetons opérés par Microsoft. L’alerte « Anomalous Token » doit être traitée comme un déclencheur d’enquête : corrélez‑la avec MFA, accès conditionnel, nature interactive ou non de la connexion, fréquence et contexte utilisateur. En mettant en place MFA obligatoire, accès conditionnel bien calibré, surveillance continue et une procédure de révocation de jetons, vous réduisez drastiquement le risque réel tout en limitant les faux positifs.
Récapitulatif actionnable
- Filtrer immédiatement les Sign‑ins sur les deux IP et valider le contexte (interactive/non‑interactive, app, CA/MFA).
- Corréler avec les sign‑ins à risque et révoquer les sessions si doute.
- Comparer aux plages Microsoft via le JSON des Service Tags.
- Durcir MFA/CA : emplacements nommés, fréquence de connexion, appareils conformes.
- Automatiser la détection via KQL et scripts Graph.
Astuce : si l’événement mentionne Service Principal ou Managed Identity, il s’agit d’un service et non d’un humain. Vérifiez alors l’application (consentements, permissions, rotation des secrets) avant de conclure.