La chaîne zero-day MikroTrick donne aux attaquants le contrôle administrateur des routeurs MikroTik

Les appareils MikroTik RouterOS dont le service SSH est exposé sur Internet font actuellement l’objet d’attaques au moyen d’une chaîne de vulnérabilités connue sous le nom de MikroTrick. Cette campagne permet à un attaquant de passer d’un accès SSH non authentifié au contrôle administrateur complet d’un routeur vulnérable.

La chaîne combine CVE-2026-67276, une vulnérabilité critique permettant de contourner l’authentification par clé RSA, évaluée à CVSS 9.2, et CVE-2026-86060, une faille d’élévation de privilèges dans les sessions SSH. CERT Polska a confirmé la compromission de plusieurs appareils, notamment la création d’un compte non autorisé nommé ops.

Le chercheur en sécurité Costin Raiu a indiqué que l’exploitation pourrait avoir débuté le 2 septembre 2026, soit un jour avant la publication par MikroTik des correctifs concernés. Cette chronologie fait de MikroTrick une campagne zero-day, et non une exploitation apparue uniquement après l’analyse publique des correctifs.

L’exploitation a précédé les mises à jour de sécurité de MikroTik

Des journaux publiés sur un forum polonais consacré à la sécurité font état de tentatives d’exploitation remontant au 2 septembre. De son côté, CERT Polska a confirmé des attaques réussies ayant commencé au plus tard ce jour-là.

MikroTik a publié des correctifs dans RouterOS 7.25beta3, 7.24.2, 7.23.4 et 6.49.21 le 3 septembre 2026. RouterOS 7.23.5, publié le 4 septembre 2026, est également identifié comme corrigé.

Raiu a publié son analyse technique le 5 septembre 2026. Le même jour, CERT Polska a diffusé un avis signalant l’exploitation active de vulnérabilités critiques de RouterOS et exhortant les clients à effectuer immédiatement la mise à jour.

Cette chronologie laisse penser que les attaquants savaient que des correctifs allaient être publiés et ont commencé à analyser ou à exploiter les appareils avant que les administrateurs ne puissent les installer. La plupart des activités observées provenaient d’une seule adresse, ce qui indique une opération capable de cibler des routeurs exposés à grande échelle.

MikroTik a également envoyé des alertes de sécurité via son application mobile officielle. Il s’agirait de la première fois que l’entreprise utilise ce canal pour diffuser une alerte de sécurité.

Aucune entrée correspondante dans le catalogue des vulnérabilités exploitées connues de la CISA ni aucune échéance fédérale associée n’a été communiquée pour ces failles. Toutefois, l’exploitation confirmée montre déjà que le risque est opérationnel et non théorique.

Comment la chaîne MikroTrick contourne l’authentification SSH

CVE-2026-67276 concerne la validation, par RouterOS, des clés publiques RSA lors de l’authentification SSH. Un attaquant qui connaît un nom d’utilisateur valide ainsi que la composante publique de la clé RSA de cet utilisateur peut construire une clé frauduleuse que RouterOS acceptera sans qu’il ne possède la clé privée correspondante.

Cette faille remet en cause un principe fondamental de la sécurité SSH. Les clés publiques servent à identifier les identifiants autorisés, tandis que la clé privée prouve que la partie qui se connecte en est bien le propriétaire légitime. Les versions vulnérables de RouterOS peuvent être trompées et accepter l’authentification sans cette preuve.

Cet accès non autorisé est ensuite combiné à CVE-2026-86060, qui permet une élévation de privilèges au sein d’une session SSH. L’enchaînement des deux vulnérabilités peut donner à un attaquant distant et non authentifié le contrôle administrateur complet.

Le scénario d’attaque nécessite que le service SSH de RouterOS soit accessible depuis le réseau de l’attaquant. Les routeurs qui exposent directement SSH sur Internet sont les plus menacés, même si un appareil peut également être ciblé depuis un autre réseau non fiable ou déjà compromis.

Ces deux vulnérabilités font partie des six failles de RouterOS identifiées et dont la divulgation a été coordonnée par CERT Polska. Les plages exactes de versions vulnérables n’ont pas été communiquées. Les administrateurs doivent donc comparer leurs installations aux versions corrigées de la branche concernée, plutôt que de supposer qu’une version légèrement plus ancienne est sûre.

Les versions corrigées identifiées sont les suivantes :

• RouterOS 7.25beta3
• RouterOS 7.24.2
• RouterOS 7.23.5
• RouterOS 7.23.4
• RouterOS 6.49.21

RouterOS 7.23.4 et 7.23.5 ont toutes deux été présentées comme des versions corrigées. Les opérateurs doivent installer la version corrigée actuellement prise en charge pour leur branche et vérifier la version installée après le redémarrage ou la fin du processus de mise à jour.

L’accès administrateur expose l’ensemble du périmètre réseau

Un routeur compromis offre aux attaquants bien plus qu’un simple point d’appui sur un équipement. Un accès administrateur peut leur permettre de modifier le routage, d’affaiblir les règles du pare-feu, d’intercepter le trafic, de rediriger les connexions, d’établir des tunnels ou de configurer l’appareil comme proxy.

Les attaquants peuvent également ajouter des utilisateurs et des clés SSH, créer des tâches planifiées, déployer des scripts ou modifier les paramètres des services afin de conserver leur accès. Les fonctions de capture de paquets peuvent exposer le trafic et les identifiants qui transitent par le routeur, tandis qu’une modification du routage ou de la configuration liée au DNS peut rediriger les utilisateurs vers une infrastructure contrôlée par les attaquants.

