Red teaming crypto : Halborn attaque avant les pirates

Le 21 février 2025, la plus grande plateforme d’échange crypto de la région de Dubaï a perdu près de 1,5 milliard de dollars (environ 1,29 milliard d’euros) en l’espace d’une seule transaction. Les contrats intelligents du portefeuille multisignature de Bybit avaient été audités et ils ont fonctionné exactement comme prévu. Aucune clé privée n’a été forcée. Le FBI a pourtant attribué le vol au groupe nord-coréen TraderTraitor, une émanation du Lazarus Group : c’est, à ce jour, le plus gros casse de l’histoire de la crypto.

Comment dérober une telle somme sans casser une seule ligne de code ? En attaquant tout ce qui entoure le code. D’après la reconstitution de Chainalysis, les assaillants ont compromis l’environnement d’un développeur de Safe, la plateforme multisig utilisée par Bybit, puis injecté un JavaScript malveillant dans l’interface de signature. À l’écran, les signataires de Bybit voyaient une transaction anodine ; en réalité, ils validaient un transfert vers des adresses contrôlées par les pirates. Le multisig n’a pas été contourné, il a été trompé, par la couche humaine et par l’interface. Aucun audit de smart contract, aussi rigoureux soit-il, n’était pensé pour repérer cela.

C’est précisément ce constat qui a fait basculer une partie de l’industrie de la sécurité. Plutôt que de demander « mon code est-il correct ? », des firmes comme Halborn posent une autre question : « que se passe-t-il quand un attaquant réel, muni de véritables techniques, s’en prend à mes équipes, à mon infrastructure et à mon flux de signature ? ». Pour y répondre, elles ne relisent pas le code, elles attaquent. Cette discipline s’appelle la sécurité offensive, et sa forme la plus aboutie est l’exercice de red teaming. Les régulateurs européens, DORA en tête, viennent d’en faire une obligation.

La sécurité offensive, définie

La sécurité informatique classique est défensive et réactive : on empile des pare-feu, on applique des correctifs, on surveille des journaux, et l’on attend l’attaque pour la bloquer. La sécurité offensive renverse ce réflexe. Halborn la décrit dans son propre manifeste comme « un cadre de gestion de la sécurité qui prône l’usage de techniques proactives (ou offensives) pour cibler les cybercriminels et neutraliser activement leurs attaques ». En clair : pour savoir si vous êtes protégé, il faut vous faire attaquer, dans des conditions contrôlées, par des gens dont c’est le métier.

Halborn résume la philosophie par ce qu’elle appelle les « trois A » : Annoyance (gêner l’attaquant en semant de faux actifs et des leurres pour lui faire gaspiller ses ressources), Attribution (l’identifier et remonter à son infrastructure), et Attack (contre-attaquer, réservé aux cas extrêmes). Le red teaming applique cet état d’esprit à vos propres systèmes : on recrute une équipe pour jouer l’adversaire, avec les mêmes outils et la même patience qu’un groupe comme Lazarus, mais avec un contrat, un périmètre et un objectif de progrès plutôt que de vol.

La crypto est un terrain idéal pour cette approche, parce que sa surface d’attaque déborde largement du smart contract. Une entreprise Web3 typique combine des contrats on-chain, des portefeuilles chauds et froids, des clés multisignatures, une infrastructure cloud, des pipelines de déploiement, des bots Discord, une équipe souvent entièrement distante et des transactions irréversibles se chiffrant en millions. Chacun de ces éléments est une porte. L’audit de code n’en inspecte qu’une seule.

Halborn : une firme conçue pour attaquer

