[Nouvelle alerte de cybersécurité] Des hackers ciblent un fournisseur de sécurité européen en se faisant passer pour Cisco

Le 13 mars 2026, l’équipe de renseignement sur les menaces d’Outpost24, société mère de Specops, a détecté et bloqué une campagne sophistiquée de phishing multi-chaîne, se faisant passer pour Cisco, fournisseur mondial d’équipements réseau. Notre équipe a identifié l’attaque très tôt, l’a stoppée avant qu’elle ne compromette des systèmes ou n’impacte les utilisateurs, et a partagé les informations pour aider d’autres organisations à se protéger contre des campagnes similaires.

Cette attaque est particulièrement complexe : elle combine des services légitimes et fiables avec des infrastructures compromises pour masquer la destination finale du phishing. Les victimes sont redirigées à travers plusieurs domaines légitimes ou anciennement réputés, ce qui réduit les chances que les filtres de sécurité ou les scanners basés sur la réputation bloquent le lien.

Les hackers ont même ajouté une étape de « validation humaine » via Cloudflare, pour s’assurer que seules de vraies personnes accèdent à la page finale demandant les identifiants. Notre équipe a cartographié la chaîne d’attaque en sept étapes claires et propose des recommandations pour s’en protéger.

Les 7 étapes de la chaîne d’attaque

Étape 1 : Le leurre initial

L’attaque commence par un email soigneusement conçu, qui usurpe l’identité du fournisseur de services financiers JP Morgan. Le message est présenté comme faisant partie d’une conversation existante, une technique classique pour renforcer la crédibilité. Le texte indique aux utilisateurs : « Un document est disponible pour votre révision et signature. »

Email de phishing initial

Lors de notre enquête, les en-têtes montrent que le message était signé DomainKeys Identified Mail (DKIM) par em.37nmtc.com, avec une signature supplémentaire liée à l’infrastructure Amazon Simple Email Service (SES).

Comme la signature DKIM a été validée avec succès, le message a été accepté par l’authentification DMARC même en l’absence d’un enregistrement Sender Policy Framework (SPF) valide. En conséquence, l’email paraissait authentique et fiable pour les systèmes de protection de messagerie Microsoft 365.

Email signé DKIM par em.37nmtc.com avec un email de phishing de « qualité normale »
Authentication-Results: spf=none (sender IP is 69.169.224.13) smtp.mailfrom=em.37nmtc.com; dkim=pass (signature was verified) header.d=37nmtc.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=37nmtc.com;compauth=pass reason=100 Received-SPF: None (protection.outlook.com: em.37nmtc.com does not designate permitted sender hosts)

Étape 2 : Redirection via Cisco Secure

Le lien attaché au bouton « Review Document » redirige vers une URL hébergée sur secure-web.cisco.com, un domaine légitime de Cisco. Ce domaine est généralement utilisé pour réécrire les liens dans les emails, afin que les destinataires ne reçoivent pas directement des URLs externes, sauf si celles-ci ont été vérifiées et jugées sûres par Cisco.

Ironiquement, si un hacker parvient à envoyer un email via la passerelle sécurisée de Cisco (Secure Email Gateway) contenant un lien non identifié comme malveillant, il obtient un atout extrêmement précieux : une URL de redirection hébergée au sein de l’infrastructure de Cisco, que les utilisateurs sont plus susceptibles de considérer comme fiable et qui peut contourner de nombreux systèmes de détection.

Lien de phishing « Cisco» sécurisé fourni dans le document

hxxps[:]//secure-web.cisco.com/1aL6ss11Orq2hbHreIVXzBwsVL_VtTGpsnWld4nI4zcao-PH1ayVpw3VCsSc-nkb7tqLEjOiHObISdpA9w_-f5hmMQI_IUeM2i46yl1kSw6GUVsuvQ0hacn91qTFvO3LtCbKhUb8HhT3kE5FU6dHf3OBeUMn4Mc2EePTWYjRH8Fuc-CXFHgmLWmPq0NUQ0EejCYkDDEuZSRC6VMjj84CnS6S-fFa8k_79jvbWe12eJ_mz6jNHzElPPKPC_E8VaIUvXtzUz85bZP3A9v45bIvrjfZ5VbiDdOBke-AAKAbtAtLcMt0U1h68_JBGO2K4PU2KyTwFHUliw9ED1V_SakNA8_1lXEP6FQhBpmQdyiNYQ8qL7GgfgNIcjDnY09J8tG_Mo21Wn_qJzzIFJoWSIYOBgW5Ih_eZ9UxikO_KiH_K5DKFO1QBkmtrpHYphv1vr8qe4qIoDdbQgpwmaQ66O3keJiBNRI8dv8bb-u8waewntfc/https%3A%2F%2Ftracking.us.nylas.com%2Fl%2Fe5fd23c84ad341959b1b1f99863d6ef7%2F0%2Fa2000da7f0c0b9f1da537753529477b583df272c3dbafb1fc15b0afade3ca218%3Fcache_buster%3D1773349270

