Le rapport Active Adversary 2025 de Sophos

Le rapport Sophos Active Adversary fête son cinquième anniversaire cette année. Le rapport est né d’une question simple : que se passe-t-il après le lancement par des cybercriminels d’une attaque ciblant une entreprise en particulier ? Après tout, connaître le playbook de l’adversaire aide les défenseurs à mieux combattre une attaque active (en effet, il y avait, au départ, une raison pour laquelle nous avions appelé ce rapport “The Active Adversary Playbook“).  Au moment où nous discutions des moyens d’instrumentaliser un environnement de test pour répondre à cette question concernant “ce qui se passe”, Sophos se préparait alors à lancer un service de réponse aux incidents (IR). Un projet inter-équipes était donc né.

Depuis les cinq dernières années, nous avons présenté nos données, d’abord uniquement celles du service IR, puis en les élargissant progressivement pour inclure les données de l’équipe sœur de celle dédiée à l’IR qui prend en charge les clients MDR actuels. Nous analysons ainsi le sens que ces résultats ont pour nous. Alors que nous continuons à affiner notre processus de collecte et d’analyse des données, ce rapport se concentrera sur certaines observations et analyses clés, et, pour célébrer une demi-décennie d’activités dédiées à la création de ce rapport Active Adversary, nous offrons à un large public l’accès à notre ensemble de données 2024, dans l’espoir d’initier des conversations plus larges. Vous trouverez plus d’informations à ce sujet, ainsi que le lien vers le référentiel Active Adversary sur GitHub, à la fin de ce rapport.

Principaux points à retenir

• Les différences entre les résultats MDR et IR montrent, quantitativement, la valeur réelle statistique de la surveillance active.
• Les identifiants compromis continuent de permettre un accès initial ; l’authentification multifacteur reste essentielle.
• Le temps de séjour diminue (encore une fois !).
• L’abus des LOLBins (Living-Off-the-Land Binaries) par les attaquants explose.
• Les ransomwares distants représentent un défi/une opportunité unique pour les systèmes managés activement.
• L’impact des attaques fournit des données essentielles sur les détections potentielles.

D’où viennent les données ?

Comme pour notre précédent rapport Active Adversary, les données de cette nouvelle édition sont tirées de cas/dossiers sélectionnés et traités en 2024 par deux équipes Sophos :  a) l’équipe IR (Incident Response) et b) l’équipe de réponse aux incidents qui gère les cas critiques survenant chez nos clients MDR (Managed Detection and Response), (pour des raisons pratiques, nous les désignerons dans ce rapport par les termes IR et MDR). Le cas échéant, nous comparerons les résultats des 413 cas sélectionnés pour ce rapport avec les données des précédents cas traités par Sophos X-Ops, remontant au lancement de notre service IR en 2020.

Pour ce rapport, 84% de l’ensemble de données (dataset) provient d’entreprises de moins de 1 000 employés. Ce chiffre est inférieur aux 88% de notre rapport précédent ; la différence est principalement (mais pas entièrement) due à l’ajout de cas MDR à l’ensemble. À peine plus de 53% des entreprises ayant fait appel à Sophos comptent 250 employés ou moins.

Quels sont les secteurs concernés exactement ? Comme c’est le cas dans nos rapports Active Adversary depuis les premières publications, le secteur manufacturier était le plus susceptible de faire appel aux services de réponse aux incidents de Sophos X-Ops, bien que le pourcentage de clients provenant du secteur manufacturier soit passé de 25% en 2023 à 16% en 2024. L’éducation (10%), la construction (8%), les technologies de l’information (7%) et la santé (6%) complètent le top cinq. Au total, 32 secteurs sont représentés dans cet ensemble de données.

De plus amples informations sur les données et la méthodologie utilisées pour sélectionner les cas présentés dans ce rapport sont disponibles en annexe. Les données de réponse aux incidents de SecureWorks ne sont pas incluses dans ce rapport.

L’événement principal : MDR versus IR

Au fur et à mesure que nous avons compilé et normalisé les ensembles de données IR et MDR, l’équipe Active Adversary a émis l’hypothèse que nous observerions probablement de meilleurs résultats en matière de sécurité dans les organisations où une surveillance et une journalisation (logging) actives qualifiées étaient déjà en place, en d’autres termes, les cas MDR. Même si cela peut paraître évident, c’est l’ampleur de certaines différences qui nous a surpris, et ce sont ces différences que nous allons souligner dans ce rapport.

Temps de séjour et ransomwares

Lors des rapports précédents, nous avons observé, sans toutefois les mettre en évidence, des différences distinctes entre les types d’attaque courants ciblant les clients MDR et les clients IR. Il s’agissait de la première indication forte de l’écart entre les deux ensembles de données, et c’est cette différence qui a donné le ton et l’orientation de ce rapport.

Dans tous les rapports précédents, les ransomwares ont dominé les classements, comme on pouvait s’y attendre d’après les données provenant de l’équipe IR. Une attaque de ransomware peut causer tout simplement trop de dégâts pour que de nombreuses organisations puissent y remédier elles-mêmes, en particulier les petites organisations qui peuvent ne pas disposer des ressources nécessaires pour mettre en place une réponse complète.

