Comptes et authentification
Particuliers et entreprisesPiratage de compte
Account takeover
Quelqu’un utilise votre compte sans votre accord et profite de ses accès.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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
Votre compte est piraté lorsque quelqu’un l’utilise sans votre accord. Cette personne peut avoir obtenu votre mot de passe, volé une session, trompé une procédure de récupération ou profité d’un accès accordé par erreur à une application. La messagerie mérite une attention particulière : elle sert souvent à réinitialiser d’autres comptes. Pour reprendre le contrôle, vérifiez aussi les appareils connectés, les moyens de récupération et les autorisations données à d’autres personnes ou applications.
- 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Vérifiez les transferts de courrier, les délégations à d’autres comptes, les applications autorisées et les sessions ouvertes. Ces accès peuvent continuer à fonctionner après le changement du mot de passe.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un compte connecté crée des accès que son titulaire ne reconnaît pas
Le compte u12 ouvre la session s8, ajoute un moyen de récupération, crée un transfert de courrier et autorise l’application app9. Examinez ces actions ensemble. Elles donnent une piste plus solide qu’une adresse IP inhabituelle, qui pourrait simplement venir d’un VPN ou d’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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àGroupeScattered Spider / Octo Tempest
Le support et les identités comme portes d’entrée
Les attaquants imitent des contacts de confiance, appellent l’assistance et détournent des numéros de téléphone. Pour prendre le contrôle des comptes, ils associent hameçonnage, interception de connexions et pression pour faire accepter les validations MFA.
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
Noms et appellations : NOBELIUM / APT29
Quelques mots de passe essayés sur plusieurs comptes
Une attaque par pulvérisation de mots de passe atteint un ancien compte de test sans MFA. Microsoft décrit ensuite des autorisations OAuth détournées pour accéder à des messageries. En limitant les essais sur chaque compte, les attaquants rendent leur activité moins visible.
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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
