Une campagne de hameçonnage qui a duré deux mois consistait à dissimuler du code JavaScript malveillant dans des pièces jointes de messagerie vocale apparemment inoffensives, en les classant à tort comme du texte brut afin de contourner les scanners de pièces jointes. Le service « INKY » a détecté et signalé l’ensemble des 26 589 messages.

Entre le 1er juin et le 4 août 2026, INKY a suivi et détecté une campagne de hameçonnage prolongée qui utilisait un leurre d’une simplicité trompeuse — une notification de message vocal manqué — pour diffuser un code malveillant dissimulé dans un fichier image. Cette campagne a touché 5 527 organisations et généré 26 589 e-mails détectés.

Chaque e-mail a été intercepté et signalé comme dangereux. L'arme de prédilection des pirates était un format de fichier que la plupart des gens, ainsi que de nombreux filtres anti-spam, considèrent comme inoffensif : l'image SVG.

Cet article explique ce que sont les fichiers SVG, pourquoi les pirates les ont adoptés comme vecteur de diffusion de logiciels malveillants en 2026 et comment cette campagne a fonctionné exactement. Nous analysons également le code JavaScript obfusqué dissimulé dans la pièce jointe, l’astuce utilisée par les pirates pour faire passer le fichier pour du texte brut, ainsi que la manière dont INKY l’a détecté dans toutes les entreprises touchées.

Qu'est-ce qu'un fichier SVG, et pourquoi les pirates l'adorent-ils ?

Le format SVG (Scalable Vector Graphics) est un format d'image, mais contrairement au JPEG ou au PNG, il n'est pas constitué de pixels. Un fichier SVG est un fichier texte écrit en XML qui décrit mathématiquement des formes, des lignes et du texte, ce qui permet à l'image d'être redimensionnée à n'importe quelle taille sans perte de qualité. Les logos, icônes et graphiques que l'on trouve sur le Web sont souvent au format SVG.

Il existe toutefois une différence fondamentale entre un fichier SVG et une image classique : un fichier SVG peut contenir du code. La spécification SVG autorise l'intégration directe de scripts, notamment en JavaScript, au sein du fichier, ce qui permet de rendre les graphiques interactifs. Lorsqu'un fichier SVG est ouvert dans un navigateur web, ce code JavaScript intégré s'exécute. Un fichier PNG ne peut jamais le faire. Un fichier SVG, lui, le peut.

C'est précisément cette caractéristique que les pirates exploitent. Pour un utilisateur lambda, comme pour de nombreux outils de sécurité, un fichier SVG ressemble à une image. Pour un navigateur, en revanche, il peut servir de vecteur de diffusion d'un programme. Cet écart entre la façon dont le fichier est perçu et ce dont il est réellement capable constitue le fondement même de la technique connue sous le nom de « SVG smuggling ».

Pourquoi les fichiers SVG parviennent-ils à passer à travers les défenses ? Les passerelles de sécurité de messagerie ont mis des années à apprendre à bloquer les types de pièces jointes dangereuses, telles que les fichiers exécutables, les scripts, les documents contenant des macros et les archives. Les fichiers SVG étaient autrefois considérés comme des images inoffensives et donc autorisés. Les pirates s'en sont aperçus. En encapsulant leur code JavaScript dans une coque SVG, ils injectent du code actif au sein d'un type de fichier que de nombreux filtres n'ont jamais été configurés pour analyser.

Une menace grandissante pour 2026

Les attaques basées sur le format SVG ne sont pas une nouveauté. Des chercheurs ont recensé des pièces jointes SVG malveillantes dès 2017 environ, mais leur utilisation a explosé en 2026. Deux éléments ont changé : l'ampleur des campagnes et le niveau de sophistication des techniques de dissimulation.

