D’abord, un grand merci à Merill Fernando pour ses newsletters toujours intéressantes sur Entra, dont voici le lien. Beaucoup d’articles écrits sur ce blog proviennent de différentes sources en anglais, et dont les travaux et réflexions méritent des tests et une retranscription en français. J’ai toujours du plaisir à essayer de comprendre certains types d’attaque visant le Cloud. Je voulais donc partager avec vous un exemple basé sur du phishing et dont la mise en place est d’une grande simplicité

Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.

Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.

Un précédent article décrivant un autre scénario d’attaque, via le Device Code Flow, est disponible juste ici. Plusieurs sources m’ont aidé à écrire ce nouvel article :

• zolder.io ont créé une application fonctionnant sur un Cloudflare Worker qui agit comme un proxy malveillant imitant la page de connexion Microsoft. Cette application intercepte les identifiants de connexion et d’autres informations sensibles, facilitant ainsi l’accès non autorisé aux comptes Microsoft, tout en contournant les mesures de sécurité comme l’authentification multi-facteurs classiques.

• Nicola Suter, MVP Microsoft, a lui aussi écrit un article inspiré par Zolder.io en démontrant qu’il est possible de créer un kit de phishing AiTM fonctionnant sur Azure. Les fonctions sur Azure peuvent imiter une page de connexion Entra ID, capter les identifiants et automatiser la reprise de session, tout en contournant des mécanismes de détection classiques.

AiTM, kesako ?

Une attaque AITM exploite un proxy intermédiaire pour intercepter les informations d’authentification pendant qu’un utilisateur se connecte à un service légitime, ce qui permet à l’attaquant de détourner la session et de contourner certaines sécurités mises en place par l’authentification multi-facteurs :

Il s’agit d’une nouvelle technique de phishing encore plus efficace. Cette méthode utilise des sites Web usurpés qui déploient un serveur proxy entre un utilisateur cible et le site Web que l’utilisateur souhaite visiter.

Tehtris

Comment fonctionne-t-elle ?

Contrairement au phishing classique, elles ne se contentent pas de tromper l’utilisateur pour lui soutirer ses identifiants. Voici en quoi elles consistent :

• Interception en temps réel : L’attaquant crée une page de connexion factice qui sert d’intermédiaire (un proxy) entre la victime et le véritable site légitime. Ainsi, l’utilisateur se connecte en pensant accéder au service habituel, tandis que l’attaquant intercepte les identifiants, cookies et autres données sensibles en temps réel.
• Bypass des mesures de sécurité : Puisque l’authentification se fait sur la vraie page (via le proxy), même si l’utilisateur passe une authentification multifacteur (MFA), les tokens et sessions générés peuvent être capturés par l’attaquant, qui peut ensuite les réutiliser pour prendre le contrôle du compte.
• Utilisation d’outils serverless : Des plateformes comme Cloudflare Workers ou Azure Functions permettent de déployer rapidement ce type d’attaque sans gérer d’infrastructures traditionnelles, rendant ainsi l’attaque plus facile à mettre en œuvre et plus discrète.

L’attaquant peut voler et intercepter le mot de passe de la victime, détourner les sessions de connexion et le cookie de session (un cookie permet d’authentifier un utilisateur chaque fois qu’il visite un site) et ignorer le processus d’authentification, car le phishing AiTM n’est pas lié à une vulnérabilité dans l’authentification.

Tehtris

Peut-on s’en protéger ?

Oui, il est possible de réduire le risque contre les attaques AITM en mettant en œuvre une combinaison de mesures préventives et de détection. Voici quelques axes de défense :

1. Authentification renforcée :
   • MFA résistant au phishing : Adopter des méthodes d’authentification fortes et moins vulnérables au phishing (comme FIDO2, Windows Hello ou l’utilisation de certificats) permet de réduire les risques, car ces solutions reposent sur des mécanismes difficiles à intercepter via un proxy.
   • Politiques d’accès conditionnel : Restreindre l’accès aux services sensibles uniquement depuis des dispositifs conformes (registered devices) ou depuis des réseaux de confiance peut empêcher l’exploitation des sessions capturées.
2. Surveillance et détection :
   • Analyse comportementale : Mettre en place des outils de détection qui surveillent les anomalies dans les logs de connexion (par exemple, des connexions depuis des adresses IP inhabituelles ou issues des plages d’IP cloud reconnues) permet d’identifier rapidement une activité suspecte.
   • Canary tokens et autres mécanismes de vigilance : Bien qu’ils puissent parfois être contournés, ces outils permettent de détecter des modifications inattendues sur la page de connexion ou d’autres indices d’une attaque.
