Vecteurs de phishing M365 : QR, OAuth & vol d'identifiants

Le phishing demeure le vecteur d’accès initial prédominant contre les environnements Microsoft 365. Toutefois, les modes opératoires des cybercriminels modernes ont largement dépassé le stade des simples formulaires imitant les interfaces d’authentification. Face à la généralisation de l’authentification multi-facteurs (MFA), des règles d’Accès Conditionnel et des EDR sur les postes de travail, les attaquants ont fait évoluer leurs techniques pour contourner les inspections périmétriques et neutraliser les défenses du terminal.

Les campagnes d’attaque contemporaines contre Microsoft 365 reposent sur deux paradigmes clés :

Le saut de frontière du terminal (quishing) : l’utilisation de QR codes pour déplacer l’interaction d’un poste professionnel managé et surveillé vers un smartphone personnel hors de tout contrôle.
Le détournement de l’infrastructure cloud légitime (living-off-the-cloud) : l’hébergement de leurres, de formulaires et de redirecteurs sur les domaines officiels Microsoft (forms.office.com, sway.office.com, Azure Static Web Apps) afin d’hériter d’une réputation DNS irréprochable et de neutraliser les passerelles de messagerie (SEG).

Ce guide analyse les mécanismes techniques de ces attaques, détaille la télémétrie collectée par Defender for Office 365 (MDO) et Exchange Online Protection (EOP), et fournit des requêtes de détection KQL prêtes pour la production.

1. Taxonomie moderne du phishing dans Microsoft 365

