Comment Corvus.Sense utilise les LLM pour classifier et trier les cybermenaces à grande échelle

Telegram est devenu l'une des sources de données à plus fort signal pour le renseignement sur les cybermenaces en temps réel. Les acteurs de menace alignés sur des États, les collectifs hacktivistes et les groupes criminels menant des attaques contre des cibles gouvernementales, des infrastructures critiques et des objectifs de défense annoncent régulièrement leurs opérations avant ou immédiatement après leur exécution — nommant les victimes, revendiquant les vecteurs d'attaque et publiant des preuves. Le problème est le volume et la structure : des centaines de canaux, des milliers de messages par jour, presque tous en langage naturel non structuré, mélangés à du bruit, des republications et des intoxications.

Corvus.Sense est conçu pour résoudre ce problème à l'échelle de production. En son cœur se trouve un pipeline LLM en plusieurs étapes qui ingère des flux bruts de messages Telegram et produit des enregistrements de renseignements sur les menaces structurés avec classification sectorielle, attribution géographique, étiquetage des vecteurs d'attaque et notation de confiance — en moins de 90 secondes à partir de la publication du message. Cet article décrit comment ce pipeline est architecturé et pourquoi chaque décision de conception a été prise.

Pourquoi les LLM plutôt que l'extraction basée sur des règles

