Analyse d'un kit de phishing AiTM (Adversary-In-The-Middle) : Tycoon 2FA

Au cours des dernières semaines, l'équipe de Réponse à Incident d'AISI a traité plusieurs cas similaires d'attaques de phishing AiTM (Adversary-In-The-Middle) liées à Storm1747. Les outils utilisés pour ce type d'attaque, disponibles à la vente en tant que PhaaS (Phishing-as-a-Service), continuent de se perfectionner. Nous avons choisi de partager nos recherches à cette belle communauté de la Cyber Sécurité afin de faciliter l'identification rapide de ces attaques et l'application de contre-mesures appropriées.

AiTM (Adversary-In-The-Middle)

L'attaque AiTM (Adversary-In-The-Middle) est une évolution de l'attaque connue (MitM) Man-in-the-Middle. Cette attaque consiste à intercepter la communication entre deux parties sans qu'aucune des deux puisse le savoir. L'attaque Adversary-In-The-Middle est plus spécialisée et plus moderne, on la retrouve généralement dans les attaques de phishing. Le fonctionnement est expliqué dans le schéma suivant :

Comme illustré sur le schéma, ce type d'attaque permet de contourner la sécurité rajoutée par une 2FA. Cette figure illustre un scénario classique de ce type d'attaque, mais l'imagination des attaquants ne manque pas (et oui, sinon ce serait trop facile ) et les scénarios évoluent très vite.

Comprendre ce type d'attaque est important pour la suite de notre analyse. Nous allons commencer par donner une vue globale sur ce type d'attaque.

Résumé de l'attaque

Le schéma suivant donne un résumé du fonctionnement du kit de phishing Tycoon 2FA. Il est important de noter que ce genre d'outil ne cesse de s'améliorer, les autres cas d'attaque peuvent varier mais le fonctionnement général reste le même.

Groupe d'attaquant Storm1747

Nos différentes recherches en source ouverte ainsi que les IOCs et Observables nous ont permis de faire le lien entre le groupe d'attaquant Storm1747 et l'outil de kit de phishing Tycoon 2FA

Sources :

• Malware analysis https://app.seesaw.me/pages/shared_item?item_id=item.8a4ddd0f-2482-4f0d-9c04-7359a88c4288&share_token=hn3_GPmUQcuVnlmnNsWTnw&mode=share Malicious activity | ANY.RUN - Malware Sandbox Online
• Malware analysis https://onzmowkbmebuiwyi5bwjubq5gewcupnhftdk0lefabjsijgclc.brghtmind.ru/horyaxlnfrazbxqcTpeJFhHkEKEZTRMDZDDSZUWWUPFWIAOXEJXGOLYUGRHpqVY04R1GA4yz0fbuv40 Malicious activity | ANY.RUN - Malware Sandbox Online
• TRAC on Twitter / X

IOCs et Observables

Nous allons maintenant voir tout cela dans les détails .

Analyse du mail de phishing

L'attaquant récupère des emails précédemment reçus par la victime, ce qui renforce la crédibilité des emails de phishing envoyés ultérieurement aux futurs destinataires.

Ci après quelques exemples de mail de phishing reçu :

A première vue, il n'y a rien d'illégitime dans ces emails. Les emails sont envoyés depuis une boite email de l'entreprise (compte compromis de la victime), l'url redirige vers un site web connu et légitime app.seesaw[.]me. Ce dernier est une plateforme connue pour faire facilement de belle présentation.

En cliquant sur le lien, on arrive sur le site de app.seesaw[.]me avec une image de l'email.

Un clique sur l'image redirige vers un nom de domaine Russe généré aléatoirement. Là, l'analyse commence à être intéressante 😄!

Analyse des systèmes anti-détection

Nous continuons notre analyse en cliquant sur le lien généré aléatoirement 5rh.zxxdkgkv[.]ru/mkrif/. Ce dernier nous ramène sur une page où il y a la vérification anti-robot de Cloudfare.

Nous validons le test et rien ne se passe, nous sommes juste redirigés vers des pages aléatoires de Microsoft. Ce qui nous semblait étrange car lors de nos enquêtes les utilisateurs nous parlaient d'une page d'authenfication avec une demande 2FA.

Après plusieurs tests sur plusieurs environnements, certains de nos tests passent. Nous commençons alors par analyser plus en profondeur les différentes requêtes HTTPS.

L'image suivante nous montre l'enchaînement des requêtes quand il y a une redirection aléatoire vers des sites de Microsoft :

1. Page app.seesaw[.]me
2. 1ère vérification anti-robot de l'attaquant avec Cloudflare
3. Différentes requêtes de vérification anti-robot de Cloudflare
4. 2ème vérification de l'attaquant
5. Redirection aléatoire vers des sites Microsoft après échec de la 2ème vérification

L'image suivante nous montre l'enchaînement des requêtes quand il y a une redirection vers la fausse page d'authentification :