• Une multiplication par cinquante. Selon le rapport 2026 de Hoxhunt sur les tendances en matière de hameçonnage, les pièces jointes SVG malveillantes ont été multipliées par cinquante en 2025 par rapport à 2024, et occupent désormais la troisième place parmi les types de pièces jointes malveillantes les plus courants, derrière les fichiers PDF et HTML.
• Des campagnes individuelles de grande envergure. Lors d'une campagne menée en février 2026 et suivie par Microsoft, environ 1,2 million de messages de hameçonnage au format SVG ont été envoyés à plus de 53 000 organisations réparties dans 23 pays. Le SANS Internet Storm Center a constaté que cette même technique inondait les boîtes de réception en juin 2026.
• Charges utiles dépourvues de contenu. En analysant des échantillons récents, les chercheurs ont découvert des fichiers SVG ne contenant absolument aucun contenu graphique. Ces fichiers ont pour seul but de transmettre du code JavaScript obfusqué au navigateur de la victime, tout en étant classés comme des images par la passerelle de messagerie.
• Leurre sous forme de message vocal. Plusieurs fournisseurs, dont Sublime Security et ReversingLabs, ont recensé des pièces jointes au format SVG déguisées en notifications de messages vocaux ou d'appels manqués, ce qui correspond précisément au leurre utilisé dans la campagne décrite ici.

La campagne INKY correspond exactement à ce schéma et ajoute un niveau de dissimulation supplémentaire en désignant à tort le type de fichier SVG comme du texte brut.

La campagne en bref

Chaque message de cette campagne suivait le même modèle : un e-mail interne falsifié se présentant comme une notification de message vocal, contenant une ou plusieurs pièces jointes au format SVG qui étaient en réalité du code JavaScript obscurci. Les statistiques ci-dessous sont tirées directement des données télémétriques d’ INKY , sur la période observée.

Système métrique	Valeur
Nombre total d'e-mails détectés	26,589
Organisations ciblées	5,527
Période de campagne respectée	1er juin – 4 août 2026 (en cours)
Traitement des menaces	Détecté à 100 %
Thème « Lure »	Notification d'appel manqué / de message vocal manqué
Charge utile	Pièce jointe au format SVG contenant du code JavaScript obscurci
Signe de dérobade	Pièce jointe SVG déclarée comme « text/plain »
Principaux signaux de détection	Contenu de hameçonnage (100 %), expéditeur interne usurpé (95 %)
Personnalisation	99,5 % des objets de courriel comportaient le nom d'utilisateur du destinataire

Tableau 1 : Résumé de la campagne d'après les données télémétriques de PhishFence d'INKY , du 1er juin au 4 août 2026.

Figure 1 : Volume quotidien d'e-mails détectés tout au long de la campagne. L'activité s'est déroulée par vagues, avec un pic le 3 juin (2 432 e-mails provenant de 1 149 organisations) et une reprise marquée fin juillet. On observe des baisses le week-end, lorsque la campagne était suspendue.

Une pulvérisation à grande échelle, et non une intervention ciblée

La répartition des e-mails entre les différentes organisations révèle une campagne de grande envergure et opportuniste, plutôt qu’une opération de précision. Sur les 5 527 organisations concernées, la médiane s'établit à seulement deux e-mails par organisation, et 32 % n'en ont reçu qu'un seul. Les dix organisations les plus touchées ne représentent à elles seules que 6 % du volume total. On ne constate aucune concentration sur un petit ensemble de cibles de grande valeur, ce qui est la marque distinctive d'une campagne de diffusion massive visant à collecter des identifiants à grande échelle, plutôt que d'une attaque de spear-phishing ciblée.

Figure 2 : Répartition des e-mails par organisation. La grande majorité des organisations n'a reçu qu'une poignée de messages, tandis qu'une très petite minorité d'organisations a été davantage touchée, ce qui confirme qu'il s'agit d'un envoi massif plutôt que d'une attaque ciblée.

Adapté au rythme de la semaine de travail

Le rythme d'envoi de la campagne renforce l'impression d'une opération conçue pour paraître crédible. Le volume d'envois était concentré du lundi au jeudi et atteignait son pic le mercredi, tandis qu'il n'y avait pratiquement aucun envoi le week-end. Cela correspond bien à un leurre destiné à arriver pendant que les destinataires travaillent activement et qu'une notification d'appel manqué passe pour un événement banal.

Figure 3 : Volume des campagnes par jour de la semaine. Les envois se concentrent du lundi au jeudi et cessent pratiquement pendant le week-end.

Personnalisé à partir de l'adresse de la personne visée

