Compromission de boîte mail M365 : check-list de réponse à incident

Une boîte compromise, c'est souvent tout le tenant

Un collaborateur clique sur un lien de phishing à 08h14. À 08h29, un attaquant basé à l'étranger a créé une règle de transfert automatique vers une adresse externe, exfiltré la boîte de réception et ajouté un appareil non géré à l'enregistrement MFA. Pour une PME de 40 personnes sans SOC dédié, la fenêtre de détection dépasse souvent 72 heures — précisément le seuil imposé par la nLPD pour notifier le PFPDT en cas de violation de données personnelles.

Vecteurs d'attaque et signaux d'alerte typiques

Comment l'accès initial est obtenu

Dans la majorité des incidents M365 traités sur des parcs de 20 à 150 endpoints, trois vecteurs concentrent plus de 80 % des cas :

• Adversary-in-the-middle (AiTM) phishing : un proxy transparent (Evilginx2, Modlishka) capture le cookie de session post-MFA. Le mot de passe et le second facteur TOTP ne suffisent plus à protéger le compte.
• Password spray sur legacy protocols : IMAP, POP3, SMTP AUTH et Basic Auth restent activés sur de nombreux tenants M365 Business Basic. Ces protocoles contournent le MFA conditionnel par design.
• Token theft via malware : un infostealer (Redline, Raccoon) extrait les tokens OAuth stockés dans %APPDATA%\Microsoft\Teams ou dans le profil Chrome, sans nécessiter de credentials.

Signaux faibles à surveiller

Sans SIEM, les journaux M365 restent accessibles via le portail Purview Compliance (auparavant Audit log) et via PowerShell (Search-UnifiedAuditLog). Les événements suivants doivent déclencher une investigation immédiate :

• Connexion depuis un pays non opérationnel (vérifier UserLoggedIn avec ClientIP géolocalisé hors CH/FR/DE/IT)
• Création d'une règle InboxRule avec action ForwardTo ou DeleteMessage
• Ajout d'un appareil dans Azure AD sans workflow d'approbation (événement Add registered owner to device)
• Téléchargement massif via Graph API ou OWA (> 500 items en moins de 10 minutes)
• Changement du numéro de téléphone MFA ou suppression d'une méthode d'authentification forte

Procédure de confinement immédiat (0–2 heures)

La priorité absolue est d'invalider l'accès sans alerter l'attaquant ni détruire les preuves. L'ordre des opérations est critique.

1. DSI / RSSI — Révoquer toutes les sessions actives : dans le portail Azure AD, aller sur l'utilisateur concerné → Révoquer les sessions. En PowerShell : Revoke-AzureADUserAllRefreshToken -ObjectId <UPN>. Cette action invalide tous les refresh tokens, y compris les cookies de session volés.
2. DSI — Désactiver le compte sans le supprimer : bloquer la connexion (AccountEnabled = false) plutôt que de réinitialiser immédiatement le mot de passe. Une réinitialisation prématurée peut déclencher une alerte côté attaquant s'il monitore le compte.
3. RSSI — Exporter les journaux avant toute remédiation : Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -UserIds user@domaine.ch -ResultSize 5000 | Export-Csv audit.csv. Conserver également les logs de connexion Azure AD (rétention native : 30 jours P1, 7 jours E3 sans add-on).
4. DSI — Inventorier et supprimer les règles de boîte malveillantes : Get-InboxRule -Mailbox user@domaine.ch | Where-Object {$_.ForwardTo -ne $null -or $_.DeleteMessage -eq $true}. Documenter chaque règle avant suppression.
5. DSI — Révoquer les applications OAuth tierces non autorisées : Enterprise Applications → vérifier les consentements délégués. Une application malveillante avec scope Mail.Read ou Mail.ReadWrite persiste après réinitialisation du mot de passe.
6. RSSI — Identifier le périmètre de données exposées : quels dossiers ont été accédés ? Y a-t-il des pièces jointes contenant des données personnelles (RH, contrats clients, données médicales) ? Cette étape conditionne l'obligation de notification.

Investigation et qualification de l'incident (2–24 heures)

Déterminer la durée et l'étendue de l'accès

