Un simple bug ? Non. Une attaque C2.
Je vais être direct : au départ, rien ne ressemblait à une cyberattaque.
Un client rencontre un problème sur une machine. Un déploiement échoue. Un fichier étrange apparaît. Une clé API consomme plus que d’habitude.
Dit comme ça, vous avez l’impression d’un incident technique classique.
Et franchement, quand vous travaillez dans l’IT, l’IoT, l’OT ou le développement logiciel, ce genre de situation arrive tout le temps.
- Un build qui casse.
- Une dépendance qui se comporte mal.
- Un fichier temporaire qui traîne.
- Une configuration qui a changé.
- Un script qui tourne trop longtemps.
Avant de lire la suite, voici le retour d’expérience complet en vidéo. Si vous préférez le format écrit, l’article détaille chaque étape ci-dessous.
La tentation est simple : vous supprimez le fichier, vous relancez le déploiement, vous forcez un redémarrage, et vous passez au problème suivant.
Sauf que cette fois, ce n’était pas un simple bug.
En creusant, nous avons découvert que la machine du client était compromise. Pas par une erreur anodine. Pas par un script isolé. Mais par une attaque C2, avec une logique de persistance.
Et c’est précisément ce qui rend ce type d’incident dangereux : il ne commence pas toujours par une alerte spectaculaire.
Parfois, il commence par un détail.
Pourquoi ce retour d’expérience doit vous intéresser
Les cyberattaques ne touchent plus seulement les grands groupes, les banques ou les opérateurs critiques.
Check Point Research indique qu’au deuxième trimestre 2025,
-
le nombre moyen d’attaques hebdomadaires par organisation a atteint 1 984, soit une hausse de 21 % par rapport à la même période en 2024.
Ce chiffre doit parler à tous ceux qui exploitent une infrastructure exposée : éditeurs SaaS, industriels, intégrateurs, mainteneurs, hébergeurs, exploitants IoT, fournisseurs de services cloud, équipes DevOps ou responsables cybersécurité.
Aujourd’hui, une machine client peut être connectée à une API, à un portail web, à un système de supervision, à un outil de déploiement, à une base de données, à une gateway IoT, à un cloud industriel ou à un service d’intelligence artificielle.
Plus l’environnement est connecté, plus il devient puissant.
Mais plus il devient aussi exposé.
Et dans ce contexte, les signaux faibles ne doivent jamais être traités à la légère.
C2 : ce que veut vraiment faire l’attaquant
C2 signifie Command and Control, c’est-à-dire commande et contrôle.
MITRE ATT&CK définit cette tactique comme l’ensemble des techniques utilisées par un adversaire pour communiquer avec des systèmes compromis dans un réseau victime afin de les contrôler.
En clair : l’attaquant ne cherche pas seulement à entrer.
- Il veut garder la main.
- Il veut observer.
- Il veut envoyer des commandes.
- Il veut maintenir un accès.
- Il veut revenir plus tard.
- Il veut parfois se fondre dans le trafic normal pour ne pas se faire repérer.
C’est là que beaucoup d’entreprises sous-estiment le problème.
Une intrusion simple, c’est grave.
Mais une attaque C2, c’est autre chose.
C’est comme si quelqu’un entrait dans vos locaux, installait une caméra discrète, cachait une clé de secours dans le jardin, puis attendait le bon moment pour revenir.
Vous pouvez changer la serrure principale.
Mais tant que la clé cachée existe, vous n’avez pas vraiment repris le contrôle.
Premier signal : le déploiement qui échoue
Tout commence avec un déploiement.
Un développeur lance une mise en production sur l’environnement du client. Une opération normale. Répétée. Presque banale.
Et là, ça bloque.
Un fichier étrange apparaît. Un type de fichier non reconnu. Un élément qui n’a rien à faire là.
À ce moment-là, personne ne peut affirmer immédiatement : “c’est une attaque”.
Et c’est justement le piège.
Parce qu’un fichier étrange peut avoir mille explications. Une mauvaise manipulation. Une dépendance. Un artefact généré par un outil. Une erreur dans le pipeline. Un problème de permission.
Mais le bon réflexe, dans cette situation, n’est pas seulement de se demander :
“Comment je débloque le déploiement ?”
La vraie question, c’est :
“Pourquoi ce fichier est là ?”
Cette question change tout.
Elle vous fait sortir du mode “correction rapide”.
Elle vous fait entrer dans le mode “investigation”.
Et dans notre cas, c’est ce réflexe qui a permis de ne pas passer à côté du problème.
Deuxième signal : une consommation API anormale
Peu après, un autre signal apparaît.
Une API commence à consommer beaucoup plus que d’habitude.
Là encore, ce n’est pas automatiquement une preuve de cyberattaque.
Une consommation anormale peut venir d’une boucle applicative, d’un script mal configuré, d’un worker qui relance trop de tâches, d’une mauvaise gestion des retries, d’un usage imprévu ou d’un simple bug.
Mais après le déploiement bloqué et le fichier suspect, cette consommation anormale ne pouvait plus être ignorée.
C’est souvent comme ça qu’un incident cyber se révèle.
Pas par un seul élément évident.
Mais par une accumulation de signaux faibles.
- Un fichier étrange seul peut être un accident.
- Une API qui consomme trop seule peut être un bug.
- Un déploiement qui échoue seul peut être un problème DevOps.
Mais quand ces éléments apparaissent ensemble, dans une fenêtre de temps rapprochée, sur une machine exposée, il faut changer de posture.
Vous ne traitez plus un simple incident technique.
Vous devez envisager l’hypothèse d’une compromission.
Ce que l’analyse a révélé
En creusant, nous avons découvert des éléments beaucoup plus inquiétants.
Des scripts suspects.
Des comportements anormaux.
Des traces qui ne correspondaient pas à l’activité attendue.
Puis plusieurs mécanismes de persistance.
Le point important, ici, n’est pas de détailler chaque élément technique. Ce serait inutile, et parfois dangereux.
Le vrai sujet, c’est la logique de l’attaque.
L’attaquant ne s’était pas contenté d’entrer sur la machine du client.
Il avait prévu de rester.
C’est exactement ce qui distingue un incident isolé d’une compromission sérieuse.
- Quand vous trouvez une backdoor, vous comprenez que l’attaquant a laissé une porte de retour.
- Quand vous en trouvez plusieurs, vous comprenez que le problème est plus profond.
- Et quand vous découvrez des mécanismes de surveillance, vous comprenez que l’attaquant n’était pas simplement de passage.
Il observait.
Backdoor : la porte cachée que vous ne voyez pas
Une backdoor, ou porte dérobée, est un accès caché qui permet à un attaquant de revenir dans un système compromis.
L’image la plus simple est celle de la clé cachée.
Quelqu’un entre chez vous. Vous changez la serrure. Vous renforcez la porte. Vous pensez être en sécurité.
Mais cette personne a caché une clé dans le jardin avant de partir.
Tant que cette clé existe, elle peut revenir.
Dans un système informatique, c’est la même logique.
- Vous pouvez supprimer le fichier suspect.
- Vous pouvez changer un mot de passe.
- Vous pouvez redémarrer les services.
- Vous pouvez croire que tout est réglé.
Mais si une autre porte dérobée existe encore, l’attaquant conserve une possibilité de retour.
C’est pour cela qu’il faut être très prudent avec les phrases du type :
“C’est bon, on a nettoyé.”
Dans une attaque C2 avec persistance, nettoyer ne suffit pas toujours.
Parfois, la seule approche sérieuse consiste à reconstruire proprement.
Le détail le plus inquiétant : l’attaquant surveillait
Le plus inquiétant dans ce cas n’était pas seulement la présence de backdoors.
C’était la surveillance.
L’attaquant avait mis en place des mécanismes pour savoir quand l’équipe se connectait à la machine, et même quand certains événements système se produisaient.
À ce moment-là, vous comprenez que vous n’êtes pas face à un simple script automatique.
Vous êtes face à une logique de contrôle.
- L’attaquant observe.
- Il attend.
- Il adapte son comportement.
- Il cherche à rester discret.
C’est exactement l’esprit d’une attaque C2 : garder un lien avec la machine compromise et continuer à piloter l’activité malveillante sans se faire remarquer.
MITRE précise d’ailleurs que les adversaires cherchent souvent à imiter le trafic normal attendu pour éviter la détection.
Et c’est là que l’incident change de dimension.
Vous ne pouvez plus raisonner comme si vous aviez juste un fichier à supprimer.
Vous devez vous demander si vous pouvez encore faire confiance à la machine.
Dans ce cas précis, la réponse était non.
Pourquoi il ne fallait pas juste “nettoyer”
À ce stade, la tentation pouvait être forte.
- Supprimer les fichiers suspects.
- Changer quelques mots de passe.
- Relancer l’application.
- Dire au client que tout est revenu à la normale.
Mais ce serait une erreur.
Parce que ce que vous trouvez au début d’un incident n’est pas forcément toute l’attaque.
C’est peut-être seulement la partie visible de l’iceberg.
- Vous supprimez un script, mais un autre mécanisme peut exister.
- Vous changez une clé, mais une autre a peut-être été copiée.
- Vous relancez l’application, mais la machine reste compromise.
- Vous bloquez un accès, mais l’attaquant a peut-être prévu un autre chemin.
C’est là qu’il faut changer de logique.
Vous ne raisonnez plus en mode “correction rapide”.
Vous raisonnez en mode “reprise de contrôle”.
Et quand la confiance dans une machine est rompue, il faut parfois accepter une vérité désagréable :
machine compromise = reconstruction propre.
Ce n’est pas de la paranoïa.
C’est de l’hygiène de sécurité.
Préserver, isoler, reconstruire : la bonne séquence
La réponse à incident n’est jamais aussi simple dans la vraie vie que dans un schéma théorique.
Il y a la pression.
- Le client.
- La production.
- Les équipes.
- Les urgences.
- Les décisions à prendre sans connaître tout le périmètre.
Mais la logique doit rester claire : préserver, isoler, reconstruire.
Le NIST SP 800-61r3 rappelle que la réponse à incident doit aider les organisations à préparer, détecter, répondre et récupérer plus efficacement après un incident de cybersécurité.
Dans notre cas, cette logique s’est traduite en trois étapes.
Étape 1 : préserver les preuves
-
La première étape a consisté à préserver l’état de la machine compromise.
Un snapshot a été réalisé pour conserver une copie complète du serveur au moment de la découverte.
Pourquoi ?
Parce que si vous nettoyez trop vite, vous risquez d’effacer les preuves.
Et ces preuves peuvent être essentielles pour comprendre :
- comment l’attaquant est entré ;
- quels accès ont été utilisés ;
- quels fichiers ont été modifiés ;
- quels secrets ont pu être exposés ;
- quels mécanismes de persistance ont été installés ;
- quelle surface doit être corrigée avant remise en production.
Dans un incident cyber, vouloir aller trop vite peut vous faire perdre la vérité.
Et sans vérité, vous reconstruisez sur des suppositions.
Étape 2 : isoler l’environnement client
Ensuite, il faut isoler.
- Limiter les communications.
- Couper les accès inutiles.
- Réduire la surface exposée.
- Empêcher la machine compromise de continuer à communiquer librement.
CISA recommande notamment d’isoler les systèmes compromis de manière coordonnée, en utilisant si nécessaire des canaux de communication hors bande pour éviter d’alerter les attaquants.Cette recommandation est importante.
Parce que dans une attaque C2, le canal de communication est central.
Tant que l’attaquant peut communiquer avec la machine compromise, il peut potentiellement observer, envoyer des commandes, déclencher des actions ou adapter sa stratégie
Isoler ne veut pas dire paniquer.
Isoler veut dire reprendre l’initiative.
Étape 3 : reconstruire proprement
Enfin, il faut reconstruire.
Dans ce cas, la machine client ne pouvait plus être considérée comme fiable.
La bonne approche n’était donc pas de supprimer deux fichiers suspects et de relancer les services comme si de rien n’était.
Il fallait repartir sur une base propre.
- Nouvelle machine.
- Nouveaux accès.
- Nouvelles clés.
- Nouvelle configuration.
- Correction des failles identifiées.
- Réduction de la surface d’exposition.
- Vérification avant remise en production.
Et surtout : ne pas reconstruire la même machine avec la même faiblesse.
Sinon, vous ne faites que déplacer le problème.
Vous reconstruisez proprement en apparence, mais vous laissez la même porte ouverte.
Ce que les industriels doivent retenir
Ce retour d’expérience ne concerne pas seulement les éditeurs SaaS ou les équipes DevOps.
Il concerne aussi les environnements industriels.
Pourquoi ?
Parce que les architectures industrielles modernes sont de plus en plus connectées.
- Vous avez des gateways IoT.
- Des API.
- Des accès distants.
- Des serveurs applicatifs.
- Des outils de supervision.
- Des plateformes cloud.
- Des connecteurs vers des applications métiers.
- Des systèmes de maintenance.
- Des scripts d’automatisation.
- Parfois même des briques d’IA.
Cette interconnexion apporte de la valeur.
Mais elle augmente aussi la surface d’attaque.
Dans le monde OT, nous avons longtemps raisonné avec une frontière assez claire : d’un côté l’IT, de l’autre l’OT.
Cette frontière existe encore, mais elle devient plus poreuse.
Et les attaquants le savent.
Ils ne cherchent pas toujours à attaquer directement un automate ou un équipement industriel.
Ils peuvent passer par une machine intermédiaire, un serveur exposé, une API mal protégée, un compte technique, une clé oubliée ou un outil de déploiement.
C’est pour cela que la cybersécurité industrielle ne peut plus se limiter à protéger le réseau OT historique.
Il faut sécuriser tout l’écosystème connecté autour.
Les bons réflexes à adopter après ce type d’incident
Le premier réflexe, c’est de prendre les signaux faibles au sérieux.
Un fichier étrange n’est pas forcément une attaque.
Mais il mérite une question.
Une consommation API anormale n’est pas forcément une compromission.
Mais elle mérite une vérification.
Un déploiement qui échoue n’est pas forcément un incident cyber.
Mais s’il s’accompagne d’autres anomalies, il mérite une investigation.
Le deuxième réflexe, c’est de protéger vos secrets.
Une clé API, un token Git, un identifiant cloud, un accès SSH ou un secret d’application ne sont pas de simples détails techniques.
Ce sont des actifs critiques.
Ils doivent être stockés correctement, limités en privilèges, renouvelés si nécessaire et retirés immédiatement en cas de suspicion d’exposition.
Le troisième réflexe, c’est de tester vos expositions.
Ce qu’un attaquant voit depuis Internet doit être connu.
- Quels services répondent ?
- Quels ports sont ouverts ?
- Quelles erreurs exposent trop d’informations ?
- Quels endpoints sont accessibles ?
- Quels accès sont trop permissifs ?
- Quels secrets sont mal protégés ?
Enfin, le quatrième réflexe, c’est de documenter votre réponse à incident.
Le jour où l’incident arrive, vous n’avez pas le luxe d’improviser.
Vous devez savoir qui décide, qui isole, qui communique, qui préserve les preuves, qui reconstruit, qui valide la remise en production.
Conclusion : le vrai danger, ce sont les signaux faibles ignorés
Ce que je retiens de cette histoire, c’est qu’un incident cyber ne commence pas toujours par une catastrophe visible.
Parfois, il commence par un détail.
- Un déploiement qui échoue.
- Un fichier bizarre.
- Une consommation API anormale.
- Une machine qui ne se comporte pas comme prévu.
Dans ce cas précis, ces signaux faibles ont permis de découvrir qu’une machine client était compromise par une attaque C2, avec des mécanismes de persistance et une logique de surveillance.
La vraie leçon est là : quand une machine est compromise, il ne faut pas seulement chercher à la nettoyer.
Il faut se demander si vous pouvez encore lui faire confiance.
Et très souvent, la réponse est non.
FAQ : attaque C2, backdoor et machine compromise
Une attaque C2, ou Command and Control, désigne une situation dans laquelle un attaquant maintient un canal de communication avec un système compromis. Ce canal lui permet d’envoyer des commandes, d’observer l’environnement et de garder le contrôle de la machine.
Parce que l’attaquant ne cherche pas seulement à entrer. Il cherche à rester. La persistance est le cœur du problème. Tant qu’un mécanisme de retour existe, l’environnement n’est pas réellement maîtrisé.
En pratique, la migration d’un parc se déroule en deux étapes :
- (1) Intégrer l’eUICC sur toutes les nouvelles unités produites dès maintenant.
- (2) Remplacer les anciens équipements progressivement lors des cycles de renouvellement naturel, plutôt que de manière massive.
Cette approche graduelle permet de limiter l’investissement initial tout en alignant progressivement le parc sur la nouvelle architecture.
Le coût du remplacement doit être mis en balance avec le risque d’obsolescence du réseau et les coûts opérationnels futurs d’un parc sans eUICC.
Une backdoor est une porte dérobée. C’est un accès caché laissé par un attaquant pour revenir plus tard dans un système compromis, même après une correction apparente.
Tout dépend du niveau de compromission. Mais en présence de plusieurs backdoors, de mécanismes de surveillance ou d’une logique C2, la reconstruction propre est souvent l’approche la plus sûre. Une machine compromise ne doit pas être considérée comme fiable par défaut.
Un snapshot permet de conserver l’état de la machine au moment de la découverte. Il aide à analyser l’incident, comprendre les mécanismes de compromission et préserver des preuves qui pourraient disparaître lors d’un nettoyage trop rapide.
Les signaux faibles peuvent inclure un fichier étrange, un déploiement qui échoue sans raison claire, une consommation API anormale, des connexions inhabituelles, des scripts inconnus, des comptes suspects ou des communications sortantes difficiles à expliquer.
Oui. Les environnements industriels modernes sont de plus en plus connectés à des API, des plateformes cloud, des gateways IoT, des outils de supervision et des accès distants. Cette interconnexion augmente la surface d’attaque.
Il faut éviter les actions impulsives. La bonne approche consiste à préserver les preuves, isoler l’environnement, analyser le périmètre, renouveler les accès et reconstruire proprement si la machine n’est plus fiable.
Sources
- Check Point Research — Global Cyber Attacks Surge 21% in Q2 2025.
- MITRE ATT&CK — Command and Control, TA0011.
- NIST SP 800-61r3 — Incident Response Recommendations and Considerations.
- CISA — StopRansomware Guide, recommandations d’isolement des systèmes compromis.
L’article Attaque C2 : le bug qui cachait une machine client compromise est apparu en premier sur IoT Industriel Blog.