Rapport CTI technique du 26 août 2026
Résumé exécutif
ANY.RUN a publié le 18 août 2026 une analyse de cluster détaillant Mirage2FA, un kit de phishing-as-a-service (PhaaS) opéré par un groupe se présentant sous le nom LinX Coders, actif depuis septembre 2024 et toujours en activité en juillet 2026. La reprise par The Hacker News le 25 août, sous le titre d'une « surge » touchant 4 500 entreprises américaines et européennes, a relancé l'attention sur cette menace dans les dernières 48 heures. Le kit cible spécifiquement les comptes Microsoft 365 via une architecture Adversary-in-the-Middle (AiTM) : il relaie en temps réel, via un canal WebSocket, les identifiants et le code de vérification à usage unique saisis par la victime vers le véritable service Microsoft, récupérant au passage un cookie de session authentifié valide qui contourne intégralement la protection MFA.
Sur la base des données ouvertes analysées par ANY.RUN, l'activité de Mirage2FA a été associée à 3 518 domaines d'organisations uniques, avec un taux de compromission potentiel atteignant 48 % des 9 426 adresses e-mail ciblées identifiées dans le jeu de données, soit 4 532 victimes potentielles. Les États-Unis concentrent 63,7 % des victimes identifiées, les secteurs technologie, industrie manufacturière et éducation étant les plus exposés. Le vol de cookie de session, plutôt que le simple vol de mot de passe, constitue le résultat de compromission le plus fréquent, ce qui signifie qu'une simple réinitialisation de mot de passe ne suffit pas à révoquer l'accès de l'attaquant.
Chronologie
| Date | Événement |
|---|---|
| Septembre 2024 | Première activité observée du kit Mirage2FA par les chercheurs |
| Mars à juillet 2026 | Hausse continue du volume de sessions sandbox liées à Mirage2FA enregistrées par ANY.RUN |
| 17-18 août 2026 | ANY.RUN publie son rapport de cluster complet sur Mirage2FA, avec IOC et attribution à LinX Coders |
| 25 août 2026 | The Hacker News et plusieurs relais couvrent une reprise d'ampleur de la campagne, chiffrée à 4 500 organisations aux États-Unis et en Europe |
Fiche d'acteur / campagne (format fiche CTI)
Mirage2FA | Phishing-as-a-Service (PhaaS), AiTM / contournement 2FA | Cible : comptes et sessions Microsoft 365
Mirage2FA n'est pas rattaché à une CVE : c'est un kit commercial vendu en tant que service, opéré sous la marque LinX Coders, identifiable par des marqueurs de construction récurrents dans son code (variables LINXCODERSEMAIL, LINXEMAIL, LINXB64EMAIL selon les générations du kit) et par un canal de diffusion nommé LinXcoded. Techniquement, le kit combine plusieurs briques : des stagers HTML/XHTML/SVG exécutés côté navigateur (629 échantillons .htm, 198 .xhtml, 187 .svg observés par ANY.RUN), une obfuscation JavaScript par XOR (clé 0xAD) suivie de Base64 et eval() pour la variante HTML, un décodeur hexadécimal pour la variante XHTML, et un proxy AiTM relayant en temps réel le flux d'authentification vers Microsoft 365 via WebSocket.
Conditions d'exploitation : aucune vulnérabilité logicielle n'est exploitée, le vecteur est intégralement social et applicatif, reposant sur l'ouverture d'une pièce jointe HTML/XHTML/SVG piégée ou d'un lien reçu par e-mail, y compris via des campagnes distribuées à grande échelle par des services légitimes comme Amazon SES, avec des thèmes de leurre fréquents autour des ressources humaines et des avantages sociaux (401(k) notamment). PoC disponible : non applicable au sens d'un exploit technique, mais les échantillons et l'infrastructure du kit ont été largement documentés et déobfusqués par ANY.RUN et par une analyse indépendante de reverse engineering (f4n6.co.uk). Mitigation : la seule remédiation efficace contre l'AiTM est le passage à une authentification résistante au phishing, les contrôles MFA classiques (TOTP, SMS, push) étant par construction interceptables par ce type de proxy.
Diagramme de la chaîne d'attaque
Reconstruction de l'infrastructure et du flux d'attaque à partir du rapport ANY.RUN du 18 août 2026 et de sa couverture par The Hacker News le 25 août 2026.
Analyse technique
Étape 1 : livraison du leurre
La victime reçoit un e-mail contenant une pièce jointe au format .htm, .xhtml ou .svg, ou un lien renvoyant vers un code QR. Ces formats de fichiers, considérés comme peu risqués par de nombreuses passerelles de messagerie, sont exécutés directement par le navigateur à l'ouverture. Une partie significative de la diffusion transite par des plateformes d'envoi légitimes comme Amazon SES, ce qui complique le filtrage basé sur la seule réputation d'expéditeur (MITRE T1566.001 / T1566.002).
Étape 2 : exécution du stager côté navigateur
À l'ouverture, le stager embarqué s'exécute dans le contexte du navigateur de la victime (T1204.002). Selon la variante, il construit une iframe plein écran chargeant un script distant, décode une chaîne hexadécimale, ou déclenche une redirection directe via un élément <script> inline dans un document SVG autonome. Un jeton propre au destinataire (l'adresse e-mail encodée en Base64, sous des noms de variable comme LINXB64EMAIL ou RSTRING2) est intégré au stager pour personnaliser la suite de l'attaque (T1027 / T1027.006).
Étape 3 : récupération du chargeur de collecte
Le stager appelle un endpoint distant suivant le motif /<code-3-lettres>/xls/<jeton>.js sur l'un des domaines d'infrastructure du kit, qui renvoie la logique JavaScript chargée de construire et d'afficher la page de connexion Microsoft 365 piégée (T1105).
Étape 4 : capture et relais en temps réel via WebSocket
La victime saisit son nom d'utilisateur, son mot de passe, puis son code de vérification à usage unique sur la fausse page. Le kit relaie ces informations en temps réel vers le véritable service d'authentification Microsoft 365 via un canal WebSocket ouvert vers l'infrastructure de l'opérateur : c'est le cœur du mécanisme AiTM. Microsoft valide l'authentification comme légitime puisque les identifiants et le code MFA transmis sont corrects et transitent, du point de vue du service, comme s'ils provenaient directement de l'utilisateur (T1557 / T1111).
Étape 5 : vol du cookie de session et prise de contrôle du compte
Une fois l'authentification acceptée par Microsoft, le proxy AiTM récupère le cookie de session authentifié généré côté serveur. Ce cookie, ainsi que les identifiants capturés, sont exfiltrés vers le panneau de l'opérateur, où ANY.RUN a observé un stockage sous forme de fichiers texte encodés en Base64. Le vol de cookie représente plus de la moitié des 9 332 événements de compromission recensés dans le jeu de données analysé. L'attaquant peut ensuite rejouer ce cookie pour accéder directement à la messagerie, aux applications connectées en SSO et aux données de l'utilisateur, sans jamais avoir à ressaisir de mot de passe ni à repasser par le MFA (T1539 / T1071.001).
Indicateurs de compromission
| Type | Valeur |
|---|---|
| Motif d'URL du chargeur | GET /[a-z]{3}/xls/[a-z0-9]+(c2v ou cpt)?.js, endpoint canonique observé : /api/xls/a1p2i.js |
| Marqueurs de jeton dans le code | LINXB64EMAIL, LINXEMAIL, LINXCODERSEMAIL, LINXCODERSRANDSTRING, #LINXMASKEMAIL, #LINXRANDSTRING |
| Variables in-page exposant le jeton | uid, self.u, RSTRING2 |
| Domaines C2 / infrastructure connus | user.cheacker.store, hvr.volatilesour.store, ver.bandhiem.com, pynutech.store, ainsi qu'une liste étendue de domaines de phishing publiée par ANY.RUN (notamment asvbtech.store, bverster.store, pcvgtech.online, schwiessdoors.com et leurs sous-domaines) |
| IP d'infrastructure C2 observée | 185.174.100.224 (ASN as-colocrossing) |
| Comportement réseau | Requête WebSocket sortante immédiatement après le chargement du script /xls/*.js, requête DNS où le sous-domaine encode une adresse e-mail en Base64 |
| Marqueur de test opérateur | Valeur de mot de passe linxz observée dans des soumissions de test de l'infrastructure |
La liste complète des indicateurs, incluant l'ensemble des domaines de phishing observés, est publiée par ANY.RUN et référencée en source ; seul un sous-ensemble représentatif est repris ici.
MITRE ATT&CK
| Tactique | Technique | ID | Justification |
|---|---|---|---|
| Initial Access | Phishing: Spearphishing Attachment / Link | T1566.001 / T1566.002 | Livraison par pièce jointe HTML/XHTML/SVG ou lien vers une page de collecte, y compris via QR code |
| Execution | User Execution: Malicious File | T1204.002 | L'ouverture de la pièce jointe par la victime déclenche l'exécution du stager dans le navigateur |
| Defense Evasion | Obfuscated Files or Information | T1027 / T1027.006 | Encodage Base64, XOR et obfuscation de type obfuscator.io appliqués aux stagers et jetons |
| Command and Control | Ingress Tool Transfer | T1105 | Récupération de la logique de collecte via le chargeur distant /xls/*.js |
| Credential Access | Adversary-in-the-Middle | T1557 | Relais en temps réel du flux d'authentification, y compris du code MFA, via proxy WebSocket |
| Credential Access | Multi-Factor Authentication Interception | T1111 | Capture du code de vérification à usage unique au moment de sa saisie par la victime |
| Collection | Steal Web Session Cookie | T1539 | Exfiltration du cookie de session authentifié généré après validation MFA côté Microsoft |
| Command and Control | Application Layer Protocol: Web Protocols | T1071.001 | Réutilisation du cookie de session volé pour accéder directement aux services Microsoft 365 |
Cette cartographie reprend les correspondances techniques indiquées par ANY.RUN dans son rapport d'origine ; il ne s'agit pas d'une attribution officielle publiée par un vendeur de threat intelligence tiers indépendant.
Remédiation : checklist opérationnelle
- Bloquer ou mettre en quarantaine au niveau de la passerelle e-mail les pièces jointes aux formats .htm, .xhtml et .svg, ou à défaut les détoner systématiquement dans un environnement isolé avant remise à l'utilisateur.
- Migrer les comptes à risque élevé (administrateurs, direction, équipes finance) vers une authentification résistante au phishing de type FIDO2/WebAuthn ou clé physique, qui ne peut pas être relayée par un proxy AiTM contrairement au TOTP ou au push classique.
- Réduire la durée de vie des sessions et activer l'évaluation d'accès continue (Continuous Access Evaluation) dans Microsoft Entra ID pour limiter la fenêtre d'exploitation d'un cookie volé.
- Déployer une détection basée sur les motifs comportementaux plutôt que sur des indicateurs statiques : requêtes correspondant au motif /<3 caractères>/xls/*.js, requêtes DNS avec sous-domaine encodé en Base64, ouverture de WebSocket immédiatement après chargement d'un script JavaScript suspect.
- En cas de compromission confirmée ou suspectée, traiter l'incident comme une compromission d'identité : révoquer explicitement toutes les sessions et jetons actifs de l'utilisateur, pas seulement réinitialiser le mot de passe.
- Auditer les règles de transfert de messagerie et les autorisations OAuth accordées sur le compte compromis, ces persistances survivant souvent à une simple réinitialisation de mot de passe.
- Sensibiliser spécifiquement sur les leurres liés aux ressources humaines et aux avantages sociaux (401(k) et équivalents), thèmes récurrents dans les campagnes Mirage2FA observées.
- Surveiller particulièrement les connexions effectuées depuis des terminaux mobiles, où l'inspection visuelle d'une URL de phishing est plus difficile et où une part significative des compromissions réussies a été observée.
Sources
- Mirage2FA Hijacks Companies' Microsoft 365 Sessions, with Over 4K Victims in the US - ANY.RUN
- Mirage2FA Surge Hits 4,500 US and EU Companies, Abusing Microsoft 365 Login Flows - The Hacker News
- Mirage2FA: Obfuscated HTML Loader Delivers Microsoft 365 MFA Phishing Kit - Fortra
- Inside Mirage2FA — Reverse-Engineering - f4n6
- Hackers Let Microsoft 365 Users Complete MFA, Then Steal Logged-In Sessions