3. Sensibilisation des utilisateurs :
   • Former les utilisateurs à reconnaître les signes d’une tentative de phishing (URL étranges, absence de certificats de sécurité attendus, etc.) est une barrière importante contre ces attaques.
   • Encourager la vérification de l’authenticité des sites et des notifications de sécurité peut réduire le risque de compromission.
4. Gestion des sessions et réponses rapides :
   • En cas de compromission, disposer de procédures de réinitialisation rapides (révocation des sessions, changements de mots de passe, etc.) permet de limiter les dommages.
   • L’implémentation de solutions de sécurité capables d’alerter en temps réel sur des activités anormales (via par exemple Microsoft Entra ID Protection ou d’autres outils SIEM) renforce la réaction face à une attaque.

Dans cet article, je vous propose donc de tester 3 déploiements d’une application frauduleuse :

• Etape 0 – Rappel des prérequis
• Etape I – Configuration Teams
• Etape II – Méthode Cloudflare
• Etape III – Méthode locale
• Etape IV – Méthode Azure
• Etape V – Ajout de la MFA

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de mettre en place notre application frauduleuse de démonstration, nous allons avoir besoin de :

• Une licence Microsoft Teams
• Une souscription Azure valide pour le déploiement sur Azure (Etape IV)

Commençons par configurer Teams afin que nous puissions recevoir les notifications et les messages lorsque notre utilisateur de test s’est authentifié au travers de notre application frauduleuse.

Etape I – Configuration Teams :

Ouvrez votre console client de Teams afin de créer un nouveau canal dans l’équipe de votre choix :

Une fois le canal Teams créé, cliquez sur le bouton ci-dessous pour ajouter un connecteur externe :

Cliquez-ici pour ajouter le connecteur Webhook entrant en utilisant la barre de recherche :

Cliquez sur Ajouter :

Une fois le connecteur ajouté, cliquez sur Créer :

Copiez l’URI du connecteur Webhook dans un éditeur de texte :

Commençons par tester la méthode de déploiement proposée par zolder.io via Cloudflare.

Etape II – Méthode Cloudflare :

Cloudflare propose justement un plan gratuit qui permet d’utiliser les Cloudflare Workers, une plateforme serverless pour exécuter du code JavaScript.

Pour cela, connectez-vous sur la page suivante, puis créez un compte Cloudflare :

Si nécessaire, vérifiez votre compte Cloudflare grâce à l’e-mail reçu sur l’adresse renseignée :

Une fois sur votre tableau de bord Cloudflare, rendez-vous dans le menu suivant afin de créer un Worker :

Conservez ses propriétés de base, puis cliquez sur Déployer :

Une fois le Worker déployé, modifiez le code par le bouton ci-dessous :

Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez sur le fichier suivant :

Copiez le code du fichier worker.js :

Collez ce dernier dans un éditeur de texte :

Collez l’URI du connecteur Webhook Teams sur la ligne suivante :

Collez l’ensemble pour remplacer le code déjà présent sur votre worker Cloudflare, puis cliquez sur Déployer :

Attendez quelques secondes la mention de la sauvegarde en bas de page :

Cliquez sur ce lien afin d’ouvrir un nouvel onglet sur votre application frauduleuse :

Attendez quelques minutes et/ou rafraîchissez la page web plusieurs fois au besoin afin d’obtenir le résultat suivant :

Renseignez le nom de compte de votre utilisateur de test, puis cliquez sur Suivant :

Renseignez le mot de passe de votre utilisateur de test, puis cliquez sur Suivant :

Cliquez sur Oui :

Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :

Retournez sur le canal Teams créé précédemment afin de constater l’apparition d’un premier message provenant du connecteur Webhook, et contenant le login et mot de passe de l’utilisateur de test :

Un second message Teams apparaît également dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Demandez à n’importe quelle IA générative de parser ce texte en JSON avec le prompt suivant :

Convertis cette chaîne de cookies en un snippet JavaScript qui utilise JSON.parse pour créer un tableau d’objets cookies, puis qui les applique avec document.cookie en leur assignant une date d’expiration fixe, comme dans cet exemple :

JSON.parse('[{"name":"ESTSAUTHPERSISTENT","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"ESTSAUTH","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"SignInStateCookie","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true}]').forEach(c => document.cookie = c.name + "=" + c.value + "; expires=Wed, 05 Aug 2040 23:00:00 UTC; path=/");

Copiez / collez le résultat obtenu par l’IA dans un éditeur de texte :

Ouvrez Google Chrome en navigation privée :

Rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :

Moins d’une heure après la publication de notre application frauduleuse chez Cloudflare, un nouvel e-mail nous informe de la détection de notre application et la fermeture de celle-ci :