Les données IR, uniquement, des quatre dernières années ont montré que l’occurrence des ransomwares variait entre 68% et 81% des cas. Pour 2024, ce chiffre tombe à 40% des cas, perdant sa première place au profit des violations de réseau à 47%. Si l’on décompose les données en fonction de leur origine, la proportion de cas IR ressemble beaucoup à toutes les données précédentes. Les ransomwares (65%) constituent le type d’attaque dominant, suivis par les violations de réseau (27%). Les données MDR dressent un tableau différent, dans lequel les violations de réseau (56%) dépassent les ransomwares (29%) avec un rapport de presque deux pour un.

Figure 1 : L’évolution des résultats concernant les types d’attaque dans notre ensemble de données est frappante : en 2024, les violations de réseau ont dépassé les ransomwares comme type d’attaque le plus fréquemment observé. Au bas du graphique, cependant, il y a un autre élément remarquable : quel que soit l’ensemble de données, quelle que soit l’année, aucun type d’attaque ne dépasse 10% de tous les cas observés ; ainsi on constate que même si les ransomwares ou les violations de réseau représentent l’événement principal d’une année donnée, tout le reste est véritablement secondaire.

Le deuxième ensemble de données soutenant notre hypothèse concerne le temps de séjour. Les années précédentes, le temps de séjour a diminué, mais s’est stabilisé dans les derniers rapports (nous avons traité le temps de séjour via une analyse approfondie dans notre rapport du premier semestre 2024, 1H 2024). Pour nous, le temps de séjour était bel et bien mort, jusqu’à ce que nous observions les statistiques de cette année.

En effet, il ne fallait pas l’enterrer trop vite : la durée de séjour médiane pour tous les cas en 2024 était de deux jours. Nous voyons un modèle familier émerger dans les cas IR : la durée de séjour médiane globale est de 7 jours, avec des cas impliquant des ransomwares étant associés à des durées de 4 jours et des cas n’impliquant pas de ransomwares étant associés à des durées de 11,5 jours. En revanche, les temps de séjour des cas MDR étaient globalement plus faibles, et l’ordre de grandeur des temps de séjour pour les attaques de ransomware (3 jours) et celles de type non-ransomware (1 jour) était inversé.

Nous pensons que ce constat est dû au fait que certaines actions (par exemple, l’exfiltration des données) ne peuvent pas être plus rapides, car elles dépendent de l’activité humaine, du débit des données ou d’autres délais assez rigides. Cette observation ne veut pas dire que les attaques ne peuvent pas être réalisées plus rapidement, car en fait elles le peuvent, mais les données montrent que les attaques de ransomware nécessitent traditionnellement des délais plus longs que les autres types d’attaque. Le fait que les temps de séjour des cas de ransomware traités par chaque service soient à peu près égaux n’est donc pas surprenant.

Les cas non liés à des ransomwares, en revanche, présentent moins de ralentissements, et c’est là que les données mettent en évidence les différences entre les services. Par exemple, dans les cas IR, un attaquant peut résider dans le réseau de la victime sans être détecté pendant beaucoup plus longtemps, jusqu’à ce qu’un événement ne se produise provoquant ainsi suffisamment de bruit ou d’impact. Un attaquant utilisant des identifiants valides, qui exfiltre silencieusement des données d’un réseau via les canaux prévus à cet effet, pourrait ne pas être détecté avant d’avoir contacté la victime, s’il le fait un jour d’ailleurs (il convient également de noter que le secteur des ransomwares a attiré un grand nombre d’attaquants amateurs, généralement moins aptes à rester silencieux et à dissimuler leurs traces). Les ransomwares restent toujours et encore une question de chiffres, donc se faire éjecter d’un grand nombre de systèmes fait tout simplement partie de leur business model).

En revanche, les cas MDR pour les incidents non liés à un ransomware (ou pré-ransomware) sont générés plus rapidement grâce à une combinaison d’ingénierie de détection et de vigilance constante. Les événements suspects font l’objet d’une investigation lancée plus tôt et ceux qui justifient une investigation supplémentaire sont signalés. En bref, une détection plus rapide conduit souvent à un blocage des ransomwares, signifiant donc une proportion plus élevée d’attaques classées comme des violations de réseau et générant ainsi de meilleurs résultats pour les victimes.

Les causes premières

En revanche, nous n’avons pas constaté de grande différence entre les cas IR et MDR en ce qui concerne les causes premières. Nous voyons ici la combinaison courante d’identifiants compromis (41%) et d’exploitation de vulnérabilités (22%) ouvrir la voie une fois de plus, et les attaques par force brute (21%) se frayer un chemin jusqu’à la troisième place, comme le montre la figure 2.

Figure 2 : La cause première en 2024 varie entre les cas MDR et IR, mais les identifiants compromis restent la principale cause dans les deux ensembles de données.

Les attaques par force brute ont toujours été reléguées à la catégorie des attaques secondaires dans les données IR, mais ont connu une augmentation spectaculaire dans les données MDR, ce qui a propulsé ce type d’attaque dans le classement de 2024. Cette tendance peut être due à une différence dans les données disponibles sur les causes premières. Dans les investigations IR, les logs ne sont souvent pas disponibles, réduisant ainsi la capacité de l’équipe d’investigation à déterminer les causes premières de l’attaque. En revanche, les investigations MDR disposent de sources de données plus cohérentes, permettant ainsi des analyses plus précises.