graph TD
    INBOUND[Email de Phishing Entrant] --> VEC{Architecture d'Attaque}

    VEC -->|Payload Graphique| QUISH[Attaque Quishing / Code QR<br/>Leurre intégré en PNG/SVG/PDF]
    VEC -->|Abus d'Infrastructures Cloud| LOTC[Leurres Living-off-the-Cloud<br/>Microsoft Forms, Sway, Azure Blob, SharePoint]
    VEC -->|Proxy en Temps Réel| AITM[Lien Adversary-in-the-Middle<br/>Proxy inverse captant le cookie ESTSAUTH]
    VEC -->|Consentement Applicatif| OAUTH[Requête de Consentement OAuth<br/>Permissions : Mail.ReadWrite, offline_access]

    QUISH --> MOB_HOP[Saut de Frontière du Terminal :<br/>Le collaborateur scanne le QR avec son smartphone personnel<br/>Contourne l'EDR et l'Accès Conditionnel]
    LOTC --> SEG_BYPASS[Détournement de Réputation :<br/>Scores de confiance parfaits sur *.office.com et *.azurewebsites.net]
    AITM --> SESS_HIJACK[Extraction de Cookie de Session :<br/>Neutralise les invites MFA Push et Number Matching]
    OAUTH --> TOKEN_ACQ[Jeton Graph API Permanent :<br/>Accès persistant sans dépendance au mot de passe]

2. Dissection approfondie du quishing (QR code phishing)

2.1 le mécanisme architectural du saut de frontière

L’objectif premier d’une attaque par QR code (Quishing) ne se résume pas à tromper les moteurs de reconnaissance optique de caractères (OCR) des passerelles de messagerie ; il consiste à orchestrer une rupture de contexte d’inspection matérielle :

sequenceDiagram
    autonumber
    participant Workstation as Poste Managé (Réseau Entreprise / EDR)
    participant EOP as Exchange Online Protection (EOP / MDO)
    participant Attacker as Infrastructure Attaquant (Proxy AiTM)
    participant Mobile as Smartphone Personnel (Non Managé)

    Attacker->>EOP: Email entrant avec image QR intégrée
    Note over EOP: Filtrage des entêtes et analyse OCR<br/>Le payload graphique apparaît comme une image inoffensive
    EOP->>Workstation: Message distribué dans la boîte de réception
    Note over Workstation: EDR actif, agent proxy d'entreprise actif.<br/>Accès Conditionnel exige un poste conforme
    Workstation-->>Mobile: L'utilisateur scanne le code QR avec son smartphone
    Note over Mobile: iPhone/Android personnel (Pas d'EDR, IP 4G/5G de l'opérateur mobile)
    Mobile->>Attacker: Requête HTTP GET vers le proxy d'attaque
    Attacker->>Mobile: Affichage de la mire Microsoft + challenge MFA
    Mobile->>Attacker: L'utilisateur valide identifiants + invite MFA
    Attacker->>Workstation: L'attaquant rejoue les jetons volés contre le tenant

Pourquoi ce saut de frontière est redoutable :

Cécité de l’EDR et du filtrage web : les sondes de sécurité du poste d’entreprise ne voient jamais la connexion HTTP hostile, celle-ci s’effectuant via la connexion cellulaire du smartphone personnel de l’utilisateur.
Contournement des politiques d’accès conditionnel : si la politique d’Accès Conditionnel exige un poste conforme pour accéder aux applications métiers internes mais tolère les terminaux mobiles non gérés pour la consultation web ou l’enregistrement des méthodes d’authentification (aka.ms/mfasetup), l’attaquant exploite directement cette faille.

2.2 techniques d’obscurcissement et d’évasion Face à l’OCR

Les attaquants déploient des techniques avancées pour empêcher les modules OCR d’EOP et des passerelles tierces d’extraire l’URL dissimulée :

Vecteurs SVG dynamiques : plutôt qu’un fichier image matriciel conventionnel (PNG/JPEG), le QR code est généré dynamiquement en Scalable Vector Graphics (<svg><path d="..."/></svg>) ou via des conteneurs <div> stylisés avec des bordures et couleurs CSS.
Bruit de fond et dégradés chromatiques : ajout d’un bruit alpha granulaire, de textures transparentes ou de dégradés chromatiques sous les motifs de synchronisation du QR code. Les algorithmes de vision des smartphones décodent l’image sans difficulté, tandis que les moteurs OCR industriels échouent à binariser les contrastes.
Poupées russes PDF multi-pages : le QR code est intégré à la deuxième page d’un document PDF, la première page comportant des textes d’entreprise leurres légitimes pour détourner l’analyse heuristique.

3. Détournement des infrastructures légitimes (living-off-the-cloud)

Pour contourner les listes de réputation des passerelles de messagerie, les cybercriminels hébergent leurs infrastructures de leurre directement au sein des sous-domaines Microsoft officiels :

Plateforme Détournée	Modèle d’URL	Technique Cybercriminelle	Indicateur Forensique
Microsoft forms	`forms.office.com/r/...`	Formulaire public configuré pour imiter une demande de validation de mot de passe ou une mise à jour d’authentificateur MFA.	Enregistrement de soumissions d’informations sensibles via `FormsData`.
Microsoft sway	`sway.office.com/...`	Présentation interactive soignée intégrant un bouton « Consulter le document » ou « Valider la paie » redirigeant vers un reverse proxy.	Présence de liens sortants vers des domaines de capture de session.
Azure static web apps	`*.azurestaticapps.net`	Déploiement de kits de phishing sur les offres gratuites d’Azure, bénéficiant des certificats TLS officiels de Microsoft.	Requêtes vers des applications CDN Azure sans aucun lien avec le SI de l’entreprise.
Partages SharePoint / OneDrive	`*-my.sharepoint.com/:b:/...`	Utilisation d’un compte compromis pour créer des liens de partage anonymes en lecture seule pointant vers des leurres PDF piégés.	Le domaine émetteur appartient à un partenaire commercial légitime et l’URL est authentiquement hébergée sur M365.

4. Architecture de la télémétrie Defender for office 365

Pour investiguer une campagne de phishing, l’analyste DFIR doit corréler trois tables fondamentales de Microsoft Defender XDR (Advanced Hunting) :

graph TD
    MSG[Email Entrant Reçu] --> T_EE[Table EmailEvents<br/>NetworkMessageId, Expéditeur, Destinataire, DeliveryAction, ThreatTypes]
    MSG --> T_EUI[Table EmailUrlInfo<br/>URLs Extraites, Domaines, Catégories]
    MSG --> T_EAI[Table EmailAttachmentInfo<br/>Noms de Fichiers, Extensions, Condensats SHA256]

    USER_ACT[Interaction Collaborateur] --> T_UCE[Table UrlClickEvents<br/>ClickType, ActionType, IP Utilisateur, IsClickedThrough]
    T_EE --- T_EUI
    T_EE --- T_EAI
    T_EUI --- T_UCE

4.1 attributs clés pour l’investigation

`EmailEvents`

NetworkMessageId : l’identifiant immuable de corrélation de transport à travers tous les journaux Exchange et Defender.
DeliveryAction : action de distribution (Delivered, Junk, Blocked, Quarantine).
ThreatTypes : type de menace détecté (Phish, Malware, Spam).
DetectionMethods : mécanisme ayant identifié la menace (Modèles IA, Politiques Anti-Phishing, Safe Attachments).

`EmailUrlInfo`

Url : l’adresse URL complète extraite du corps du message ou de ses pièces jointes.
UrlDomain : le nom de domaine qualifié (FQDN).

`UrlClickEvents`

Workload : service d’origine du clic (Email, Teams, OfficeApp).
ActionType : UrlAllowed (accès autorisé), UrlBlocked (bloqué par Safe Links).
IsClickedThrough : vaut True si l’utilisateur a délibérément passé outre la page d’avertissement de Defender pour accéder au site frauduleux.

5. Requêtes de chasse KQL en production

5.1 détection des campagnes de quishing (pièces jointes avec mots-clés suspects)

Identifier les emails entrants contenant des images ou PDF associés à des thématiques classiques de phishing :

let PhishKeywords = dynamic(["mfa", "authenticator", "qr", "scan", "salaire", "paie", "docusign", "adobesign", "bulletin", "rh"]);
EmailEvents
| where TimeGenerated >= ago(7d)
| where DeliveryAction in ("Delivered", "DeliveredToJunk")
| join kind=inner (
    EmailAttachmentInfo
    | where FileType in ("png", "jpg", "jpeg", "svg", "pdf")
) on NetworkMessageId
| extend SubjectLower = tolower(Subject)
| where SubjectLower has_any (PhishKeywords)
| project TimeGenerated, NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject, FileName, FileType, SHA256
| sort by TimeGenerated desc

5.2 détection des clics sur des services cloud Microsoft détournés

Identifier les utilisateurs ayant cliqué sur des liens hébergés sur les plateformes Microsoft sans blocage Safe Links :

UrlClickEvents
| where TimeGenerated >= ago(14d)
| where Workload == "Email"
| where ActionType == "UrlAllowed"
| where Url has_any ("forms.office.com", "sway.office.com", "azurestaticapps.net", "blob.core.windows.net")
| project TimeGenerated, AccountUpn, IPAddress, Url, NetworkMessageId, IsClickedThrough
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated >= ago(14d)
    | where ResultType == 0
    | project SigninTime=TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName
) on $left.AccountUpn == $right.UserPrincipalName, $left.IPAddress == $right.IPAddress
| sort by TimeGenerated desc

