Démantèlement du kit de phishing Kratos : 200 serveurs saisis, 1 800 copies en circulation

Le 20 juillet 2026, l'unité cybercriminalité du parquet de Francfort et l'Office fédéral de police criminelle allemand ont annoncé la mise hors ligne de plus de 200 serveurs. Ces serveurs faisaient tourner Kratos, une plateforme de phishing en tant que service que Microsoft Threat Intelligence suit sous le nom de SneakyLog et qui, selon les enquêteurs, était derrière environ 15 000 campagnes de phishing Microsoft 365 par mois. Les autorités indonésiennes ont arrêté l'homme identifié comme son développeur et opérateur, avec l'appui des forces de l'ordre américaines.

C'est une perturbation réellement significative. C'en est aussi une incomplète pour les défenseurs — et c'est la partie incomplète qui mérite d'être anticipée. Les enquêteurs estiment le nombre d'abonnés à environ 1 800, et ces abonnés possèdent déjà le code. Les serveurs ont disparu ; le kit non.

Ce qui rendait Kratos efficace

Kratos ne sort pas de nulle part. Trend Micro suivait son prédécesseur, Sneaky2FA, depuis décembre 2024 et a observé son évolution vers la plateforme Kratos. En chemin, il a accumulé les fonctionnalités qui rendent le phishing d'identifiants moderne difficile à intercepter :

• Le vol du cookie de session, et pas seulement du mot de passe. La description du BKA est directe sur ce point : le cookie volé suffit à lui seul à contourner l'authentification à deux facteurs et à entrer dans le compte en tant qu'utilisateur. Tout le reste du kit existe au service de ce résultat.
• Deux modes de fonctionnement. L'analyse par ingénierie inverse d'ANY.RUN a identifié un mode PHP simple qui récoltait des identifiants statiques depuis une page falsifiée, et un mode proxy inverse en Node.js qui relayait la connexion de la victime vers Microsoft au moment même où elle se produisait et capturait le jeton de session émis après l'authentification multifacteur. Les abonnés choisissaient le mode selon la cible.
• Des fenêtres « navigateur dans le navigateur », ajoutées en novembre 2025 — de fausses fenêtres de connexion affichées dans la page, qui déjouent le conseil « vérifiez la barre d'adresse » sur lequel repose l'essentiel de la sensibilisation des utilisateurs.
• Des défis Cloudflare Turnstile placés devant la page de phishing, qui gênent l'exploration automatisée et l'analyse en bac à sable, et ralentissent les demandes de retrait.
• Des services légitimes comme rebonds intermédiaires. De véritables liens SharePoint, OneDrive, Canva, Tilda et Microsoft Forms servaient de premier clic : l'URL que voit l'utilisateur et qu'inspecte la passerelle de messagerie appartient à un service auquel l'organisation fait déjà confiance.
• L'exfiltration via des bots Telegram ou par courriel, les données volées étant envoyées en POST vers des points de terminaison nommés next.php et save.php.

Les publications de Microsoft donnent un exemple concret de ce à quoi ressemblait une campagne. Le 10 février, l'éditeur a intercepté des opérateurs envoyant des courriels sur le thème fiscal à une centaine d'organisations, principalement aux États-Unis, dans l'industrie manufacturière, le commerce de détail et la santé. Chaque message contenait un formulaire W-2 avec un code QR personnalisé pour le destinataire, menant à une fausse page de connexion Microsoft 365.

Les artefacts qui survivent au démantèlement

Comme les abonnés conservent le code, les empreintes du kit restent utiles. Deux artefacts publiés sont assez spécifiques pour être recherchés directement :

• La paire de fichiers de ressources barr.svg et lg.svg. L'analyse d'ANY.RUN a trouvé cette combinaison présente dans la grande majorité des sessions Kratos. Deux fichiers SVG portant ces noms et chargés ensemble ne correspondent à rien dans un parcours de connexion Microsoft légitime.
• Les requêtes POST vers next.php ou save.php. Ce sont les points d'exfiltration. Un navigateur qui envoie des données de formulaire vers l'un de ces chemins, dans le contexte de ce qui ressemblait à une connexion Microsoft, marque l'instant où les identifiants ont quitté l'organisation.

Les deux méritent une requête rétrospective sur la télémétrie des proxys, des filtres web et des terminaux, et non seulement une règle de détection tournée vers l'avenir. Kratos menait des campagnes en volume depuis fin 2024, les autorités chiffrant les victimes en centaines de milliers : la probabilité que vos journaux contiennent une correspondance est largement antérieure au démantèlement.

Pourquoi « nous avons du MFA » n'est plus une réponse

Les kits AiTM ont proliféré parce qu'ils transforment l'authentification multifacteur en une étape que l'attaquant relaie, au lieu d'une barrière qu'il doit briser. La victime reçoit une véritable demande de Microsoft, l'approuve légitimement, et le proxy inverse empoche le jeton de session qui en résulte.

