Les entreprises ont renforcé leurs réseaux avec de nombreux outils de sécurité, mais beaucoup peinent encore à détecter rapidement ce qui se passe en interne. EDR, SIEM, pare-feu, EPP, fournisseurs gérés et alertes automatiques ne garantissent pas une visibilité totale si personne ne vérifie que la télémétrie arrive bien, que les règles restent pertinentes et que les signaux faibles sont investigués avant qu’un attaquant ne prenne le contrôle.

Le dernier rapport d’évaluation de compromis de Kaspersky, basé sur des évaluations menées en 2025, quantifie ce problème. 30,8 % des incidents détectés présentaient une activité historique de plus de trois mois, et 52 % des compromissions graves n’ont été identifiées qu’après plus de 90 jours sans détection. Le cas le plus ancien remontait à quatre ans, caché dans le réseau d’une organisation.

La leçon pour les équipes IT et sécurité est claire : la faille ne réside pas toujours dans l’absence d’outils, mais dans leur mauvaise utilisation. Selon le rapport, 20 % des incidents ont été découverts manuellement, tandis que 60 % sont passés inaperçus parce que les outils existants n’ont pas généré d’alertes fiables. Kaspersky souligne ainsi une faiblesse courante : des contrôles installés, mais mal ajustés, peu suivis ou sans routine de revue continue.

La sécurité achetée ne garantit pas une sécurité opérationnelle

Depuis des années, beaucoup d’organisations mesurent leur posture de défense à travers le nombre de solutions déployées. Disposer d’un EDR sur chaque endpoint, d’un SIEM centralisé, de logs transférés, d’un antivirus nouvelle génération ou d’un MSP sous contrat semblait suffire à réduire les risques. Pourtant, le rapport remet en question cette facilité.

Kaspersky constate qu’en l’absence de surveillance continue, 86 % des incidents de gravité moyenne ou élevée ont été détectés tardivement. En revanche, sans threat hunting structuré, cette proportion était de 84 %. La différence entre voir et ne pas voir ne dépend pas uniquement de l’outil, mais d’une équipe, interne ou externe, capable de valider les alertes, d’examiner les signaux faibles, de confronter les motifs et de rechercher proactivement toute activité anormale.

Un exemple illustratif du rapport : une entreprise avait investi dans des contrôles de sécurité et pensait être protégée. Toutefois, une analyse historique des logs a révélé une activité liée à Impacket, la mise en place de Cobalt Strike et la présence de Mimikatz sur des serveurs critiques, y compris leurs contrôleurs de domaine. Cette activité était passée inaperçue depuis trois mois, faute de monitoring 24/7 efficace.

Le rapport précise aussi le rôle des services managés. Avoir un MSSP peut améliorer la posture défensive, mais ne dispense pas de la gouvernance interne. Dans les projets externalisés, Kaspersky a observé des incidents non détectés à cause d’une couverture limitée ou d’audits Windows insuffisants, comme des événements non collectés ou des politiques d’audit désactivées. Externaliser ne doit pas être une excuse pour se décharger de la responsabilité interne ; une collaboration claire avec attentes, indicateurs et responsabilités est essentielle.

Backups, inventaire et persistance : les zones souvent négligées

Une des découvertes pratiques concerne les copies de sauvegarde. 40 % des web shells détectés par Kaspersky se trouvaient dans des backups. Cela signifie qu’une organisation peut effacer un serveur, clore une incident, puis réinjecter le malware en restaurant une copie apparemment saine.

Le backup est généralement considéré comme un gage de récupération, mais en cas d’intrusion, il peut aussi préserver le malware. Si ces backups ne sont pas scannés, comparés à une ligne de base ou validés avant restauration, ils peuvent réintroduire un accès que l’équipe de réponse pensait avoir éliminé.

Le problème s’aggrave si l’inventaire est incomplet. Kaspersky a constaté des lacunes dans 25 % des audits : des serveurs Linux dans le cloud non liés à Active Directory, donc hors des scans habituels. Un attaquant pouvait y déployer une web shell et y rester longtemps, surtout si le serveur est sauvegardé automatiquement mais pas intégré dans les outils de sécurité classiques.

Exemple : une web shell a été découverte dans un fichier compressé .rar sur un serveur interne déconnecté lors de l’évaluation, qui n’avait pas été bien référencé. La recherche a révélé une porte dérobée et d’autres serveurs Windows compromis via un changement de mot de passe administrateur local.

LoLBins et outils distants : le bruit qui masque l’attaquant

L’un des points clés évoqués dans le rapport est le recours accru à des outils légitimes par les cybercriminels : utilitaires d’administration à distance non standard et LoLBins, ces binaires ou outils système pouvant être utilisés pour des actions malicieuses ( mouvement latéral, persistance, exfiltration).

Il n’y a pas de règle simple. Des outils comme PsExec, AnyDesk, TeamViewer, VNC, certutil, bitsadmin, regsvr32 ou wmic peuvent être légitimes ou mal utilisés selon le contexte. La différence réside dans qui exécute, depuis quel terminal, à quelle heure, avec quels paramètres, vers quelle cible, et si cet usage s’insère dans la routine normale de l’entreprise.

Kaspersky recommande d’établir des politiques explicites concernant les outils d’administration à distance, le transfert de logs vers une plateforme centrale, l’audit logiciel, le classement fonctionnel des hashes et la définition de règles pour repérer les abus classiques de LoLBins. La clé n’est pas de tout bloquer par défaut, mais de construire une ligne de base réaliste et de détecter les écarts.