Fondée en 2019 à Miami par Steven Walbroehl et Rob Behnke, Halborn a passé ses trois premières années en autofinancement avant de lever 90 millions de dollars (environ 77 millions d’euros) en série A menée par Summit Partners à l’été 2022, avec Castle Island, Digital Currency Group et Brevan Howard au tour de table. Contrairement à ses concurrents nés autour de la vérification formelle ou de la relecture de code, l’ADN de Halborn est offensif : red team, pentest et réponse à incident. Son directeur technique, Walbroehl, est l’auteur du cours SANS SEC554 consacré à la sécurité des blockchains et affiche plus de quinze ans de tests d’intrusion et de hacking éthique.

En septembre 2024, Jacques Boschung, venu de Kudelski Security, a pris la direction générale, Behnke devenant président et président exécutif ; Walbroehl reste cofondateur et directeur technique. Ce changement accompagne un virage vers les banques et les acteurs institutionnels de la tokenisation, mais le socle reste l’attaque simulée. La page de services de Halborn distingue deux familles : le conseil (revue d’architecture, préparation à la conformité, évaluation de la garde et de la gestion des clés) et l’assurance technique, où figurent l’exercice red team, le test d’intrusion applicatif et cloud, l’évaluation de smart contracts et une nouveauté, le red teaming d’intelligence artificielle. Halborn revendique avoir travaillé pour Coinbase, Polygon et la Solana Foundation. À l’offensive proactive répond d’ailleurs un versant réactif : la firme s’est fait connaître du grand public par ses autopsies détaillées des grands hacks, publiées sous la bannière « Explained », qui disséquent au fil de l’eau chaque incident majeur du secteur.

Audit, pentest, red team : trois promesses différentes

On confond souvent ces trois exercices, mais ils répondent à des questions distinctes et n’offrent pas les mêmes garanties. L’audit de smart contract demande « le code fait-il ce qu’il est censé faire, sans faille connue ? ». Le test d’intrusion demande « puis-je entrer par une porte technique précise et jusqu’où ? ». Le red teaming demande « un adversaire déterminé peut-il atteindre son objectif, par n’importe quel moyen, sans que l’équipe de défense ne s’en aperçoive ? ». Cette dernière question est la plus proche de la réalité d’un vrai casse.

La différence de périmètre est décisive. Un audit est borné à un dépôt de code à une date donnée ; un pentest à un système ou une application ; un red team n’a, lui, presque pas de bornes, sinon celles fixées par le contrat. Il peut hameçonner un employé, cloner un badge, exploiter une clé exposée sur GitHub, pivoter du cloud vers le portefeuille chaud, et il se juge non pas au nombre de bugs trouvés mais à sa capacité à atteindre la « joyau de la couronne » sans déclencher l’alarme. C’est la seule des trois épreuves qui teste aussi vos humains et votre capacité de détection.

Rouge, bleu, violet : la palette des équipes

Le vocabulaire du red teaming vient de la simulation militaire et se décline en couleurs. L’équipe rouge attaque : elle joue l’adversaire et cherche à atteindre l’objectif. L’équipe bleue défend : ce sont vos opérations de sécurité, votre centre de surveillance, vos analystes qui doivent détecter, contenir et répondre. Le red teaming n’a de valeur que confronté à une équipe bleue, car ce qu’il mesure, ce n’est pas seulement « peut-on entrer ? », mais « combien de temps avant que quelqu’un ne le remarque ? ».

L’équipe violette est plus récente et souvent la plus utile pour une jeune entreprise crypto. Plutôt qu’un affrontement fermé, rouges et bleus collaborent en temps réel : l’attaquant explique chaque mouvement, le défenseur ajuste ses détections dans la foulée, et l’on transforme chaque brèche en règle de surveillance. On croise aussi l’équipe jaune (les développeurs et les constructeurs) dans les modèles dits « BAD » (build, attack, defend). Pour une équipe qui déploie des contrats irréversibles, l’exercice violet a un avantage pédagogique : il ne se contente pas de dresser une liste de failles, il renforce la capacité maison à voir venir la prochaine.

« Assume breach » : la philosophie du red teaming

