Aller au contenu
Beveiligingsnieuws

Microsoft 365 : phishing AitM pour voler des emails finance

Microsoft 365 AitM phishing

Des chercheurs en cybersécurité mettent en garde contre une campagne de phishing AitM (adversary-in-the-middle) qui cible des comptes Microsoft 365. L’opération vise notamment les personnes impliquées dans les circuits de paie, les ressources humaines et la finance, afin d’identifier des profils clés et d’extraire des messages pertinents.

Selon les observations rapportées par Arctic Wolf Labs, la campagne s’appuie sur des techniques destinées à rendre les connexions malveillantes moins suspectes. L’intrusion repose sur la création et l’occupation de sessions compromises, avec une réactivation régulière, ce qui complique la corrélation entre la tentative initiale et l’activité ultérieure.

Une campagne de phishing AitM qui prend le contrôle des sessions

Le cœur de l’attaque consiste à intercepter le flux d’authentification. Concrètement, les victimes sont amenées vers des pages leurres qui se comportent comme un proxy du processus légitime d’accès à Microsoft 365. Pendant ce temps, les informations nécessaires pour se connecter sont capturées : identifiants et codes issus de la vérification multifactorielle (MFA).

Arctic Wolf indique que l’automatisation maintient les sessions compromises à un rythme d’environ huit heures. Cette logique réduit l’écart temporel entre les premières anomalies et les actions de collecte, tout en rendant l’ensemble plus difficile à attribuer à l’événement de phishing initial.

Des sign-in dissimulés via des proxys résidentiels

Pour masquer l’origine des connexions, les attaquants utiliseraient des proxys résidentiels. L’objectif est d’imiter un trafic “grand public” et de passer sous certains seuils de détection basés sur la réputation des adresses IP.

Dans les cas observés, des sign-in malveillants démarrent très rapidement : dans les minutes suivant l’accès initial, depuis un nœud de sortie de proxy résidentiel situé dans le pays de la victime. Les chercheurs notent aussi que des données géographiques pourraient être exploitées pour choisir des infrastructures de proxy cohérentes avec la localisation, afin d’éviter les alertes déclenchées par des IP inattendues.

Chaîne de redirection : de services reconnus vers une infrastructure AitM

Un point clé de la campagne est la manière dont le phishing contourne des filtres fondés sur la réputation. La chaîne d’attaque combine des services légitimes et largement utilisés pour guider la victime vers la page malveillante.

Arctic Wolf décrit une chaîne en plusieurs étapes : elle commencerait par un lien lié à Google Meet, puis passerait par l’infrastructure de gestion des liens sortants de Google. Ensuite, la redirection mène à un tracker de type “Campaign Manager” (via un clic dynamique) avant d’aboutir à un contenu hébergé sur Amazon S3.

Selon les observations, l’objet HTML placé sur S3 redirige ensuite l’utilisateur vers l’infrastructure de phishing AitM proprement dite. Dans cette logique, les composants intermédiaires contribuent à rendre la navigation initiale plus crédible, tout en préparant l’arrivée sur la page qui intercepte l’authentification.

Empreinte du navigateur et collecte d’indices techniques

Les pages de phishing intègreraient du JavaScript pour établir une empreinte (“fingerprinting”) du poste visité. Les informations collectées incluraient le navigateur, le système d’exploitation, la taille de l’écran et de la fenêtre, la langue du navigateur, le décalage horaire, les capacités liées aux cookies, l’état WebDriver, les éléments WebGL ainsi que la disponibilité de certaines API du navigateur.

Ces données seraient regroupées puis envoyées à un point d’extrémité PHP via une requête HTTP POST. Enfin, la victime est renvoyée vers une page d’autorisation OAuth Microsoft, mais via le mécanisme d’intermédiation mis en place par les attaquants.

Géolocalisation : un cookie pour conserver le contexte

Les chercheurs indiquent également que l’attaque interroge une API de géolocalisation (de type “api.country[.]is”) afin d’obtenir un code pays. Le résultat est stocké dans un cookie nommé rcfh_country, avec une expiration d’environ sept jours.