Ce travail, moins visible que l’achat d’une nouvelle console, fait souvent la différence. Lorsque les analystes maîtrisent l’usage normal du réseau, chaque alerte devient une occasion de discussion. Sinon, chaque faux positif peut conduire à des investigations infructueuses ou des fausses rectifications.

Réagir à un incident ne suit pas une recette figée

Kaspersky met aussi en lumière une faiblesse dans la réponse aux incidents : 39 % des compromissions analysées ont nécessité une mise à jour du plan de réponse en cours d’investigation, et 59 % ont demandé une collecte et une analyse approfondies de paquets. La raison : les incidents évoluent à mesure que de nouvelles preuves apparaissent.

Une organisation peut contenir le premier serveur compromis tout en laissant des persistes sur d’autres systèmes. Le rapport cite un cas où, après une réaction initiale efficace, l’évaluation a retrouvé plusieurs portes dérobées hors du scope initial : un cron qui recréait une web shell, une reverse shell active, une persistance via le journal Windows ou un client WMI contaminé.

La gestion des incidents doit être un processus dynamique, adaptable à chaque nouvelle donnée. Suivre un playbook rigide ne permet que d’arrêter la fuite immédiate, pas d’éliminer toutes les vulnérabilités. Si la procédure reste figée, d’autres accès peuvent rester opérationnels, laissant la porte ouverte aux attaques furtives.

L’aspect communication est crucial. 32 % des projets étudiés ont connu des défaillances internes : confirmations tardives, validations lentes, canaux compromis ou perte de savoir-faire suite à des rotations de personnel. En cas d’incident grave, la technique est essentielle, mais la coordination décide en grande partie du résultat.

L’IA générative, un facteur de risque supplémentaire

Le rapport donne un exemple illustratif : une station macOS analysée utilisait Claude Code comme extension de VS Code. Cette plateforme de développement envoyait des snapshots du système de fichiers pour enrichir ses prompts, incluant des listes de dossiers et des chemins d’accès vers des fichiers Excel contenant des données sensibles.

Il ne s’agit pas d’accuser tous les assistants IA, mais d’alerter sur le besoin de politiques claires à leur sujet. Ces outils, omniprésents dans le travail, dans la gestion, dans la surveillance et l’automatisation, peuvent exposer des données si aucune réglementation n’est appliquée. Sans délimitation précise, ils deviennent une zone d’ombre supplémentaire.

Pour les équipes de sécurité, cela signifie élargir leur champ de surveillance. La surface de risque ne se limite plus aux endpoints, emails, identités, cloud ou applications web. Elle comprend aussi les extensions, assistants de code, agents locaux, prompts, snapshots, connecteurs et automatisations, pouvant accéder à des données internes sans passer par les contrôles classiques.

Recommandations pour les équipes techniques et de la sécurité

L’évaluation principale à faire est de considérer la détection comme une fonction dynamique, non comme une solution à acheter. Cela passe par une vérification régulière de la santé des moteurs de détection : capteurs actifs, règles à jour, télémétrie complète, logs critiques activés, couverture des endpoints et alertes pertinentes. Sans signal, il ne faut pas supposer l’absence d’attaque sans avoir d’abord confirmé que tout est bien en place.

Ensuite, il faut effectuer un travail opérationnel : examiner les alertes à faible confiance, instaurer une routine de threat hunting, définir des lignes de référence pour les outils distants et LoLBins, auditer l’inventaire des actifs, valider les backups avant restauration, et faire évoluer les playbooks en fonction des nouvelles preuves.

Il est également conseillé de renforcer les capacités internes en analyse forensique et malware. Kaspersky a observé que les organisations capables de réaliser elles-mêmes des analyses forensiques ont eu moins d’incidents graves, et que la présence de ressources en rétro-ingénierie corrélait avec une gravité moindre des compromissions étudiées.

En résumé, il ne s’agit pas de tout faire seul en interne, mais d’assurer une gouvernance claire même en délégant. La sécurité ne consiste pas à déployer une solution technologique et espérer qu’elle suffise. Il faut s’assurer chaque jour qu’elle écoute, comprend et permet d’agir à temps.

Questions fréquentes

Qu’est-ce qu’un compromise assessment ?
C’est une évaluation indépendante permettant de vérifier si un réseau a été compromis ou l’est encore. Elle combine threat intelligence, scans d’endpoints, revue de logs, analyse du trafic et, si nécessaire, investigations forensiques digitales.

Pourquoi les outils de sécurité ne détectent-ils pas certains attaques ?
Parce qu’ils peuvent être mal configurés, obsolètes, dépourvus de télémétrie ou manqués par des analystes peu actifs. Le problème réside souvent dans leur utilisation opérationnelle plutôt que dans la technologie en elle-même.

Pourquoi les sauvegardes infectées sont-elles dangereuses ?
Parce qu’elles peuvent restaurer des web shells, scripts malveillants ou mécanismes de persistance, même après une première suppression, rouvrant ainsi la porte à l’attaquant.

Que sont les LoLBins ?
Ce sont des binaires légitimes du système ou des outils courants que les cybercriminels réutilisent pour exécuter des actions malicieuses sans déployer de malware évident.

Quels éléments doit vérifier une entreprise en priorité ?
L’état de ses capteurs et règles, l’intégrité des logs, l’inventaire des actifs, la surveillance des alertes faibles, la validité des backups, et l’actualisation des playbooks de réponse en fonction des nouvelles preuves.

Source : Open Security