Articleransomware

Le ransomware INC enchaîne deux zero-days SonicWall SMA (CVE-2026-15409, CVE-2026-15410)

Des affiliés d'INC exploitent une SSRF et une injection de code post-authentification sur SonicWall SMA 1000 pour atteindre les réseaux internes. L'exploitation a commencé des semaines avant le correctif du 14 juillet — voici comment mener la recherche et le triage.

IsMalicious TeamIsMalicious Team
8 min read
Cover Image for Le ransomware INC enchaîne deux zero-days SonicWall SMA (CVE-2026-15409, CVE-2026-15410)
Signal
Context
Action

Des affiliés du ransomware INC ont passé la majeure partie de juillet 2026 à parcourir les appliances SonicWall Secure Mobile Access 1000 exposées sur Internet, et l'histoire technique est celle d'un enchaînement de deux failles plutôt que d'un correctif manqué isolé. CVE-2026-15409 est une faille SSRF. CVE-2026-15410 est une injection de code post-authentification sur le chemin wsproxy. Enchaînées sur un équipement de périphérie qui se trouve déjà entre Internet et votre réseau interne, elles offrent à un acteur externe bien plus qu'un simple point d'appui sur un concentrateur VPN.

Ce qui justifie de traiter cet incident comme un dossier actif plutôt qu'un ticket de correctif, c'est le calendrier. SonicWall a divulgué et corrigé les deux failles le 14 juillet 2026 dans l'avis SNWLID-2026-0008. La CISA les a ajoutées au catalogue Known Exploited Vulnerabilities le même jour, avec une échéance fédérale de remédiation au 17 juillet. Le renseignement sur les menaces lié au cluster UTA0533 montre cependant une exploitation dans la nature débutant environ trois semaines plus tôt. Au moment où l'avis est paru, les affiliés d'INC disposaient déjà d'une piste mesurée en semaines, non en heures.

Comment la chaîne fonctionne sur SMA 1000

Les appliances SonicWall SMA 1000 terminent l'accès distant pour les employés et les partenaires. Cette position compte : une compromission ici n'équivaut pas à celle d'un serveur web ordinaire. L'appliance est conçue pour joindre des hôtes internes, conserver l'état des sessions et établir des connexions que les équipes de sécurité autorisent volontairement à traverser la périphérie.

La chaîne observée se déroule en deux étapes :

  • CVE-2026-15409 (SSRF) permet à un attaquant non authentifié de contraindre l'appliance à émettre des requêtes qu'il spécifie. Sur une passerelle d'accès, une SSRF est rarement un bug abstrait. C'est un moyen d'atteindre des interfaces de gestion, des services internes et des points de terminaison réservés à localhost qui n'étaient pas censés répondre depuis la périphérie Internet.
  • CVE-2026-15410 (injection de code wsproxy) intervient une fois que l'attaquant dispose du contexte post-authentification attendu par le composant wsproxy. Le chemin d'injection mène à l'exécution de code avec les privilèges du service concerné, ce qui, sur une appliance SMA, suffit à faire fonctionner l'équipement au gré de l'attaquant.

Aucune des deux CVE seule ne correspond à ce que les défenseurs ont observé chez les victimes. Les affiliés d'INC et l'ensemble d'activité UTA0533 plus large ont utilisé la paire comme un unique primitif d'intrusion, d'où la nécessité de prioriser le correctif pour les deux identifiants même si un seul apparaissait dans un rapport de scan.

INC comme opérateur dominant

Parmi les groupes de ransomware suivis en juillet et début août 2026, INC a été l'opérateur le plus constant sur cette chaîne. Il ne s'agit pas d'une exclusivité — d'autres acteurs ont pu obtenir le même kit d'exploitation — mais la chronologie du site de fuite est instructive.

Des victimes liées à une compromission SMA ont commencé à apparaître sur le site d'extorsion d'INC de la mi-juillet au 1er août. Cette fenêtre chevauche la période d'exploitation pré-avis plutôt que de la suivre de quelques jours. Les organisations qui ont traité SNWLID-2026-0008 comme « corriger cette semaine » plutôt que « supposer une compromission depuis fin juin » sont celles qui établissent aujourd'hui le périmètre d'un vol de données commencé avant la mise à jour du firmware.