La corrélation entre les logs MailItemsAccessed (opération audit niveau E5 ou add-on Microsoft Purview Audit Premium) et les logs de connexion Azure AD permet de reconstituer une timeline précise. Sans licence adéquate, MailItemsAccessed n'est pas disponible — un angle mort fréquent dans les tenants Business Basic ou Standard.

Points clés à documenter dans le rapport d'incident :

• Première connexion suspecte (date, heure UTC, IP source, User-Agent)
• Nombre d'emails accédés ou téléchargés
• Présence de données soumises à la nLPD (art. 5 let. c : données personnelles sensibles, données de santé, données financières)
• Propagation latérale : d'autres comptes du tenant ont-ils reçu des emails de l'expéditeur compromis ? Des liens de phishing ont-ils été renvoyés depuis le compte ?
• Impact sur la chaîne de tiers : clients, partenaires, fournisseurs contactés depuis le compte compromis

Obligation de notification nLPD

Depuis le 01.09.2023, la nLPD impose de notifier le PFPDT dans les meilleurs délais dès que la violation de données personnelles est susceptible d'engendrer un risque élevé pour les personnes concernées. La loi ne fixe pas de délai chiffré à l'article 24, mais le PFPDT aligne son interprétation sur les 72 heures du RGPD pour les cas à risque élevé. La notification se fait via le formulaire en ligne sur edoeb.admin.ch.

Critères de risque élevé pertinents pour un incident M365 :

• Données de santé, données financières ou données RH exposées
• Volume > quelques dizaines de personnes concernées
• Risque concret d'usurpation d'identité ou de préjudice financier pour les personnes concernées
• Données de mineurs impliquées

La notification au PFPDT ne dispense pas d'informer les personnes concernées si le risque élevé est avéré (art. 24 al. 4 nLPD). La décision doit être documentée, qu'elle soit positive ou négative (obligation de tenir un registre des violations).

En parallèle, un signalement au NCSC est recommandé, même s'il reste volontaire pour les PME non critiques. Il contribue à la veille nationale sur les campagnes AiTM actives.

Remédiation et durcissement post-incident

Restaurer l'accès de façon sécurisée

1. Réinitialiser le mot de passe vers une valeur temporaire forte (≥ 16 caractères, générée aléatoirement)
2. Supprimer toutes les méthodes MFA existantes et ré-enrôler uniquement via FIDO2 ou Authenticator Number Matching — pas de SMS (SIM swapping) ni de TOTP seul
3. Réactiver le compte uniquement depuis un poste de travail sain, de préférence réinstallé ou provisionné via Autopilot
4. Placer le compte en surveillance renforcée (alertes sur chaque connexion) pendant 30 jours

Durcissement du tenant contre les prochaines attaques

Mesures à implémenter dans les 72 heures suivant l'incident :

• Désactiver Basic Auth sur tous les protocoles (bloquer BasicAuthentication via Authentication Policy)
• Activer les Security Defaults ou, mieux, déployer des Conditional Access policies avec Named Locations et Device Compliance
• Activer MailItemsAccessed audit si la licence le permet (Microsoft 365 E5 ou add-on Purview Audit Premium)
• Mettre en place une alerte automatique sur création de règles InboxRule via Microsoft Sentinel ou un SIEM tiers
• Restreindre le consentement OAuth utilisateur : bloquer le consentement pour les apps non vérifiées (Admin consent required)
• Vérifier l'alignement avec les CIS Benchmarks Microsoft 365 (niveau 1 minimum, niveau 2 pour les tenants avec données sensibles)

Cas pratique : fiduciaire vaudoise, 35 employés

Contexte : Cabinet fiduciaire basé à Lausanne, 35 collaborateurs, tenant M365 Business Standard, pas de Conditional Access actif, MFA déployé à 70 % (TOTP via Authenticator). Un associé senior reçoit le 14.03.2024 à 07h52 un email imitant un avis de versement PostFinance. Il clique, entre ses credentials sur une page AiTM. L'attaquant dispose d'une session valide à 07h58.

Étendue de la compromission détectée :

