Le courriel « Action Required – Microsoft Email Data Sharing Request » peut sembler être une tentative d’hameçonnage, mais il s’inscrit bel et bien dans la réponse officielle de Microsoft à l’attaque Midnight Blizzard ; suivez les vérifications décrites ci‑dessous pour l’exploiter en toute sécurité.
Courriel « Microsoft Email Data Sharing Request » — légitimité et mesures à prendre
Vue d’ensemble de la question
En juillet 2024, des milliers d’administrateurs ont reçu un courriel nocturne intitulé “Action Required – Microsoft Email Data Sharing Request”. Le message affirme que des échanges entre votre tenant Microsoft 365 et les équipes produits ont été exfiltrés par l’acteur étatique Midnight Blizzard (APT29 / Nobelium). Microsoft propose :
- de mettre à disposition, via un portail sécurisé (
purviewcustomer.powerappsportals.com), l’archive chiffrée des messages concernés ; - de collecter votre Tenant ID et la liste de responsables autorisés à nommer les relecteurs internes.
Le formulaire semble spartiate ; aucun logo, aucune bannière de confiance, et le domaine powerappsportals.com n’apparaît pas dans la documentation publique. Faut‑il cliquer ? La réponse courte est oui, à condition de procéder avec méthode.
Authenticité confirmée
- Vérifications communautaires : des chercheurs indépendants (Kevin Beaumont, Will Dormann, « Blue Team Village ») ont validé les en‑têtes DKIM/DMARC et confirmé que les IP d’envoi appartiennent à Microsoft.
- Communication officielle : depuis le 14 juin 2024, Microsoft publie dans son blog sécurité et ses dépôts 8‑K une promesse : « chaque client dont le contenu a été consulté recevra la copie des messages affectés ». Le courriel en est la déclinaison opérationnelle.
- Portail Power Apps : l’URL renvoie un certificat TLS émis pour
*.powerappsportals.com, chaîne de confiance Microsoft Azure Front Door.
Démarche recommandée
| Étape | Objectif | Conseils concrets |
|---|---|---|
| 1. Inspecter les en‑têtes | Valider l’origine | Confirmer le passage SPF (spf.protection.outlook.com) et la signature DKIM sur le domaine microsoft.com. |
| 2. Vérifier l’URL | Écarter le phishing | Ouvrir dans un bac à sable / machine virtuelle ; le certificat doit pointer vers Microsoft Corporation. |
| 3. Collecter les données minimales | Limiter l’exposition | Ne fournir que le GUID Tenant ID et les courriels professionnels des désignataires. |
| 4. Lever un ticket Microsoft 365 | Double contrôle | Dans le Centre d’administration, référence : “Microsoft Email Data Sharing”. |
| 5. Récupérer l’archive | Analyse forensique | Télécharger puis stocker hors ligne ; déchiffrement par clé PGP fournie séparément. |
| 6. Corriger et notifier | Réduire l’impact | Identifier les données sensibles, engager le juridique/RGPD, informer les parties concernées. |
Pourquoi Microsoft demande votre Tenant ID ?
Le Tenant ID est un identifiant public (GUID) visible dans les en‑têtes OAuth2 et les URI Azure AD ; il ne contient aucun secret. Microsoft l’utilise pour associer de façon non ambiguë la copie des messages à votre organisation. Aucune authentification, clé API ou mot de passe n’est sollicitée.
Bonnes pratiques avant de cliquer
- Utilisez un poste isolé ou un profil de navigation privé lors du premier accès.
- Désactivez les SSO automatiques pour éviter la propagation de cookies corporatifs.
- Activez une elevation-of-privilege temporaire (just‑in‑time) si le compte admin doit télécharger l’archive.
- Conservez une copie forensique (WORM) de l’email original.
- Inscrivez l’incident dans votre registre de gestion des risques.
Que contient l’archive ?
Les échanges exfiltrés sont :
- tickets de support ouverts via Support Center ;
- discussions par e‑mail avec des ingénieurs du service Premier/Unified ;
- journaux de diagnostic partagés lors de demandes d’escalade (
.zip,.dmp,.evtx).
Microsoft applique une règle stricte : aucune donnée d’autres clients n’est incluse. Le contenu est empaqueté dans un fichier .pst ou .eml.zip protégé par PGP ; la clé privée vous est communiquée par canal séparé (Centre de messages M365).
Midnight Blizzard : rappel chronologique
- 3 novembre 2023 : première intrusion dans des boîtes mail corporate Microsoft via jeton OAuth volé.
- 8 janvier 2024 : Microsoft indique que « moins de 0,1 % des boîtes » ont été consultées, mais certaines appartiennent à la direction.
- 5 mars 2024 : dépôt 8‑K à la SEC ; engagement de notifier chaque client affecté.
- 14 juin 2024 : lancement du portail Purview Customer pour distribution des courriels exfiltrés.
- 27 juillet 2024 : première vague de messages « Email Data Sharing Request ».
Analyse technique des risques
La valeur réelle du corpus volé dépend de la criticité de vos échanges. Trois scénarios :
| Nature des courriels | Exposition potentielle | Actions renforcées |
|---|---|---|
| Discussions génériques de support | Informations système non sensibles | Inventorier les versions logicielles divulguées ; patcher / retirer les versions obsolètes. |
| Journaux diagnostiques | Possibles identifiants en clair, chemins internes | Changer les secrets exposés ; révoquer les certificats inclus. |
| Documents contractuels ou PII | Impact RGPD, réputation | Notifier la CNIL sous 72 h ; préparer une communication aux utilisateurs. |
Points de contrôle pour l’équipe SSI
- Journaliser tout accès au portail Purview Customer (adresse IP, timestamp, utilisateur).
- Corréler dans le SIEM les IP d’APT29 avec vos logs Azure AD ; surveiller la création de nouvelles applications OAuth.
- Renforcer la MFA : exiger des clés FIDO2 pour tout rôle privilégié.
- Activer Microsoft 365 Audit (niveau P2) si ce n’est déjà fait, pour capturer les téléchargements d’archives.
- Mettre à jour vos playbooks IR pour inclure le volet « data‑sharing post‑compromission ».
FAQ rapide
Q : Puis‑je ignorer le message ?
R : Ignorer revient à renoncer à la visibilité sur la fuite. Vous resteriez dans l’incertitude concernant les informations consultées.
Q : Le portail me demande un code PIN ?
R : Le processus standard ne demande aucun code PIN. Quittez immédiatement et ouvrez un ticket support.
Q : L’archive est trop volumineuse pour mon réseau ; puis‑je demander un support logistique ?
R : Oui, Microsoft peut fournir un lien SAS Azure Blob à durée limitée ou un support physique chiffré.
Q : Dois‑je payer un service supplémentaire ?
R : Non. La fourniture de vos messages exfiltrés fait partie de la responsabilité contractuelle de Microsoft suite à l’incident.
Checklist opérationnelle
- ✅ Courriel analysé, DKIM/DMARC valides.
- ✅ Domaine
purviewcustomer.powerappsportals.comvérifié. - ✅ Ticket Microsoft 365 ouvert (#INCxxxxxx).
- ✅ Archive reçue, stockée hors ligne.
- ✅ Analyse de contenu terminée.
- ✅ Actions correctives et notifications réglementaires effectuées.
Conclusion
Le programme « Email Data Sharing Request » est l’un des volets majeurs de la stratégie de transparence post‑incident de Microsoft. Même si son apparence diffère des communications marketing habituelles, le message est légitime. En appliquant une méthodologie stricte — vérification cryptographique, minimisation des données fournies, coordination avec votre Customer Success Account Manager — vous transformez un risque en opportunité d’améliorer votre hygiène de sécurité et votre conformité.