Dans 99,5 % des messages, le nom affiché dans la ligne d’objet était une copie exacte de la chaîne de caractères précédant le symbole @ dans l’adresse e-mail du destinataire lui-même. Un destinataire dont l’adresse serait jsmith@… verrait ainsi un objet du type « mCaller a laissé un message à Jsmith, aperçu de 34 secondes… ». Les attaquants n’avaient pas besoin d’une liste de contacts volée. Ils généraient automatiquement une personnalisation pour chaque destinataire à partir de l’adresse elle-même. Le fait que ces messages aient été générés par une machine plutôt que par un humain est révélé par le fait que les boîtes mail liées à des rôles étaient adressées par leur nom littéral (par exemple « mCaller left Accountspayable »), ce qu’aucun véritable expéditeur n’écrirait jamais.

Anatomie d'un e-mail de hameçonnage

L'e-mail lui-même est délibérément succinct. Il se présente sous la forme d'une notification automatique de message vocal, avec très peu de texte, un objet faisant référence à un appel manqué et une ou plusieurs pièces jointes conçues pour ressembler au fichier du message vocal. Vous trouverez ci-dessous un exemple expurgé tiré de cette campagne.

Figure 4 : Exemple d'e-mail issu de la campagne, dont certaines informations ont été masquées. Le message simule une notification interne de message vocal et contient deux pièces jointes dont les noms sont conçus pour ressembler à celui du fichier du message vocal. Notez l'extension .svg…​.txt. Les identifiants du destinataire et de l'expéditeur ont été masqués.

Deux niveaux de tromperie

Avant même qu'une seule ligne de code ne soit exécutée, le message repose déjà sur deux formes de tromperie au niveau de l'enveloppe :

• Expéditeur interne usurpé. L'e-mail prétend provenir du domaine du destinataire, mais il a en réalité été envoyé depuis une source externe et l'expéditeur n'a jamais été authentifié par le serveur de messagerie de l'organisation. Il est conçu pour ressembler à une notification interne du système.
• La pièce jointe est mal identifiée. Bien que les fichiers portent l'extension .svg et contiennent du balisage SVG/XML, ils sont déclarés dans le message avec un type de contenu « text/plain » au lieu de « image/svg+xml ». Un scanner de pièces jointes qui se base sur le type déclaré détecte alors un fichier texte inoffensif, et non un contenu actif.

Contenu de la pièce jointe : ce que fait réellement le code

En ouvrant la pièce jointe dans un éditeur de texte, plutôt que dans un navigateur, on constate que le « message vocal » n'est pas du tout une image. Il s'agit d'un document XML contenant du code JavaScript obscurci. La capture d'écran ci-dessous montre le contenu brut d'un exemple.

Figure 5 : Contenu brut de la pièce jointe SVG. Sous une fine couche SVG (un titre et deux rectangles) se cache du code JavaScript obscurci, contenu dans un objet « foreignObject » et un bloc CDATA de type « script ». Le bloc contenant l'URL de rappel active a été masqué.

La structure

Dans sa forme la plus simple, le fichier se compose de trois parties :

• Une coque SVG minimaliste. Un <svg> racine avec un <title> et quelques <rect> éléments. C'est la seule partie qui s'afficherait sous forme d'« image », et il s'agit essentiellement d'une couverture décorative.
• Un attribut de données caché. L'élément racine comporte un attribut personnalisé (par exemple data-strand-key-tk=« … ») contenant une valeur codée que le script lit lors de l'exécution. Le fait de dissimuler la configuration dans des attributs obscurs permet d'éviter que les valeurs malveillantes ne se retrouvent dans le chemin d'exécution évident.
• Deux charges utiles de script. A <foreignObject> contenant du code HTML <script type="application/json"> bloc, et un deuxième

Comment fonctionne l'obfuscation ?

Le code est conçu pour déjouer à la fois les analystes humains et les scanners automatisés qui recherchent des schémas malveillants reconnaissables. Plusieurs techniques sont combinées :

