La campagne de phishing EvilProxy exploite des usurpations d’identité convaincantes d’applications d’entreprise.

Résumé

Okta Threat Intelligence a identifié une campagne d'attaque à grand volume qui, selon des recherches ultérieures, est active depuis au moins mars 2025, exploitant le kit de ressources de phishing-as-a-service (PhaaS) EvilProxy pour exécuter des attaques de phishing en temps réel conçues pour voler les identifiants des utilisateurs et les cookies de session actifs. Nous suivons cette campagne sous le nom de O-UNC-035.

Cette opération cible des organisations dans de nombreux secteurs, notamment la finance, le gouvernement, la santé et la technologie, en utilisant principalement des leurres très convaincants imitant des outils commerciaux populaires tels que SAP Concur et des services de signature de documents tels qu’Adobe ou DocuSign.

Analyse des menaces

EvilProxy Phishing-as-a-Service

EvilProxy (O-TA-041) est un kit de ressources PhaaS qui utilise une architecture de reverse proxy/d'intermédiaire (AitM) pour intercepter les connexions et les cookies de session des victimes en temps réel, permettant aux attaquants de contourner l'authentification multifacteur (authentification multifacteur) et de pirater des comptes.

Observé initialement en 2022 et rapidement industrialisé sur les marketplaces du dark web, EvilProxy a été largement utilisé dans des campagnes ciblées d'usurpations de compte et de compromission d'e-mail professionnelle, car il proxy les sites légitimes. Cela signifie que les utilisateurs voient de vraies invites d'authentification multifacteur et que l'attaquant est capable de capturer les tokens et les cookies que l'attaquant pourra rejouer. Comme EvilProxy est vendu et maintenu en tant que service, il permet de mettre à l'échelle les attaques et d'abaisser le seuil de compétences pour les criminels : les opérateurs peuvent lancer de grands volumes de campagnes de phishing personnalisées.

Mécanismes de leurre

Nous avons observé des logiciels et des services d’entreprise de confiance usurpés pour inciter les utilisateurs à cliquer sur des liens et à saisir des identifiants :

• Services de signature de documents (tels que Docusign, Adobe Acrobat, Adobe Sign, EchoSign) : Un thème cohérent observé dans cette campagne était l’usurpation de fournisseurs de gestion de documents et de signature électronique. Les attaquants utilisent la promesse d’un document partagé ou d’une demande de signature pour attirer les victimes.
• Plateformes de gestion des dépenses et d'approvisionnement (telles que SAP Concur, Coupa) : Il s'agissait de l'appât le plus fréquemment observé dans cette campagne. Elle cible les employés en se faisant passer pour des systèmes populaires de gestion des dépenses et des voyages, souvent avec des invites à approuver un rapport ou à examiner une dépense. Un appât plus générique utilise des termes tels que dépense, rapport de dépenses ou solutions de dépenses.
• Microsoft SharePoint: La campagne cible également les utilisateurs de l'écosystème Microsoft 365 en simulant un lien vers un document partagé ou un site collaboratif.
• Réunions en ligne : Les attaquants ont enregistré des domaines génériques qui incluent des mots comme réunion pour imiter les invitations aux plateformes de réunion.
• KnowBe4 : Les attaquants ont usurpé l’identité d’une entreprise de formation de sensibilisation à la sécurité, afin d’inciter les utilisateurs ciblés à penser que le leurre de phishing faisait partie d’un test de phishing officiel.

Analyse du code

La chaîne de redirection d'appât commence par un lien court dans lequel l'adresse e-mail de la victime est masquée dans le chemin d'URL. L'utilisateur est ensuite redirigé via un redirecteur portant le nom de l'entreprise cible dans le sous-domaine, et atterrit finalement sur une page d'hameçonnage convaincante à l'image de Microsoft qui vole les identifiants. Le JavaScript sur le redirecteur extrait l'e-mail du chemin, le réencode et construit une URL de redirection personnalisée qui transporte cette identité à chaque étape.

Chaîne HTTP exemple 1

Lien initial :

