Mise à jour du 1er septembre 2026 : ajout d'un quatrième cas suite aux inculpations prononcées en août 2026 à l'encontre de deux opérateurs présumés de TeamPCP, ainsi qu'une conclusion sur ce que ces défaillances apportent ou non aux défenseurs.
--
Un groupe d'auteurs de ransomware a lancé un programme d'affiliation doté de ses propres systèmes de gestion accessibles depuis Internet. Un groupe affirmant avoir mis la main sur des données piratées avait en réalité fouillé dans un « honeypot ». Un développeur travaillant pour les services de cyberopérations d'un État avait installé un logiciel de vol d'informations courant sur sa propre machine.
cybercriminels Ils investissent dans l'outillage, les infrastructures et les systèmes de contournement, tout en s'efforçant de donner une image de rigueur. Le rapport ci-dessous suggère que ces investissements sont inégaux.
Voici quatre failles avérées en matière d'OPSEC. Les trois premières ont été signalées par des chercheurs en décembre 2025, la quatrième en août 2026. Je les ai classées en fonction de l'élément qui a failli : processus, comportement, isolation technique et identité.
Devman : Échecs procéduraux de l'OPSEC dans les opérations de ransomware
Dans un article précédent, j'ai abordé les détails techniques du ransomware Devman, notamment son fonctionnement et les éléments qu'il réutilisait à partir du code de ransomware existant.
Après le lancement, Devman a fait l'objet de critiques publiques sur X pour ce que les chercheurs ont qualifié de « mauvaise sécurité opérationnelle (OPSEC) ». L'article de Ctrl Alt Intel a révélé qu'un groupe avait exposé sa propre infrastructure lors du déploiement d'une offre de ransomware en tant que service.
Les problèmes signalés :
- Infrastructure interne exposée lors du lancement : les systèmes utilisés pour gérer l'opération, y compris les services internes, étaient accessibles depuis Internet.
- Les systèmes de gestion et de communication étaient peu protégés, ce qui a permis aux chercheurs d'observer comment certains aspects de l'opération étaient coordonnés.
- Réutilisation d'outillage sans durcissement : l'opération a été menée sur des composants existants qui n'avaient pas été testés du point de vue de la sécurité opérationnelle (OPSEC).
Le lancement a été mis en ligne avant que tout cela n'ait été résolu. Pour un groupe recrutant des affiliés, cela s'est traduit par une réputation publique d'entreprise manquant de maturité.
Lapsu$ dispersés Hunters: défaillances comportementales en matière d'OPSEC lors de la vérification des cibles
Acteurs associés à SLSH ont publiquement dénoncé une faille de sécurité chez une entreprise spécialisée dans la cybersécurité, publié des captures d'écran et affirmé que des données sensibles avaient été volées.
Les rapports de suivi ont permis d'établir que les systèmes auxquels ils avaient accédé n'étaient pas des systèmes de production. Ceux-ci contenaient des données synthétiques, une technique de leurre décrite ici par Resecurity, conçue pour résister à un examen superficiel.
Les échecs :
- Aucune validation de l'environnement cible : les systèmes accessibles ont été considérés comme réels, sans vérifier s'ils étaient isolés ou surveillés.
- Les données synthétiques ont été acceptées comme preuve d'une intrusion, car elles semblaient authentiques.
- Les tentatives répétées de scraping et d'accès ont provoqué des défaillances du proxy, entraînant la divulgation d'informations techniques utiles au suivi.
Cette affirmation a été rendue publique avant d'être confirmée, et la crédibilité du groupe s'est effondr ée lorsqu'elle a été démentie.
Opérateur nord-coréen : défaillances techniques en matière de sécurité opérationnelle (OPSEC) dans l'isolation du système
Un ordinateur utilisé par un développeur impliqué dans des cyberopérations nord-coréennes était lui-même infecté par LummaC2, un « malware » courant destiné au vol d’informations. L’analyse des journaux a permis de mettre au jour des identifiants et des outils sur cet appareil, et les enquêteurs l’ont relié à une infrastructure associée au vol de cryptomonnaies sur Bybit, attribué à des acteurs nord-coréens, notamment le groupe Lazarus. Le présent rapport constitue une information secondaire et non un avis de sécurité primaire ; il convient donc de traiter ces détails avec la prudence qui s’impose.
Les défaillances signalées :
- Manque d'hygiène en matière d'endpoint : un système contrôlé par un pirate a été compromis par un logiciel de vol d'informations de type « commodity ».
- Pas d'isolation : les outils, les domaines d'phishing s et les ressources opérationnelles se trouvaient sur une seule machine, et les identifiants qui y étaient stockés étaient liés à une infrastructure malveillante connue.
- Anonymisation incomplète : l'utilisation d'un VPN n'a pas masqué la configuration du navigateur, les paramètres linguistiques ni les habitudes d'utilisation.
En mai 2025, les développeurs à l'origine de l'malware DanaBot ont accidentellement infecté leurs propres machines, et les enquêteurs ont par la suite utilisé les identifiants récupérés.
Ces deux cas montrent comment les pirates peuvent être victimes des mêmes menaces qu'ils déploient.
TeamPCP : identification des failles de sécurité opérationnelle (OPSEC) dans la gestion des identités
Les versions corrompues de Trivy et LiteLLM dont j’ai parlé en juillet sont attribuées à TeamPCP, selon l’alerte FLASH publiée par le FBI le 2 juillet. Le 27 août 2026, la Police fédérale australienne (AFP) a mis en examen deux hommes d’Australie-Occidentale à la suite d’une opération conjointe menée par l’AFP, le FBI et la police d’Australie-Occidentale. Ces accusations constituent des allégations et n’ont pas encore été examinées par un tribunal.
L'équipe « Emerging Threats » de Flare a publié le même jour un guide pratique sur la désanonymisation, tandis que Brian Krebs a rendu compte séparément des accusations. C'est le point de départ qui est utile, pas le résultat.
Flare a commencé par un simple pseudonyme utilisé lors d'opérations antérieures de TeamPCP, suffisamment caractéristique pour faire l'objet d'une recherche directe. Cela a permis de remonter à un profil de programme de récompense de bogues associé à un vrai nom, ainsi qu’à un profil au sein d’une communauté d’apprentissage automatique qui mentionnait publiquement un domaine utilisé par la suite comme infrastructure de commande et de contrôle pour le mini-Shai-Hulud worm. À partir de là, la piste a suivi des identifiants divulgués : une adresse e-mail scolaire, un mot de passe exposé dans une base de données publique, puis un compte e-mail personnel récupéré en exploitant ce mot de passe. L’un des comptes associés à ce profil arborait la même photo que celle figurant en tête de la chaîne Telegram du groupe.
Les échecs :
- Un pseudonyme caractéristique utilisé à la fois sur les comptes professionnels et personnels, apparaissant aussi bien dans les outils TeamPCP que dans un profil associé à un nom réel.
- Infrastructure opérationnelle mentionnée dans un profil personnel : selon Flare, un domaine C2 utilisé lors de la campagne « worm » de mai 2026 était accessible au public sur un compte personnel.
- Réutilisation des mots de passe : un identifiant figurant dans une base de données publique a permis de relier une adresse e-mail scolaire à un compte personnel, et ce compte à tous les services associés à celui-ci.
Tout cela n'a rien de technique. La recommandation de Flare à l'intention des défenseurs est claire : surveillez vos domaines dans les journaux des logiciels de vol d'identifiants et les listes de combinaisons. L'exposition des identifiants qui a permis aux chercheurs d'accéder à une identité réelle relève de la même catégorie d'exposition que celle qui a conduit 2 500 organisations à figurer dans les archives de TeamPCP.
TeamPCP s'est également fait remarquer de manière délibérée: canaux Telegram, compte X supprimé depuis, railleries à l'encontre des victimes et publication du code source d'worm sous licence MIT accompagnée d'une blague. Le groupe a également accordé une interview à Forbes, se décrivant comme « un groupe informel d'adolescents et de jeunes adultes qui, ne trouvant pas d'emploi rémunéré, se sont tournés vers la cybercriminalité ». Chacun de ces éléments constituait un point de départ pour l'enquête.
Ce que ces échecs apportent en réalité aux défenseurs
Ctrl Alt Intel a documenté les systèmes de gestion de Devman en analysant son infrastructure depuis l'extérieur. Le logiciel de vol d'informations présent sur la machine de l'opérateur nord-coréen a été mis au jour lors de l'analyse des journaux d'une autre personne. La chaîne d'attaques de Flare a débuté à partir d'un pseudonyme public et s'est déroulée sur des données publiques. Dans ces quatre cas , l'erreur a été rendue publique à la suite de recherches menées a posteriori , et non grâce à des éléments détectés par les propres systèmes de surveillance des victimes.
Cette distinction est importante, compte tenu de la manière dont se présente le cas de figure habituel :
- Un pirate utilisant des outils d'administration natifs et des binaires signés ne laisse aucune « malware » à analyser : tout semble normal.
- Une personne présentant des identifiants valides et un jeton valide génère une entrée valide dans le journal de connexion : l'authentification aboutit.
- Le croisement des plans « sur site », « identité » et « cloud » fait qu'aucun système ne dispose d'une vue d'ensemble : les mouvements ne sont pas visibles.
Il s'agit les trois failles dont je parle, et aucune des quatre défaillances mentionnées ci-dessus n’a eu d’incidence sur l’une d’entre elles pendant que les attaques étaient en cours.
Le tableau de bord de Devman a permis aux chercheurs de dresser le profil d'une opération, et non à une victime de repérer une intrusion. La démonstration de Flare a abouti à une attribution, et non à une alerte. Ces erreurs servent à l'attribution, aux poursuites judiciaires et à la communication publique, trois aspects qui ont tous leur importance, mais dont aucun ne relève de la détection. La détection doit partir du principe qu'aucune erreur n'a été commise.
Ce que ces échecs mettent en évidence, c’est le type de signal qu’il convient de surveiller. Dans chaque cas, l’indice était comportemental plutôt que statique : la manière dont l’acteur s’est comporté après avoir obtenu l’accès, l’infrastructure qui a été réutilisée et l’endroit où l’isolation a été contournée. Les environnements de simulation de tromperie, les données synthétiques et la surveillance basée sur le comportement n’empêchent pas les attaques. Ils mettent en évidence les comportements lorsque une hypothèse s’avère erronée.
Les pirates informatiques ont également recours à des outils basés sur l’IA, qui accélèrent les phases de reconnaissance, de ciblage et d’exploitation sans pour autant écarter le jugement humain du processus. Cela engendre des risques spécifiques : une confiance excessive dans les résultats automatisés et la généralisation d’une hypothèse erronée avant même que l’on se rende compte de son caractère fallacieux.
Les chapitres consacrés aux failles dans Mind Your Attack Gaps expliquent comment se déroule la détection lorsque l'attaquant réussit son attaque, ce qui est le scénario pour lequel il convient de se préparer. Chez Vectra AI , nous modélisons le comportement en fonction des accès au niveau de l'identité, de l'cloud et du réseau, car ce signal subsiste lorsque l'attaquant ne commet aucune erreur.
La technologie évolue. Les gens, non.