Le groupe Interlock Ransomware cible les infrastructures réseau Cisco

En juin 2026, le groupe cybercriminel Interlock Ransomware a ajouté à son arsenal l’exploitation d’une vulnérabilité zero-day dans Cisco Firepower Management Center (FMC), la plateforme de gestion centralisée des pare-feux Cisco Firepower. La faille, identifiée comme CVE-2026-20358, permet une exécution de code arbitraire sans authentification via l’interface web d’administration de FMC.

Interlock Ransomware est un groupe apparu fin 2024, initialement connu pour ses attaques ciblées contre les établissements de santé et les collectivités territoriales. En 2026, le groupe a étendu ses cibles aux entreprises industrielles et aux fournisseurs de services gérés (MSPs), capitalisant sur leur accès aux réseaux de nombreux clients simultanément.

L’exploitation de CVE-2026-20358 est particulièrement dangereuse : un pare-feu FMC compromis donne accès non seulement au réseau de l’organisation, mais aussi à la configuration complète de la sécurité, permettant à l’attaquant de désactiver des règles de détection, ouvrir des accès distants et se mouvoir latéralement en contournant les contrôles de sécurité existants.

Analyse technique de CVE-2026-20358

La CVE-2026-20358 est une injection de commande dans le composant de traitement des requêtes HTTPS de l’interface web Cisco FMC (versions 7.2.x à 7.4.1). Un attaquant ayant accès réseau à l’interface d’administration (port 443 par défaut) peut envoyer une requête HTTP spécialement formée qui bypasse l’authentification et exécute des commandes arbitraires avec les privilèges du processus web (root dans la plupart des configurations).

Le vecteur d’attaque est le endpoint `/api/fmc_platform/v1/updates/` qui ne valide pas correctement les paramètres de version dans certaines configurations. L’exploitation réussie aboutit à un reverse shell vers l’infrastructure de commande et contrôle d’Interlock, utilisant des techniques de living-off-the-land (Bash, curl, Python) pour éviter la détection.

Cisco a publié un bulletin de sécurité (cisco-sa-fmc-rce-2026) avec les versions corrigées : FMC 7.4.2 et 7.6.0. Un workaround d’urgence existe : restreindre l’accès à l’interface web FMC aux seules IPs d’administration connues via une ACL réseau, réduisant drastiquement la surface d’attaque exposée.

Indicateurs de compromission Interlock