Un examen des données d’une année sur l’autre, comme le montre la figure 3, montre l’évolution des pourcentages entre les années précédentes et 2024.

Figure 3 : En 2024, les identifiants compromis ont reculé par rapport aux niveaux élevés précédents en tant que cause première des problèmes, mais la situation reste mauvaise (les données des cas de 2020 ne sont pas représentées dans ce graphique en raison d’un changement dans l’étiquetage de nos données pour cette catégorie).

En 2024, les logs manquaient dans 47% des cas : 66% pour les cas IR, 39% pour les cas MDR. La principale raison de l’absence de logs dans tous les cas était qu’ils n’étaient tout simplement pas disponibles (20%) pour les analystes pendant l’investigation, suivie par 17% de logs effacés par les attaquants et par 7% de logs manquants du fait de périodes de conservation insuffisantes.

Remarque : un outil souvent utilisé pour effacer les logs est le binaire Microsoft wevtutil.exe (l’utilitaire d’événement Windows). Cet outil générera les ID de log d’événement Windows 1102 (pour les logs de sécurité) et 104 (pour les logs système). Les organisations devraient envisager de configurer leurs outils de sécurité et leurs chasses aux menaces pour détecter cette activité.

L’augmentation des attaques par force brute comme cause première correspond bien aux statistiques d’accès initial/Initial Access (TA0001). Les services distants externes/External Remote Services (T1133) étaient la méthode d’accès initial privilégiée, observée dans 71% des cas. Comme nous l’avons indiqué précédemment, ce système est souvent étroitement associé aux comptes valides/Valid Accounts (T1078) ; cette année, le duo a fait équipe dans 78% des cas. L’utilisation d’une application publique/Public-Facing Application (T1190) a été le deuxième facteur le plus important contribuant à l’accès initial. La principale vulnérabilité directement exploitée pour l’accès initial était CVE-2023-4966 (Citrix Bleed ; 5%). D’autres facteurs incluent l’exposition de l’infrastructure de bureau à distance (Remote Desktop) (18%), les VPN vulnérables (12%) et l’exposition de services internes (11%).

Comment ont évolué ces TTP ?

Nous avons démontré dans un rapport précédent qu’il y avait peu de différences au niveau des TTP entre les attaques avec des temps de séjour courts (5 jours ou moins) et longs (plus de 5 jours). Ces données concernaient exclusivement des cas IR. En examinant les TTP du rapport de cette année, nous constatons que la tendance se maintient lorsque l’on compare les cas IR et MDR.

Un nombre légèrement plus élevé d’artefacts ont été observés dans les cas MDR (+24%), bien que l’ensemble de données MDR soit environ 240% plus grand que celui tiré des cas IR. Il y avait un chevauchement de 60% au niveau des 10 outils les plus utilisés par les attaquants. Parmi les outils légitimes les plus utilisés à mauvais escient, on trouve les noms familiers suivants : SoftPerfect Network Scanner, AnyDesk, WinRAR et Advanced IP Scanner, comme illustré dans la figure 4.

Figure 4 : Les outils utilisés abusivement dans les cas IR et MDR ne varient pas beaucoup en haut du classement, mais certaines différences et absences sont frappantes.

Les binaires Microsoft ont montré une corrélation plus étroite entre les ensembles de données. Les 10 LOLBins les plus abusés présentaient un chevauchement de 70%, comme le montre la figure 5. Il y a eu un léger remaniement au niveau de la première place, avec cmd.exe battant le RDP comme LOLBin le plus abusé au niveau de la charge de travail MDR. Ce constat n’est pas entièrement surprenant, car de nombreux cas MDR ont une zone d’impact limitée : en effet, lorsqu’ils y sont autorisés, les analystes isolent automatiquement les hôtes affectés, limitant ainsi les capacités de mouvement latéral des attaquants.

Figure 5 : L’abus de LOLBins se présente de la même manière, quelle que soit l’équipe qui observe ; en particulier, la différence entre MDR et IR en ce qui concerne l’abus du RDP existe mais n’est pas notable.

La comparaison finale porte sur la catégorie “autres“, dans laquelle nous regroupons les techniques et les traces qui n’entrent pas dans les deux autres catégories. Les 10 premiers cas présentaient un chevauchement de 80% dans les cas IR et MDR ; la création de comptes, la suppression de fichiers, l’installation de services, de scripts malveillants et la modification du registre étaient les techniques dominantes, comme le montre la figure 6. D’autres, comme le dumping du SAM (Security Account Manager), étaient plus courants dans l’ensemble de données d’une équipe en particulier.

Figure 6 : Comme nous le voyons, dans plus de la moitié des cas, les attaquants ont utilisé des TTP courantes et similaires (notez que les pourcentages totalisent plus de 100 %, car la plupart des cas présentent plusieurs résultats dans cette catégorie).

Retour sur le précédent rapport Active Adversary

Comme c’est devenu la norme pour l’équipe Active Adversary, nous aimons vérifier certaines de nos conclusions issues de nos rapports précédents, en particulier celles pour lesquelles la période de temps en matière de données est inférieure à 12 mois. La section suivante examine les principaux points à retenir dans notre rapport précédent (couvrant les six premiers mois de 2024) et les compare à l’ensemble des données de l’année complète.

LOLBins