Le mode opératoire d'INC sur les appliances de périphérie reprend un schéma connu sur d'autres cibles VPN et d'accès distant : établir une persistance sur la passerelle, cartographier les sous-réseaux internes joignables depuis la table de routage de l'appliance, déployer un mécanisme de préparation léger, puis se déplacer vers les contrôleurs de domaine ou les serveurs de fichiers en utilisant les identifiants et sessions que l'appliance peut atteindre. Le chiffrement, lorsqu'il apparaît, intervient tardivement et sert de levier de pression plutôt que d'accès initial.

Pourquoi corriger après compromission n'est pas un cadrage

Un firmware qui ferme CVE-2026-15409 et CVE-2026-15410 arrête les nouvelles exploitations. Il ne supprime pas les webshells, tâches planifiées ou caches d'identifiants qu'un attaquant a déposés pendant que les failles étaient ouvertes.

Si votre SMA 1000 était exposée sur Internet en juin et juillet 2026, la posture minimale défendable est la suivante :

  • Conserver les journaux de l'appliance et toute sortie de debug wsproxy disponible avant que la rotation des logs n'efface la fenêtre pré-correctif.
  • Rechercher des connexions sortantes inattendues depuis les interfaces de gestion et de plan de données de la SMA. Les appliances de périphérie ont une liste courte de destinations légitimes — points de mise à jour du fabricant, votre fournisseur d'identité, peut-être un collecteur syslog. Tout le reste mérite un enrichissement avant d'être écarté comme bruit VPN utilisateur.
  • Examiner les tables d'authentification et de session pour des comptes authentifiés depuis des géographies ou ASN incohérents avec votre population d'utilisateurs, en particulier durant les trois semaines précédant le 14 juillet.
  • Renouveler les secrets que l'appliance stocke ou peut joindre — secrets partagés RADIUS, mots de passe LDAP, clés privées de certificats téléversés pour le portail, jetons API configurés pour les intégrations.
  • Inspecter les hôtes en aval ayant accepté des connexions provenant de l'appliance SMA durant la fenêtre d'exposition. Les étapes SSRF et wsproxy précèdent souvent le mouvement latéral de plusieurs jours.

Les équipes qui se sont arrêtées à « nous avons corrigé le 15 juillet » sans recherche rétrospective découvrent des entrées sur le site de fuite faisant référence à des arborescences de fichiers exfiltrées avant la mise à niveau du firmware.

Signaux de détection et de recherche

Artefacts concrets à exploiter :

  • Requêtes non authentifiées vers les chemins wsproxy suivies de processus fils anormaux sur l'appliance, si vos journaux capturent l'exécution de processus au niveau OS.
  • Requêtes HTTP internes émanant de l'hôte SMA vers des destinations RFC1918 ou link-local qui ne font pas partie de votre configuration documentée de split-tunnel ou de portail — l'étape SSRF apparaît souvent ici avant la réussite de l'injection de code.
  • Fichiers nouveaux ou modifiés sous les répertoires web ou script de l'appliance avec des horodatages antérieurs au correctif.
  • Pics de sessions VPN concurrentes depuis un petit ensemble d'adresses sources, surtout si ces sessions se terminent rapidement après avoir atteint des ressources internes.
  • Trafic sortant vers des ASN de VPS ou hébergement bulletproof inconnus depuis l'appliance elle-même plutôt que depuis le trafic client tunnelisé.

Les indicateurs publiés par le fabricant avec SNWLID-2026-0008 doivent être ingérés dans votre SIEM, mais les dossiers rétrospectifs se terminent rarement avec les seuls IOC du vendeur. Les adresses et domaines de vos propres journaux de trafic sortant de juin et juillet sont l'ensemble qui compte.

Enrichir les indicateurs issus de la télémétrie SMA

La recherche produit des centaines d'adresses IP et de domaines candidats. La question de triage est de savoir quelles connexions représentent un comportement d'accès distant ordinaire et lesquelles pointent vers l'infrastructure de préparation d'INC.

  • Faites passer les adresses sources et destinations inconnues par des recherches de réputation IP pour vérifier l'ASN, le contexte d'hébergement et les associations malveillantes antérieures avant d'escalader.
  • Pour les domaines vus dans les cibles SSRF ou les callbacks sortants, utilisez le renseignement domaine et l'historique DNS — l'infrastructure de campagne possède souvent une chronologie d'enregistrement qui ne ressemble pas à une dépendance VPN d'entreprise.
  • Poussez l'ensemble candidat via des recherches en masse plutôt que de pivoter indicateur par indicateur. Une fenêtre de trois semaines sur une SMA chargée génère assez de bruit pour bloquer la réponse à incident.
  • Branchez l'enrichissement dans votre SIEM via l'API pour que le même contexte s'attache automatiquement à la prochaine alerte liée à la SMA.
  • Suivez les deux CVE dans CVE Watch sur les produits SonicWall déclarés afin que le statut KEV et l'évolution EPSS repriorisent les files de correctifs sans revue tableur.

