Sur une récente investigation CTI, nous avons travaillé sur une campagne sophistiquée visant des développeurs blockchain à travers un faux processus de recrutement. Le scénario était crédible : une fausse entreprise, un dépôt GitHub soigneusement préparé, un projet qui semblait légitime, puis plusieurs mécanismes de compromission dissimulés dans l’environnement de développement. À l’ouverture du dossier dans VSCode, une tâche malveillante pouvait s’exécuter automatiquement. En parallèle, une dépendance npm piégée introduisait un second vecteur d’infection. Derrière cette façade, l’analyse a révélé une chaîne de staging multi-étapes, des JWT éphémères, un filtrage comportemental côté C2 et une infrastructure pensée pour résister à l’investigation.
C’est précisément sur ce type de dossier que l’usage d’un LLM devient intéressant. Non pas parce qu’il “fait l’enquête à la place” de l’analyste, mais parce qu’il permet d’absorber beaucoup plus vite une masse importante de matière technique, et notamment dans l’analyse statique de code. Ainsi, le modèle a permis d’examiner rapidement un dépôt GitHub volumineux, affichant 574 commits, et d’isoler en l’espace de 40 minutes quatre artefacts malveillants dissimulés dans des fichiers de configuration et de dépendances : tasks.json, settings.json, package.json et config.env.example.
Le LLM a ensuite analysé ces codes et produit, en un peu plus d’une heure, une cartographie complète de la chaîne d’attaque: identification des trois vecteurs d’infection, reconstruction de la chaîne de staging en quatre étapes, extraction des IOCs, décodage de l’URL C2 encodée en base64, désobfuscation partielle de parser.js (algorithme d’obfuscation obfuscator.io, rotation de tableau 62 itérations, alphabet base64 custom, clé XOR). Cette couverture aurait demandé une journée complète à un analyste humain travaillant seul.
L’IA a également assuré l’intégralité de la rédaction structurée : plan en 13 sections, mapping MITRE ATT&CK sur 30 techniques, tableaux d’IOCs, hashes cryptographiques, recommandations de signalement. Le livrable final — ce rapport — est directement issu de cette production.
L’analyste décide, le LLM exécute
Mais alors quid de l’humain dans cette histoire? Son rôle est celui du pilotage, de la prise de décision et de l’interprétation. Ainsi, c’est l’analyste qui a identifié le dépôt suspect et décidé d’aller l’inspecter. Et c’est l’analyste qui guide le LLM dans les tâches à réaliser, par l’intermédiaire d’une ingénierie continue de prompt. Chaque reformulation de consigne, chaque correction de cap, chaque décision d’investigation est une interaction de pilotage dont la qualité détermine directement la qualité des sorties IA.
A certains moment, la qualité d’interprétation de l’analyste a permis de débloquer des situations. Ainsi, lors des tentatives de reconstruction de la chaîne de staging, l’IA a interprété l’échec des requêtes HTTP vers le C2 de stage-2 comme un blocage IP — hypothèse plausible, mais fausse. C’est l’analyste humain qui a identifié la vraie cause : le C2 filtre sur le User-Agent, exigeant une empreinte au format npm. Ce type d’erreur est caractéristique des limites de raisonnement probabiliste de l’IA. L’humain a su sortir du cadre.
Au final, sur cet exemple, le LLM et l’analyste auront « travaillé » à peu près la même quantité de temps, soit trois heures chacun. En l’espace de six heures, il a donc été possible de produire un rapport qui aurait sans doute demandé 2 à 3 jours de travail en solo.
Cette expérience valide un modèle de collaboration où l’IA agit comme un multiplicateur de capacité d’exécution et non comme un remplaçant de l’analyste. Dans ce modèle :
- L’analyste CTI ne perd pas de temps à lire 50 fichiers JavaScript ligne par ligne — l’IA le fait.
- L’analyste CTI conserve le rôle de décideur : qu’est-ce qui mérite d’être investigué ? Quelle hypothèse est fausse ? Quand arrêter une piste ?
- Le prompt engineering devient une compétence analytique à part entière — structurer correctement une question à l’IA est aussi exigeant intellectuellement que de poser la bonne hypothèse d’investigation.
- Les échecs de l’IA (comme l’hypothèse d’IP blacklistée) ne sont pas des bugs — ils sont des signaux. Ils indiquent les zones où le modèle atteint les limites de son espace d’entraînement, et donc exactement là où l’expertise humaine est irremplaçable.
Conclusion
Cette expérience valide un modèle de collaboration où l’IA agit comme un multiplicateur de capacité d’exécution, pas comme un remplaçant de l’analyste. Six heures de travail combiné pour un livrable qui en aurait demandé deux à trois en solo : le gain est réel, mais il tient entièrement à la qualité du pilotage humain.
C’est d’ailleurs la leçon la plus importante de ce dossier. L’erreur de l’IA, interpréter un filtrage sur le User-Agent comme un blocage IP, n’est pas un défaut à corriger, c’est une frontière à cartographier. Elle indique exactement là où le raisonnement probabiliste s’arrête et où l’expertise humaine reste irremplaçable. Bien employé, le LLM ne dilue pas le métier d’analyste CTI : il en déplace la valeur vers ce qui compte le plus, décider quoi investiguer, reconnaître une hypothèse fausse, et savoir quand sortir du cadre.
Pour aller plus loin
Ce dossier illustre notre façon de travailler : l’IA accélère l’exécution, mais c’est l’analyste qui dirige, interprète et tranche. C’est ce pilotage humain qui fait la différence dans un service de renseignement sur la menace. Notre équipe CTI accompagne les organisations sur la durée — anticipation des menaces qui les visent, investigations dédiées et restitution actionnable.