L’abus des binaires Microsoft s’est poursuivi sans relâche au cours du second semestre 2024, et le ratio de LOLBins uniques par rapport aux années précédentes a également continué d’augmenter. Au cours du premier semestre 2024, nous avons constaté une augmentation de 51% du nombre de LOLBins uniques, laquelle est passée à 126% en fin d’année par rapport aux chiffres de 2023. Il y a eu une augmentation de 17% des cas au deuxième semestre 2024 et une augmentation de 24% des binaires uniques utilisés. Il n’y a pas eu de différences significatives au niveau des binaires individuels utilisés tout au long de l’année. Entre le premier et le second semestre de l’année, il y a eu un chevauchement de 95% au niveau des 20 outils les plus utilisés dans les cas IR et MDR. Les outils pouvant être utilisés pour l’énumération, en plus des utilisations légitimes et malveillantes, ont continué d’être fortement présents dans les deux ensembles de données, représentant 50% des 20 binaires les plus utilisés à mauvais escient.

Notepad.exe est un nouvel entrant dans le top 10 de cette année. Cet outil était principalement utilisé pour parcourir les fichiers sur le réseau, notamment ceux contenant des mots de passe stockés en clair (5%). Des outils comme Notepad offrent une opportunité de détection intéressante. Nous pensons que la plupart des utilisateurs n’utilisent pas Notepad à la place d’autres programmes Office. Mais il y a tout de même une grande différence entre cliquer sur l’icône “Notepad”, taper “Notepad” dans la recherche Windows ou taper “notepad.exe” au niveau de la ligne de commande. Être capable de faire la distinction entre ces trois méthodes de lancement différentes peut éclairer sur l’intention se cachant derrière son utilisation.

Il en va de même pour des outils comme PowerShell. Nous n’allons pas suggérer aux équipes informatiques d’arrêter de l’utiliser, mais il existe quelques questions simples et rapides à se poser en matière d’ingénierie de détection. Ce script PowerShell était-il fortement obfusqué et s’est-il connecté à Internet ? Si c’est le cas, il faudrait probablement investiguer.

Le principal problème avec les LOLBins est qu’ils ont tendance à générer beaucoup de bruit. Le défi pour les équipes informatiques est de comprendre où se trouve le véritable signal.

RDP

Les détections RDP continuent de figurer en tête du classement des outils Microsoft utilisés à mauvais escient. En 2024, il a été utilisé par les attaquants dans 84% des cas, 67% étant utilisé uniquement pour un mouvement latéral interne et 3% étant utilisé seulement pour un mouvement externe. C’est sans compter les cas où il a été utilisé à la fois en interne et en externe. L’addition de ces cas porte respectivement les chiffres globaux à 83% et 19%.

Malgré les abus continus du RDP, et nos appels à ce qu’il soit banni hors des murs de l’entreprise, nous comprenons pourquoi il persiste dans les réseaux. Ainsi, ce constat nous donne l’occasion d’explorer comment nous pourrions à la fois limiter son utilisation et instrumentaliser certaines détections d’abus.

Idéalement, toute utilisation du RDP est limitée à la fois par les goulets d’étranglement du réseau et par les identités des utilisateurs. Dans la mesure du possible, nous devons ajouter un MFA au flux d’authentification et appliquer le principe du moindre privilège. En limitant son utilisation et en comprenant à quoi ressemble la norme, il devient plus facile de détecter les anomalies.

Il existe plusieurs façons de détecter les événements d’authentification, mais de manière générale, vous pouvez rechercher les ID de log d’événement Windows 4624 et 4625. Le premier est un événement d’authentification réussi, tandis que le second indique une tentative échouée. Les événements de connexion réussis peuvent vous aider à attraper un attaquant utilisant des identifiants valides en dehors de l’utilisation normale, tandis que plusieurs tentatives infructueuses peuvent vous alerter de manière précoce concernant d’éventuelles attaques par force brute contre vos comptes.

Si vous utilisez une norme interne à l’entreprise pour nommer vos appareils, comme le font de nombreuses entreprises, vous pouvez l’utiliser comme un autre indicateur. Toute authentification réussie qui n’est pas conforme à la norme doit faire l’objet d’une investigation. Si votre organisation ne dispose pas d’une norme, cela pourrait être l’occasion d’en mettre une en place et de créer des pièges/déclencheurs passifs pour les attaquants. En revanche, si le nom d’hôte “kali” apparaît sur votre réseau, comme c’est le cas dans 6% des cas, vous devriez investiguer.

Enfin, vous pouvez tirer parti du décalage horaire dans la journalisation/logging RDP. Il s’agit du décalage horaire du client distant par rapport à l’UTC. Si la plupart de vos utilisateurs sont en UTC-6, mais qu’un client distant, par ailleurs banal, se connecte à l’aide d’identifiants valides et d’un nom d’hôte d’apparence normale, mais présente un décalage horaire de +3, ne perdez pas une seconde pour découvrir ce qui se passe (nous nous rappelons avoir vu des machines d’apparence inoffensive connectées, mais partageant une imprimante portant un nom russe pour une raison quelconque…).

L’idée derrière ces opportunités de détection est de prendre des signaux indépendants, mais parfois bruyants ou faibles, et de les assembler pour obtenir un signal plus fort et plus fiable, une approche aussi appelée par les cool kids une défense en profondeur (defense in depth).