Lorsque le lien est ouvert, la requête est envoyée vers l’infrastructure Cisco Secure Web, qui renvoie une redirection vers l’étape suivante de la chaîne d’attaque.

Réponse de CISCO secure-web:

Réponse de CISCO secure-web:
hxxps[:]//tracking.us.nylas.com/l/e5fd23c84ad341959b1b1f99863d6ef7/0/a2000da7f0c0b9f1da537753529477b583df272c3dbafb1fc15b0afade3ca218?cache_buster=1773349270

• HTTP/2 302 Found
• Server: openresty/1.27.1.2
• Content-Type: text/html
• Content-Length: 0
• Talos-Dc-Id: 3

Réponse de CISCO secure-web

Étape 3 : Redirection via Nylas

Après la redirection initiale depuis l’infrastructure Cisco Secure Web, la requête est transférée vers tracking.us.nylas.com.

Nylas est une plateforme d’API email largement utilisée, qui fournit aux développeurs des services tels que la synchronisation des emails, le suivi et l’automatisation. Dans ce cas, les hackers semblent exploiter une fonctionnalité de suivi et de redirection de liens de la plateforme afin de faire progresser la victime dans la chaîne de phishing.

L’utilisation de l’infrastructure de Nylas provient probablement du besoin des hackers de générer un lien capable de passer par l’infrastructure Cisco Secure Web sans éveiller de soupçons. Pour cela, n’importe quel service légitime et bien établi permettant de créer des liens de redirection aurait pu être utilisé.

Lorsque la requête atteint l’infrastructure de Nylas, celle‑ci effectue immédiatement une nouvelle redirection vers l’étape suivante de l’attaque.

Réponse de Nylas : HTTP/2 301 Moved Permanently

Emplacement : hxxps[:]//infra.infratechcorpsolutionllp.com/MQadYJ7z29BJTL.pdf

Réponse de Nylas

En enchaînant des redirections via des services légitimes tels que Cisco et Nylas, les hackers augmentent les chances que le lien passe les filtres de sécurité et les contrôles de réputation. Ces domaines sont largement considérés comme fiables et apparaissent fréquemment dans le trafic légitime, ce qui rend leur blocage automatique plus difficile.

La victime est alors envoyée vers l’étape suivante de l’attaque, hébergée sur infra.infratechcorpsolutionllp.com.

Étape 4 : Infrastructure compromise

La victime est maintenant dirigée vers ce qui semble être un document PDF :

Victime redirigée vers une infrastructure compromise

Le domaine infratechcorpsolutionllp.com appartient à ce qui semble être une entreprise de développement légitime basée en Inde. Cependant, le sous‑domaine infra.infratechcorpsolutionllp.com est plus suspect.

Bien que la redirection de l’étape précédente semble pointer vers un fichier .pdf, le serveur ne fournit en réalité aucun document. À la place, il renvoie une nouvelle redirection qui transfère la requête vers un autre domaine. Nos tests ont montré que toute requête envoyée vers ce serveur avec un chemin d’URL précis déclenche automatiquement la même redirection.

Le domaine principal et le sous‑domaine infra pointent tous deux vers la même infrastructure d’hébergement. Cela suggère que les attaquants ont probablement obtenu un accès au serveur et y ont inséré une logique de redirection malveillante vers un autre site :

Logique de redirection malveillante

HTTP/2 302 Found

Emplacement : https://www-0159.com/

Étape 5 : Redirection via un domaine réenregistré

Après le point de terminaison PDF factice, la victime est redirigée vers www-0159.com. L’analyse de l’historique du domaine montre qu’il existait initialement depuis plusieurs années et qu’il a été enregistré pour la première fois en 2017 par une entité chinoise. Depuis, plusieurs certificats TLS ont été émis pour ce domaine par différentes autorités de certification à travers le monde. Cependant, son certificat TLS précédent a expiré le 7 mars 2026, et les enregistrements DNS associés ont été supprimés peu après.

Le 12 mars 2026, le domaine a été réenregistré et plusieurs nouveaux certificats TLS ont été émis le même jour. Ce timing suggère fortement que le domaine a été récupéré puis réutilisé spécifiquement pour cette campagne.

Cette technique permet aux hackers de tirer parti de domaines qui ont déjà eu un usage légitime et qui peuvent encore conserver une certaine réputation. Réenregistrer des domaines expirés peut rendre une infrastructure malveillante moins suspecte pour les systèmes de sécurité automatisés qu’un domaine nouvellement créé.

À partir de là, la requête est à nouveau redirigée vers la dernière étape de la chaîne d’attaque, hébergée sur tradixyu.cfd, où l’infrastructure de phishing est protégée par Cloudflare.

Étape 6 : Page de validation humaine / anti‑bot

L’environnement d’hébergement de tradixyu.cfd utilise Cloudflare, ce qui masque le serveur d’origine et ajoute une couche de protection supplémentaire pour l’infrastructure des hackers.

