Compromission de boîte mail M365 : check-list de réponse pour PME suisses

Une boîte compromise, 72 heures pour agir

Un collaborateur clique sur un lien de phishing à 07h43. À 08h15, une règle de transfert automatique est créée silencieusement vers une adresse Gmail externe. À 10h30, l'attaquant commence à répondre à des e-mails de clients en se faisant passer pour le titulaire du compte. Dans une PME romande de 40 personnes sans SOC dédié, ce scénario passe souvent inaperçu pendant 48 à 72 heures — précisément le délai légal que la nLPD (nouveau droit suisse de la protection des données) impose pour notifier le PFPDT (Préposé fédéral à la protection des données et à la transparence) en cas de violation susceptible d'entraîner un risque élevé pour les personnes concernées.

Vecteurs d'attaque et signaux d'alerte

Comment les comptes M365 sont compromis

Les vecteurs les plus fréquents observés sur des parcs de 20 à 150 endpoints en Suisse romande :

• Phishing AiTM (Adversary-in-the-Middle) : proxy transparent qui capte le token de session OAuth 2.0 après authentification MFA réussie. L'attaquant dispose d'un token valide sans connaître le mot de passe. Outils courants : Evilginx2, Modlishka.
• Password spray : tentatives sur des comptes sans MFA activé (souvent comptes de service, boîtes fonctionnelles type info@, compta@).
• OAuth app consent phishing : l'utilisateur autorise une application tierce malveillante à accéder à sa boîte sans que le mot de passe soit jamais divulgué.
• Credential stuffing depuis des fuites de données antérieures (HaveIBeenPwned recense des millions de comptes suisses compromis).

Signaux d'alerte à surveiller dans les logs M365

Microsoft 365 génère des événements dans le journal d'audit unifié (Unified Audit Log, UAL). Les événements critiques à monitorer :

• Set-InboxRule avec action ForwardTo ou DeleteMessage — règle de transfert ou suppression automatique.
• Add-MailboxPermission — ajout d'un délégué sur la boîte.
• Connexions depuis des pays non habituels (plage IP hors Suisse/UE sans VPN légitime).
• UserLoggedIn depuis un User-Agent inhabituel (scripts PowerShell, MailClientVersion = EAS).
• ConsentToApplication — consentement OAuth accordé à une app non répertoriée.

Prérequis : l'UAL doit être activé (il ne l'est pas par défaut sur les tenants E1 anciens). La rétention par défaut est de 90 jours pour E3, 180 jours pour E5. Sans licence adéquate, les logs peuvent manquer au moment de l'investigation.

Containment immédiat — les 4 premières heures

Toute action de remédiation avant containment risque d'alerter l'attaquant et de déclencher une exfiltration accélérée ou une destruction de preuves. L'ordre des opérations est non négociable.

1. Révoquer toutes les sessions actives du compte compromis : dans le portail Entra ID (Azure AD), Révoquer les sessions + Réinitialiser le mot de passe. PowerShell : Revoke-AzureADUserAllRefreshToken -ObjectId <UPN>.
2. Désactiver le compte (pas supprimer — préservation des preuves) dans Entra ID et bloquer la connexion interactive.
3. Supprimer les règles de transfert malveillantes via Exchange Admin Center ou PowerShell : Get-InboxRule -Mailbox <UPN> | Remove-InboxRule. Documenter d'abord (screenshot + export CSV).
4. Révoquer les consentements OAuth suspects : Entra ID > Applications d'entreprise > filtrer par date de consentement.
5. Bloquer l'application tierce malveillante si OAuth app phishing confirmé : désactiver l'application dans le portail, révoquer le consentement pour tous les utilisateurs.
6. Isoler les endpoints associés : si l'attaquant a utilisé un device enrôlé (Autopilot ou MDM), isoler le device du réseau en attendant l'investigation forensique.

Investigation et périmètre de la violation

Reconstituer la timeline

L'UAL est la source centrale. Exporter via PowerShell (Search-UnifiedAuditLog) ou via l'outil de conformité Microsoft Purview. Cibler la fenêtre T-7 jours à partir du premier signal suspect. Points d'investigation :

• Quels e-mails ont été lus (opération MailItemsAccessed, disponible uniquement en E5 ou Microsoft 365 Business Premium avec Audit avancé) ?
• Des pièces jointes ont-elles été téléchargées via OWA ou EAS ?
• D'autres comptes ont-ils reçu des e-mails internes provenant du compte compromis après la compromission ?
• Le compte a-t-il été utilisé pour envoyer du phishing interne (mouvement latéral) ?