Ceux qui souhaitent en savoir plus sur le RDP et comment détecter ses abus peuvent trouver des détails supplémentaires dans notre série dédiée au RDP.

Attribution

Dans le dernier rapport, nous avions prédit qu’en 2024, il n’y aurait finalement pas d’adversaire, utilisant les ransomwares, qui seraient fortement dominant ; avec un démantèlement par les forces de l’ordre en début d’année qui a mis hors d’état de nuire LockBit, le principal acteur malveillant de 2023, le champ s’est ouvert pour la prochaine grande vague (malveillante). Comme le montre le tableau de la figure 7, c’est exactement ce qui s’est passé : Akira s’est hissé au sommet du classement, mais de justesse (LockBit était, en fait, si dominant au début de l’année dernière qu’il est resté troisième au classement malgré son démantèlement). Au cours de la seconde moitié de l’année, Fog a fait son apparition dans les graphiques, devançant Akira pour atteindre la première place (l’équipe MDR a constaté quelques traces d’infections liées à LockBit au début du second semestre, mais même ces dernières se sont évaporées à la fin de l’année). Cette tendance pourrait encore se trouver bouleverser en 2025 en raison de changements probables dans (entre autres) la coordination des efforts menés par les forces de l’ordre et LockBit qui jure toujours de faire son retour. Nous suivrons, bien sûr, cette évolution avec le plus grand intérêt.

Figure 7 : La célébrité est éphémère, comme les auteurs de LockBit l’ont appris au cours de la seconde moitié de 2024 ; pendant ce temps, un acteur Fog imposant s’était installé.

Pouvoir attribuer un problème à un adversaire spécifique est apaisant, d’une certaine manière. Mais les professionnels de la cybersécurité combattent souvent des forces qu’ils sont en mesure de maîtriser, tout en faisant face à des choix faits par les entreprises au sens large qui débouchent sur un conflit supplémentaire à gérer. Notre étude de cas dans ce rapport décrit comment les évènements se sont déroulés pour un client MDR “malchanceux”.

Étude de cas

Bien que nous continuions à réitérer les principes fondamentaux en matière de sécurité (fermer les ports RDP exposés, utiliser le MFA et corriger les systèmes vulnérables), face à des processus de décision au niveau des entreprises qui sont hors du contrôle des professionnels de la sécurité, ce n’est pas toujours aussi simple. Les professionnels de la sécurité ne se contentent pas de lutter contre les menaces émanant des adversaires externes, mais mènent également une lutte interne contre les processus métier et la gestion du changement. Ce bras de fer s’est retourné contre un client MDR. À la suite d’une violation du réseau au cours de laquelle l’acteur malveillant a obtenu un accès initial via un VPN vulnérable, le client a attendu, à priori, deux mois pour corriger l’appliance VPN. Avec un gang de ransomware prêt à bondir en coulisses, le conflit entre les priorités de sécurité et celles de l’entreprise dans son ensemble s’est fini de la pire des manières possible.

Un client finalement perdant

L’équipe Sophos MDR a récemment répondu à l’incident critique de ce client, l’accès initial ayant été identifié comme l’un de nos suspects habituels : un appareil VPN non corrigé. Dans ce cas, un pare-feu FortiGate fonctionnait sur la version 5.6.11 du firmware, publiée en juillet 2010 ; le pare-feu lui-même avait atteint sa fin de vie en octobre 2021. De plus, le MDR a identifié une mauvaise configuration dans les contrôles d’accès des utilisateurs VPN, ce qui a considérablement augmenté le risque d’accès non autorisé.

Après avoir obtenu un accès initial, l’acteur malveillant s’est déplacé latéralement vers le contrôleur de domaine, a exploité des outils anti-AV, a effectué une énumération et a obtenu une persistance sur un certain nombre d’appareils au sein du domaine. À ce stade, l’équipe MDR de réponse aux incidents a perturbé l’activité de l’attaquant et le calme est alors revenu.

L’équipe MDR a recommandé au client (a minima) de corriger d’urgence le firmware VPN vieux de 14 ans et de désactiver, entre-temps, le VPN SSL Cependant, les processus métier du client n’étaient pas coopératifs ; la désactivation totale du VPN aurait eu un impact commercial inacceptable, et donc les correctifs n’ont pas pu être installés pendant deux mois (!). Le client a estimé que la mauvaise configuration prendrait une semaine pour être corrigée.

Déjà en train de se battre

C’est un fait malheureux dans la vie d’une équipe de réponse aux incidents : nous ne pouvons pas imposer ; nous ne pouvons que recommander, et, parfois, nous ne pouvons que regarder l’histoire se répéter sans rien pouvoir faire. Et ce cycle ne cesse de se répéter : le même client avait déjà subi une faille similaire, impliquant le même VPN vulnérable, 14 mois plus tôt. Dans ce cas, le client n’avait pas encore activé le MFA pour les connexions VPN ; une attaque par force brute a ainsi réussi et l’attaquant a pu désactiver les protections et récupérer les identifiants. Au cours du processus, l’attaquant a réussi à compromettre un compte de service clé, laissant le client incapable d’effectuer une réinitialisation cruciale des identifiants en raison, encore une fois, de contraintes liées à l’entreprise (souvenez-vous bien de ce compte de service ; nous allons le revoir très bientôt).