Les installations MikroTik anciennes sont particulièrement exposées lorsqu’elles font l’objet d’une maintenance limitée. Les routeurs peuvent rester opérationnels pendant des années, ce qui fait des appareils oubliés et des déploiements non gérés dans les agences des cibles probables pour une mise à jour tardive.

Les appareils qui utilisent la configuration de pare-feu par défaut de MikroTik et n’exposent pas SSH sur Internet sont considérés comme probablement protégés contre ce vecteur d’accès distant particulier. Cela ne signifie pas qu’ils sont à jour ou qu’ils n’ont pas été compromis par d’autres moyens. Leur exposition pour l’administration et leurs versions logicielles doivent tout de même être vérifiées.

Les journaux et l’historique de configuration peuvent révéler une compromission

Une tentative MikroTrick échouée peut créer une entrée dans les journaux d’authentification contenant le nom d’utilisateur -2. Il ne s’agit pas d’un nom de compte normal : toute apparition dans les enregistrements RouterOS doit faire l’objet d’une investigation.

Une activité réussie peut être enregistrée dans /system history sous une forme semblable à celle-ci :

ssh:-2@<IP>

Les équipes d’intervention doivent mettre cet événement en corrélation avec les opérations administratives qui ont suivi. Parmi les modifications suspectes peuvent figurer :

• Création ou modification d’utilisateurs et de clés SSH
• Ajout ou modification de scripts et d’entrées du planificateur
• Modification des services activés
• Modification des règles de pare-feu ou de routage
• Activation d’un proxy ou d’un tunnel
• Modification de la configuration de capture de paquets
• Toute autre modification inexpliquée de la configuration

Le compte non autorisé ops constitue un indicateur confirmé de cette campagne. Sa présence doit déclencher immédiatement une investigation de réponse à incident.

L’absence d’une entrée -2 ne prouve pas qu’un routeur est sain. Les journaux peuvent avoir subi une rotation, avoir été écrasés ou avoir été effacés par un attaquant. Un événement historique affichant ssh:-2@<IP> et suivi d’une modification de configuration doit être considéré comme une compromission avérée, sauf s’il provient d’un test de sécurité autorisé.

Les enquêteurs doivent examiner l’état actuel de l’appareil ainsi que les enregistrements historiques. Les utilisateurs, les clés, les scripts, les planificateurs, les services, les règles de pare-feu, les proxys, les tunnels, les paramètres de capture de paquets et les règles d’accès d’administration doivent tous être inspectés.

Infrastructure de la campagne et indicateurs liés aux fichiers

La plupart des attaques observées provenaient de 82.192.72[.]4, une adresse hébergée par Leaseweb. Une seconde adresse, 103.102.31[.]18, a également été associée à la campagne.

L’adresse principale hébergeait quatre fichiers :

• Une version MIPS du binaire officiel précompilé BusyBox 1.16.1, compilée en 2010
• ftpsrv.py
• launch.sh
• serve.py

Trois des fichiers fournis n’étaient détectés par aucun moteur sur VirusTotal au moment de leur analyse. Un faible niveau de détection, voire l’absence de détection, ne doit pas être interprété comme la preuve qu’ils sont inoffensifs dans ce contexte opérationnel.

Les équipes de défense peuvent rechercher ces fichiers et les éléments de télémétrie collectés à l’aide des empreintes SHA-256 suivantes :

Fichier	SHA-256
ftpsrv.py	6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d
launch.sh	972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd
serve.py	6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e

L’empreinte du binaire BusyBox n’a pas été communiquée. Les données réseau historiques doivent être analysées afin de rechercher des connexions entrantes ou sortantes impliquant les deux adresses IP signalées.

Appliquer les correctifs avant d’enquêter sur les routeurs exposés

Les administrateurs doivent immédiatement mettre à jour leurs appareils vers la version corrigée de RouterOS appropriée et vérifier que la mise à niveau s’est déroulée correctement. SSH doit être désactivé ou restreint partout où il est accessible depuis Internet ou depuis un autre réseau non fiable.

L’accès d’administration doit plutôt être limité à des chemins d’administration de confiance, à des adresses sources strictement contrôlées ou à des mécanismes d’accès internes protégés. Le filtrage des deux adresses de la campagne est utile, mais ne saurait remplacer l’application des correctifs, car les attaquants peuvent recourir à de nouvelles infrastructures.

Tout appareil RouterOS dont le service SSH est accessible depuis Internet doit être considéré comme potentiellement compromis tant que ses journaux, son historique de configuration, ses utilisateurs, ses clés et ses paramètres actifs n’ont pas été examinés.

Si une activité administrateur non autorisée est découverte, les équipes d’intervention doivent isoler le routeur, préserver les journaux et les éléments de preuve liés à la configuration, renouveler les mots de passe et les clés SSH, supprimer les mécanismes de persistance et vérifier les règles de routage et de pare-feu. La reconstruction ou la restauration de l’appareil au moyen d’un processus de confiance peut s’avérer nécessaire.

Aucun proof of concept public fonctionnel n’avait été signalé au 5 septembre. Raiu estimait qu’un tel code pourrait apparaître sur GitHub sous un ou deux jours, alors que l’exploitation active était déjà en cours sans celui-ci. Attendre la publication du code d’exploitation n’offrirait donc aux défenseurs aucune marge de sécurité significative.