Quishing : phishing par QR code, techniques AiTM et défenses

Le quishing — contraction de QR code et phishing — est devenu en 2025-2026 l'une des techniques d'hameçonnage les plus efficaces et les moins détectées par les infrastructures de sécurité email traditionnelles. Là où les URL malveillantes dans le corps d'un email sont systématiquement analysées par les passerelles de messagerie sécurisée (SEG) et les outils de sandbox, un QR code est une image encodant une URL : les scanners de liens ne voient qu'un fichier PNG ou une chaîne de pixels. Selon Cofense et Proofpoint, le volume de campagnes quishing a augmenté de plus de 340% entre 2024 et 2026, avec une sophistication croissante. Les attaquants combinent désormais le QR code avec des proxies AiTM (Adversary-in-the-Middle) comme EvilProxy ou Evilginx pour capturer non seulement les identifiants, mais aussi les tokens de session MFA — rendant la double authentification inefficace. Ce guide couvre l'intégralité de la chaîne d'attaque, les vecteurs émergents (QR codes dans PDF, Unicode art), les mécanismes de détection par OCR, et les défenses allant jusqu'au FIDO2 qui résiste à ces attaques par proxy.

Pourquoi les QR codes contournent-ils les filtres email ?

Pour comprendre l'efficacité du quishing, il faut comprendre comment fonctionnent les passerelles de messagerie sécurisée (SEG — Secure Email Gateway). Ces solutions analysent principalement : les pièces jointes (sandbox d'exécution), les URL présentes dans le corps du message (vérification réputation, détonation dans sandbox), et les métadonnées de l'email (expéditeur, headers d'authentification). Un QR code est traité par les SEG comme n'importe quelle image attachée ou intégrée. Sauf si la SEG dispose d'une capacité OCR spécifique pour décoder les QR codes et en extraire l'URL pour analyse, le contenu malveillant reste opaque.

Cette limitation est fondamentale : les URL scanners fonctionnent sur du texte. Un QR code est une matrice de pixels noirs et blancs dont la signification nécessite un décodage. Les SEG traditionnelles (génération pre-2023) ne disposaient tout simplement pas de cette capacité. Même les solutions plus récentes ont des délais de mise à jour de leurs signatures de détection. Les attaquants l'ont parfaitement compris et ont industrialisé la génération de QR codes malveillants dans leurs outils de phishing-as-a-service.

Statistiques 2025-2026 : l'explosion du quishing

Le rapport Cofense 2025 sur les menaces email documente une hausse de 340% des campagnes quishing par rapport à l'année précédente. Proofpoint, dans son rapport State of the Phish 2026, confirme que le quishing est désormais dans le top 5 des techniques d'hameçonnage par volume. Microsoft rapporte que ses outils de sécurité M365 bloquent chaque mois plusieurs millions de tentatives de quishing, avec une accélération nette depuis le T3 2025.