L’écart entre la première violation et la deuxième était, comme mentionné, de 14 mois. L’écart entre la deuxième et la troisième était beaucoup plus court.

Encore une nouvelle attaque ?

Une fois ce deuxième incident terminé, le VPN et ce compte de service, non pris en charge depuis près de quatre ans et connus comme compromis depuis plus d’un an, ont attendu dans les profondeurs des processus métier, tout comme la mauvaise configuration du VPN. Les experts en sécurité ont fait preuve de patience. Mais pas l’attaquant. Neuf jours après le traitement de la deuxième faille, CryTOX a fait irruption. Utilisant le compte de service compromis et tirant pleinement parti du VPN non corrigé et (toujours) mal configuré, le ransomware s’est alors propagé à travers le système, se déplaçant latéralement, bloquant les processus de sécurité des systèmes endpoint et finissant par chiffrer l’ensemble du parc.

On peut dire, dans ce cas, que le ransomware est sorti gagnant de ce bras de fer entre les pratiques de sécurité et les processus métier décisionnels de l’entreprise (point positif (tout de même) : après le troisième incident, le VPN a finalement été désactivé, bien que les comptes affectés aient toujours été réactivés sans réinitialisation des identifiants). Même si toutes les organisations ne sont pas aussi malchanceuses, dans ce cas précis, l’attente de l’approbation au niveau des changements à mener en interne était un pari en termes de risques qui a été lamentablement perdu.

Résumé de nos autres observations

Alors que nous tirons nos conclusions pour 2024, examinons d’autres statistiques qui ont retenu notre attention.

Outre un nombre accru de cas, l’ensemble de données de cette année comprenait la plus forte augmentation d’une année sur l’autre au niveau de toutes les TTP observées. Par rapport à 2023, le nombre d’outils mal utilisés a augmenté de 80%, les LOLBins ont augmenté de 126% et tout le reste (“autres“) a augmenté de 28%. Ce qui est intéressant dans ces chiffres, c’est la longue traîne de chaque catégorie, c’est-à-dire le nombre d’outils ou de LOLBins ou “autres” qui apparaissent dix fois ou moins dans l’ensemble de données. Lorsque nous comptabilisons chaque détection dans chaque cas, ces raretés représentent 35% de l’ensemble des utilisations d’outils (689 détections sur un total de 1945 ; 334 éléments uniques), 12% de l’ensemble des utilisations de LOLBins (508 détections sur 4357 ; 184 éléments uniques) et 12% de tous les “autres” (476 détections sur 4036 ; 189 éléments uniques).  Un biologiste pourrait appeler ce phénomène une traîne vestigiale ; nous les considérons avec une priorité d’investigation inférieure à celle des TTP dominantes classées en haut de nos tableaux.

Pas de temps à perdre

Lorsqu’il s’agit de certains objectifs, les attaquants ne perdent pas de temps à se disperser. Nous avons d’abord rendu compte de la course à la compromission ciblant Active Directory en 2023. Cette statistique a continué de baisser et la médiane s’établit désormais à 0,46 jour. En d’autres termes, une fois qu’un attaquant pénètre dans l’environnement, il ne lui faut que 11h avant de s’attaquer au serveur AD. La plupart (62%) des serveurs compromis exécutaient des systèmes d’exploitation qui n’étaient plus pris en charge de manière globale.

Des attaques sans cadre temporel défini

Une autre statistique liée au temps que nous avons signalée pour la première fois en 2023 était le moment de la journée choisi par les attaquants pour déployer les charges virales des ransomwares. Même si davantage de données adoucissent quelque peu les valeurs, les résultats restent très parlants. En 2024, 83% des binaires de ransomware ont été déployés en dehors des heures de bureau locales de la cible concernée ; la statistique historique s’élève à 88%. Bien qu’il semble que les déploiements de ransomware ne se produisent que la nuit, il ne semble cependant pas y avoir de préférence particulière pour les jours de la semaine.

Des outils qui vont et viennent

La proportion et les types d’outil, légitimes et malveillants, qui composent cette catégorie sont restés relativement stables pendant de nombreuses années. Voici quelques points à retenir au niveau des données de cette année, en plus des questions abordées ci-dessus.

Nous avons constaté une forte baisse de la proportion d’attaques utilisant Cobalt Strike. Cet outil occupait la première place des outils utilisés de manière malveillante de 2020 à 2022, avant de tomber à la deuxième place en 2023. Cette année, il est tombé à la treizième place de notre classement, apparaissant dans seulement 7,51% des cas. En raison de sa popularité historique auprès des attaquants, il occupe toujours la première place du classement global, où il a été impliqué dans 25% des attaques au cours des cinq dernières années. Nous pensons que cette diminution est due à des capacités accrues en matière de prévention et de détection. Cobalt Strike était populaire parce qu’il était efficace. Maintenant que son efficacité a diminué, son utilisation a également diminué. Bien que ce soit une bonne nouvelle, ce constat suggère également qu’un autre outil a pris ou prendra sa place.

