Comptes et authentification
Particuliers et entreprisesPiratage de compte
Account takeover
Une autre personne utilise votre compte et ses possibilités à votre place.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Votre messagerie semble fonctionner, mais des messages disparaissent et des contacts reçoivent des demandes d’argent. Un tiers peut utiliser le compte en parallèle, sans vous en retirer immédiatement l’accès. Il peut également modifier les coordonnées de récupération pour vous empêcher de reprendre la main.
Comment cela fonctionne
Un compte piraté est un compte utilisé sans votre autorisation. Le point d’entrée peut être un mot de passe divulgué, une session volée, une application autorisée par erreur ou une récupération détournée. Le compte de messagerie est particulièrement important parce qu’il permet souvent de réinitialiser d’autres comptes. Reprendre le mot de passe ne suffit pas toujours : il faut aussi vérifier les sessions, les moyens de récupération et les accès délégués.
- Un accès est obtenu
Secret, session ou récupération détournés.
- Le compte sert à un tiers
Messages, documents et actions sont exposés.
- L’intrus peut conserver un accès
Il ajoute une application ou modifie la récupération du compte.
Les signes qui doivent attirer l’attention
- Des connexions ou appareils inconnus apparaissent dans l’historique.
- Des messages, règles de classement ou coordonnées de récupération ont changé.
- Un service vous avertit d’une action que vous n’avez pas effectuée.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Utilisez un mot de passe différent par service et activez la double authentification. Pour reprendre un compte, vérifiez aussi les appareils connectés, les applications autorisées et les coordonnées de récupération.
Si vous êtes responsable du service ou de l’organisation
Préparez une procédure de reprise qui couvre les sessions, les transferts de courrier et les autorisations d’applications. Le support doit vérifier l’identité par un canal non compromis.
Pouvoir encore se connecter ne signifie pas être le seul à utiliser le compte.
À vous de décider
Vous avez repris votre mot de passe, mais des courriels partent encore ailleurs. Que vérifier ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Les règles de transfert, délégations, applications et sessions encore autorisées. Ces accès ne disparaissent pas nécessairement avec le changement de mot de passe.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un compte connecté crée des accès que son titulaire ne reconnaît pas
Le compte u12 ouvre une nouvelle session s8, ajoute un moyen de récupération, crée un transfert de courrier et autorise l’application app9. C’est cet enchaînement qui mérite une investigation. Une adresse IP inhabituelle, seule, pourrait correspondre à un VPN ou à un déplacement.
Le champ mfa=token_claim signifie ici que le jeton porte une authentification déjà satisfaite. Il ne prouve pas que le titulaire vient de valider une demande MFA. Il faut retrouver l’authentification d’origine, puis les actions effectuées avec la session. Lorsque les services n’utilisent pas le même identifiant de session, le rapprochement par compte et horaire reste une hypothèse à vérifier.
Le changement de mot de passe de 09:25 ne suffit pas à fermer tous les accès. Un consentement OAuth, une règle de transfert ou un moyen de récupération ajouté peuvent subsister. La réponse doit donc porter sur les sessions, les délégations et les paramètres du compte. Pour établir les données exposées, examiner l’audit du courrier et des fichiers : le journal de connexion ne décrit pas ce qui a été lu.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Authentification ou réutilisation de token
Titulaire / tiers vers Fournisseur d’identité
Trace s8
- Action
Session acceptée
Fournisseur d’identité vers Service SaaS
Trace mfa=token_claim
- Action
Ajout récupération et consentement
Service SaaS vers Délégations
Trace m7 / app9
- Action
Règle de transfert externe
Service SaaS vers Délégations
Trace Audit courrier
- Action
Changement de mot de passe
Titulaire / tiers vers Fournisseur d’identité
- Action
Accès délégué potentiellement encore valide
Délégations vers Service SaaS
Trace À vérifier
- Action
Révocations spécifiques après inventaire
Fournisseur d’identité vers Délégations
Trace Preuve de refus
Comment repérer cette attaque
Indices à rechercher
Rechercher les ajouts de moyens de récupération, les transferts externes et les consentements à des applications que le titulaire ne reconnaît pas. Examiner aussi les sessions anciennes : un accès détourné ne commence pas toujours par une nouvelle connexion.
Éléments à croiser
Construire une chronologie par compte, puis comparer les identifiants de session ou de corrélation lorsqu’ils existent. Ne pas supposer que les identifiants Entra et Exchange sont interchangeables.
Limites de l’interprétation
Une géolocalisation inhabituelle peut venir d’un VPN. Ce sont les actions non reconnues et leur contexte qui établissent l’abus ; le changement du mot de passe ne prouve pas la révocation de tous les accès.
Comment réagir
Depuis une identité fiable, retirer les sessions et capacités non reconnues, corriger les moyens de récupération puis renouveler les secrets exposés. Conserver la chronologie et les permissions des applications avant révocation. Vérifier que l’accès au courrier et aux données ne reste pas possible par une délégation différente.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Une session de test révoquée ne doit plus lire une ressource protégée.
- Une application retirée doit perdre l’accès selon les délais documentés du fournisseur.
- Le titulaire doit retrouver des moyens de récupération contrôlés et aucune règle de transfert inconnue.
À vous de raisonner
Le mot de passe a changé, mais une application inconnue reste autorisée et un transfert de courrier reste actif. Peut-on rendre le compte à son titulaire en l’état ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Il reste des accès à traiter : retirez les autorisations et règles inconnues, vérifiez les moyens de récupération et révoquez les sessions concernées. Contrôlez ensuite leur refus effectif. Le journal des connexions seul ne permet pas de connaître les messages ou fichiers déjà consultés.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
token_claim- Raccourci du scénario pour une MFA reconnue via une preuve antérieure ; ce n’est pas le libellé à rechercher tel quel dans chaque export Entra.
Chronologie d’un compte détourné
JournalTraces synthétiques ; les sessions et facteurs sont des identifiants fictifs.
09:00Z identity actor=u12 session=s1 ip=192.0.2.10 result=success mfa=performed
09:17Z identity actor=u12 session=s8 ip=198.51.100.40 result=success mfa=token_claim
09:18Z account actor=u12 session=s8 action=add_recovery_method method=m7
09:19Z mail actor=u12 session=s8 action=create_forward_rule destination=external
09:20Z oauth actor=u12 session=s8 action=grant_consent app=app9 scope=mail.read
09:25Z response actor=u12 action=password_resetPréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Relever compte, application, adresse IP, appareil, résultat et détails d’authentification. Distinguer une MFA effectuée à cet instant d’une exigence satisfaite par une authentification antérieure.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Microsoft Entra ID — Audit logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Audit logs. Filtrer les changements sur le compte ou l’application, puis ouvrir les détails de l’activité.
- Quoi relever
- Chercher les ajouts de moyens de récupération et les consentements à une application : acteur initiateur, compte ou application cible, propriétés modifiées et résultat.
- Accès et prérequis
- Droits de lecture et rétention suffisants. Ces journaux décrivent des modifications d’annuaire ; ils ne recensent pas toutes les lectures effectuées dans une boîte mail.
Microsoft 365 — audit dans Microsoft Purview
- Où les trouver
- Portail Microsoft Purview → Audit : rechercher par utilisateur, période et activité, puis exporter les résultats détaillés du service concerné, par exemple Exchange ou SharePoint.
- Quoi relever
- Dans l’audit Exchange, rechercher les créations ou modifications de règles de boîte et le transfert de messages. Vérifier les paramètres de la règle, pas seulement son nom.
- Accès et prérequis
- Rôle d’audit requis. Les activités disponibles et la durée conservée varient selon la licence et la configuration ; vérifier la couverture avant d’interpréter une absence.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àGroupeScattered Spider / Octo Tempest
Le support et les identités comme portes d’entrée
Des attaquants usurpent des interlocuteurs de confiance, appellent l’assistance et détournent des numéros de téléphone. Ils combinent hameçonnage, interception de connexions et pression sur les validations MFA pour prendre le contrôle de comptes.
Ce qu’établit la source. Microsoft décrit Octo Tempest comme un périmètre recoupant Scattered Spider, 0ktapus et UNC3944. Ces noms de suivi ne sont pas nécessairement des synonymes exacts.
Consulter le rapport Octo Tempest crosses boundaries to facilitate extortion, encryption, and destructionMicrosoft · Publié le
- àGroupeMidnight Blizzard
Repères de nommage : NOBELIUM / APT29
Quelques mots de passe essayés sur plusieurs comptes
Une attaque par pulvérisation de mots de passe compromet un ancien compte de test sans MFA. Microsoft décrit ensuite l’abus d’applications OAuth pour accéder à des messageries. Le faible nombre d’essais par compte contribue à la discrétion de l’attaque.
Ce qu’établit la source. Microsoft attribue l’intrusion à Midnight Blizzard après sa détection en janvier 2024. Les premiers accès remontent à novembre 2023.
Consulter le rapport Midnight Blizzard: Guidance for responders on nation-state attackMicrosoft · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Depuis un appareil fiable, utilisez le parcours officiel de récupération si nécessaire.
- Changez le secret exposé, révoquez les sessions et supprimez les moyens de récupération inconnus.
- Contrôlez règles, délégations et applications, puis prévenez les contacts réellement exposés.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Valid Accounts — attack.mitre.org
- MITRE ATT&CK — Account Manipulation — attack.mitre.org
- Microsoft — détails des connexions Entra — learn.microsoft.com
- OWASP — Session Management — cheatsheetseries.owasp.org