• Session active pendant 61 heures avant détection (alerte manuelle d'un client surpris de recevoir un email suspect)
• 3 règles de transfert créées vers une adresse Gmail externe
• Estimation de 2 200 emails accédés (reconstruction partielle via logs de connexion, sans MailItemsAccessed)
• Pièces jointes identifiées : déclarations fiscales de 47 clients personnes physiques, bilans de 12 sociétés avec données salariales

Décision de notification : présence de données personnelles sensibles (données financières, salaires) pour un volume supérieur à 40 personnes physiques → risque élevé qualifié. Notification au PFPDT effectuée le 16.03.2024 à 16h30 (soit < 72 h après détection à 09h00 le 14.03). Notification individuelle aux 47 clients personnes physiques envoyée le 18.03.2024.

Coût estimé de l'incident :

• Analyse forensique externe (4 jours·homme) : CHF 4 800
• Communication juridique clients + conseil externe : CHF 2 200
• Perte de facturation associé senior pendant 3 jours : CHF 3 600
• Upgrade licences vers M365 Business Premium (add-on Entra ID P1 + Defender) pour 35 postes : CHF 7 fois 35 = CHF 245/mois supplémentaires
• Total incident (one-shot) : environ CHF 10 600 + surcoût récurrent CHF 245/mois

Procédure suivie étape par étape :

1. 09h00 14.03 — Alerte client → DSI notifié, session révoquée, compte désactivé
2. 09h30 — Export audit log 30 jours, identification des 3 règles de transfert, suppression
3. 10h15 — Identification des apps OAuth : 2 applications tierces révoquées
4. 11h00 — Briefing associés + juriste : qualification du risque nLPD
5. 14h00 — Reconstitution timeline avec prestataire externe, inventaire des données exposées
6. 15.03 — Décision notification PFPDT actée, rédaction du rapport
7. 16.03 16h30 — Soumission notification PFPDT via formulaire edoeb.admin.ch
8. 17.03 — Réactivation compte avec nouveau MFA FIDO2, Conditional Access déployé
9. 18.03 — Envoi courriers recommandés aux 47 clients personnes physiques
10. 25.03 — Audit CIS Benchmark M365 niveau 1, 14 points de remédiation ouverts

Checklist opérationnelle

1. Révoquer immédiatement toutes les sessions de l'utilisateur compromis (Azure AD → Révoquer les sessions + Revoke-AzureADUserAllRefreshToken)
2. Désactiver le compte sans réinitialiser le mot de passe tant que les logs ne sont pas exportés
3. Exporter les journaux d'audit unifiés et les logs de connexion avant toute modification — rétention limitée à 7 ou 30 jours selon la licence
4. Supprimer les règles de boîte malveillantes et révoquer les applications OAuth non autorisées
5. Qualifier le risque nLPD : données personnelles exposées ? Volume ? Sensibilité ? Décision documentée dans le registre des violations
6. Notifier le PFPDT dans les 72 heures si risque élevé avéré (formulaire edoeb.admin.ch) — notifier les personnes concernées si le risque individuel est concret
7. Signaler volontairement au NCSC pour contribuer à la veille sur les campagnes actives
8. Ré-enrôler le MFA sur un facteur résistant au phishing (FIDO2, Authenticator Number Matching) avant de réactiver le compte
9. Désactiver Basic Auth sur l'ensemble du tenant (Authentication Policy + blocage IMAP/POP3/SMTP AUTH)
10. Auditer la configuration tenant contre les CIS Benchmarks M365 et ouvrir un plan de remédiation daté avec responsables nommés

SynGuard accompagne les PME romandes dans la mise en place de ces contrôles MDM et d'une supervision continue des tenants M365 — sans remplacer la nécessité d'un plan de réponse à incident documenté en interne.

Sources

• nLPD — Loi fédérale sur la protection des données (RS 235.1), fedlex.admin.ch — texte consolidé de la nouvelle LPD en vigueur depuis le 01.09.2023, notamment art. 24 sur la notification des violations.
• PFPDT / FDPIC — Préposé fédéral à la protection des données et à la transparence — autorité compétente pour la notification des violations de données personnelles en Suisse.
• NCSC — Cyberrisques pour les entreprises, ncsc.admin.ch — conseils pratiques du Centre national pour la cybersécurité destinés aux PME suisses.
• CIS Benchmark Microsoft 365, cisecurity.org — référentiel de durcissement niveau 1 et 2 pour les tenants M365, base de tout audit de configuration post-incident.
• NIST Cybersecurity Framework, nist.gov — cadre de référence pour structurer les fonctions Identify, Protect, Detect, Respond, Recover dans une organisation.