Le principe directeur du red teaming moderne tient en deux mots : « assume breach », partez du principe que l’attaquant est déjà à l’intérieur. Cette hypothèse change tout. Au lieu de concentrer toute l’énergie sur le périmètre extérieur, on suppose qu’un poste a déjà été compromis, qu’une clé a fuité, qu’un développeur a cliqué sur le mauvais lien, et l’on mesure les dégâts que l’adversaire peut alors infliger. Combien de temps met-il à passer d’un ordinateur portable infecté au portefeuille chaud ? Peut-il atteindre les clés de signature ? Quelqu’un l’arrête-t-il ?

Pour rester fidèle au réel, les équipes rouges calquent leurs opérations sur les tactiques, techniques et procédures des vrais groupes, cataloguées dans des référentiels comme MITRE ATT&CK. Un engagement inspiré de Lazarus commencera ainsi par une fausse offre d’emploi et un document piégé, exactement le vecteur utilisé contre Ronin en 2022 puis raffiné contre Bybit. L’objectif n’est pas de collectionner des vulnérabilités théoriques, mais de rejouer la chaîne complète d’une attaque plausible, du premier hameçon jusqu’à l’exfiltration des fonds, pour révéler où la chaîne aurait dû casser et ne l’a pas fait.

L’asymétrie attaquant-défenseur

Derrière la sécurité offensive se cache une vérité inconfortable : le défenseur et l’attaquant ne jouent pas la même partie. Le défenseur doit avoir raison partout, tout le temps ; l’attaquant n’a besoin de gagner qu’une seule fois. Un protocole peut protéger parfaitement quatre-vingt-dix-neuf de ses cent portes, il suffit d’une seule mal fermée pour tout perdre. Cette asymétrie explique pourquoi la relecture passive du code ne suffit jamais : elle confirme que les portes connues sont solides, elle ne cherche pas la centième porte que personne n’a pensé à dessiner.

Le red teaming existe précisément pour rétablir l’équilibre. En s’offrant les services d’un attaquant, une équipe s’achète le luxe rare de trouver sa porte oubliée avant qu’un groupe malveillant ne le fasse. C’est aussi la logique du « Zero Trust » devenue standard dans la finance : ne jamais présumer qu’un accès interne est légitime, vérifier chaque requête, cloisonner les privilèges, pour qu’une seule compromission ne se propage pas à tout le système. Seul un exercice offensif permet de vérifier que ce cloisonnement tient vraiment sous la pression d’un adversaire patient, et pas seulement sur le papier d’une politique de sécurité. La question n’est jamais « sommes-nous attaquables ? », tout l’est, mais « jusqu’où l’attaque irait-elle avant de buter sur un mur ? ».

Anatomie d’un engagement red team

Un exercice sérieux suit une séquence reconnaissable, souvent appelée « cyber kill chain », qui reproduit le cheminement d’un attaquant réel. La différence tient au filet de sécurité : chaque étape est encadrée par un contrat, un canal de communication d’urgence avec un petit cercle de responsables (le « white team ») et une règle d’arrêt immédiat si l’exercice menace la production.

1. Renseignement sur la menace : profiler les adversaires réalistes de la cible et leurs méthodes, à partir de renseignement sur mesure.
2. Reconnaissance : cartographier l’entreprise, ses employés (LinkedIn, GitHub, Discord), ses domaines, son cloud et ses dépôts.
3. Accès initial : hameçonnage ciblé, clé exposée, dépendance logicielle piégée ou faille applicative pour poser le premier pied.
4. Élévation et latéralisation : gagner des privilèges, se déplacer de machine en machine vers les systèmes de signature ou de trésorerie.
5. Objectif : atteindre la « joyau de la couronne », un accès de signature multisig, une clé de déploiement, une console d’administration, sans jamais déplacer de vrais fonds.
6. Exfiltration et persistance simulées : démontrer qu’on pourrait rester et voler, puis documenter le chemin exact.
7. Rapport et rejeu : restituer le récit complet à l’équipe bleue, transformer chaque étape en détection et rejouer pour vérifier les corrections.