• Des noms de fonctions et de variables dénués de sens. Chaque identifiant est dissimulé sous des noms farfelus à connotation pseudo-scientifique et inspirés de la biologie, tels que « intronGap91 », « riboUnit30 », « vectorArm37 », « codonBuf13Go » ou « primerSet56 ». Ces noms n'ont aucune signification et n'existent que pour rendre le code illisible et varier d'un échantillon à l'autre, de sorte qu'aucun fichier ne ressemble à un autre.
• Construction de chaînes à partir de codes de caractères. Les chaînes sensibles ne sont jamais écrites en texte clair. Elles sont plutôt assemblées lors de l'exécution à partir de codes de caractères numériques via la méthode `String.fromCharCode(…)`. Un analyseur statique lisant le fichier voit une liste de nombres, et non les mots qu'ils représentent.
• Injection de script à l'exécution. Plutôt que d'appeler directement des fonctions dangereuses, le code crée un nouvel élément de script à l'aide de la méthode `document.createElementNS(…)`, lui attribue une source constituée d'une valeur générée à l'exécution, puis l'ajoute au document. Il s'agit d'une méthode couramment utilisée pour contourner l'analyse statique, car la destination malveillante n'existe pas sous forme de chaîne littérale dans le fichier.
• Exécution différée. L'exécution est planifiée via requestIdleCallback / setTimeout ; ainsi, la charge utile se déclenche légèrement après le chargement plutôt qu'immédiatement, ce qui lui permet d'échapper aux outils qui ne détectent que le moment où un fichier est ouvert.

Ce que cela fait réellement

Une fois décodée, cette technique d'obfuscation devient évidente. Les séquences de codes de caractères présentes dans l'exemple se traduisent par de courtes chaînes de caractères que le script utilise pour construire le nom du point de terminaison distant qu'il contacte. Un scanner statique analysant le fichier ne voit que la liste de chiffres ci-dessous, jamais les mots qu'ils forment :