La première décision de conception portait sur l'utilisation de l'extraction déterministe (expressions régulières, correspondance de mots-clés, reconnaissance d'entités nommées) ou de l'inférence LLM générative pour la classification. Nous avons évalué les deux approches de manière approfondie sur un ensemble de données étiqueté de 12 000 annonces d'attaques confirmées provenant de 34 canaux Telegram. Les conclusions étaient sans ambiguïté.

Les systèmes basés sur des règles ont atteint une précision acceptable pour les groupes d'acteurs bien connus avec des schémas de publication cohérents, mais ont échoué face aux nouveaux acteurs, au mélange de codes (messages mélangeant ukrainien, russe et anglais), aux abréviations, à l'obfuscation délibérée et aux variations stylistiques. Des taux de faux négatifs supérieurs à 30 % pour les nouveaux canaux d'acteurs ont rendu l'extraction basée sur des règles opérationnellement inadéquate — manquer une annonce d'attaque réelle sur trois ne constitue pas un produit de renseignement viable.

La classification basée sur les LLM a atteint plus de 91 % de F1 sur le même ensemble d'évaluation, y compris sur les messages avec mélange de codes et les nouveaux canaux d'acteurs absents des données d'entraînement. Le compromis porte sur la latence et le coût par message, que nous traitons tous deux par l'architecture de pipeline décrite ci-dessous.

Étape 1 du pipeline : ingestion et prétraitement

Corvus.Sense se connecte aux canaux Telegram via l'API Telegram en utilisant des comptes de service dédiés. Chaque canal configuré est interrogé selon un intervalle configurable (30 secondes par défaut). Les nouveaux messages depuis le dernier horodatage d'interrogation sont récupérés, dédupliqués par rapport à l'index des IDs de messages, et mis en file d'attente pour traitement.

Le prétraitement gère plusieurs problèmes de qualité des données avant toute inférence. Les messages de moins de 20 tokens sont rejetés — ils ne contiennent pas suffisamment de contenu sémantique pour la classification. Les messages transférés sont suivis avec leur canal source d'origine ; si l'original a déjà été traité, le transfert est marqué comme doublon et ignoré, empêchant la même annonce de générer plusieurs enregistrements d'alerte. Les messages contenant uniquement des médias (images, vidéos sans légende) sont mis en file d'attente séparément pour un pipeline basé sur la vision hors du périmètre de cet article.

La détection de langue s'exécute sur chaque message pour étiqueter la langue source (ISO 639-1). Cette étiquette est transmise en aval au prompt LLM pour permettre des exemples few-shot adaptés à la langue dans le prompt de classification.

Étape 2 du pipeline : classification binaire de pertinence

L'appel complet de classification LLM est coûteux par rapport au volume de messages traités. Un classificateur binaire léger s'exécute avant toute inférence LLM pour filtrer le contenu non opérationnel. Ce classificateur est un modèle encodeur affiné (350M de paramètres) entraîné à distinguer les annonces d'attaques opérationnelles des commentaires, republications d'actualités, publications de recrutement, propagande et contenus généraux de canaux.

Le classificateur binaire fonctionne en moins de 200 millisecondes par message sur du matériel d'inférence CPU uniquement. Sur l'ensemble d'évaluation de production, il atteint 94,3 % de précision et 89,7 % de rappel. Le chiffre de rappel n'est intentionnellement pas poussé plus haut — le coût d'un faux négatif à cette étape (une vraie annonce qui ne progresse pas vers la classification LLM) est élevé, donc le seuil est fixé de manière conservatrice pour maximiser le rappel. Les faux positifs à cette étape coûtent un appel d'inférence LLM complet, ce qui constitue le compromis maîtrisé.

Étape 3 du pipeline : classification et enrichissement LLM

Les messages passant la porte binaire entrent dans l'étape de classification LLM. Corvus.Sense utilise un prompt de sortie structurée qui instruit le modèle d'extraire et de classifier chacun des champs suivants à partir du texte du message :

Organisation victime. L'organisation cible nommée ou implicite, normalisée sous une forme canonique. Lorsque le message nomme une organisation spécifique (par exemple un ministère, une société de services publics ou une institution financière), ce nom est extrait tel quel. Lorsque la victime est implicite par le secteur et la géographie sans nom spécifique, le champ est renseigné comme null et signalé pour examen par un analyste.

Classification sectorielle. L'une des huit étiquettes de taxonomie fixe : infrastructure critique, finance, gouvernement, télécommunications, énergie, défense, santé ou transport. La taxonomie fixe est intentionnelle — la classification en texte libre produit des étiquettes incohérentes qui ne peuvent pas être agrégées de manière fiable. Le LLM reçoit des définitions pour chaque catégorie et est instruit de sélectionner l'étiquette la mieux adaptée.

Attribution géographique. Code pays ISO 3166-1 alpha-2 pour le pays d'opération de la victime. Lorsque plusieurs pays sont nommés comme cibles, tous sont extraits sous forme de tableau. Le modèle est explicitement instruit de distinguer le pays victime du pays d'origine présumé de l'acteur — une source d'erreur fréquente dans les approches d'extraction naïves.

Vecteur d'attaque. L'une des six catégories de vecteurs : DDoS, défiguration, exfiltration de données, ransomware, vol d'identifiants ou compromission de la chaîne d'approvisionnement. Les attaques multi-vecteurs sont représentées sous forme de tableau.

Scores de confiance. Pour chaque champ extrait, le modèle retourne un score de confiance de 0 à 1. Le prompt instruit le modèle de représenter l'incertitude épistémique réelle — un message indiquant « nous allons attaquer l'énergie ukrainienne » donne une confiance élevée sur la géographie (UA) et le secteur (énergie), mais une confiance plus faible sur le vecteur d'attaque (non spécifié) et l'organisation victime (non nommée). Les scores ne sont pas une calibration a posteriori ; ils sont dérivés directement de la représentation d'incertitude du modèle lors de la génération.

Le prompt LLM est structuré pour produire une réponse JSON conforme à un schéma strict. L'analyse de la réponse valide le schéma à la réception ; les réponses malformées déclenchent une nouvelle tentative automatique avec une instruction supplémentaire pour corriger l'erreur de formatage. La logique de nouvelle tentative est limitée à deux essais ; les messages produisant toujours une sortie malformée après deux nouvelles tentatives sont signalés pour examen par un analyste et retirés du traitement automatisé.

Construction du graphe de chaîne d'attaque

Chaque enregistrement de message classifié est écrit dans la base de données graphique de chaîne d'attaque après la classification LLM. Le graphe modélise le paysage des menaces sous la forme d'un graphe de propriétés avec trois types de nœuds : acteurs de menace, organisations victimes et événements d'attaque. Les arêtes représentent des relations : « a conduit » (acteur vers événement), « a ciblé » (événement vers victime) et « a utilisé le vecteur » (événement vers nœud de taxonomie de vecteur d'attaque).

Lorsqu'un nouvel enregistrement classifié arrive, le moteur graphique effectue une résolution d'entités : il vérifie si l'organisation victime nommée existe déjà comme nœud (en utilisant la correspondance de noms approximative et la désambiguïsation par code pays) et si le canal Telegram source correspond à un profil d'acteur connu. Si les deux sont résolus, une arête est créée reliant le nœud d'acteur au nœud victime via un nouveau nœud d'événement d'attaque. Si l'acteur est nouveau (canal pas encore mappé à un profil), un nœud d'acteur provisoire est créé pour examen par un analyste.

