🧨 Introduction — « Sauvegardez dans le cloud, qu’ils disaient… »
C’était censé être pratique, simple, moderne. SonicWall proposait un service de sauvegarde cloud de configuration pour ses firewalls — l’équivalent numérique d’un coffre-fort hermétique, disait-on.
Sauf que, mercredi 9 octobre 2025, la firme a reconnu qu’un acteur non autorisé s’était introduit dans ce fameux coffre-fort… et avait gentiment fait une copie de toutes les sauvegardes clients. Oui, toutes. Pas 5 %, pas 10 %. Tous ceux qui utilisaient la fonction cloud backup.
En résumé : le fournisseur de sécurité réseau a été victime d’une brèche… dans sa propre infrastructure censée sécuriser vos firewalls. Ironie : niveau “sécurité dans le cloud”, on frôle la satire cyberpunk.
l’origine, SonicWall indiquait que l’impact ne concernait que < 5 % des clients 🤣🤣, mais dans une mise à jour plus récente ils ont reconnu que tous les clients utilisant le service de sauvegarde cloud sont concernés. SecurityWeek
🔐 Le casse du siècle… version fichiers de conf’
Les fichiers volés contiennent :
- Des identifiants chiffrés,
- Des configurations réseau complètes (règles de pare-feu, IP internes, topologies),
- Des paramètres VPN, parfois même les clés d’authentification.
SonicWall assure que « le chiffrement reste intact ». C’est bien.
Mais on sait tous que dans la vraie vie, une fois qu’un acteur malveillant met la main sur ces fichiers, il a tout le plan du château : les pont-levis, les douves, les portes dérobées, les clés sous le paillasson.
Et même si les credentials sont chiffrés, leur structure, leur format ou leur contexte peuvent déjà aider à monter des attaques ciblées.
🕵️♂️ Un air de déjà-vu : OVERSTEP et les fantômes de l’été
Ce n’est pas la première fois que SonicWall voit rouge.
Souviens-toi : l’été dernier, le rootkit OVERSTEP s’invitait sur les appliances SMA 100.
Une backdoor discrète, planquée sous le kernel, capable de survivre à une réinstallation — l’équivalent cyber d’un cafard post-apocalyptique.
Les attaquants (UNC6148, selon Google Threat Intelligence) utilisaient des identifiants volés et exploitaient des failles non patchées pour conserver un accès persistant.
À l’époque, SonicWall avait juré que “tout est sous contrôle”.
Quelques mois plus tard, voilà que le cloud backup se fait siphonner comme un FTP anonyme de 1999.
Coïncidence ? Peut-être. Mais à ce stade, le karma a clairement un sens de l’humour.
🧩 Le vrai problème : la confiance aveugle dans le cloud
Le problème ici n’est pas seulement technique — il est systémique.
Les entreprises délèguent de plus en plus la gestion de leurs configurations à des services “managés” : cloud backup, zero-touch provisioning, monitoring as a service…
Mais chaque fois qu’on “externalise la sécurité”, on externalise aussi le risque.
Et quand le fournisseur de sécurité tombe, il tombe pour tout le monde à la fois.
Autrement dit : single point of failure as a service.
Ce n’est pas une faille sur un firewall isolé, c’est une compromission de masse par effet de levier.
Chaque fichier de config volé, c’est potentiellement :
- Des adresses IP internes exposées,
- Des politiques de filtrage connues,
- Des routes VPN exploitables,
- Des credentials récupérables par attaque offline.
Bref, une cartographie complète des réseaux clients servie sur un plateau d’argent.
⚙️ Le côté technique (et inquiétant)
SonicWall précise que :
“Les fichiers sont chiffrés et le chiffrement n’a pas été compromis.”
Soit.
Mais l’attaque s’est produite dans le cloud de SonicWall, c’est-à-dire à la source du stockage.
Autrement dit : l’attaquant a eu un accès légitime ou quasi-légitime à l’infrastructure (compte de service compromis ? clé API exposée ? faille sur un bucket ?).
Et là, deux scénarios se dessinent :
- Compromission interne — accès à la couche d’administration du cloud backup (IAM, token, script de maintenance).
- Compromission externe — un attaquant a escaladé depuis un composant exposé (ex : interface de backup API).
Dans les deux cas, le problème est grave, car il touche un système centralisé censé gérer des milliers d’environnements clients.
🧯 Et maintenant ?
SonicWall promet :
- Une notification à tous les clients concernés,
- Une revue complète des accès cloud,
- Et la rotation des clés de chiffrement.
Mais soyons honnêtes : si les attaquants ont déjà les configurations, la partie préventive est terminée.
On entre dans la phase “attente du prochain rebond”.
Car oui, ces fichiers valent de l’or sur les marchés underground — parfaits pour cibler des entreprises précises, identifier leurs règles NAT, et monter des attaques VPN ou exfiltration sur mesure.
🧠 Morale de l’histoire — le cloud, c’est pratique… pour tout le monde
Dans le monde réel, on chiffre, on segmente, on sauvegarde localement, on audite.
Dans le monde marketing, on clique sur “Backup to the Cloud” et on dort tranquille.
Jusqu’au jour où un attaquant se réveille avant toi, quelque part entre un bucket S3 et une clé API oubliée.
Alors oui, c’est plus pratique de tout confier au cloud.
Mais quand la boîte censée protéger ton réseau se fait braquer son coffre-fort de configs, il faut bien se poser la question :
👉 à qui tu confies vraiment ta sécurité ?
🧩 En résumé
- Fournisseur concerné : SonicWall
- Service touché : Cloud Backup (tous clients)
- Données exposées : fichiers de configuration (avec credentials chiffrés)
- Risque : attaques ciblées facilitées, exposition de topologies réseau
- Lien avec OVERSTEP ? : non prouvé, mais contexte inquiétant
- Moralité : le cloud, c’est comme les couteaux : pratique, mais ça coupe dans les deux sens.