Le livrable qui compte n’est pas la liste des failles mais le récit : « voici comment, en dix-sept jours, nous serions passés d’un courriel à vos clés, et voici les quatre moments où vous auriez pu nous stopper ». C’est cette narration qui distingue un red team d’un scan automatisé.

Rien de tout cela ne s’improvise. Avant le premier courriel piégé, les deux parties signent des règles d’engagement qui fixent les cibles autorisées, les techniques interdites, les fenêtres horaires et une procédure dite de deconfliction : si l’équipe bleue repère l’attaque et la prend pour un vrai incident, un appel au white team confirme en quelques minutes qu’il s’agit de l’exercice. Cette discipline est ce qui sépare un red team professionnel d’un accès illégal ; c’est elle qui rend l’attaque à la fois réaliste et parfaitement légale.

Rab13s : quand Halborn a attaqué 280 réseaux avant les pirates

La signature offensive de Halborn porte un nom : Rab13s. En mars 2022, un ingénieur offensif de la firme, Hossam Mohamed, audite le code de Dogecoin et y découvre une famille de vulnérabilités qui, en réalité, affecte plus de 280 réseaux dérivés du même socle, dont Litecoin et Zcash. Selon Cointelegraph, ce sont plus de 25 milliards de dollars (environ 21,5 milliards d’euros) d’actifs qui étaient exposés. Trois failles au total : deux dénis de service et, surtout, une exécution de code à distance permettant de faire planter un nœud avec un message de consensus forgé, un chemin possible vers une attaque à 51 %.

Halborn a mené une divulgation coordonnée : les projets majeurs ont été prévenus et corrigés avant l’annonce publique de mars 2023, décrite dans les disclosures officiels de la firme. Beaucoup de forks plus petits, eux, n’ont jamais appliqué le correctif. Rab13s illustre exactement ce qu’apporte un état d’esprit offensif : ce n’est pas en vérifiant que Dogecoin faisait « ce qu’il était censé faire » qu’on trouve ce genre de faille, c’est en cherchant activement à le casser, comme le ferait un attaquant.

La couche humaine : l’ingénierie sociale dopée à l’IA

Si un red team crypto sur deux commence par un humain, c’est parce que les pirates font pareil. Le vecteur Ronin et le vecteur Bybit reposaient tous deux sur la manipulation de personnes, pas sur une faille arithmétique. Or ce front se durcit avec l’intelligence artificielle. Steven Walbroehl, cofondateur et directeur technique de Halborn, prévient dans Cointelegraph que « l’ingénierie sociale dopée à l’IA jouera un rôle majeur dans le manuel des pirates crypto », les attaquants s’appuyant sur l’IA pour lancer « des attaques hautement personnalisées et contextuelles qui contournent la sensibilisation classique à la sécurité ».

Concrètement, cela veut dire des courriels de spearphishing parfaitement rédigés, des voix clonées, des visioconférences deepfake où un faux directeur financier ordonne un virement. Un red team répond à cette menace en la rejouant : appels prétextes, faux recruteurs, campagnes d’hameçonnage sur mesure, pour mesurer non pas si un employé peut cliquer (il le fera toujours), mais si les contrôles en aval, la double validation, la ségrégation des clés, la détection d’anomalie, tiennent malgré tout. La leçon vaut aussi pour les particuliers : la compromission matérielle reste un angle mort, comme l’a montré le hack visant le générateur d’entropie de Coldcard, preuve qu’attaquer le maillon humain et matériel est souvent plus rentable que d’attaquer le code.

AI red teaming : la nouvelle frontière