Impacket est un outil qui a connu une augmentation considérable en termes d’abus. Les outils Impacket existent depuis au moins une décennie et peuvent effectuer diverses actions, notamment la manipulation de protocoles réseau, la récupération d’identifiants (dumping) et de la reconnaissance. Son utilisation a augmenté régulièrement ces dernières années, passant de 0,69% en 2021 à 21,43% en 2023 ; les attaquants ont vraiment intensifié leur utilisation d’Impacket en 2024, lorsqu’il a dépassé tous les autres outils et s’est retrouvé en première place.  L’outil Impacket le plus utilisé était wmiexec.py, qui figurait dans 35% des attaques (dans nos statistiques, nous identifions la sous-classe Impacket spécifique chaque fois que possible ; en cas de doute, nous le classons simplement sous Impacket, sans aucune sous-classe associée).

Un outil vénérable qui connaît un léger déclin d’une année sur l’autre est Mimikat. L’outil de collecte d’identifiants a été observé de manière fiable dans environ un quart des attaques au cours des années précédentes, mais a chuté à 15% en 2024. Bien que nous ne puissions pas attribuer de manière incontestable son déclin à une seule raison, il est possible qu’il soit lié à l’utilisation accrue des outils Impacket ; en particulier, le script secretsdump.py qui peut être utilisé pour récupérer les hachages des machines distantes. Cette tendance est en corrélation avec une augmentation d’une année sur l’autre de la récupération du contenu des registres distants et une réduction de moitié du dumping LSASS (le plus souvent attribué à Mimikatz dans nos données). Secretsdump.py a été observé dans au moins 6% des attaques et était le deuxième outil Impacket le plus utilisé après wmiexec.py.

Parmi les 15 outils les plus utilisés à mauvais escient, 47% sont souvent utilisés pour l’exfiltration de données. Ces outils incluent des logiciels d’archivage et des outils de transfert de fichiers bien connus.

Autres résultats

Depuis que nous avons commencé à suivre la mise à disposition de l’authentification multifacteur (MFA) dans les organisations victimes de violations, la situation s’est en réalité aggravée. En 2022, nous avons observé que 22% des victimes n’avaient pas configuré le MFA. Cette proportion a presque triplé pour atteindre 63% en 2024. Il s’agit d’un domaine dans lequel il n’y a pas de distinction significative entre les cas IR et MDR. Le MFA n’était pas disponible dans 66% des cas IR et 62% des cas MDR. Cette tendance met en évidence le fait que même le programme de détection et de réponse le plus performant peut encore rendre les organisations vulnérables aux attaques.

Un autre indicateur préoccupant était la proportion de systèmes non protégés trouvés dans les organisations victimes d’une violation. Dans 40% des cas que nous avons investigués, il s’agissait de systèmes non protégés. Si l’on considère qu’il y avait également des VPN vulnérables (12%), des systèmes vulnérables (11%) et des systèmes en fin de vie (5%) dans certains de ces environnements (l’étude de cas de ce rapport, par exemple, présentait les trois), les attaquants pourraient se sentir tout-puissant tel un renard dans un poulailler.

Certains pourraient se demander pourquoi nous voyons encore des cas de ransomware dans un service MDR. L’une des principales raisons est liée aux systèmes non protégés et à leur relation avec les ransomwares distants. Toute l’activité malveillante (intrusion, exécution de la charge virale et chiffrement) se produit sur la machine non gérée permettant ainsi de contourner les outils de sécurité de l’entreprise. Seul le transfert de documents vers et depuis d’autres machines indique que le système a été compromis. Notre télémétrie indique qu’il y a eu une augmentation de 141% d’une année sur l’autre des attaques intentionnelles débouchant sur un chiffrement à distance depuis 2022, comme le montre la figure 8 (nous avons déjà parlé des ransomwares distants et de la manière de les contrer, notamment en menant des analyses en profondeur {deep dive] via notre technologie CryptoGuard. À mesure que les chiffres augmentent, les ransomwares distants pourraient être un sujet majeur dans un prochain rapport Active Adversary).

Figure 8 : Selon les données de Sophos X-Ops, le nombre de ransomwares distants en 2024 représentait 141% de celui de 2022 ; notez l’augmentation surprenante des cas dans les données des 18 derniers mois.

Le manque de visibilité sur les fichiers circulant sur le réseau, et sur les logs manquants, contribue également aux statistiques d’exfiltration. En 2024, les analystes ont pu confirmer que l’exfiltration s’est produite dans 27% des cas. Si l’on inclut les preuves de staging des données et d’exfiltration possible, ce chiffre s’élève à 36%. Les victimes de ransomware ont vu leurs données exfiltrées dans 43% des incidents que nous avons investigués. 14% supplémentaires présentaient une possible exfiltration ou des preuves de staging des données. Contrairement aux attaques impliquant le paramètre time-to-AD, les détections d’exfiltration surviennent vers la fin d’une attaque. Il y avait un délai médian de 72,98 heures (3,04 jours) entre le début d’une attaque et l’exfiltration, mais seulement 2,7 heures (0,11 jour) entre l’exfiltration et l’attaque ont été détectées pour les cas de ransomware, d’exfiltration de données et d’extorsion de données.

Détecter le bruit

Ce rapport a traditionnellement examiné les impacts au niveau du framework MITRE (TA0040). Étant donné la prévalence des ransomwares dans les données, il n’est pas surprenant que, comme le montre la figure 9, Data Encrypted for Impact (T1486) soit en tête du classement, comme c’est le cas chaque année. Mais en regardant les autres impacts, nous voyons une opportunité pour les défenseurs : les causes de nombreux autres impacts sont des événements qui peuvent être détectés.