1. Page app.seesaw[.]me
2. 1ère vérification anti-robot de l'attaquant avec Cloudflare
3. Différents requêtes de vérification anti-robot de Cloudflare
4. 2ème vérification de l'attaquant
5. Redirection vers la fausse page d'authentification après validation de la 2ème vérification.

L'idée maintenant est de comprendre comment fonctionne cette 2ème vérification.

En analysant les différentes requêtes HTTP, on a remarqué du code javascript offusqué qui nous a semblé intéressant.

Pour avoir le code en clair, nous avons créé un petit script python (comme on les aime ) pour nous aider :

Le code en clair nous montre que l'attaquant vérifie la présence de sandbox d'analyse automatique de lien ou l'utilisation de BURP.

De là, tout s'explique car nous avons utilisé l'outil BURP à chaque fois qu'on a été redirigé aléatoirement vers les sites de Microsoft.

Ensuite, l’attaquant vérifie si la victime utilise le mode développeur, l'inspection du navigateur, ou même juste un clic droit pour analyser les requêtes, dans ce cas, une redirection aléatoire vers les sites web de Microsoft est faite.

Après, l'attaquant vérifie la présence d'un debugger dans le navigateur, dans ce cas une redirection aléatoire est faite, vers Google pour notre exemple.

Une fois toutes ces vérifications faites, une requête poste est envoyée avec les paramètres d'URL de la page de Phishing. Cette requête retourne une réponse chiffrée avec l'algorithme AES, elle est ensuite déchiffrée et la victime est redirigée vers une url contenue dans la réponse déchiffrée. En cas d'erreur, la victime est redirigée aléatoirement, vers Microsoft Teams dans cet exemple.

On commence à voir plus clair maintenant sur les différentes redirections aléatoires que l'on a eu lors de nos tests

En avançant dans le parcours de phishing, nous arrivons sur une page disant API has expired.

En analysant les différentes requêtes, il y en a une qui vérifie la date d'expiration du lien et retourne une donnée indiquant si la page a expiré ou non.

POST hxxps://uyyv.zxxdkgkv[.]ru/wrq1tUOE0wtcDZ2aVQE1XyBtVVVDtylAQAiuDAfGZI3uknNi524g

En modifiant la requête dans BURP, ou en la supprimant, on arrive à contourner cette vérification

Une fois toutes ces vérifications faites, des Cookies de Session sont rajoutés à la page de la victime, permettant ainsi l'accès à la fausse page d'authentification Microsoft. Un copier-coller de l'url ne permet pas d'afficher la fausse page d'authentification du phishing.

Maintenant que nous avons compris les différents mécanismes anti-détection dans le kit de phishing, nous allons analyser le parcours avec la fausse page de phishing.

Analyse du parcours de phishing

Comme pour les différents systèmes anti-détection utilisés par l'attaquant, le code source de la fausse page d'authentification Microsoft est offusqué dans le javascript avant d'être affiché à l'aide de la fonction document.write().

Cette méthode permet de conditionner l'affichage de la page et d'éviter la détection par les solutions de sécurité. La fausse page d'authentification est illustrée dans la figure ci-dessous.

Dès qu'un caractère est saisie dans le formulaire, les informations suivantes sont envoyées vers l'attaquant :

• lien de la page
• le type d'authentification
• l'adresse IP de la victime
• le pays de la victime
• l'User-Agent de la victime

Nous avons choisi de tester 2 scénarios :

• Authentification avec un faux mot de passe
• Authentification avec les vrais identifiants

(Bien sur, il faut créer un compte Microsoft de test, jetable et qui n'est pas lié au tenant de votre entreprise)

Authentification avec un faux mot de passe

Nous nous authentifions sur la page de phishing en renseignant notre adresse email et puis un faux mot de passe.

Instantanément, nous avons une authentification en échec depuis une IP aux Etats-Unis dans les journaux d'activité du compte Microsoft. Je tiens à noter que nous n'étions pas aux Etats-Unis lors de nos tests.

Authentification avec les vrais identifiants

Maintenant, nous allons essayer avec les vrais identifiants et observer ce qui se passe. Nous réussissons la connexion et une demande d'authentification multifacteur 2FA est faite. Nous jouons le jeu et renseignons notre code 2FA.

Nous retrouvons dans les journaux d'activités du compte Microsoft une autre connexion depuis les Etats-Unis, cette fois-ci en réussie Successful sign-in.

Voilà, notre compte de test est compromis

Recommandations

Si vous faites face à ce genre d'attaque, nous vous recommandons de :

• Réinitialiser le mot de passe Azure des comptes compromis
• Réinitialiser tous les jetons 2FA des comptes compromis
• Révoquer toutes les sessions d'authentifications actives Azure des comptes compromis
• Vérifier dans les logs Azures toutes les actions faites par les comptes compromis
• Vérifier tous les tokens API Azure
• Vérifier toutes les applications Azure installées
• Mettre en place une restriction géographique pour l'authenfication si possible

Si vous souhaitez une investigation approfondie, pourquoi ne pas contacter l'équipe DFIR d'AISI (oups, pas de pub on a dit)