Le graphe permet des requêtes que les bases de données à enregistrements plats ne peuvent pas prendre en charge efficacement. Exemples de workflows d'analystes : « Afficher toutes les organisations du secteur énergétique ciblées par cet acteur au cours des 90 derniers jours, avec la répartition des vecteurs d'attaque. » « Quels acteurs ont ciblé à la fois des organisations des secteurs de la défense et de la finance en Pologne ce mois-ci ? » « Quelle est la distribution temporelle des attaques de ce groupe par rapport aux événements cinétiques dans le théâtre ? » Ces requêtes s'exécutent comme des parcours de graphe, renvoyant des résultats en quelques secondes sur des graphes de dizaines de milliers de nœuds.

La surveillance des menaces basée sur OSINT à ce niveau de structure n'était pas réalisable avant l'extraction basée sur les LLM à l'échelle et la précision nécessaires pour alimenter continuellement un graphe à partir de sources ouvertes. Les approches précédentes nécessitaient un effort analytique manuel significatif par enregistrement, ce qui limitait la densité et la fraîcheur du graphe.

Analyse du schéma de vie pour les groupes d'acteurs de menace

Une fois qu'un profil d'acteur de menace accumule suffisamment d'historique dans le graphe (généralement 7 jours ou plus d'ingestion), Corvus.Sense calcule des métriques de schéma de vie. Celles-ci sont dérivées des propriétés temporelles et structurelles des nœuds d'événements d'attaque de l'acteur dans le graphe.

Distribution des heures d'activité. Les horodatages des événements d'attaque sont regroupés par heure UTC et jour de la semaine. La plupart des groupes alignés sur des États opèrent pendant les heures de bureau de leur fuseau horaire local ; les déviations par rapport à ce schéma (pics inhabituels en fin de nuit, pics le week-end) peuvent indiquer des changements de tempo opérationnel ou l'implication de plusieurs sous-groupes géographiquement distribués. L'histogramme des heures d'activité est mis à jour quotidiennement.

Carte thermique des préférences de cibles. Le ratio des attaques par secteur et géographie est calculé sur l'ensemble de l'historique des événements de l'acteur. Cela met en évidence des préférences de ciblage cohérentes — un acteur ayant attaqué l'infrastructure énergétique ukrainienne dans 73 % des événements est clairement spécialisé, et les nouvelles annonces contre des cibles énergétiques de cet acteur devraient recevoir une priorité élevée indépendamment du score de confiance.

Suivi de l'évolution des TTPs. Les distributions des vecteurs d'attaque sont calculées sur des fenêtres glissantes de 30 jours et comparées à la base de référence historique de l'acteur. Un groupe ayant historiquement conduit des opérations DDoS et qui est maintenant classifié comme conduisant des événements d'exfiltration de données représente un changement de TTP — un signal de renseignement à haute valeur indiquant le développement de capacités ou des objectifs modifiés.

Génération automatisée de synthèses exécutives

Corvus.Sense inclut un pipeline de génération de synthèses automatisé qui produit des produits de renseignement lisibles par des humains à partir des données graphiques structurées. Les synthèses sont générées selon un calendrier configurable (quotidien, hebdomadaire ou à la demande) ou déclenchées par des événements seuils (nombre d'attaques d'un acteur suivi dépassant une limite configurée dans une fenêtre temporelle).

Le pipeline de synthèse interroge le graphe pour l'acteur, le secteur ou le périmètre géographique défini par le modèle de rapport, récupère les enregistrements d'événements structurés et les métriques de schéma de vie, et passe ce contexte structuré à un modèle de génération avec un prompt de synthèse narrative. Le résultat est un résumé de renseignement en prose dans le registre approprié aux consommateurs exécutifs — pas de JSON, pas d'étiquettes de champs, pas de scores de confiance sauf s'ils sont analytiquement significatifs.

De manière critique, le modèle de génération de synthèses opère sur des données structurées récupérées du graphe, et non sur le texte brut des messages Telegram. Cette séparation architecturale prévient les hallucinations provenant de matériaux sources ambigus : le modèle de génération ne peut référencer que des événements qui existent en tant qu'enregistrements classifiés validés dans le graphe. Si une attaque revendiquée n'a pas passé les contrôles de qualité de classification, elle n'apparaît pas dans une synthèse.