La sécurité offensive suit ses cibles, et les cibles intègrent désormais des modèles d’IA. Halborn a ouvert une ligne dédiée, l’AI Red Teaming, décrite comme un « test adverse contre les menaces réelles pesant sur l’IA ». L’enjeu est nouveau : quand un agent autonome dispose d’un accès à un portefeuille ou à une console d’administration, il devient une sorte de nouveau détenteur de clés, sauf que sa logique de décision peut être manipulée par de simples entrées.

Ronghui Gu, cofondateur de CertiK, résume le danger dans Forbes : « un agent d’IA disposant d’un accès à un portefeuille est essentiellement un nouveau type de détenteur de clés privilégié, sauf que sa prise de décision peut être manipulée par des entrées, d’une façon qu’un humain pourrait détecter et qu’un agent mal encadré ne détectera pas ». Le red teaming d’IA consiste à injecter des prompts hostiles, à empoisonner des données, à détourner un agent de sa mission, avant que quelqu’un d’autre ne le fasse en production. C’est la même logique offensive, appliquée à une surface qui n’existait pas il y a deux ans. Les référentiels suivent le mouvement : l’OWASP tient désormais un Top 10 des risques propres aux grands modèles de langage, où l’injection de prompt occupe la première place, et c’est exactement ce type de faille qu’un exercice offensif cherche à déclencher en conditions contrôlées avant un attaquant réel.

DORA impose le red teaming : le TLPT

Jusqu’ici, se faire attaquer volontairement relevait de la bonne pratique. Depuis le règlement européen DORA (Digital Operational Resilience Act), entré en application le 17 janvier 2025, c’est en passe de devenir une obligation légale pour les acteurs financiers, prestataires de services sur crypto-actifs (PSCA) inclus. Ses articles 26 et 27 introduisent le TLPT, pour « threat-led penetration testing », soit un test d’intrusion piloté par le renseignement sur la menace, très proche d’un red team d’intelligence.

Le texte de l’article 26 est exigeant : le test doit porter sur des systèmes de production en conditions réelles, couvrir plusieurs fonctions critiques et se répéter au moins tous les trois ans pour les entités désignées. L’article 27 impose des testeurs hautement qualifiés et réputés, internes ou externes. Selon le cabinet financialregulations.eu, environ 8 447 entités financières de l’Union sont concernées et devront avoir mené leur premier TLPT avant le 17 janvier 2028. Autrement dit, le red teaming quitte le domaine du luxe volontaire pour entrer dans celui de la conformité.

La nuance compte : un TLPT n’est pas un test d’intrusion de plus, coché dans une case de conformité. Il se déroule à l’insu de l’équipe de défense, sur des systèmes vivants, à partir d’un scénario de menace crédible bâti par des analystes de renseignement, puis se solde par une phase de remédiation et de rejeu. C’est un red team d’intelligence encadré par le régulateur, avec des exigences précises sur la qualification des testeurs, la maîtrise des risques pendant l’exercice et la restitution finale. Pour beaucoup d’acteurs, la difficulté ne sera pas de « réussir » le test, mais d’avoir la maturité opérationnelle nécessaire pour le subir sans interrompre la production.

TIBER-FR : quand la Banque de France coordonne l’attaque

DORA ne réinvente pas la roue : son TLPT s’appuie sur un cadre européen préexistant, TIBER-EU (Threat Intelligence-based Ethical Red Teaming), conçu par la Banque centrale européenne. Chaque pays en décline sa version nationale, et la France a la sienne : TIBER-FR. Elle est pilotée conjointement par la Banque de France et l’Autorité de contrôle prudentiel et de résolution (ACPR), qui ont publié en mars 2025 un guide national d’implémentation détaillant comment mener un test TIBER-FR et un TLPT au sens de DORA.