Les secteurs les plus ciblés sont la finance, les cabinets d'avocats, les entreprises industrielles et les administrations. La raison est liée au contexte d'usage : ces organisations ont généralement une MFA déployée sur leurs accès (ce qui motive l'utilisation de la technique AiTM) et des processus nécessitant des validations par email. Les attaquants ont notamment ciblé les processus de re-authentification M365 qui génèrent légitimement des QR codes pour l'accès conditionnel, habituant les utilisateurs à scanner des QR codes dans des emails de sécurité.

Mécanisme complet : du QR code à la capture MFA

Étape 1 : Génération du QR code malveillant

L'attaquant génère un QR code encodant l'URL de son proxy AiTM (par exemple https://m365-secure-login.attaquant.com/auth). Cette URL est rendue aussi légitimante que possible : sous-domaine ressemblant à Microsoft, Microsoft Azure ou à l'entreprise cible, certificat TLS valide (Let's Encrypt), et interface de connexion copiée pixel par pixel depuis le portail légitime. Le QR code est intégré dans un email HTML reproduisant fidèlement les communications de sécurité Microsoft, d'un service RH, ou d'une notification de livraison de colis.

Étape 2 : Envoi et contournement des filtres

L'email est envoyé depuis une infrastructure d'envoi légitime (compte compromis, service d'envoi bulk) pour passer les contrôles SPF/DKIM. Le corps de l'email ne contient aucune URL en texte clair — seulement l'image du QR code. Les SEG sans capacité OCR laissent passer l'email. L'objet joue sur l'urgence : "Votre session Microsoft 365 expire dans 24h — Réauthentifiez-vous", "Colis en attente de confirmation identité", "Accès VPN : vérification requise".

Étape 3 : L'utilisateur scanne le QR code avec son smartphone

C'est un élément clé de l'attaque : l'utilisateur scanne le QR code avec son téléphone mobile, un appareil qui n'est généralement pas sous la protection du proxy de sécurité de l'entreprise. Les solutions de filtrage web de l'entreprise ne voient pas la navigation du smartphone personnel. L'URL du proxy AiTM s'ouvre dans le navigateur mobile.

Étape 4 : Proxy AiTM et capture du token MFA

Le proxy AiTM (EvilProxy, Evilginx, Modlishka) se comporte comme un man-in-the-middle transparent. Il présente à l'utilisateur la vraie page de connexion Microsoft (en la proxifiant en temps réel depuis les serveurs Microsoft). L'utilisateur saisit ses identifiants et valide sa MFA normalement. Le proxy capture à la fois les identifiants et le cookie de session (token d'authentification) émis par Microsoft après validation MFA. L'attaquant récupère ce cookie et peut se connecter au compte de la victime depuis n'importe quel appareil sans MFA pendant la durée de vie du token (généralement 24h à plusieurs jours selon la politique de l'organisation).

; Exemple simplifié de ce que voit le proxy AiTM
; L'utilisateur se connecte à : https://m365-auth.attaquant.com/login
; Le proxy relaie vers : https://login.microsoftonline.com/login
; Capture les headers de réponse contenant le cookie de session :
Set-Cookie: ESTSAUTHPERSISTENT=0.AXXX...long_session_token...;
  Path=/; Secure; HttpOnly; SameSite=None; Domain=login.microsoftonline.com

Vecteurs d'attaque avancés : au-delà de l'email corporate

QR codes dans pièces jointes PDF

Pour contourner les SEG avec capacité OCR basique sur les images inline, les attaquants ont évolué vers l'encapsulation du QR code dans un document PDF joint à l'email. Le PDF semble être une facture, un bon de livraison ou un formulaire administratif. Le QR code y est présenté comme un "lien de paiement en ligne" ou une "validation de signature électronique". Les solutions d'analyse sandbox doivent ouvrir le PDF, en extraire les images, les décoder et analyser les URL — une chaîne d'analyse complexe que beaucoup de solutions ne complètent pas en temps réel avant livraison.

Affiches physiques et faux QR codes

Le quishing ne se limite pas au vecteur email. Des campagnes documentées ont utilisé des affiches collées sur des bornes de recharge électrique, des menus de restaurant et des formulaires d'enquête de satisfaction dans des hôtels fréquentés par des cadres d'entreprise. Ces QR codes physiques remplacent ou recouvrent des QR codes légitimes et dirigent vers des pages de phishing. Ce vecteur est particulièrement difficile à contrer car il contourne toute infrastructure de sécurité digitale.

QR codes obfusqués et Unicode art

Pour contourner les OCR et les détecteurs de QR codes intégrés aux SEG, des techniques d'obfuscation émergent. Les QR codes avec une densité de correction d'erreur maximale (niveau H) peuvent être partiellement masqués ou altérés tout en restant lisibles par les scanners mobiles. Des techniques utilisant l'Unicode art (caractères Unicode à haute densité visuelle) génèrent des pseudo-QR codes qui trompent les OCR de reconnaissance mais sont décodables par les applications mobiles modernes. La segmentation du QR code sur plusieurs images assemblées côté client en CSS est une autre technique documentée.

Détection : OCR, sandboxing et DNSBL

Analyse OCR dans les SEG modernes

Les solutions SEG de génération récente (Proofpoint TAP, Microsoft Defender for Office 365 Plan 2, Mimecast, Abnormal Security) intègrent désormais une capacité de décodage des QR codes dans les images et les PDF. Lorsqu'un QR code est détecté, l'URL extraite est soumise aux mêmes analyses que les URL textuelles : vérification de réputation, analyse sandbox, suivi de redirections. Microsoft a annoncé en 2025 l'intégration native du décodage QR dans Exchange Online Protection, disponible dans tous les plans M365.

Sandboxing et détonation des URL

Même avec l'extraction de l'URL, les proxies AiTM utilisent des techniques anti-sandbox : détection de User-Agent de robot, vérification de géolocalisation IP (blocage des IP de datacenter), CAPTCHA à l'entrée, délai avant affichage du contenu malveillant. Une stratégie de détection robuste combine la détonation en conditions réalistes (avec un User-Agent de navigateur mobile réel) et la corrélation avec des DNSBL/bases de réputation de domaines de phishing.

Indicateurs de compromission QR (QR IOCs)

Les proxies AiTM laissent des traces distinctives dans les logs : le domaine du proxy présente souvent un certificat Let's Encrypt très récent (moins de 72h), l'URL path ressemble aux URLs d'authentification légitimes mais avec de légères variations, et les headers de réponse HTTP révèlent parfois la technologie de proxy (Nginx en tant que reverse proxy avec configuration spécifique). Des outils comme URLscan.io permettent de soumettre l'URL extraite du QR code pour analyse en environnement sandbox.

Cas réel : campagne MFA bypass M365 via QR — EvilProxy 2025

En 2025, une campagne documentée par plusieurs équipes de threat intelligence a ciblé plusieurs centaines d'entreprises européennes avec une technique quishing combinée à EvilProxy. Les emails se présentaient comme des notifications de "mise à jour obligatoire de la politique de sécurité Microsoft 365" et incluaient un QR code à scanner "depuis votre appareil mobile d'entreprise pour plus de sécurité". L'argument du mobile d'entreprise était habile car les utilisateurs se sentaient en conformité avec la procédure recommandée. Le QR code pointait vers un reverse proxy EvilProxy hébergé sur des VPS en Asie du Sud-Est, enregistrés sous des domaines comme m365-policy-update.com et microsoft-security-compliance.net.

La chaîne complète : utilisateur scanne → arrive sur page de login M365 proxifiée → saisit identifiants + valide MFA → token capturé → attaquant se connecte depuis IP russe → exfiltre emails → installe règle de transfert vers boîte externe → utilise accès pour lancer des attaques BEC internes. Le délai moyen entre la scan du QR et la première activité malveillante dans la boîte compromise était de 4 minutes. La détection n'a eu lieu que 3 semaines plus tard via une alerte UEBA sur les connexions inhabituelles.

Défenses : de la sensibilisation au FIDO2

Désactiver l'aperçu automatique des QR codes

Sur les appareils mobiles professionnels gérés (MDM), il est possible de désactiver la fonctionnalité d'aperçu automatique des QR codes dans les applications email (Outlook Mobile). Une configuration MDM Intune peut imposer l'ouverture des URL QR via un navigateur sécurisé géré plutôt que le navigateur système, permettant le filtrage via les politiques de navigation protégée.

FIDO2/Passkeys : la seule défense contre AiTM

Contre les attaques AiTM par proxy, la MFA classique (TOTP, SMS, push notification) est inefficace car le proxy relaie les codes en temps réel. La seule défense technique robuste est FIDO2 (WebAuthn) avec des clés physiques (YubiKey, clés intégrées aux appareils Windows Hello). La propriété fondamentale de FIDO2 est que la signature cryptographique est liée à l'origine du domaine (l'URL réelle du site). Un proxy AiTM présente un domaine différent de microsoft.com — la clé FIDO2 refuse de s'authentifier, l'attaque échoue même si l'utilisateur est trompé. Les passkeys sur appareils modernes (TPM, Secure Enclave) offrent la même protection.

# Activer FIDO2 comme méthode MFA dans Azure AD / Entra ID
# Via Microsoft Graph API ou Azure AD portal
# Politique d'accès conditionnel : exiger strength FIDO2 pour accès sensibles
$params = @{
    "@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    state = "enabled"
    isAttestationEnforced = $true
    keyRestrictions = @{
        isEnforced = $false
        enforcementType = "allow"
        aaGuids = @()
    }
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "fido2" -BodyParameter $params

Formation ciblée anti-quishing

La sensibilisation doit cibler spécifiquement le comportement de scan de QR : former les utilisateurs à ne jamais scanner un QR code reçu par email avec leur smartphone personnel, à vérifier l'URL affichée avant de la visiter, et à signaler tout email contenant un QR code non attendu. Les simulations de quishing (envoi de QR codes tests avec landing page pédagogique) sont plus efficaces que les formations théoriques.

Réponse en cas d'incident quishing

Si un utilisateur a scanné un QR code suspect et saisi ses identifiants, la procédure d'urgence est identique à celle d'un phishing classique avec compromission de compte : réinitialiser le mot de passe immédiatement, révoquer toutes les sessions actives (Revoke-AzureADUserAllRefreshToken), inspecter les règles de messagerie créées, analyser les logs de connexion des dernières 24h, et vérifier les activités sur les applications autorisées. La rapidité d'action est critique car les tokens de session peuvent avoir une durée de vie de plusieurs heures à plusieurs jours.

Pour les techniques AiTM détaillées et Evilginx, notre article Evilginx et le phishing AiTM qui bypasse la MFA couvre l'infrastructure de proxy en profondeur. La sécurisation de votre tenant M365 contre ces attaques est détaillée dans notre guide durcissement Exchange Online anti-phishing. La récente faille Microsoft 365 Copilot (2025) montre comment les nouvelles surfaces IA deviennent des vecteurs. Notre livre blanc IA et cyberdéfense offre une vision stratégique de ces menaces émergentes.

Les références sectorielles incluent le rapport Cofense 2025 sur le quishing et les recommandations anti-phishing de la CISA qui intègrent désormais les vecteurs QR code.

FAQ — Questions fréquentes sur le quishing

Les solutions de filtre email modernes bloquent-elles vraiment le quishing ?

Les solutions de nouvelle génération avec décodage OCR des QR codes (Microsoft Defender for Office 365 Plan 2, Proofpoint TAP, Abnormal Security) détectent une partie des campagnes de quishing, notamment celles utilisant des URLs présentes dans des bases de réputation connues. Cependant, les attaquants utilisent systématiquement des domaines fraîchement enregistrés (moins de 24h) que ces bases ne connaissent pas encore. La fenêtre de vulnérabilité entre l'enregistrement d'un domaine de phishing et son ajout aux bases de réputation est typiquement de 12 à 48 heures — suffisant pour mener une campagne ciblée. La défense par couches (OCR + réputation + comportemental + FIDO2) reste nécessaire.

Comment détecter qu'un QR code physique a été remplacé par un attaquant ?

La détection d'un QR code physique falsifié est difficile. Quelques indices visuels : un autocollant par-dessus le QR code original, une qualité d'impression différente, un QR code légèrement décalé ou bombé sur une surface plane. Pour les environnements professionnels (bornes de recharge, salles de conférence), une mesure simple est d'imprimer l'URL correspondant à chaque QR code officiel à côté de celui-ci, pour que les utilisateurs puissent vérifier que l'URL affichée correspond. Les QR codes officiels dans des contextes sensibles devraient idéalement être protégés contre la falsification (lamination, hologramme).

Si la MFA a été contournée, combien de temps l'attaquant garde-t-il accès au compte ?

La durée de vie d'un token de session capturé dépend de la politique de durée de session configurée dans votre tenant Azure AD. Par défaut, les tokens d'actualisation Microsoft peuvent être valides de 1 à 90 jours selon les paramètres. Sans politique de durée de session stricte (Conditional Access avec fréquence de connexion configurée à 1h par exemple), un attaquant peut maintenir l'accès pendant des semaines. La révocation via Revoke-AzureADUserAllRefreshToken invalide immédiatement tous les tokens actifs. Configurer une fréquence de réévaluation continue dans les politiques d'accès conditionnel réduit drastiquement cette fenêtre.