Notation de confiance et gestion de l'incertitude

Chaque enregistrement classifié dans Corvus.Sense porte des scores de confiance au niveau des champs. Ces scores se propagent à tous les consommateurs en aval : le tableau de bord des analystes affiche la confiance visuellement, les règles d'alerte peuvent être configurées pour se déclencher uniquement au-dessus d'un seuil minimum par champ, et l'exportation STIX mappe les scores de confiance à la propriété de confiance STIX.

Les enregistrements où un champ critique (secteur, géographie ou attribution d'acteur) tombe en dessous du seuil configuré sont placés dans la file d'examen des analystes plutôt que de générer des alertes automatisées. Le seuil est configurable par déploiement : les installations à haute sensibilité surveillant les infrastructures critiques peuvent abaisser les seuils pour maximiser le rappel ; les déploiements de surveillance plus larges peuvent augmenter les seuils pour réduire le volume de la file d'attente des analystes.

Pour les champs où la confiance du LLM est marginale (entre 0,65 et 0,80 par défaut), Corvus.Sense soumet optionnellement le message pour un second passage LLM indépendant utilisant une formulation de prompt différente. Lorsque les deux passages s'accordent sur une valeur de champ, le score de confiance est rehaussé ; lorsqu'ils divergent, le champ est signalé comme contesté et les deux valeurs candidates sont présentées à l'analyste.

Configuration de Corvus.Sense pour suivre un acteur de menace spécifique

La séquence suivante décrit comment configurer Corvus.Sense pour la surveillance ciblée d'un groupe de pirates nommé sur ses canaux Telegram.

Étape 1 — Identifier les canaux Telegram de l'acteur. Compilez les IDs de canaux numériques et les @noms d'utilisateur pour tous les canaux connus exploités par ou affiliés au groupe cible, y compris les canaux miroirs et de secours. Corvus.Sense accepte les deux formats.

Étape 2 — Créer un profil d'acteur. Dans le panneau Acteurs, créez un nouveau profil avec le nom canonique du groupe et les alias connus. Attribuez les IDs de techniques MITRE ATT&CK reflétant les TTPs connus du groupe. Liez les identifiants de canaux à ce profil. À partir de ce moment, tous les messages de ces canaux sont associés à ce nœud d'acteur dans le graphe.

Étape 3 — Configurer le périmètre sectoriel et géographique. Sélectionnez les secteurs et les codes pays que vous souhaitez surveiller pour cet acteur. Les attaques hors périmètre sont toujours ingérées et classifiées mais exclues de la génération d'alertes spécifiques à l'acteur. Cela permet une ingestion large tout en maintenant le volume d'alertes focalisé sur les événements opérationnellement pertinents.

Étape 4 — Définir les seuils de confiance et la livraison des alertes. Configurez les seuils de confiance minimum par champ. Pour les secteurs de la défense et des infrastructures critiques, des seuils plus bas (0,65) maximisent le rappel. Configurez la livraison des alertes par e-mail, webhook ou un point de terminaison d'intégration SIEM. Corvus.Sense prend en charge les formats d'alerte CEF et JSON pour l'ingestion SIEM.

Étape 5 — Examiner et corriger les classifications initiales. Durant les 72 premières heures, examinez tous les enregistrements classifiés dans la file d'attente des analystes pour cet acteur, quel que soit le score de confiance. Les outils de correction intégrés permettent des modifications au niveau des champs. Les corrections sont journalisées et peuvent être soumises pour améliorer la calibration du modèle pour les schémas linguistiques de cet acteur au fil du temps.

Étape 6 — Activer l'analyse du schéma de vie. Après 7 jours de données d'événements accumulées, activez la vue du schéma de vie. Les distributions d'heures d'activité, les cartes thermiques de préférence de cibles et les histogrammes de TTPs sont calculés à partir du graphe et mis à jour quotidiennement. Cette vue est la principale entrée pour anticiper le comportement de ciblage futur.

Étape 7 — Exporter le renseignement structuré. Utilisez l'exportation du profil d'acteur pour générer des produits de renseignement en format JSON, PDF ou bundle STIX 2.1. L'exportation STIX mappe les données du profil d'acteur aux objets STIX Threat Actor et Campaign pour le partage via TAXII ou l'importation dans des plateformes CTI externes.