Le principe est frappant pour qui découvre la matière : ici, c’est le régulateur lui-même qui organise l’attaque de vos systèmes. Une équipe de renseignement produit un profil de menace sur mesure, une équipe rouge mène une attaque contrôlée sur vos systèmes de production réels, et une cellule dédiée au sein de la banque centrale (le TIBER Cyber Team) coordonne l’ensemble. Détail essentiel : le test n’aboutit ni à un « réussi » ni à un « échoué ». Il n’existe pas de note. L’objectif affiché est de révéler forces et faiblesses pour hausser la maturité cyber de l’entité, exactement la promesse d’un red team privé, mais adossée à l’autorité prudentielle. Pour un PSCA français cherchant son agrément, se faire « red-teamer » n’est donc plus un simple gage de sérieux commercial, c’est un horizon réglementaire.

Le basculement est net. Jusqu’à récemment, participer à un test TIBER relevait du volontariat : quelques établissements s’y prêtaient pour éprouver leurs défenses, sans y être contraints. Avec DORA, l’exercice devient obligatoire pour les entités les plus significatives, et son périmètre déborde largement les banques traditionnelles, vers les infrastructures de marché et, à terme, les prestataires crypto d’une certaine taille. Le red teaming cesse d’être une curiosité de spécialistes pour devenir une brique attendue de la résilience opérationnelle, au même titre qu’un plan de continuité d’activité.

Le hack le plus cher n’est jamais dans le code

Pourquoi tout ce dispositif offensif, plutôt qu’un audit de plus ? Parce que les chiffres racontent une histoire sans ambiguïté. Selon le rapport semestriel de TRM Labs pour le premier semestre 2026, les exploits de smart contracts représentent la majorité des incidents en nombre, mais la compromission d’infrastructure, de clés et d’opérations ne pèse qu’environ 15 % des incidents pour près de 76 % de la valeur volée. Traduction : l’audit couvre le vecteur le plus fréquent, pas le plus coûteux. Sur les quelque 972 millions de dollars (environ 835 millions d’euros) dérobés au premier semestre, la Corée du Nord en concentre à elle seule près des deux tiers.

Le tableau ci-dessous rassemble trois casses parmi les plus lourds des derniers mois. Dans aucun l’attaque ne visait d’abord une faille de logique dans un contrat correctement écrit ; toutes passaient par les humains, l’infrastructure ou une erreur de configuration, précisément ce qu’un red team cherche à provoquer avant les pirates.

Le cas de Kelp DAO est parlant : 116 500 rsETH volés via une infrastructure RPC compromise, sans faille de contrat, une perte dont la contagion a ensuite ébranlé les marchés du crédit on-chain comme Aave et Morpho lorsque les actifs restés collatéralisés ailleurs ont dû être dénoués. Même les attaques purement économiques, comme les stratégies MEV, échappent au périmètre d’un audit classique. Le red team, lui, modélise cette surface élargie.

Ce que le red teaming ne remplace pas

Il serait faux d’opposer red team et audit : ils se complètent. Un red team ne relira pas ligne à ligne un contrat de 3 000 lignes à la recherche d’un dépassement d’entier, et le cas Balancer rappelle qu’une faille d’arrondi enfouie peut survivre à plus de dix audits. La bonne posture est une défense en couches, où l’audit de code, le fuzzing, la vérification formelle, le pentest et le red team se recouvrent partiellement. Encore faut-il savoir lire ce qu’ils produisent : un badge « audité par X » ne vaut rien sans lecture du périmètre réel, comme nous l’avons détaillé à propos des rapports d’audit de Trail of Bits.

Reste la question du prix et de la responsabilité. Un exercice red team complet se situe généralement dans une fourchette haute, de plusieurs dizaines à plusieurs centaines de milliers d’euros, réservée aux protocoles, aux plateformes et aux acteurs institutionnels qui gardent des fonds ou visent un agrément. Pour tous les autres, l’audit ciblé et le bug bounty restent le socle. Et lorsque le pire survient, la vraie question devient celle de l’indemnisation, un terrain que nous avons cartographié dans notre analyse sur qui rembourse vraiment après un hack.