Lorsque vous récupérez des binaires ou scripts sur le système de fichiers de l'appliance, les recherches par hash de fichier aident à déterminer si l'artefact correspond à une boîte à outils INC connue ou à un dropper ad hoc.

Posture de périphérie et de réponse à incident

Les appliances SMA 1000 appartiennent au même niveau de risque que tout autre produit d'accès distant exposé sur Internet : restreindre les interfaces de gestion aux hôtes de saut administratifs, imposer la MFA sur toute authentification portail, et surveiller l'appliance comme un capteur de sécurité plutôt que comme une simple plomberie réseau.

Si l'enrichissement confirme un contact avec une infrastructure INC connue ou si le calendrier du site de fuite correspond à votre fenêtre d'exposition, traitez la réponse à incident d'abord comme une enquête sur le vol de données. Le modèle de pression d'INC repose sur la preuve d'exfiltration ; vos journaux et indicateurs de trafic sortant enrichis disent si cette preuve existe.

Pour les organisations alimentant des indicateurs dans des contrôles en aval, les adresses malveillantes confirmées peuvent être poussées vers l'application de blocklist au pare-feu une fois la correspondance documentée — les équipes pare-feu doivent se coordonner avec le responsable du dossier SMA pour que le blocage ne coupe pas prématurément la collecte de preuves.

L'avis est publié, les entrées KEV sont actives et le correctif est disponible. La question ouverte pour de nombreuses équipes n'est pas de savoir s'il faut mettre à jour le firmware, mais si les journaux de trafic de juillet contiennent la réponse à une compromission qu'elles n'ont pas encore terminé de cadrer.

FAQ

Frequently asked questions

Quelles vulnérabilités la campagne INC sur SonicWall SMA exploite-t-elle ?
Les attaquants enchaînent CVE-2026-15409, une faille SSRF sur SonicWall SMA 1000, avec CVE-2026-15410, une injection de code post-authentification dans le composant wsproxy. Utilisées ensemble, ces failles offrent à un acteur externe un chemin depuis l'appliance exposée sur Internet jusqu'à l'exécution de code et au mouvement latéral, sans attendre qu'un utilisateur s'authentifie par les voies normales.
Quand SonicWall SMA a-t-il été corrigé et quelle est l'échéance CISA ?
SonicWall a publié SNWLID-2026-0008 le 14 juillet 2026 avec un firmware corrigé pour la série SMA 1000. La CISA a ajouté les deux CVE au catalogue Known Exploited Vulnerabilities le même jour, fixant une échéance fédérale de remédiation au 17 juillet 2026 en vertu de la Binding Operational Directive 22-01.
Combien de temps l'exploitation a-t-elle duré avant le correctif ?
Le renseignement sur les menaces attribué au cluster UTA0533 indique une exploitation active environ trois semaines avant la parution de l'avis. Les organisations qui ont corrigé le 14 juillet peuvent donc déjà avoir hébergé un intrus sur l'appliance pendant la majeure partie de juillet. Considérez un correctif de juillet comme la fermeture de la porte, non comme la preuve que la maison était vide.
Quel comportement post-compromission INC a-t-on observé sur cette chaîne ?
INC a été le groupe de ransomware dominant observé utilisant la chaîne complète. Des victimes ont commencé à apparaître sur le site de fuite du groupe de la mi-juillet au 1er août 2026, ce qui correspond à la fenêtre d'exploitation pré-correctif plutôt qu'à une réaction des défenseurs à l'avis.
En quoi isMalicious aide-t-il à répondre à cette campagne ?
Après avoir recherché le trafic sortant des appliances SMA, les équipes peuvent faire passer les adresses IP et domaines inconnus par un enrichissement en masse pour distinguer le trafic partenaire VPN de l'infrastructure de préparation et d'exfiltration. Les mêmes recherches alimentent les workflows SIEM via l'API, et CVE Watch suit le statut KEV de CVE-2026-15409 et CVE-2026-15410 sur les actifs SonicWall déclarés.
Read next

Protect Your Infrastructure

Check any IP or domain against our threat intelligence database with indexed records.

Try the IP / Domain Checker