Figure 9 : Les catégories Impact de MITRE changent au fil du temps, mais le règne de ‘Data Encrypted for Impact’ en haut des classements Active Adversary est ininterrompu tout au long de nos cinq années d’historiques, notamment dans les cas IR et MDR de cette année (notez que les pourcentages totalisent plus de 100%, car certains cas ont des impacts multiples).

Par exemple, Inhibit System Recovery (T1490) est souvent invoqué parce que l’acteur malveillant a supprimé les clichés instantanés de volume. Des outils comme vssadmin.exe, l’outil de gestion des clichés instantanés (utilisé abusivement dans 10% des cas), ou la ligne de commande WMI (utilisée abusivement dans 24%) sont utilisés pour réaliser cette action. Vous pouvez également détecter quand vssadmin est utilisé pour créer des clichés instantanés, ce qui précède généralement les exfiltrations. De même, nous avons constaté que les attaquants supprimaient des fichiers dans 26% des cas. Dans ces circonstances, surveiller une utilisation inattendue de del.exe peut être le signe d’une action malveillante. L’ingénierie de détection peut repérer les événements suspects de ce genre, à savoir écouter le bruit que font les attaquants lorsqu’ils tentent de vous attaquer de manière sournoise.

Conclusion

Aux experts en sécurité à l’œuvre sur le terrain, sachez que nous vous voyons. Vous faites le travail et vous connaissez bien le métier. Vous avez conscience également des limites de ce que vous pouvez accomplir. La bonne nouvelle est que vous n’avez pas besoin d’attendre désespérément que les choses s’améliorent, surtout lorsque de l’aide est disponible.

Aux dirigeants d’entreprise et aux responsables techniques, donnez une chance à vos équipes. Nous savons que l’argent et les ressources sont limités. Cela signifie souvent surcharger votre personnel IT avec plus de travail et de responsabilités qu’il ne peut en gérer réellement. Même si cela peut paraître intéressé de la part d’une équipe de recherche rattachée à un éditeur de sécurité, nous pensons que les équipes informatiques doivent se concentrer sur la manière avec laquelle elles permettent à l’entreprise de fonctionner et laisser les experts faire le ‘sale boulot’ de lutte contre les attaquants. Car une chose ressort clairement des données : lorsque quelqu’un est attentif à l’environnement et qu’il est capable d’agir rapidement et de manière décisive, les résultats s’améliorent considérablement. L’alternative est de répéter les erreurs du passé, inlassablement. Le choix vous appartient : vous pouvez vous en sortir d’une manière ou d’une autre, mais nous pensons que vous y arriverez de toute façon, car c’est un passage obligé.

Remerciements

Les auteurs souhaitent remercier les équipes Sophos IR et MDR, Mark Loman, Chester Wisniewski et Matt Wixey pour leurs contributions au processus AAR.

Annexe : Démographie et méthodologie

Lors de la rédaction de ce rapport, nous avons choisi de nous concentrer sur 413 cas qui pouvaient être analysés de manière significative pour obtenir des informations utiles sur l’état du paysage des adversaires en 2024. La protection de la relation confidentielle entre Sophos et ses clients est bien sûr une priorité absolue, et les données que vous voyez ici ont été vérifiées à plusieurs étapes au cours de ce processus pour s’assurer qu’aucun client n’était identifiable via ces données, et qu’aucune donnée client ne faussait la synthèse de manière inappropriée. En cas de doute sur un cas spécifique, nous avons exclu les données de ce client du dataset.

Figure A1: Nous sommes présents globalement : il s’agit de Sophos Incident Response et Sophos MDR à l’œuvre dans le monde entier (carte générée avec l’aimable autorisation de 29travels.com).

Les 57 nations suivantes ainsi que d’autres zones sont représentées dans l’ensemble de données complet :

Secteurs d’activité

Les 32 secteurs suivants sont représentés dans l’ensemble de données complet :

Méthodologie

Les données de ce rapport ont été recueillies au cours d’investigations individuelles menées par les équipes Sophos X-Ops Incident Response et MDR. Pour ce rapport initial de 2025, nous avons recueilli des informations sur toutes les investigations menées par l’équipe en 2024 et les avons normalisées via 52 domaines, en examinant chaque cas pour nous assurer que les données disponibles étaient appropriées au niveau du détail et de la portée des éléments regroupés tels que définis par l’objectif principal du rapport proposé. Nous avons également travaillé à la normalisation des données entre nos processus de reporting MDR et IR.

Lorsque les données n’étaient pas claires ou n’étaient pas disponibles, l’auteur a travaillé avec des cas IR et MDR individuels pour éclaircir les questions ou dissiper la confusion. Les incidents qui n’ont pas pu être suffisamment clarifiés pour les besoins du rapport, ou à propos desquels nous avons conclu que l’intégration risquait d’exposer ou d’endommager la relation Sophos-client, ont été écartés. Nous avons ensuite examiné la chronologie de chaque cas restant pour obtenir plus de clarté sur des questions telles que l’accès initial, le temps de séjour, l’exfiltration, etc. Nous avons retenu 413 cas, qui ont servi de base pour ce rapport. Les données proposées dans l’ensemble de données téléchargeable ont été davantage expurgées pour garantir la confidentialité des clients.

Billet inspiré de It takes two: The 2025 Sophos Active Adversary Report, sur le Blog Sophos.