Qualification de la violation au sens nLPD

L'art. 24 nLPD impose une notification au PFPDT en cas de violation de la sécurité des données susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées. Les critères d'évaluation du risque élevé :

• Nature des données exposées : données sensibles (santé, situation financière, données personnelles de clients ou d'employés) augmentent le niveau de risque.
• Volume : même 50 contacts clients avec nom, e-mail et IBAN peut suffire à qualifier le risque élevé.
• Intentionnalité : une exfiltration active est plus grave qu'un accès en lecture isolé.
• Capacité à identifier les personnes : si les e-mails contenaient des devis nominatifs, des fiches de paie ou des communications médicales, le risque élevé est quasi certain.

Si le risque élevé est confirmé ou non écarté, la notification au PFPDT doit intervenir dans les meilleurs délais. Le PFPDT recommande de ne pas dépasser 72 heures, par analogie avec le RGPD. La procédure de signalement est disponible sur la page de notification du PFPDT.

Parallèlement, si les personnes concernées courent un risque concret (usurpation d'identité, fraude financière), elles doivent être informées directement (art. 24 al. 4 nLPD).

Remédiation et durcissement post-incident

Actions de remédiation sur le tenant

1. Réactiver le compte avec un nouveau mot de passe fort (≥16 caractères, générateur) et enrôlement MFA obligatoire (méthode FIDO2 ou Authenticator app — bannir SMS OTP).
2. Auditer les règles de boîte de tous les comptes (pas seulement le compte compromis) : Get-InboxRule -Mailbox * | Where-Object {$_.ForwardTo -ne $null}.
3. Activer la stratégie Conditional Access : bloquer les connexions depuis des pays non utilisés, exiger un device conforme (Intune Compliance Policy) pour accéder à Exchange Online.
4. Activer l'Audit avancé Microsoft Purview (nécessite E5 ou add-on) pour disposer de MailItemsAccessed lors des prochains incidents.
5. Déployer Microsoft Defender for Office 365 Plan 1 minimum (Safe Links, Safe Attachments, Anti-phishing avec protection AiTM via Defender XDR).
6. Restreindre le consentement OAuth aux applications approuvées uniquement (Entra ID > Paramètres utilisateur > Consentement d'application).
7. Activer DMARC en mode reject sur le domaine de messagerie, avec DKIM signé — réduit le risque d'usurpation du domaine vers des tiers.

Signalement au NCSC

La notification au NCSC (Centre national pour la cybersécurité) n'est pas obligatoire pour les PME non-OFI, mais elle est fortement recommandée. Elle permet d'alimenter la veille nationale et peut déboucher sur une assistance technique. Le signalement est confidentiel et gratuit.

Cas pratique : Fiduciaire vaudoise, 38 collaborateurs

Contexte : cabinet fiduciaire à Lausanne, 38 employés, tenant Microsoft 365 Business Standard (sans Audit avancé ni Defender for Office 365). Parc de 42 endpoints Windows 11 23H2, gérés via Intune. Pas de RSSI dédié — le DSI est aussi responsable infrastructure.

Incident : Le vendredi 14.03.2025 à 16h52, un associé reçoit un e-mail d'un client lui signalant qu'il a reçu une demande de virement de 18 500 CHF depuis l'adresse de la fiduciaire — demande qu'il n'a jamais émise. Investigation immédiate :

• Une règle de transfert vers comptabilite.backup@gmail.com était active depuis le 11.03.2025 à 09h14 sur la boîte du responsable administratif.
• L'UAL (90 jours de rétention, disponible) montre une connexion le 11.03.2025 depuis une adresse IP roumaine (AS 9009) à 08h47, avec un User-Agent correspondant à un navigateur Chrome sous Linux — inhabituel pour ce poste Windows.
• 3 e-mails contenant des devis signés et les coordonnées bancaires de 7 clients ont été lus via OWA entre 08h47 et 09h10.
• Le phishing initial date du 10.03.2025 : un faux e-mail Microsoft « Votre boîte est pleine » avec lien AiTM.

Procédure suivie (chronologie réelle) :

1. J0 — 17h05 : DSI révoque les sessions et désactive le compte dans Entra ID. Export UAL complet pour la période 08.03–14.03.
2. J0 — 17h30 : Suppression de la règle de transfert après documentation. Audit de toutes les InboxRules du tenant (38 boîtes) — aucune autre règle suspecte.
3. J0 — 18h00 : Qualification de la violation. Données exposées : noms, adresses, coordonnées bancaires de 7 clients (données financières = risque élevé quasi certain). Décision : notification PFPDT obligatoire.
4. J1 — 09h00 : Notification soumise au PFPDT via le formulaire en ligne. Contenu : nature de la violation, catégories de données, nombre de personnes concernées (7 clients identifiés), mesures prises.
5. J1 — 10h30 : Information directe des 7 clients par téléphone et e-mail sécurisé. Conseils donnés : surveiller les mouvements bancaires, signaler toute tentative de virement non sollicité.
6. J1 — 14h00 : Signalement au NCSC via le formulaire en ligne.
7. J2 — 09h00 : Réactivation du compte avec nouveau mot de passe, enrôlement FIDO2 (clé YubiKey 5 NFC, coût unitaire ~55 CHF). Activation Conditional Access — device conforme requis.
8. J7 : Déploiement Defender for Office 365 Plan 1 sur le tenant (~2 CHF/utilisateur/mois, ~76 CHF/mois). Formation anti-phishing AiTM pour les 38 collaborateurs (session 45 min, simulée).

Coût de l'incident : 6 heures DSI interne (estimé à ~150 CHF/h = 900 CHF), frais juridiques externes pour rédaction de la notification PFPDT et des courriers clients (~1 800 CHF), perte de confiance d'un client qui a résilié son mandat (valeur annuelle ~12 000 CHF). Total direct estimé : ~14 700 CHF — sans compter le temps de la direction.

Le virement de 18 500 CHF n'a pas abouti : le client avait rappelé le cabinet avant d'exécuter l'ordre. La fiduciaire a échappé à la perte financière directe, mais pas aux coûts indirects.

Récapitulatif opérationnel

1. Containment avant tout : révoquer les sessions OAuth et désactiver le compte avant toute action de nettoyage. Documenter chaque étape (screenshots horodatés).
2. Exporter l'UAL immédiatement : la fenêtre de rétention (90 ou 180 jours) peut exclure des événements anciens si l'investigation tarde. PowerShell ou Purview Compliance Portal.
3. Auditer toutes les InboxRules du tenant, pas seulement le compte compromis : le mouvement latéral est fréquent.
4. Qualifier le risque nLPD sous 24 heures : nature des données exposées, volume, intentionnalité. Si risque élevé non écarté → notification PFPDT dans les meilleurs délais (objectif 72 h).
5. Informer les personnes concernées directement si elles courent un risque concret (fraude, usurpation d'identité).
6. Signaler au NCSC — confidentiel, gratuit, utile pour la veille nationale.
7. Durcir avant de réactiver : MFA FIDO2 ou Authenticator (bannir SMS), Conditional Access avec device compliance, restriction du consentement OAuth.
8. Activer DMARC reject + DKIM sur le domaine d'envoi pour réduire le risque d'usurpation sortante.
9. Planifier l'upgrade de licence si absence d'Audit avancé : sans MailItemsAccessed, il est impossible de prouver ce qui a été lu — problème majeur en cas de litige ou d'audit PFPDT.
10. Simuler le scénario annuellement : phishing AiTM simulé + exercice de réponse à incident (tabletop), avec le DSI, le juriste et la direction.

Des outils comme SynGuard permettent de centraliser la visibilité sur l'état de conformité des endpoints et d'automatiser certaines actions de containment (isolation device, révocation certificat MDM) en complément des actions menées côté tenant M365.

Sources

• nLPD — Loi fédérale sur la protection des données (fedlex.admin.ch) — Texte consolidé, notamment art. 24 sur la notification en cas de violation.
• PFPDT — Notification des violations de données (edoeb.admin.ch) — Procédure et formulaire de notification au Préposé fédéral.
• NCSC — Formulaire de signalement d'incidents (ncsc.admin.ch) — Signalement confidentiel pour entreprises et particuliers.
• CIS Benchmark for Microsoft 365 (cisecurity.org) — Référentiel de durcissement des configurations M365, niveaux L1 et L2.
• NIST Cybersecurity Framework (nist.gov) — Cadre de référence pour la réponse à incident (fonctions Detect, Respond, Recover).