Les indicateurs de compromission publiés par Cisco Talos et les CERTs européens permettent de détecter une exploitation de CVE-2026-20358 et une infection Interlock. Dans les logs FMC, recherchez des requêtes vers `/api/fmc_platform/v1/updates/` avec des paramètres contenant des caractères spéciaux (`;`, `|`, `$(`, «  ` « ) depuis des IPs non reconnues.

Sur les systèmes compromis, Interlock dépose plusieurs fichiers caractéristiques : un agent de persistance nommé `cisco_update_helper` ou `fmc_health_monitor` dans `/usr/local/bin/`, et modifie `/etc/cron.d/` avec une tâche planifiée de beacon vers l’infrastructure C2. Les IPs C2 connues d’Interlock (à bloquer immédiatement) sont publiées sur le flux MISP de l’ANSSI et le feed threat intelligence de CISA.

La note de rançon Interlock est déposée sous le nom `!!READ_ME!!.txt` dans chaque répertoire chiffré. Le chiffrement utilise ChaCha20 pour les fichiers et RSA-2048 pour la clé de chiffrement, aucun déchiffreur public n’est disponible. La prévention est donc la seule option viable.

Remédiation immédiate et isolation

Si vous utilisez Cisco FMC 7.2.x à 7.4.1, la première action est l’isolation réseau de votre instance FMC : restreignez l’accès au port 443 aux seules IPs de vos administrateurs réseau via votre infrastructure réseau (switch, pare-feu upstream, ACL). Cette mesure bloque l’exploitation à distance de CVE-2026-20358 en attendant le patch.

La mise à jour vers FMC 7.4.2 ou 7.6.0 doit être prioritaire. Avant de mettre à jour, vérifiez les IoC listés ci-dessus pour vous assurer que votre FMC n’est pas déjà compromis. Mettre à jour un système compromis sans remédiation préalable ne supprime pas l’accès de l’attaquant.

Si vous suspectez une compromission active : isolez immédiatement la machine FMC du réseau (déconnexion physique ou VLAN dédié), préservez les logs et l’image disque pour analyse forensique, contactez votre CSIRT ou un prestataire de réponse sur incident, et notifiez l’ANSSI si vous êtes une entité NIS2. Ne rallumez pas une FMC potentiellement compromise sur votre réseau de production sans remédiation complète.

Leçons : sécuriser les interfaces d’administration réseau

CVE-2026-20358 dans Cisco FMC illustre un problème récurrent : les interfaces d’administration des équipements réseau et de sécurité sont exposées sur le réseau et constituent des cibles de grande valeur. Un FMC compromis donne plus d’accès qu’un serveur applicatif compromis, il contrôle la politique de sécurité de tout le réseau.

Bonnes pratiques universelles pour les interfaces d’administration réseau : (1) Jamais exposées sur Internet, uniquement accessibles depuis un réseau d’administration dédié ou via un jump host, (2) Authentification multi-facteur obligatoire même pour l’accès interne, (3) Versions à jour avec un processus de patch management dédié pour les équipements de sécurité (les patch de sécurité réseau doivent être traités aussi rapidement que les patches serveur), (4) Alertes sur les connexions depuis des IPs non reconnues.

Le principe de ‘security devices are not immune to security vulnerabilities’ est souvent négligé dans les organisations qui font confiance à leurs équipements de sécurité sans les maintenir. En 2026, 23 % des incidents analysés par Mandiant impliquaient une compromission d’un équipement de sécurité (firewall, VPN, endpoint protection). Ces équipements sont des cibles prioritaires précisément parce qu’ils ont accès à tout.

Le modèle d’extorsion Interlock et négociation

Le modèle économique d’Interlock combine chiffrement et exfiltration de données (double extorsion). Avant de chiffrer, le groupe exfiltre des données sensibles pendant 2 à 4 semaines de présence discrète sur le réseau. La rançon initiale se situe entre 500 000 $ et 3 millions $ selon la taille de l’organisation et les données exfiltrées.

Les organisations victimes font face à deux pressions simultanées : la restauration des systèmes chiffrés et la menace de publication des données volées sur le site de leak d’Interlock (hébergé sur Tor). Payer la rançon ne garantit ni le déchiffrement complet, ni la suppression des données exfiltrées, 40 % des victimes qui paient signalent des problèmes avec les déchiffreurs ou une double extorsion ultérieure.

La meilleure protection reste la prévention : sauvegardes immuables (snapshots S3 Glacier avec Object Lock, ou bandes hors ligne), segmentation réseau qui limite le mouvement latéral, et detection & response qui détecte l’exfiltration avant le chiffrement. Aucune de ces mesures ne remplace l’autre, ensemble, elles réduisent l’impact d’un ransomware de catastrophique à gérable.

#!/bin/bash
# Vérification exposition CVE-2026-20358 (Cisco FMC)
# Usage : ./check-fmc.sh <IP_ou_hostname_FMC>

FMC_HOST="${1:-fmc.votreentreprise.local}"
FMC_URL="https://$FMC_HOST"

echo "=== Audit Cisco FMC — CVE-2026-20358 ==="
echo "Cible : $FMC_URL"

# 1. Vérifier la version FMC via API (si accès avec credentials)
echo -e "
[1] Version FMC (nécessite credentials) :"
echo "curl -sk '$FMC_URL/api/fmc_platform/v1/info/serverversion'"
echo "Versions vulnérables : 7.2.x à 7.4.1"
echo "Versions corrigées : 7.4.2+, 7.6.0+"

# 2. Tester l'accès sans auth au endpoint vulnérable
echo -e "
[2] Test accès non authentifié au endpoint vulnérable :"
HTTP_CODE=$(curl -sk -o /dev/null -w "%{http_code}"     "$FMC_URL/api/fmc_platform/v1/updates/"     --max-time 5 2>/dev/null)
if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "400" ]; then
    echo "[POTENTIELLEMENT VULNÉRABLE] Endpoint accessible (HTTP $HTTP_CODE)"
    echo "Appliquez le workaround ACL immédiatement !"
elif [ "$HTTP_CODE" = "401" ] || [ "$HTTP_CODE" = "403" ]; then
    echo "[OK] Endpoint nécessite authentification (HTTP $HTTP_CODE)"
else
    echo "[INFO] HTTP $HTTP_CODE — FMC peut être isolé ou non joignable"
fi

# 3. Vérifier les IoC Interlock dans les logs (si accès au serveur)
echo -e "
[3] Recherche IoC Interlock (sur le serveur FMC) :"
echo "Commandes à exécuter sur le FMC :"
echo "  find /usr/local/bin/ -name 'cisco_update_helper' -o -name 'fmc_health_monitor'"
echo "  ls /etc/cron.d/ | grep -v '^[a-z]'"
echo "  netstat -tunp | grep -E '(185.176|194.165|45.155)'"

echo -e "
IoC réseau Interlock 2026 à bloquer :"
echo "  185.176.43.0/24, 194.165.16.0/24, 45.155.204.0/24"

Chasse rétroactive : présumer la compromission avant l’application du correctif

Patcher une faille zero-day déjà exploitée ne suffit pas : le correctif ferme la porte, il n’expulse pas l’intrus déjà entré. La posture correcte après une exploitation active connue est l’hypothèse de compromission, on présume que l’attaquant a pu agir et on chasse les traces de son passage. Cela implique d’analyser les journaux antérieurs au patch à la recherche de connexions d’administration anormales, de créations de comptes ou de modifications de configuration hors fenêtre de changement.

Cette chasse rétroactive est ce qui distingue une réponse mature d’un simple colmatage. Elle s’appuie sur une priorisation rigoureuse, on traque d’abord ce qui est exposé et critique, selon la même logique que notre guide de priorisation des vulnérabilités. Trouver des indicateurs après coup change radicalement la réponse : on bascule d’un correctif de routine à une gestion d’incident complète.

# Présomption de compromission : chasser AVANT la date du correctif
PATCH="2026-06-20"
# 1) Connexions admin depuis des IP hors plage de confiance, avant le patch
awk -v d="$PATCH" '$1 < d && /admin login/' fmc-audit.log 
  | grep -vE "10.|192.168."

# 2) Comptes créés ou élevés dans la fenêtre suspecte
grep -E "user (created|privilege)" fmc-audit.log | awk -v d="$PATCH" '$1 <= d'
# -> tout résultat = déclenchement d'une procédure d'incident, pas un simple patch

Restaurer une configuration FMC saine sans réimporter la porte dérobée

Quand un équipement de gestion de pare-feu est compromis, la tentation de restaurer la dernière sauvegarde de configuration est piégeuse : si la compromission précède la sauvegarde, on réimporte la porte dérobée. La restauration doit donc partir d’un point connu comme sain, antérieur à la première trace d’intrusion identifiée lors de la chasse, puis rejouer les changements légitimes manuellement après vérification.

Cette reconstruction prudente s’accompagne d’une rotation complète des secrets : identifiants d’administration, clés d’API, certificats, qui ont tous pu être exfiltrés. Une sauvegarde de configuration n’est fiable que si l’on connaît précisément sa date par rapport à l’incident, d’où l’importance, là encore, de la journalisation. Les leçons rejoignent celles tirées du zero-day Cisco SD-WAN, où la chronologie de l’attaque conditionne toute la remédiation.

# Restaurer un point SAIN, pas le dernier en date (qui peut être infecté)
# 1) Identifier la dernière sauvegarde antérieure à la 1re trace d'intrusion
INTRUSION="2026-06-15"
ls -1 backups/fmc-config-*.tar | awk -F'config-' -v d="$INTRUSION" 
  '{ if (substr($2,1,10) < d) last=$0 } END { print "Point sain:", last }'

# 2) Après restauration : rotation OBLIGATOIRE de tous les secrets exposés
#    (mots de passe admin, clés API, certificats) -> ne JAMAIS les conserver

Cartographier l’attaque sur MITRE ATT&CK pour outiller la détection

Décrire une attaque par ransomware en langage courant ne permet pas de la détecter automatiquement. Traduire les techniques observées du groupe Interlock dans le référentiel MITRE ATT&CK transforme un récit en règles de détection actionnables. Chaque technique, accès initial via la faille, persistance par compte créé, exfiltration avant chiffrement, correspond à un identifiant que l’on peut câbler dans un EDR ou un NDR pour alerter au prochain incident similaire.

Cette cartographie a un double bénéfice : elle structure la réponse présente et arme la prévention future. En reliant les indicateurs de compromission à des techniques connues, on couvre aussi les variantes, un autre groupe réutilisant le même mode opératoire sera détecté. C’est l’approche systématique qu’un audit de sécurité rigoureux cherche à institutionnaliser : passer des symptômes ponctuels aux comportements génériques.

# Règles de détection dérivées des TTP Interlock (mappées MITRE ATT&CK)
detections:
  - technique: T1190   # Exploit Public-Facing Application (la faille FMC)
    signal: "requête anormale sur l'interface de gestion FMC"
  - technique: T1136   # Create Account (persistance)
    signal: "nouveau compte admin hors processus RH"
  - technique: T1567   # Exfiltration Over Web Service (avant chiffrement)
    signal: "volume sortant inhabituel vers domaine non catégorisé"
# -> câblées dans l'EDR/NDR, elles attrapent aussi les variantes du mode opératoire

Intégrer les équipements réseau au programme de gestion des vulnérabilités

L’angle mort que cette attaque exploite est organisationnel autant que technique : les équipements de sécurité réseau, pare-feu, gestionnaires de politiques, sont souvent exclus des cycles de patch disciplinés réservés aux serveurs. Or ils sont au cœur du réseau et constituent une cible de choix. La maturité consiste à les intégrer dans le même programme de gestion des vulnérabilités, avec un inventaire de firmware à jour et un abonnement aux flux d’alertes officiels comme le catalogue des failles activement exploitées.

Cette gouvernance transforme la réaction paniquée post-divulgation en processus maîtrisé : quand une CVE touchant un équipement du parc paraît, on sait en minutes ce qui est concerné et on applique un délai de correction (SLA) fonction de l’exposition. Cette concentration d’attaques sur les infrastructures critiques est un signal de fond, comme l’illustre notre dossier sur les failles critiques de l’été 2026.

# Croiser l'inventaire firmware réseau avec le catalogue KEV de la CISA
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json 
  | jq -r '.vulnerabilities[] | select(.vendorProject=="Cisco")
           | "(.cveID)  (.product)  echeance:(.dueDate)"' 
  | grep -Ff <(cut -d, -f2 inventaire-reseau.csv)
# -> toute correspondance = correctif prioritaire avec SLA selon l'exposition

Sources et références

WP Admin Lab
· Chef de la rédaction

La rédaction de WP Admin Lab réunit des praticiens WordPress, sécurité et développement web. Nous publions des guides testés en conditions réelles, vérifiés en production et régulièrement mis à jour, sans jargon inutile. Chaque procédure est relue avant publication.

mastodon