Cette collecte de contexte peut aider les opérateurs à adapter la suite de l’attaque, notamment pour aligner les connexions suivantes sur des infrastructures géographiquement “compatibles”.

Après l’accès : récupération ciblée des emails paie et finance

Une fois l’accès initial obtenu, les attaquants abuseraient des sessions compromises pour collecter des emails provenant des personnes liées à la paie, aux ressources humaines et aux fonctions financières.

Arctic Wolf souligne que le scénario s’inscrit dans une logique plus large : l’opération présenterait des recoupements tactiques avec des attaques précédemment suivies par Microsoft sous le nom Storm-2755. L’objectif global de ces clusters est financier : détourner les comptes d’employés pour rediriger les paiements de salaire vers des comptes contrôlés par les attaquants.

Dans le cadre des intrusions observées, les opérateurs se concentreraient sur la maintenance des sessions, le repérage et la collecte de boîtes aux lettres. Ils éviteraient en général d’autres actions typiques d’attaques BEC, comme la modification des méthodes MFA, l’enregistrement d’appareils, la modification d’identifiants, le hameçonnage latéral ou la création de règles dans la boîte de réception.

Moins de traces, plus de difficulté à relier l’incident

En limitant les mouvements après compromission, les attaquants réduisent les signaux qui permettraient une détection précoce. L’absence d’actions évidentes sur le compte diminue les opportunités de déclenchement basées sur des modifications d’authentification ou sur l’abus d’envois.

Le rapport mentionne toutefois un sous-ensemble de cas où les opérateurs auraient eu une intervention plus directe via une activité “hands-on keyboard”. Dans ces cas, des règles de messagerie pourraient déplacer automatiquement certains messages de la boîte de réception vers les éléments supprimés et les marquer comme lus.

Récurrence toutes les huit heures et incohérences de client

Les chercheurs indiquent qu’entre 11 et 24 heures après la première activité anormale, des connexions malveillantes réapparaissent selon un rythme d’environ huit heures, avec des adresses issues de proxys résidentiels rotatifs.

Les sign-in correspondants utiliseraient comme application cliente Microsoft Outlook, mais des agents utilisateur observés seraient ceux de Firefox (selon les versions relevées) ou parfois de Python Requests, au lieu de l’agent utilisateur attendu pour le navigateur. Des combinaisons “improbables” entre versions mobiles de Safari/Chrome et un système Windows 10 auraient aussi été rapportées.

Un autre indice important : les connexions récurrentes conserveraient le même SessionID tandis que l’adresse IP, le ASN et la localisation changeraient. Cette configuration suggère que l’automatisation régénère indépendamment le point d’origine de la session tout en conservant l’élément de session nécessaire au contrôle.

Utilisation de Microsoft Graph pour cibler les utilisateurs

Comme dans le cas de Storm-2755, les opérateurs s’appuieraient sur Microsoft Graph API pour lister les utilisateurs du tenant associés à des fonctions liées à la paie, aux ressources humaines, à la finance et à l’administration. Ensuite, ils consulteraient les messages pertinents : factures, paiements, éléments bancaires, avantages sociaux et documents internes.

Autrement dit, la collecte ne serait pas “globale” mais structurée autour des rôles et des flux informationnels ciblés. Cette approche renforce l’efficacité de l’attaque et aide à produire une matière exploitable rapidement.

À retenir : surveiller la logique, pas seulement l’événement initial

Ce qui rend la campagne de phishing AitM particulièrement préoccupante, c’est la combinaison de plusieurs facteurs : proxys résidentiels, chaîne de redirection s’appuyant sur des services connus, empreinte technique côté client et réactivation périodique des sessions. Ajoutez à cela la retenue des actions post-compromission, et vous obtenez une opération plus difficile à relier au phishing d’origine.

Pour mieux se protéger, les organisations doivent donc porter une attention particulière aux sign-in anormaux, même lorsqu’ils ressemblent à du trafic “normal”, et analyser la continuité entre les événements de connexion et l’activité sur les boîtes aux lettres. Une approche de détection centrée sur la séquence d’actions est souvent plus efficace qu’une surveillance isolée de l’alerte initiale.

Source: https://thehackernews.com/2026/08/microsoft-365-aitm-phishing-hijacks.html