La console Cloudflare de notre application frauduleuse devient alors inexploitable :

Enfin, il en est de même côté client pour l’URL générée pour notre application frauduleuse :

Continuons les tests en effectuant un déploiement en local de l’application frauduleuse.

Etape III – Méthode locale :

Rendez-vous sur la page suivante pour télécharger Node.js :

Lancez l’installation de Node.js, puis cliquez sur Suivant :

Cochez la case pour accepter les termes, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Une fois Node.js correctement installé, cliquez sur Terminer :

Rendez-vous sur la page suivante pour télécharger les outils d’exécution locale d’Azure Functions :

Lancez l’installation, puis cliquez sur Suivant :

Cochez la case pour accepter les termes, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Une fois les outils Azure Functions correctement installés, cliquez sur Terminer :

Rendez-vous sur la page suivante pour télécharger Visual Studio Code :

Cochez la case pour accepter les termes, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Une fois Visual Studio Code correctement installé, cliquez sur Terminer :

Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez-ici pour télécharger l’archive au format ZIP :

Décompressez l’archive ZIP dans un dossier local de votre choix :

Ouvrez Visual Studio Code, puis cliquez sur le bouton ci-dessous :

Choisissez le dossier précédemment créé en local :

Confirmez votre confiance en ce dernier :

Ouvrez par le menu suivant la console Terminal intégrée à Visual Studio Code :

Saisissez la commande suivante afin d’ajouter le webhook de votre canal Teams :

func settings add TEAMS_WEBHOOK_URI "https://"

Constatez l’apparition de votre configuration webhook Teams dans le fichier suivant :

Lancez la commande suivante pour installer le package @azure/functions dans votre projet Node.js et l’ajouter comme dépendance dans le fichier package.json.

npm install @azure/functions --save

Lancez la commande suivante pour démarrer l’application frauduleuse en local tout en affichant des informations détaillées de log pour le diagnostic.

func start --verbose

Choisissez node :

Attendez quelques secondes afin de constater le bon démarrages des 4 fonctions de l’application frauduleuse :

Copiez l’URL suivante :

Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :

Cliquez sur Oui :

Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :

Retournez sur le canal Teams créé précédemment afin de constater l’apparition :

• d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
• d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :

Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :

Terminons nos tests par un déploiement de notre application frauduleuse sur Azure.

Etape IV – Méthode Azure :

Ouvrez un onglet vers ce répertoire GitHub, puis cliquez-ici pour déployer votre application frauduleuse sur Azure :

Renseignez tous les champs ci-dessous dont également l’URI de votre webhook Teams, puis lancez la validation Azure:

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 10 minutes la fin de la création des ressources Azure, puis cliquez-ici :

Cliquez sur la fonction Azure créée lors du déploiement :

Copiez l’URL de votre application frauduleuse, puis vérifiez la bonne activation des différentes fonctionnalités :

Ajoutez au besoin un domaine personnalisé afin de rendre l’URL de votre site moins suspicieux :

Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :

Retournez sur le canal Teams précédemment créé afin de constater l’apparition :

• d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
• d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :

Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :

Testons maintenant si l’ajout d’une MFA renforce la protection de notre compte de test.

Etape V – Ajout de la MFA :

Configurez une méthode MFA de type Microsoft Authenticator sur votre utilisateur de test :

Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA à votre utilisateur de test :

Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :

Réussissez le challenge MFA demandé par Microsoft via la notification reçue sur votre compte Microsoft Authenticator :

Retournez sur le canal Teams précédemment créé afin de constater l’apparition :

• d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
• d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :

Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies précédemment copié, appuyez sur la touche Entrée, puis fermer la fenêtre du mode Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application, sans souci particulier concernant l’instauration de la MFA :

Conclusion

Qu’il s’agisse d’un déploiement via Cloudflare, d’un environnement local ou d’un déploiement sur Azure, cela illustre la facilité avec laquelle ces attaques peuvent être exécutées.

Pourtant, elles soulignent également l’importance cruciale d’une authentification renforcée (avec des solutions telles que FIDO2 ou autres) et de politiques d’accès conditionnel strictes.

La surveillance continue, la gestion proactive des sessions et la sensibilisation des utilisateurs complètent ce dispositif de défense pour mieux protéger les environnements Cloud. Ces mesures, lorsqu’elles sont correctement implémentées, offrent une barrière robuste contre l’exploitation des failles de sécurité et renforcent significativement la protection des systèmes face aux menaces modernes.

Pour information, environ 12 heures après mon déploiement, la fonction Azure était toujours opérationnelle mais l’URL personnalisée avait bien été détectée et bloquée :