Le FBI a émis une alerte concernant Kali365, une plateforme phishing-as-a-service (PhaaS) qui industrialise le vol de tokens d’accès Microsoft 365 chez les PME-ETI. Cette nouvelle génération de PhaaS contourne les mécanismes MFA standards en interceptant les cookies de session, ce qui en fait une menace prioritaire pour toute organisation reposant sur l’écosystème Microsoft Cloud.
Pourquoi Kali365 change la donne pour les PME-ETI
Contrairement aux campagnes de phishing classiques, Kali365 ne cherche pas vos mots de passe : il vole le token d’authentification déjà validé par MFA. Le résultat est immédiat — l’attaquant rejoue la session depuis sa propre infrastructure, contournant Conditional Access, MFA et même certaines protections Microsoft Defender for Identity.
Le modèle économique de Kali365 abaisse drastiquement la barrière d’entrée. Pour quelques centaines d’euros par mois, un cybercriminel sans compétence technique loue une plateforme clé en main : kit reverse-proxy AiTM (Adversary-in-the-Middle), templates de pages de connexion Microsoft 365 indétectables, infrastructure de C2 chiffrée, et tableau de bord de gestion des victimes. Cette commoditisation explique l’explosion des incidents observés ces derniers mois.
L’anatomie d’une attaque Kali365
- Hameçon initial : email Teams/SharePoint/DocuSign hyper-réaliste, souvent envoyé depuis un tenant M365 déjà compromis pour passer les filtres DMARC/SPF/DKIM.
- Reverse proxy AiTM : la victime saisit ses identifiants et son code MFA sur ce qu’elle croit être login.microsoftonline.com. Le proxy relaie en temps réel vers Microsoft.
- Vol du cookie de session : une fois la session établie, Kali365 capture le cookie ESTSAUTH et le rejoue depuis l’infrastructure attaquante.
- Persistance silencieuse : l’attaquant configure une règle Outlook, exfiltre OneDrive/SharePoint et pivote vers Entra ID en quelques minutes.
Pourquoi votre MFA ne suffit plus contre Kali365
Les déploiements MFA classiques en PME-ETI — push notification, code TOTP, SMS — restent vulnérables à Kali365 par construction. Le PhaaS Microsoft 365 contourne MFA non pas en cassant le facteur, mais en court-circuitant l’étape post-authentification. Le cookie volé porte déjà la mention « MFA satisfait », donc Conditional Access laisse passer sans nouvelle vérification.
Seule la phishing-resistant MFA bloque réellement l’attaque : FIDO2 (clés YubiKey, Titan), Windows Hello for Business avec hardware-bound credentials, ou Microsoft Authenticator en mode passwordless avec number matching. Ces facteurs lient cryptographiquement la session au domaine légitime — le reverse proxy de Kali365 ne peut pas relayer la signature.
Plan d’action concret pour neutraliser Kali365 en PME-ETI
La défense contre Kali365 PhaaS repose sur quatre chantiers prioritaires que toute PME-ETI peut lancer cette semaine, sans attendre une migration Entra ID complète.
1. Durcir Conditional Access immédiatement
- Activer la politique Require token protection for sign-in sessions (preview Entra ID) — bloque le replay de cookies depuis un autre device.
- Imposer compliant device via Intune pour tout accès à Exchange Online, SharePoint et Teams. Un cookie volé sur un endpoint non géré devient inutilisable.
- Réduire la durée de vie des tokens Access Token à 1 heure et révoquer agressivement sur sign-out.
2. Déployer FIDO2 sur les comptes à privilèges
Tous les Global Admin, Privileged Role Admin, Application Admin et comptes de service à forte portée doivent passer en authentification FIDO2 sous 30 jours. Les clés YubiKey 5C NFC (~50 € l’unité) restent l’option la plus pragmatique pour une PME-ETI. Pour l’utilisateur lambda, déployer Windows Hello for Business avec TPM 2.0 bloque l’écrasante majorité des kits AiTM.
3. Détecter le replay de cookies
- Activer Microsoft Defender for Cloud Apps avec la règle « Suspicious inbox forwarding rule » et « Impossible travel ».
- Forwarder les logs Entra ID Sign-in vers votre SIEM et chercher les patterns AiTM : même utilisateur, deux IP différentes en moins de 60 secondes, deux User-Agents différents.
- Surveiller les ajouts de règles Outlook serveur-side (event ID
New-InboxRule) — premier geste de l’attaquant après compromission.
4. Former les utilisateurs sur les signaux faibles
Les pages Kali365 sont visuellement indiscernables des vraies. Le seul signal fiable reste l’URL dans la barre d’adresse. Formation flash de 15 minutes recommandée : montrer 5 URLs Kali365 réelles, faire repérer la différence, ancrer le réflexe « je vérifie le domaine avant de saisir le code MFA ». Un parcours complémentaire sur la fatigue MFA renforce la posture globale.
Détection : trois requêtes KQL à déployer maintenant
Pour les organisations équipées de Microsoft Sentinel ou Defender XDR, trois requêtes Kusto identifient les indicateurs Kali365 sans bruit excessif :
- SigninLogs avec
ResultType == 0etUserAgent contains "evilginx"ou correspondance avec les User-Agents publiés par CISA. - AADNonInteractiveUserSignInLogs filtré sur les ASN d’hébergeurs bulletproof connus (référentiel AbuseIPDB ou Spamhaus).
- OfficeActivity sur
Operation == "New-InboxRule"avec création moins de 2 heures après un sign-in atypique.
Ce que la PhaaS Microsoft 365 annonce pour 2026
Kali365 n’est pas un cas isolé : il s’inscrit dans la trajectoire Tycoon 2FA, EvilProxy et Greatness, où le PhaaS est devenu un produit SaaS comme un autre. La défense PME-ETI ne peut plus reposer sur « on a activé MFA, on est tranquilles ». L’horizon 2026 impose une posture phishing-resistant by default, avec FIDO2 généralisé sous 12 mois et une stratégie cybersécurité PME-ETI complète intégrant détection comportementale en plus du préventif.
Les organisations qui agiront avant l’automne 2026 réduiront drastiquement leur exposition. Celles qui attendront paieront le prix d’un incident M365 — médian à 280 000 € pour une ETI française selon les chiffres ANSSI 2026.