Bombe logique : le code dormant qui attend le bon moment pour saboter un système
Le pire moment pour découvrir un code malveillant, c’est rarement celui où il arrive sur la machine.
C’est parfois plus tard. Quand le logiciel a déjà été lancé plusieurs fois. Quand le script téléchargé “pour dépanner” a été oublié dans un dossier. Quand une extension a reçu une mise à jour douteuse. Quand un outil piraté fonctionne assez bien pour ne plus attirer l’attention. Quand une tâche automatique tourne en arrière-plan depuis des semaines.
Une bombe logique joue sur ce délai. Elle peut rester inactive dans un programme, un script, une application ou un système, puis s’exécuter seulement lorsqu’une condition prévue à l’avance se produit : une date, l’ouverture d’un fichier, la suppression d’un compte, une commande précise, une modification dans une base de données.
Ce n’est pas seulement un sujet d’entreprise. Un particulier peut aussi être exposé, notamment avec des logiciels modifiés, des cracks, des scripts copiés sans vérification, des extensions de navigateur ou des outils récupérés hors des sources officielles.
Une bombe logique, c’est quoi exactement ?
Selon la définition du NIST, une bombe logique est un morceau de code inséré volontairement dans un système logiciel pour déclencher une fonction malveillante lorsque certaines conditions sont réunies.
Quelqu’un place du code dans un système, mais ce code ne produit pas d’effet visible immédiatement. Il attend le scénario prévu par son auteur.
La condition peut être très simple. Une date précise, par exemple. Ou l’ouverture d’un fichier, la suppression d’un compte utilisateur, l’absence d’un fichier, une modification dans une base de données, le changement d’un droit d’accès.
L’action déclenchée peut varier, supprimer des fichiers, bloquer des connexions, modifier des données, arrêter un service, effacer des journaux, lancer un autre programme, provoquer des erreurs répétées.
C’est la logique cachée qui relie une condition à une action la partie la plus importante de ce type de procédé.
Un exemple simple : un programme téléchargé hors d’une source officielle contient une instruction qui vérifie la date. Pendant plusieurs semaines, il fonctionne normalement. Puis, à partir d’un jour précis, il commence à supprimer des fichiers, à désactiver une protection ou à lancer un autre composant malveillant.
Dans un environnement plus technique, le même principe peut se retrouver dans une application métier, un script d’administration, une tâche planifiée, une extension, une dépendance logicielle ou un outil interne utilisé depuis longtemps.
Pourquoi cette attaque peut passer inaperçue
Une bombe logique peut être difficile à repérer parce qu’elle ne produit pas toujours de comportement suspect au moment où elle est installée.
Un outil de sécurité peut détecter certains fichiers connus, certaines actions dangereuses ou certains comportements inhabituels. Mais si le code reste inactif pendant l’analyse, la détection devient moins évidente. Il faut alors comprendre ce que le programme pourrait faire plus tard, dans une situation qui n’est pas forcément reproduite pendant le contrôle.
Le problème est encore plus délicat lorsque le code est ajouté par une personne ou un compte qui avait déjà accès au système. Un administrateur, un développeur, un prestataire, une extension compromise ou un compte piraté peuvent modifier des fichiers sans déclencher immédiatement une alerte, surtout si les changements sont mal suivis.
Dans beaucoup d’environnements, il existe déjà des scripts anciens, des tâches automatisées, des comptes de service, des exceptions, des outils bricolés pour résoudre un problème urgent. Une ligne dangereuse peut se perdre dans cet ensemble. Elle peut ressembler à un vieux correctif, à une condition métier mal écrite, à une vérification technique ou à une erreur de développement.
Chercher une bombe logique demande plus qu’une simple recherche de fichier suspect. Il faut comprendre le contexte : qui a modifié quoi, quand, avec quels droits, pour quelle raison, et ce que cette modification peut produire dans certaines conditions.
A lire également : Comment savoir si je suis victime de piratage ?
Un exemple récent : l’affaire Davis Lu
L’affaire Davis Lu illustre bien le risque côté entreprise.
En 2025, ce développeur a été condamné aux États-Unis à quatre ans de prison pour avoir déployé du code malveillant sur le réseau de son ancien employeur. Selon le ministère américain de la Justice, il avait travaillé comme développeur pour l’entreprise concernée pendant plusieurs années. Après une réorganisation interne qui avait réduit ses responsabilités et ses accès, il a introduit du code destiné à perturber les systèmes de l’entreprise.
Le dossier judiciaire mentionne notamment des blocages de connexion et des plantages système. Ce cas est intéressant parce qu’il ne correspond pas à l’image classique d’une attaque venue de l’extérieur. Le point de départ est un environnement professionnel, avec une personne qui connaissait déjà les systèmes et leur fonctionnement.
Cet exemple montre surtout qu’un compte autorisé peut être utilisé pour préparer une action malveillante. C’est plus difficile à surveiller qu’un fichier douteux téléchargé depuis un site inconnu.
Un déclenchement coordonné : la Corée du Sud en 2013
Un autre exemple souvent cité est l’attaque qui a touché plusieurs banques et médias sud-coréens en mars 2013. Des machines ont été rendues inutilisables au même moment, avec effacement de disques et perturbation de certains services.
L’intérêt de cet exemple est le déclenchement coordonné. Plusieurs systèmes sont touchés à un moment précis. Pour les équipes concernées, la priorité devient immédiatement le rétablissement du service, l’identification des machines affectées et la limitation des dégâts. L’analyse détaillée du code vient après, quand l’incident est déjà visible.
Dans ce type de scénario, le choix du moment fait partie de l’attaque. Une activation simultanée peut amplifier les dégâts, créer de la confusion et compliquer la réponse.
Comment limiter le risque ?
Pour un particulier, le risque vient surtout des logiciels modifiés, des cracks, des scripts copiés sans vérification, des extensions douteuses ou des programmes téléchargés hors des sources officielles. Un outil peut fonctionner normalement tout en contenant une instruction prévue pour plus tard.
Les bons réflexes restent assez simples : éviter les logiciels piratés, télécharger depuis les sources officielles, maintenir ses applications à jour, utiliser une protection de sécurité correcte, ne pas exécuter de commande que l’on ne comprend pas et conserver des sauvegardes séparées du système principal.
Côté entreprise, la question se déplace vers les droits d’accès et le suivi des changements. Une bombe logique peut être ajoutée par un compte qui avait réellement le droit de modifier du code, un script ou une configuration. Les mesures les plus utiles sont donc assez concrètes : limiter les privilèges, relire les changements sensibles, surveiller les tâches automatisées, désactiver proprement les accès lors des départs, tester les sauvegardes et garder des journaux d’activité exploitables.
Ce n’est pas une défense parfaite. Mais cela réduit les situations où un morceau de code peut rester en place pendant des mois sans propriétaire clair, sans relecture et sans trace compréhensible.
Ce qu’il faut retenir
Une bombe logique repose sur une idée simple : une condition déclenche une action. Cette action peut être banale ou destructrice, immédiate ou différée, visible ou discrète au départ.
Ce type d’attaque rappelle surtout qu’un système peut contenir des risques déjà présents, installés dans un logiciel, une extension, un script ou une application que personne ne vérifie vraiment.
A propos de l'auteur : Lisa
Fondatrice de VPN Mon Ami
Avec plus de 12 ans d'expérience dans le domaine des VPN, j'écris de nombreux articles pour sensibiliser les internautes à la confidentialité en ligne.