Le red teaming a d’ailleurs un prérequis souvent passé sous silence : il faut déjà avoir une défense à tester. Lancer une équipe rouge contre une organisation sans surveillance, sans journalisation et sans personne pour réagir, revient à payer très cher pour s’entendre dire ce qu’un audit de base aurait révélé. La séquence saine commence par les fondamentaux (gestion des clés, séparation des environnements, surveillance), passe par l’audit et le bug bounty, et ne culmine dans un exercice offensif complet que lorsqu’il reste vraiment quelque chose à mettre à l’épreuve. Attaquer trop tôt, c’est gaspiller ; attaquer trop tard, c’est laisser le vrai adversaire ouvrir le bal.

C’est là que le contraste réglementaire français devient éclairant. Un commissaire aux comptes engage sa responsabilité civile et pénale, sous la supervision de la Haute Autorité de l’audit (H2A) depuis le 1er janvier 2024. Aucun régime équivalent n’existe pour les auditeurs de smart contracts : personne ne les accrédite, ni MiCA ni DORA n’imposent d’audit de code, et un protocole pleinement décentralisé sort même du champ de MiCA. Du côté des prestataires, la période transitoire française du régime PSAN vers l’agrément MiCA s’est achevée le 1er juillet 2026, l’AMF rappelant qu’exercer sans agrément est désormais un délit. Dans ce vide d’accréditation, la meilleure garantie qu’une équipe puisse offrir n’est pas un tampon, c’est la preuve qu’elle s’est fait attaquer, et qu’elle a tenu.

Foire aux questions

Quelle est la différence entre un audit et un red team ?

Un audit vérifie qu’un code fait ce qu’il est censé faire, sur un périmètre figé et connu du testeur. Un red team simule un adversaire réel qui vise un objectif (voler des fonds, atteindre les clés) par n’importe quel moyen : technique, humain ou physique. L’audit teste le code ; le red team teste toute l’organisation, y compris ses employés et sa capacité à détecter une intrusion.

Qu’est-ce que la sécurité offensive ?

C’est une approche proactive qui, au lieu d’attendre l’attaque derrière des pare-feu et des correctifs, emploie les techniques des attaquants pour tester ses propres défenses. Halborn la définit comme un cadre visant à « neutraliser activement » les attaques, notamment via le red teaming et le test d’intrusion, plutôt que de se contenter d’une posture défensive.

Le red teaming est-il obligatoire en Europe ?

Pour de nombreuses entités financières, oui, sous une forme précise. Le règlement DORA (articles 26 et 27) impose un test d’intrusion piloté par la menace (TLPT) au moins tous les trois ans aux entités désignées, sur leurs systèmes de production. En France, ces tests s’appuient sur le cadre TIBER-FR de la Banque de France et de l’ACPR ; le premier TLPT doit être mené avant le 17 janvier 2028.

Pourquoi un projet audité se fait-il quand même pirater ?

Parce que l’audit couvre le code, pas le reste. D’après TRM Labs, la compromission de clés, d’infrastructure et d’opérations ne représente qu’environ 15 % des incidents au premier semestre 2026 mais près de 76 % de la valeur volée. Bybit et Kelp DAO, deux des plus gros casses récents, sont passés par les humains et l’infrastructure, pas par une faille de contrat.

Qui est Halborn et pourquoi la citer sur le red teaming ?

Halborn est une firme de sécurité blockchain fondée en 2019 à Miami, connue pour son ADN offensif (red team, pentest, réponse à incident) plutôt que pour la seule relecture de code. Elle a levé 90 millions de dollars en 2022, compte Coinbase, Polygon et Solana parmi ses références, et a révélé la faille Rab13s touchant plus de 280 réseaux, un exemple typique de sécurité offensive appliquée avant les pirates.

Par Julien Mercier, rédacteur sécurité chez HOGE Wire.