52 % des compromissions graves identifiées par Kaspersky en 2025 n’ont été détectées qu’après plus de 90 jours sans alerte. Le cas extrême : une intrusion vieille de quatre ans, tapisée dans le réseau d’une organisation, invisible pendant toute cette période. Ce n’est pas une question de manque d’outils — c’est une question d’utilisation.

Le rapport d’évaluation de compromis de Kaspersky, basé sur des missions menées en 2025, quantifie le problème avec précision : 30,8 % des incidents présentaient une activité historique de plus de trois mois. Et 60 % sont passés inapreçus non pas parce que les outils étaient absents, mais parce qu’ils n’ont pas généré d’alertes fiables. 20 % des incidents ont été découverts manuellement, par une revue humaine, pas par un automate.

La leçon est inconfortable pour beaucoup de DSI : un EDR, un SIEM, un pare-feu et un fournisseur managé sous contrat ne suffisent pas 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.

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

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

Sans surveillance continue, 86 % des incidents de gravité moyenne ou élevée ont été détectés tardivement. Sans threat hunting structuré dans le centre d’opérations, cette proportion atteignait 84 %. La différence entre voir et ne pas voir ne dépend pas uniquement de la technologie, mais d’une équipe — interne ou externe — capable de valider les alertes, examiner les signaux faibles et rechercher proactivement toute activité anormale.

Un cas illustratif du rapport : une entreprise avait investi dans des contrôles de sécurité et pensait être protégée. 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ȩu pendant trois mois, faute de monitoring 24/7 efficace.

La question des services managés est aussi abordée. 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 : événements non collectés, politiques d’audit désactivées. Externaliser ne dispense pas de définir des attentes, des indicateurs et des responsabilités claires.

Backups infectés et inventaire incomplet : les angles morts

40 % des web shells détectés par Kaspersky se trouvaient dans des backups. Une organisation peut effacer un serveur, clore un incident, puis réinjecter le malware en restaurant une copie apparemment saine. Le backup, perçu comme filet de sécurité, devient un vecteur de ré-infection si personne ne le valide avant restauration.

L’inventaire est l’autre angle mort. 25 % des audits présentaient des lacunes : des serveurs Linux dans le cloud non rattachés à Active Directory, hors du périmètre des scans habituels. Un attaquant pouvait y déployer une web shell et y rester longtemps, surtout si le serveur était sauvegardé automatiquement mais non intégré dans les outils de sécurité.

Exemple concret du rapport : une web shell a été découverte dans un fichier .rar compressé sur un serveur interne déconnecté lors de l’évaluation, mal référencé dans l’inventaire. L’investigation 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 légitimes : le bruit qui cache l’attaquant

L’un des points clés du rapport concerne les outils légitimes détournés par des cybercriminels : utilitaires d’administration à distance et LoLBins, ces binaires système utilisables pour du mouvement latéral, de la persistance ou de l’exfiltration.

Il n’y a pas de règle simple. Des outils comme PsExec, AnyDesk, TeamViewer, VNC, certutil, bitsadmin 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 et vers quelle cible. La chasse aux menaces dans le trafic légitime est devenue une pratique incontournable pour distinguer usage normal et abus.

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

La réponse à incident n’est pas un processus figé

39 % des compromissions analysées ont nécessité une mise à jour du plan de réponse en cours d’investigation. 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 persistances actives ailleurs. 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, un client WMI contaminé.

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. Et la communication compte : 32 % des projets étudiés ont connu des défaillances internes — confirmations tardives, validations lentes, canaux compromis ou perte de savoir-faire après rotation de personnel.

L’IA générative, une nouvelle surface d’exposition

Le rapport donne un exemple concret : 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 vers des fichiers Excel contenant des données sensibles.

Ce n’est pas une accusation contre les assistants IA, c’est une alerte sur le besoin de politiques claires. Ces outils, présents dans le travail quotidien, la gestion, la surveillance et l’automatisation, peuvent exposer des données si aucun cadre n’est appliqué. Sans périmètre défini, ils deviennent une zone d’ombre supplémentaire.

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, connecteurs et automatisations, qui peuvent accéder à des données internes sans passer par les contrôles classiques.

Ce que les équipes techniques doivent faire maintenant

L’évaluation principale à faire : considérer la détection comme une fonction dynamique, pas 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. Pas d’alerte ne signifie pas absence d’attaque — cela peut signifier que la télémétrie est muette.

Concrètement : examiner les alertes à faible confiance, instaurer une routine de threat hunting, définir des lignes de base 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.

Kaspersky a observé que les organisations capables de réaliser elles-mêmes des analyses forensiques ont eu moins d’incidents graves. La présence de ressources en rétro-ingénierie corrélait avec une gravité moindre des compromissions. Ce n’est pas une option réservée aux grandes structures — des capacités même modestes font la différence.

La sécurité ne consiste pas à déployer une solution 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 ?

Une évaluation indépendante qui vérifie 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 numériques.

Pourquoi les outils de sécurité ratent-ils certaines attaques ?

Parce qu’ils peuvent être mal configurés, obsolètes ou dépourvus de télémétrie complète. Le problème réside souvent dans l’utilisation opérationnelle, pas dans la technologie elle-même. Un EDR sans revue humaine des alertes faibles est souvent aveugle.

Pourquoi les sauvegardes infectées sont-elles dangereuses ?

Elles peuvent restaurer des web shells, scripts malveillants ou mécanismes de persistance, même après une première suppression. 40 % des web shells trouvés par Kaspersky se trouvaient dans des backups.

Que sont les LoLBins ?

Des binaires légitimes du système ou des outils courants que des attaquants réutilisent pour exécuter des actions malveillantes sans déployer de malware évident : mouvement latéral, persistance, exfiltration.

Quels éléments vérifier en priorité dans une organisation ?

L’état des capteurs et règles de détection, l’intégrité des logs, l’inventaire des actifs, la surveillance des alertes à faible confiance, la validité des backups avant restauration et la mise à jour des playbooks selon les nouvelles preuves.

Source : Open Security