Lorsque la victime atteint cette étape, une page de validation dans le navigateur s’affiche et nécessite une interaction manuelle. Cette étape vise à bloquer les outils d’analyse automatisés, les environnements sandbox et les scanners de sécurité qui tentent de suivre les liens malveillants.

Page de validation

Ce n’est qu’après que l’utilisateur a terminé cette validation que le site poursuit le chargement du contenu de phishing. La page indique ensuite que le système est « conforme », avant de finalement rediriger la victime vers une fausse page de connexion Microsoft 365.

Étape 7 : Page finale de phishing des identifiants Microsoft

Cette page de phishing très convaincante est conçue pour voler des identifiants. Comme le reste de la chaîne d’attaque, cette étape est également soigneusement élaborée : elle inclut notamment une fausse animation de chargement imitant Outlook, ainsi qu’une vérification qui confirme que la valeur saisie par l’utilisateur correspond bien à une adresse email. En dernière étape, le site tente une connexion légitime afin de vérifier que les identifiants capturés sont valides.

Page de connexion

Observations

Les caractéristiques de cette attaque semblent indiquer l’utilisation de Kratos, un kit Phishing‑as‑a‑Service relativement récent qui gagne en popularité grâce aux nombreuses fonctionnalités qu’il propose. Celles‑ci incluent notamment la capacité d’imiter des sites légitimes, des mécanismes empêchant l’analyse, ainsi que plusieurs fonctionnalités QoL facilitant le lancement et l’exploitation de campagnes complexes.

Des campagnes comme celle‑ci montrent que les opérations de phishing modernes reposent de plus en plus sur des infrastructures en plusieurs couches et sur des services légitimes pour échapper à la détection. Elles illustrent également que le phishing est devenu une véritable « industrie » de la cybercriminalité, avec des groupes et organisations spécialisés dans le développement et la maintenance de fonctionnalités toujours plus avancées.

Dans ce cas précis, les hackers ont combiné un envoi d’email signé DKIM, des infrastructures de redirection considérées comme fiables, des serveurs web compromis et des pages de phishing protégées par Cloudflare afin de masquer l’étape finale de collecte des identifiants. Ce type d’attaque montre que, même lorsque les utilisateurs sont formés à reconnaître les emails suspects, des campagnes de phishing bien conçues peuvent encore réussir.

« Le volume et la qualité des outils dont disposent les acteurs de la menace, y compris ceux sponsorisés par des États, est très élevé et continue d’augmenter. Il devient de plus en plus évident qu’un mot de passe, même combiné à une authentification multi-facteur standard (MFA), ne suffit pas à protéger contre un adversaire persistant et bien équipé.
Le phishing assisté par intelligence artificielle, en particulier, augmente le niveau moyen des attaques d’ingénierie sociale, au point que même des utilisateurs attentifs à la sécurité peuvent se faire avoir de temps en temps. Ce n’est pas une critique des utilisateurs, mais une réalité structurelle que les équipes de sécurité doivent prendre en compte.
La bonne approche n’est pas de rendre les utilisateurs parfaits. Il faut concevoir des systèmes dans lesquels un identifiant compromis seul ne permet pas à un hacker de prendre le contrôle. »

Commentaire de Martin Jartelius, directeur produit chez Outpost24, sur cette attaque

Pour y faire face, les organisations ont de plus en plus besoin de contrôles qui valident à la fois l’identité de l’utilisateur et l’état de sécurité de l’appareil effectuant la demande d’accès.

Stratégies de mitigation

Une défense efficace contre ce type d’attaque consiste à utiliser un accès Zero Trust lié à l’appareil, où l’authentification ne repose pas seulement sur l’identité de l’utilisateur, mais aussi sur la sécurité et la conformité de l’appareil utilisé pour se connecter.

Specops Device Trust (anciennement connu sous le nom d’Infinipoint), la solution Zero Trust de Specops, permet aux organisations d’appliquer ce modèle en vérifiant en continu la posture des appareils avant d’accorder l’accès aux applications et ressources de l’entreprise. Avec ce système :

• Les identifiants volés seuls ne permettent pas d’accéder aux ressources protégées
• Les demandes d’accès doivent provenir d’appareils connus et conformes aux politiques
• Les décisions d’accès peuvent inclure des vérifications en temps réel de la posture de l’appareil, comme la configuration du système et les contrôles de sécurité
• Si un appareil n’est plus conforme, l’accès peut être bloqué ou restreint jusqu’à ce qu’il redevienne sûr

En liant l’authentification à des appareils vérifiés plutôt qu’aux identifiants uniquement, les organisations peuvent réduire significativement l’impact des campagnes de phishing visant à voler mots de passe et jetons de session.

Parlons-en

Se protéger contre des campagnes de phishing de plus en plus sophistiquées nécessite des solutions robustes de sécurité des identités. Pour découvrir comment Specops peut aider votre organisation, contactez-nous ou réservez une démo pour voir nos solutions en action.