Cela déplace la question de la réponse à incident de « le mot de passe a-t-il été volé » vers « une session a-t-elle été volée », et les deux appellent des remédiations différentes :

• Compromission des seuls identifiants — le mode PHP. Une réinitialisation du mot de passe et une revue de la configuration multifacteur clôturent le dossier.
• Compromission de session — le mode proxy inverse. Une réinitialisation du mot de passe ne change rien à elle seule. La session doit être explicitement révoquée, sinon l'attaquant continue de détenir un jeton valide émis avant la réinitialisation.

Microsoft notifie les utilisateurs concernés et établit exactement cette distinction dans ses recommandations, avec le conseil de plus long terme : basculer les comptes à forte valeur vers des méthodes de connexion résistantes au phishing telles que FIDO2 ou WebAuthn, qu'un proxy ne peut pas relayer.

Quoi faire dans les deux prochaines semaines

1. Recherchez les artefacts publiés de manière rétrospective. Interrogez vos journaux sur le chargement conjoint de barr.svg et lg.svg, et sur les POST vers next.php et save.php, sur toute la profondeur de rétention dont vous disposez.
2. Examinez les connexions à la recherche d'anomalies de jeton, et pas seulement d'échecs de mot de passe. Une authentification réussie depuis une adresse inconnue, immédiatement après une approbation multifacteur légitime depuis l'emplacement habituel de l'utilisateur, correspond à la forme que laisse une compromission AiTM.
3. Révoquez les sessions au moindre soupçon, plutôt que de réinitialiser les mots de passe et clôturer le ticket. Faites de la révocation de session une étape par défaut de votre playbook phishing, et non une escalade.
4. Contrôlez le courrier entrant à la recherche de rebonds via des services de confiance. Les liens SharePoint, OneDrive, Canva, Tilda et Forms ne sont pas suspects en soi, et c'est justement le principe : évaluez donc leur destination de redirection plutôt que le domaine qui les héberge.
5. Priorisez l'authentification résistante au phishing pour les comptes qui comptent. Les approbateurs financiers, les administrateurs et les dirigeants sont là où le vol de jeton se convertit en fraude.
6. Attendez-vous à un successeur. La base d'abonnés est intacte et cherche une nouvelle plateforme. Une détection construite autour de la technique — connexions relayées, anomalies de jeton de session, chaînes de redirection passant par des services de confiance — survit à une détection construite autour de la marque Kratos.

Enrichir les domaines et URL qui remontent

Une recherche rétrospective sur une campagne de cette ampleur produit une longue liste d'URL et de domaines, pour la plupart inactifs désormais, certains encore en service sur des infrastructures gérées par les abonnés. Trier cette liste, c'est là qu'est le travail.

• Passez les pages d'atterrissage et les cibles de redirection par le scanner d'URL pour suivre toute la séquence de rebonds — les kits comme Kratos masquent délibérément la destination finale derrière des liens légitimes au premier saut, si bien que l'URL présente dans le courriel est rarement celle qui compte.
• Vérifiez l'infrastructure d'hébergement avec le renseignement sur les domaines et l'âge de domaine. Les kits redéployés atterrissent souvent sur des domaines fraîchement enregistrés, et l'ancienneté d'enregistrement reste l'un des discriminants les moins coûteux disponibles.
• Utilisez l'historique DNS pour voir si un domaine a été repointé depuis que vos journaux l'ont enregistré, ce qui est fréquent quand les abonnés migrent leur infrastructure après un démantèlement.
• Traitez toute la liste extraite par recherche en masse au lieu d'un triage manuel, puis versez l'infrastructure confirmée malveillante dans la liste de blocage afin que les mêmes domaines ne réussissent pas à la tentative suivante.
• Branchez l'enrichissement sur vos workflows de sécurité de la messagerie et de SIEM via l'API, pour qu'un message de phishing signalé arrive dans la file d'un analyste avec la chaîne de redirection et la réputation déjà résolues.

La leçon structurelle

Les démantèlements agissent sur les infrastructures et les opérateurs. Ils n'agissent pas sur des copies distribuées d'une base de code détenue par 1 800 clients payants, et ils n'agissent pas sur une technique. Kratos était lui-même le descendant de Sneaky2FA ; quelque chose sera le descendant de Kratos.

Les défenses qui ont tenu de Sneaky2FA à Kratos sont celles dans lesquelles il vaut la peine d'investir aujourd'hui : traiter les jetons de session comme des identifiants, révoquer au lieu de réinitialiser, basculer les identités critiques vers une authentification qui ne peut être relayée, et enrichir les chaînes de redirection au lieu de faire confiance au premier domaine du lien. Ces principes tiendront quelle que soit la marque qui vendra le prochain kit.