hxxps[://]expensereport[.]ch/[coded_string]

Redirecteur :

hxxps[://][company][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

URL finale (montrant le site Web de connexion pour la collecte d'informations d'identification) :

hxxps[://][32_characters_string][.]laurimarierefling[.]com/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

Exemple de chaîne HTTP 2

Lien initial :

hxxps[://]sapconcursolutions[.]pl/[coded_string]

Redirecteur :

hxxps[://][company][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

URL finale (affichant le site web de connexion pour la collecte d'identifiants) :

hxxps[://][32_characters_string][.]concurmgt[.]pl//?uid=[uid]&hid=[hid]&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

Comment le redirigeur décode et personnalise la victime

Les pages de phishing acceptent le dernier segment de chemin d’accès et tentent d’utiliser plusieurs décodeurs en séquence (mappage de tokens personnalisés, hexadécimal, Base32 et Base64) jusqu’à ce que le résultat contienne « @ ». Cette valeur devient l’adresse e-mail de la victime pour une utilisation en aval, comme le montre cet exemple de code de page d’appât initiale :

let encodedValue = window.location.pathname.split('/').pop();
...
e-mail = decodeEmail(encodedValue); // custom tri-gram map
...
if (!decodingSuccessful && isHexadecimal(encodedValue)) e-mail = hexToString(encodedValue);
if (!decodingSuccessful && isBase32(encodedValue)) e-mail = base32ToString(encodedValue);
if (!decodingSuccessful && isBase64(encodedValue)) e-mail = base64ToString(encodedValue);

Le décodeur personnalisé remplace les tokens à trois caractères par des caractères, à l'aide d'une carte comme :

const encodingMap = {
 "@":"MN3",".":"OP4","a":"QR5","e":"ST6","i":"UV7",
    "o":"WX8","u":"YZ9","s":"ABO","n":"CD1","r":"EF2",
 "d":"GH3","I":"JK4"
};

Barrières anti-analyse

Avant la redirection, le script tente d'éviter les robots d'indexation et les environnements sandbox :

function isBot() {
 const botPatterns = ['bot','spider','crawl','slurp','baidu','yandex',
 'wget','curl','lighthouse','pagespeed','prerender','screaming frog',
 'semrush','ahrefs','duckduckgo'];
if (navigator.webdriver || navigator.plugins.length === 0 ||
 navigator.languages === "" || navigator.languages === undefined)
return true;
...
}

Si un signal de bot/headless est détecté - ou si l'organisation « bloquée » de l'opérateur apparaît - la page redirige directement vers la connexion Microsoft légitime, donnant aux équipes de triage une page propre tandis que les vrais utilisateurs continuent sur le phishing. Le service api.ipify.org est utilisé pour renvoyer l'adresse IP publique de la victime, afin de la comparer à une liste de blocage IP/plage.

Domaines bloqués

Le code contient également deux domaines bloqués qui, s'ils sont présents dans l'adresse e-mail de la victime, entraîneront la sortie du flux de phishing vers la page de connexion Microsoft authentique :

const blockedDomains = ['belfius', 'baringa'];
const emailDomain = email.split('@')[1].toLowerCase();

for (const blocked of blockedDomains) {
    if (emailDomain.startsWith(blocked)) {
        window.location.href = "https://login.microsoftonline.com/common/login";
return;
    }
}

La provenance du blocage de ces deux domaines est inconnue. Le domaine "belfius" semble faire référence à une banque belge, tandis que "baringa" semble être associé à une société de conseil en gestion britannique.

Paramètres de requête

Dans les échantillons observés, le redirecteur construit la même URL paramétrée et seule la famille de domaine varie. Deux paramètres sont l'e-mail de la victime dans différents wrappers ; les autres sont des nonces plus un horodatage :

• uid → Base64(e-mail)
  • Peut être décodé à l'aide d'une recetteCyberChef
• hid → hex(Base64(e-mail))
  • Peut être décodé à l'aide d'une recetteCyberChef
• document, token → ID aléatoires (de type nonce)
• t → Timestamp Unix (ms)
  • Peut être converti en une date lisible par l'homme à l'aide d'une recetteCyberChef

Flux d’authentification

Dans le flux d’authentification, le nom de l’entreprise imitée apparaît dans certains champs du redirecteur et de l’URL finale. De plus, le framework de phishing remplit automatiquement le champ du nom d’utilisateur de la page de phishing avec l’adresse e-mail de la victime.

Lien initial :

hxxps[://]expensereport[.]ch/616c6578616e6465722e652e6261754073662e6672622e6f7267

Redirector :

hxxps[://]sf[.]sapconcur[.]sa[.]com/expense/?uid=...&hid=...&document=...&token=...&t=...

URL finale

hxxps[://]299afcb76fac4238a0facad80c326230[.]concursolutions[.]asia/?uid=...&hid=...
&document=...&token=...&t=...&u9pPUdqL=...

Réponse aux menaces

Ce que nous faisons :

Nous sommes activement engagés dans les activités suivantes pour atténuer cette menace :

• Surveillance continue des nouveaux domaines d’hameçonnage et des infrastructures associées à cette campagne.
• Dépôt proactif de signalements d’abus auprès des registraires et des fournisseurs d’hébergement concernés afin de lancer des demandes de retrait pour les sites malveillants identifiés.
• Fournir des conseils et une assistance aux organisations pour améliorer la sécurité de leurs environnements Okta et les aider à enquêter sur toute activité suspecte liée à des comptes potentiellement compromis.

Contrôles de protection

Recommandations pour les clients

• Inscrivez les utilisateurs à des authentificateurs forts tels qu’Okta FastPass, FIDO2 WebAuthn et des cartes à puce, et appliquez la résistance au phishing dans la politique.
• Les politiques d'authentification des applications Okta (anciennement « politiques d'authentification ») peuvent également être utilisées pour restreindre l'accès aux comptes utilisateur en fonction d'un éventail de conditions préalables configurables par le client. Nous recommandons aux administrateurs de restreindre l'accès aux applications sensibles aux terminaux gérés par les outils de gestion des terminaux et protégés par les outils de sécurité des terminaux. Pour l'accès aux applications moins sensibles, exigez des terminaux enregistrés (à l'aide d'Okta FastPass) qui présentent des indicateurs d'hygiène de base.
• Refuser ou exiger un niveau d'assurance plus élevé pour les demandes provenant de réseaux rarement utilisés. Avec Okta Network Zones, l’accès peut être contrôlé par emplacement, ASN (Autonomous System Number), IP et type d’IP (qui peut identifier les mandataires d’anonymisation connus).
• Les évaluations du comportement et des risques d'Okta peuvent être utilisées pour identifier les demandes d'accès aux applications qui s'écartent des modèles d'activité des utilisateurs établis précédemment. Les politiques peuvent être configurées pour l'authentification renforcée ou refuser les demandes à l'aide de ce contexte.
• Formez les utilisateurs à identifier les indicateurs d’e-mails suspects, de sites d’hameçonnage et de techniques d’ingénierie sociale courantes utilisées par les attaquants. Facilitez le signalement des problèmes potentiels par les utilisateurs en configurant les Notifications de l'utilisateur final et le Signalement d'activité suspecte.
• Documenter, promouvoir et respecter un processus standardisé pour valider l'identité des utilisateurs distants qui contactent le personnel de support informatique, et vice versa.
• Adoptez une approche de « privilèges permanents nuls » pour l'accès administratif. Attribuez aux administrateurs des Rôles d'administrateur personnalisés avec le minimum d'autorisations requises pour les tâches quotidiennes, et exigez une double autorisation pour l'accès JIT (en flux tendu (JIT)) aux rôles plus à privilèges.
• Appliquez la liaison de session IP à toutes les applications administratives pour empêcher la relecture des sessions administratives volées.
• Activez les Actions Protégées pour forcer la réauthentification chaque fois qu'un utilisateur administratif tente d'effectuer des actions sensibles.

Observer et répondre à l'infrastructure de phishing :

• Examinez les logs d'application (logs Okta, proxies Web, systèmes d'e-mail, serveurs DNS, pare-feu) pour toute preuve de communication avec de tels domaines suspects.
• Surveiller régulièrement les domaines pour voir si le contenu change.

Si le contenu hébergé sur le domaine viole le droit d’auteur ou les marques légales, envisagez de fournir des preuves et d’émettre une demande de retrait auprès du registraire de domaine et/ou du fournisseur d’hébergement Web.