5.3 suivi des neutralisations rétroactives via zero-hour auto purge (ZAP)

Repérer les messages initialement distribués en boîte aux lettres mais purgés a posteriori par Defender ZAP :

EmailPostDeliveryEvents
| where TimeGenerated >= ago(14d)
| where ActionType in ("PhishZAP", "MalwareZAP")
| project TimeGenerated, NetworkMessageId, RecipientEmailAddress, ActionType, ActionTrigger, ActionResult
| join kind=inner (
    EmailEvents
    | project NetworkMessageId, Subject, SenderFromAddress, InternetMessageId
) on NetworkMessageId
| sort by TimeGenerated desc

6. Protocole de vérification forensique en réponse à incident

Dès qu’un signalement de phishing est émis au SOC ou au CIRT :

Validation du routage de transport :
- Interroger EmailEvents à l’aide du NetworkMessageId pour confirmer si le message est arrivé en boîte de réception, en courrier indésirable ou en quarantaine.
Analyse des clics d’URLs :
- Vérifier dans UrlClickEvents si l’utilisateur a cliqué sur le lien et si Safe Links l’a autorisé (UrlAllowed) ou bloqué.
Corrélation temporelle avec l’authentification :
- Pivoter sur le compte de l’utilisateur dans SigninLogs dans une fenêtre de $\pm 15$ minutes autour du clic. Détecter l’apparition d’adresses IP inhabituelles, de User-Agents atypiques ou d’alertes Entra ID Protection (Unfamiliar sign-in properties, Atypical travel).
Audit des altérations de boîte post-clic :
- Scruter le Unified Audit Log (UAL) à la recherche d’actions exécutées immédiatement après le clic : création de règles de redirection (New-InboxRule) ou octroi de privilèges délégués (Add-MailboxPermission).

Fiche précédente : 19. Kill Chain de Compromission de Compte M365
Fiche suivante : 21. Mécanismes du Reverse Proxy Adversary-in-the-Middle (AiTM)
Fiches complémentaires :