String.fromCharCode(104,116,116,112,115) -> « https » String.fromCharCode(46,112,104,112) -> « .php » (les codes numériques permettent de constituer le point de terminaison lors de l'exécution)

Le code lit son attribut « data » caché, assemble le nom du point de terminaison à partir de ces codes, puis utilise la fonction `window.fetch(…)` pour contacter un serveur contrôlé par le pirate et récupérer la prochaine étape de l'attaque. Le fichier SVG lui-même ne contient pas la page de hameçonnage ; il s'agit d'un lanceur qui récupère sa charge utile depuis un serveur distant au moment de l'exécution.

D'après le comportement habituel de ce type de campagne, cette prochaine étape suit généralement un schéma bien connu.

Le contenu récupéré est généralement une page destinée à dérober des identifiants, imitant une interface de connexion couramment utilisée, telle que celle de Microsoft 365, Google Workspace ou Adobe. Dans de nombreuses campagnes, l’adresse e-mail de la victime est transmise et utilisée pour préremplir le faux formulaire de connexion, ce qui donne l’impression qu’il s’agit d’un message personnalisé et légitime.

De plus en plus, ces pages ne sont pas de simples clones, mais des portails de type « adversary-in-the-middle » (AiTM): elles transmettent en temps réel ce que la victime saisit au véritable service de connexion, capturent le jeton de session généré et contournent ainsi l'authentification multifactorielle. Cette technique a été associée à des kits de « phishing-as-a-service » tels que Tycoon2FA, Mamba2FA et Sneaky2FA. L'hébergement à distance de la charge utile permet également à l’attaquant de mettre à jour ou de remplacer la page de hameçonnage à tout moment sans jamais modifier le fichier SVG initialement diffusé.

L'idée clé Le fichier SVG n'est pas la charge utile. C'est le **conteneur de contrebande**. Son seul rôle est de faire passer du code JavaScript exécutable à travers la passerelle de messagerie à l'intérieur d'un fichier de type image (ici, faussement étiqueté comme « texte »), puis de transmettre ce code au navigateur, qui peut l'exécuter. La pièce jointe qui ressemble à un message vocal est en réalité un petit programme dont la première action consiste à « rentrer à la base ».

Pourquoi cette campagne contourne les défenses traditionnelles

• Type de fichier considéré comme fiable. Les fichiers SVG sont généralement considérés comme des images inoffensives. Par le passé, de nombreuses passerelles ne les analysaient pas en tant que contenu actif.
• Erreur d'étiquetage MIME. Le fait de déclarer la pièce jointe comme « text/plain » permet de contourner les scanners qui décident de l'inspecter ou non en fonction du type de contenu indiqué.
• Pas de signature statique. La présence d’identifiants aléatoires, la construction de chaînes de codes de caractères et les variations d’échantillon en échantillon font qu’il n’existe aucune chaîne ni aucun hachage fixe à comparer tout au long de la campagne. Chaque fichier présente un aspect différent.
• Charge utile active uniquement lors de l'exécution. La destination malveillante n'est assemblée et récupérée que lorsque le fichier est exécuté dans un navigateur. Elle n'apparaît pas sous forme de texte lisible pouvant être détecté par un scanner statique.
• Fausse identité interne. Le message se fait passer pour une notification interne, en tirant parti de la confiance que les utilisateurs accordent aux e-mails qui semblent provenir de leur propre organisation.

Mise en correspondance avec le cadre MITRE ATT&CK

Les techniques observées dans le cadre de cette campagne correspondent aux tactiques et techniques suivantes du modèle MITRE ATT&CK.

Tactique	Technique (ID)	Comment cela se traduit-il dans cette campagne ?
Accès initial	Hameçonnage : pièce jointe de spearphishing (T1566.001)	Fichier SVG malveillant transmis en pièce jointe d'un e-mail, déguisé en fichier de message vocal
Exécution	Exécution par l'utilisateur : fichier malveillant (T1204.002)	L'attaque repose sur le fait que le destinataire ouvre le fichier SVG, ce qui déclenche l'exécution du code JavaScript intégré dans le navigateur.
Évasion défensive	Déguisement (T1036)	Pièce jointe au format SVG incorrectement identifiée comme « text/plain » et présentée comme une notification de message vocal
Évasion défensive	Fichiers ou informations obscurcis (T1027)	Les identifiants indésirables, la construction de chaînes de codes de caractères et les variations d'échantillon en échantillon masquent l'intention
Évasion défensive	Désobfusquer/décoder des fichiers ou des informations (T1140)	Le script reconstitue les chaînes de caractères et leur destination lors de l'exécution à l'aide de la méthode String.fromCharCode
Évasion défensive	Fausses alertes de sécurité / Usurpation d'identité (T1656)	Le message se fait passer pour un expéditeur interne du système appartenant au domaine du destinataire
Commandement et contrôle	Protocole de la couche application : protocoles Web (T1071.001)	Le script intégré utilise une requête Web vers un point de terminaison contrôlé par l'attaquant pour récupérer la phase suivante
Accès aux identifiants	Capture des données saisies (T1056)	L'étape suivante consiste généralement en une page destinée à récupérer des identifiants, qui se fait passer pour une page de connexion familière.

Tableau 3 : Mise en correspondance avec le modèle MITRE ATT&CK pour la campagne de messages vocaux visant à détourner des identifiants SVG. L'étape « accès aux identifiants » est déduite de la charge utile de suivi récupérée, caractéristique de cette catégorie de campagne.

Comment « INKY » l'a détecté

INKY ne repose pas sur des hypothèses relatives au type de fichier ni sur des signatures statiques. Il évalue l’ensemble du contexte et le comportement de chaque message. Sur l’ensemble des 26 589 e-mails, INKY a détecté la campagne et a signalé chaque message avec un verdict « Danger ». La détection s’est appuyée sur un signal universel, renforcé par un second :

• Le contenu de hameçonnage a permis de détecter 100 % de la campagne. Chaque message a été classé comme du hameçonnage sur la base de plusieurs indicateurs suspects, notamment le fait qu’il comportait une pièce jointe au contenu suspect et ressemblait à une fausse notification de message vocal. C’est ce signal qui a permis de détecter l’intégralité de la campagne, dans toutes les organisations, sans exception.
• Le critère « Expéditeur interne usurpé » s’est déclenché dans 95 % des cas de la campagne. En guise de signal supplémentaire, le filtre « INKY » a détecté que le message prétendait provenir du domaine du destinataire, mais qu’il provenait en réalité d’une source externe, avec un expéditeur qui ne s’était pas authentifié auprès du serveur de messagerie de l’organisation. Ce critère s’est déclenché dans 95 % des cas de la campagne ; les messages restants, dans les organisations où ce critère particulier n’était pas activé, ont tout de même été intégralement interceptés par le filtre « Phishing Content ».

La bannière INKY présentée aux destinataires expliquait précisément pourquoi ce message était dangereux :

Figure 6 : Bannière d'avertissement « INKY » affichée dans un message de campagne, expliquant les deux catégories de menaces en langage clair. Le domaine du destinataire a été masqué.

Chaque message a été évalué à l'aune de l'ensemble des catégories de menaces définies par l'INKY . Le contenu de hameçonnage suffisait à lui seul à signaler chaque message de la campagne comme dangereux, l'utilisation d'un expéditeur interne usurpé venant ajouter un deuxième signal corroborant ce constat pour la plupart d'entre eux.

Catégorie de menace	Couverture	Rôle dans la détection
Contenu de hameçonnage	100%	Signal universel — tous les messages ont été captés
Expéditeur interne falsifié	95%	Signal de confirmation sur la plupart des messages

Tableau 2 : Catégories de menaces identifiées par l’ INKY au cours de la campagne. Le filtrage anti-hameçonnage a signalé tous les messages ; l’identification d’un expéditeur interne usurpé a confirmé la plupart d’entre eux.

Ce qu'a détecté le système de filtrage intégré de Microsoft

Dans le cadre de cette campagne, le fossé entre le verdict rendu dans l’affaire « INKY» et le filtrage natif des e-mails est flagrant.

Microsoft attribue à chaque message un niveau de confiance anti-spam (SCL): un score de 0 ou 1 signifie que le message a été jugé comme n'étant pas du spam et qu'il est livré normalement dans la boîte de réception, tandis qu'un score de 5 le classe comme spam. Au cours de cette campagne, 19 994 des 26 589 messages (75 %) avaient un SCL Microsoft de 0 ou 1, et seuls 4 777 (18 %) avaient obtenu un SCL de 5.

En d'autres termes, le filtre anti-spam intégré de Microsoft a classé trois de ces messages de hameçonnage sur quatre comme n'étant pas du spam, mais comme des e-mails destinés à la boîte de réception, tandis que INKY les a tous signalés de manière indépendante comme dangereux.

Figure 7 : Comparaison entre le score de spam attribué par Microsoft et le verdict d'INKY tout au long de la campagne. Microsoft a classé 75 % des messages comme n'étant pas du spam (SCL 0 ou 1) et seulement 18 % comme du spam (SCL 5), tandis qu'INKY a émis un verdict « dangereux » pour l'ensemble des 26 589 messages.

Ce qui est frappant, c'est que cette campagne a été élaborée à partir d'un seul et même modèle. Une structure de message identique, un appât identique et une pièce jointe identique ont donné lieu à des classements natifs radicalement différents selon la boîte de réception : « normal » pour la plupart, « spam » pour certaines.

INKY, en revanche, a rendu le même verdict de danger pour l’ensemble des 26 589 messages. C’est là l’argument central en faveur de la détection basée sur le comportement : un message jugé « propre » du point de vue du spam peut tout de même constituer une attaque de hameçonnage visant à dérober des identifiants, et seule une approche évaluant l’ensemble du contexte permet de la détecter de manière fiable.

Indicateurs de compromission

Les indicateurs suivants sont associés à cette campagne. La charge utile variant d'un échantillon à l'autre, les indicateurs comportementaux et de schémas sont plus fiables que n'importe quel hachage de fichier pris isolément.

Indicateur	Valeur / Motif	Remarques
Thème « Lure »	Notification d'appel manqué / de message vocal manqué	Prétexte d'ingénierie sociale
Modèle de sujet	mCaller left <name> - 34s Preview vHC- <date> <number>	<name> = recipient's email local-part
Nom de la pièce jointe	PLAY_Voice-….svg	Nom de fichier SVG inspiré de la messagerie vocale
Type MIME déclaré	text/plain	Fichier SVG mal étiqueté pour échapper aux scanners
Comportement de la charge utile	SVG → code JS obfusqué → requête vers un point de terminaison distant	Injection de script / rappel au moment de l'exécution
Obscurcissement	String.fromCharCode, identifiants indésirables	Contourne les signatures statiques

Tableau 4 : Indicateurs de compromission liés à la campagne de messagerie vocale clandestine SVG.

Recommandations

À l'attention des équipes de sécurité

1. Considérez les fichiers SVG comme du contenu actif. Configurez les passerelles de messagerie et Web de manière à ce qu’elles analysent les pièces jointes au format SVG en les considérant comme des vecteurs potentiels de scripts, et non comme de simples images inoffensives ; ne vous fiez pas au type MIME déclaré pour déterminer s’il convient de les analyser.
2. Envisagez de bloquer ou de mettre en quarantaine les pièces jointes SVG entrantes. Dans le cadre d'une communication professionnelle légitime, il est rare que l'on ait besoin d'envoyer directement des fichiers SVG aux utilisateurs finaux. Le blocage ou la mise en quarantaine des fichiers SVG entrants permet d'éliminer une surface d'attaque en expansion, tout en minimisant les perturbations.
3. Ne vous fiez pas aux signatures basées sur les hachages de fichiers. L’obfuscation au cas par cas fait que les hachages changent constamment. Privilégiez la détection comportementale et basée sur le contenu, qui évalue ce que fait un fichier, et non ce à quoi il correspond.
4. Renforcez les contrôles contre l'usurpation interne. Assurez-vous que votre système de sécurité des e-mails est capable de détecter les messages qui prétendent provenir de votre propre domaine mais qui proviennent en réalité de l'extérieur et ne sont pas authentifiés : c'est en effet sur cette « astuce de l'enveloppe » que reposait cette campagne.
5. Sensibilisez les utilisateurs aux messages vocaux et aux pièces jointes sous forme d'images inattendus. Insistez sur le fait qu'un e-mail signalant un appel manqué ou un message vocal, accompagné d'une pièce jointe permettant d'« écouter » le message, constitue un prétexte courant utilisé dans le cadre d'attaques de hameçonnage, et que les fichiers image peuvent contenir du code.

À l'attention des destinataires de l'e-mail

• Méfiez-vous des notifications de messages vocaux ou d'appels manqués qui vous parviennent par e-mail sous forme de pièce jointe à ouvrir, surtout si vous ne les attendiez pas.
• N'ouvrez jamais une pièce jointe au format .svg que vous n'attendiez pas. Contrairement aux images classiques, les fichiers SVG peuvent exécuter du code lorsqu'ils sont ouverts dans un navigateur.
• Considérez comme non fiable toute page de connexion à laquelle vous accédez en ouvrant une pièce jointe. Accédez directement aux services, sans passer par les liens ou les fichiers contenus dans les e-mails.
• N'oubliez pas qu'un e-mail semblant provenir de votre propre organisation peut tout de même être un faux. Une notification « système » qui semble provenir de l'interne ne constitue pas une preuve de légitimité.

Conclusion

Cette campagne est un exemple typique d’une technique caractéristique des menaces par e-mail en 2026 : dissimuler du code exécutable dans un type de fichier que tout le monde considère comme une image inoffensive. En intégrant du code JavaScript obfusqué dans un fichier SVG, en déguisant ce fichier SVG en texte brut, en usurpant l'identité d'un expéditeur interne et en présentant le tout comme un message vocal banal, les attaquants ont mis au point un leurre conçu pour échapper à la fois aux filtres automatisés et au jugement humain, à une échelle de dizaines de milliers de messages envoyés à des milliers d'organisations.

Cela n’a pas fonctionné. INKY a détecté et signalé l’ensemble des 26 589 messages, en s’appuyant sur des indicateurs comportementaux qui évaluent la nature et le comportement d’un message plutôt que de se fier à ce qu’il prétend être. Cette distinction est essentielle : les filtres anti-spam natifs ont classé les trois quarts de cette campagne comme des e-mails légitimes, destinés à la boîte de réception. Alors que les attaquants continuent d’exploiter à des fins malveillantes des formats de fichiers fiables, c’est une approche axée sur le comportement, et non sur les signatures ou les hypothèses relatives au type de fichier, qui fait la différence entre la détection et la livraison.

Mots-clés : contrebande de fichiers SVG, hameçonnage via SVG, pièce jointe SVG malveillante, contrebande de JavaScript, hameçonnage par messagerie vocale, contournement des types MIME, expéditeur interne usurpé, sécurité des e-mails 2026, INKY PhishFence, renseignements sur les menaces