Bruit de fond pirate

Une communauté peut désigner quelques postes et quelques serveurs compromis. Ils continuent leur journée de travail — le comptable continue de comptabiliser —, et le bruit d'un attaquant s'y ajoute : une balise vers un serveur de commande, le téléchargement d'une charge, une reconnaissance, un vol d'identifiants, une exfiltration.

Ce qui fait l'intérêt de ce bruit n'est pas qu'il existe, c'est qu'il est cohérent de bout en bout. Pour un même geste, à la même seconde, le pare-feu, le proxy, le résolveur DNS et l'EDR nomment le même indicateur de compromission. C'est ce qui donne à un analyste quelque chose à corréler — et c'est ce qu'aucun générateur de bruit ne donne quand chaque technologie tire sa destination dans son coin.

La clé de voûte : un indicateur est une destination

SekoiaCraft décrivait déjà la journée d'une entreprise et la faisait raconter à l'identique par une douzaine de technologies : un geste porte ses faits — la destination, le processus, le document — et toutes les projections de ce geste les lisent. Le bruit pirate ne fait qu'entrer par cette porte.

Quatre gestes de menace ont été ajoutés au catalogue, et ils nomment une destination :

Geste	Ce que les journaux en montrent
Résolution d'un domaine malveillant	La question posée au résolveur — BIND, Sysmon, les quatre EDR
Balise vers un serveur de commande	La connexion sortante — pare-feu, proxy, socket de l'agent
Téléchargement d'une charge utile	La même, plus l'URL chez les proxies
Sortie de données vers l'attaquant	La même, côté téléversement

Chaque famille est lue par le champ qu'elle journalise réellement : un pare-feu voit un socket — une adresse et un port —, un proxy voit une transaction — donc un nom —, un résolveur voit une question. Ils ne rendent pas le même champ ; ils rendent la même ligne du catalogue d'indicateurs, ce qui fait qu'ils ne peuvent pas se démentir.

Une campagne, un serveur de commande

La destination d'un geste de menace se tire sur (entité, jour) et non sur le geste : un implant a une configuration pour la journée. Résoudre le domaine, y baliser, en télécharger la charge et y sortir les données nomment donc le même hôte — sans quoi la chaîne se démentirait d'un maillon à l'autre, et on aurait déplacé la contradiction au lieu de la retirer.

Le binaire qui parle à l'indicateur vient d'un pool propre — schtasks.exe, rundll32.exe, mshta.exe, transcrits du corpus d'alertes de référence. Sans lui, l'EDR annonçait chrome.exe en train de baliser vers un serveur de commande : un message qui se contredit dans deux champs voisins.

D'où viennent les indicateurs

Deux sources, et elles ne se marchent pas dessus.

Le plancher, semé avec le produit. Une dizaine d'hôtes et d'adresses dans les plages réservées à la documentation (RFC 5737) et sur des domaines réservés (RFC 2606). Ils n'appartiennent à personne et n'ont aucune valeur de renseignement — leur seul rôle est de garantir que le bruit reste cohérent sur une installation sans clé d'API. Sans eux, une campagne n'aurait aucun hôte à nommer.

Le feed Sekoia, une fois une clé d'API renseignée — mais renseigner la clé ne récupère rien à elle seule. Le feed est interrogé par Rafraîchir maintenant, ou chaque jour quand Rafraîchir le catalogue chaque jour est coché (il ne l'est pas par défaut). Il rend des indicateurs actifs — domaines, adresses, URL — modifiés depuis minuit UTC : tôt dans la journée, il peut n'avoir rien à rendre, et le catalogue reste alors en l'état. Les règles CTI de Sekoia ne se déclenchent sur ce que la simulation émet que si un message porte l'un de ces indicateurs.

Un rafraîchissement réussi touche la date de modification de chaque communauté qui greffe une menace — le canal par lequel l'ordonnanceur apprend que son plan du jour est périmé. La journée est reconstruite au tic suivant, et l'indicateur d'un hôte compromis change sur-le-champ plutôt qu'à minuit. Contrepartie : la liste des communautés, triée sur cette date, se réordonne.

Le rafraîchissement ne remplace que ce que le feed avait écrit : une ligne semée, ou saisie depuis les jeux de données, survit. Et un feed qui ne rend rien laisse le catalogue en l'état — remplacer un catalogue daté par un catalogue vide serait strictement pire.

L'écran annonce donc deux chiffres : ce que le catalogue porte, et ce qui en vient du feed. Le premier n'est jamais nul sur une base semée — c'est le plancher, et c'est lui qu'on regarde quand le second est à zéro.

La clé se saisit dans Configuration → Configuration générale. Comme les clés d'intake, elle ne se relit jamais : seul son masque revient (••••1a2b), et le contrat est le même — champ laissé vide = conservée, case « effacer » cochée = effacée, valeur saisie = remplacée. Elle n'est pas chiffrée en base, et l'écran le dit : la clé de déchiffrement vivrait sur le même hôte que PostgreSQL.

Les campagnes : une par heure

Les menaces vivent dans la bibliothèque de scénarios. Six de ses scénarios sont des campagnes — et greffées, une seule joue à chaque heure de la journée. C'est ce que fait un attaquant : une chose à la fois, et autre chose à l'heure suivante.

Six raretés « 1 jour sur 6 » n'auraient pas dit cela : elles donneraient une journée sans aucune campagne une fois sur trois, et deux campagnes simultanées presque aussi souvent.

Campagne	Ce qu'elle enchaîne
Balise vers le serveur de commande	Résolution → balise toutes les 10 minutes
Téléchargement de charge	Résolution → récupération → exécution de la charge
Reconnaissance	Énumération de l'annuaire
Vol d’identifiants et rebond	Extraction de secrets → rebond vers un autre hôte
Exfiltration	Téléversement → sortie massive détectée
Ancrage et persistance	Réveil de l'implant → ancrage sur la machine

« Battement de l’implant » est un scénario de fond : un battement toutes les deux heures, hors de la rotation. C'est ce qui fait qu'un hôte compromis se voit toute la journée, et pas seulement pendant l'heure de sa campagne.

Tout scénario de la bibliothèque qui vise des postes ou des serveurs peut entrer dans la rotation — une compromission de messagerie, une pulvérisation de mots de passe —, et chacun se rejoue dans chaque heure qui lui revient, depuis le début de cette heure.

Greffer la menace sur une communauté

Onglet Menaces d'une communauté, première carte :

Réglage	Ce qu'il décide
Scénarios en rotation	Les scénarios qui tournent sur les hôtes compromis
Heures sans campagne	Les issues vides de la rotation
Comment les désigner	Par un nombre, ou nommément — trois modes
Postes compromis	Combien d'utilisateurs de la population
Serveurs compromis	Combien de machines du parc
Postes / serveurs désignés	Les hôtes nommés, un par ligne

Avec deux scénarios et une heure sans campagne, une heure sur trois reste calme. La rotation se tire chaque jour, et chaque hôte compromis ne joue que les étapes de sa tranche : un serveur ne reçoit pas le courriel piégé d'une compromission de messagerie, il en reçoit l'élévation de privilèges.

C'est une greffe, jamais une attribution. La menace est composée par-dessus la journée métier de l'hôte : le comptable garde sa comptabilité, et le bruit de l'attaquant s'y ajoute. L'attribuer en aurait fait un attaquant à plein temps, muet sur son métier — et le trafic malveillant n'aurait plus rien eu à côté de quoi se lire.

Un serveur compromis qui ne joue aucun archétype métier joue la menace seule : c'est le cas normal d'un parc, dont la grande majorité des machines ne joue rien.

Trois façons de désigner les compromis

Mode	Ce qu'il dit
Tirage stable	Un nombre, et toujours les mêmes hôtes. Le défaut.
Hôtes désignés	Ceux-là, nommément. Les nombres ne servent plus.
Cohorte qui tourne	Un nombre, et une cohorte du jour où la menace change d'hôte chaque heure.

En tirage stable, qui est compromis n'est pas stocké : la communauté dit combien, et un tirage stable sur (communauté, nom) dit qui. Augmenter le nombre n'échange personne : les compromis d'un compte de 3 sont les trois premiers de ceux d'un compte de 5.

Désigner les hôtes est la seule chose qu'un tirage ne peut pas faire — nommer cette machine-là. La liste est alors la vérité, et les deux nombres ne servent plus. Contrepartie déclarée : une liste se périme. Un nom que la population ne porte plus est donc nommé à l'écran plutôt que cru, tandis qu'un nom inconnu au moment d'enregistrer est refusé sur place — à l'écriture c'est une faute de frappe, plus tard c'est un renommage. Changer de population vide les deux listes, comme elle vide déjà les attributions.

La cohorte tourne à l'heure, et le grain n'est pas un hasard. C'est déjà l'unité à laquelle un attaquant change de tâche dans ce produit — la cadence horaire d'une bifurcation le dit aussi. Plus fin, la chaîne se contredirait d'un maillon à l'autre : la configuration du serveur de commande est tirée par (entité, jour), si bien que l'hôte qui résout le domaine malveillant à 09:14 et celui qui balise à 09:15 nommeraient deux indicateurs différents — exactement la contradiction que le bruit de fond pirate existe pour retirer.

La cohorte du jour est plus large que le nombre d'hôtes bruyants à la fois : c'est le périmètre compromis, et la rotation dit lequel de ses hôtes est bruyant à cette heure. Un attaquant qui a pris pied pivote dans une poignée de machines ; il ne visite pas le parc entier toutes les heures. C'est aussi ce qui garde la liste nommable — une douzaine d'hôtes, pas deux cents.

L'écran nomme donc la cohorte, jamais « ceux de la minute courante » : une telle liste serait périmée la seconde d'après, et surtout ne serait pas celle que le plan de journée vise.

Dans les trois modes, l'écran nomme les hôtes — un chiffre ne dit pas où regarder.

Enregistrer la menace touche la date de modification de la communauté, qui est le canal par lequel la configuration prévient l'ordonnanceur que son plan du jour est périmé. Greffer la menace à 14 h prend donc effet au tic suivant.

Lancer un scénario maintenant

Même onglet, deuxième carte : Lancer un scénario. N'importe quel scénario de la bibliothèque — y compris le déni de service, qu'aucune greffe ne peut jouer — se joue maintenant, sur cette communauté, pour une durée bornée :

Champ	Ce qu'il décide
Scénario	Lequel, dans la bibliothèque
Durée (minutes)	Combien de temps il dure — soixante par défaut, une journée au plus
Hôtes tirés par tranche	Combien de postes, de serveurs ou de sites il vise quand aucun n'est nommé
Nommer les hôtes plutôt	Postes, serveurs et sites par leur nom, un par ligne

Aperçu dit ce que le lancement enverrait, sans rien envoyer ; Lancer maintenant le met en file. Le scénario commence à la minute suivante, et chaque minute part à la fin de cette minute, avec l'heure réelle dans chaque message — un lancement à 23 h 50 ne s'arrête pas à minuit.

L'aperçu liste aussi les messages, dans l'ordre d'émission, chacun replié sur une ligne — heure, hôte, technologie, message type, étape — qui se déplie sur le message tel qu'il partirait. Ceux qui ne partiraient pas y figurent aussi, marqués de leur sort : Sans clé d’intake, Rendu invalide, Rendu en échec ; c'est en voyant les messages d'une technologie qu'on sait quelle clé poser. L'écran montre les 200 premiers et le dit ; Télécharger les … message(s) (JSON) les récupère tous. Le fichier rejoue l'aperçu — même graine, même début, mêmes hôtes — plutôt que de le stocker : un réglage changé entre-temps, une clé posée par exemple, se lit dans le fichier.

Les hôtes qu'on ne nomme pas sont retirés à chaque aperçu et à chaque lancement : deux lancements du même scénario visent en général d'autres postes, d'autres serveurs ou d'autres sites — y compris un lancement qui suit un aperçu. Pour envoyer ce qu'un aperçu a montré, Lancer sur ces hôtes, sous son résultat, joue le scénario sur les hôtes qu'il a tirés, par leur nom. Un hôte nommé dans une tranche veut dire « ceux-là, et pas d'autres » : rien n'est tiré dans les autres tranches.

Ce qui ne part pas est dit, jamais tu : les étapes qu'aucune technologie active ne couvre, celles qu'aucune cible ne peut jouer, les technologies sans clé d'intake. Et un lancement émet les alertes que ses étapes appellent quand la technologie n'a rien d'autre pour les décrire — le courriel piégé, la règle de boîte, la connexion à risque ne se décrivent qu'ainsi.

La troisième carte liste les lancements de la communauté : scénario, début, durée, cibles, et avancement — envoyés sur prévus, lu sur les lots envoyés et jamais stocké. La page se rafraîchit à mesure que les lots partent.

Sur une équipe d'un pool, un lancement part sur toutes les équipes ; l'écran du pool le lance aussi, et le suit pour toutes — cf. Pools de communautés.

Retrouver une menace sur la plateforme

Chaque message de menace qui part s'écrit dans le journal d'api-activity, sous son propre contexte [Menace] — une ligne par message mis en file, donc par geste et par technologie :

docker compose -f infrastructure/docker/docker-compose.dev.yml logs -f api-activity | grep '\[Menace\]'

Sur un hôte déployé, la même commande logs vise le fichier compose de l'environnement, comme pour le mot de passe initial. Une ligne se lit ainsi :

« Acme » 2026-09-14T08:02:31Z poste jdoe (PC-JDOE-01) · Battement de l’implant → Fortinet FortiGate / traffic-forward · IOC evil-c2.net (domain-name, feed CTI) : ABSENT du message, seule l’adresse dérivée 198.51.100.14 y figure · activité <activityId> · lot c.<communauté>.2026-09-14.482.<technologie>.0

• L'instant — l'heure que porte le message lui-même, en UTC : celle sous laquelle la plateforme l'indexe.
• L'hôte — le poste et son nom de machine, ou le serveur et son adresse.
• Le geste — l'étape de scénario qui l'a produit.
• La technologie et le message type — donc l'intake où chercher.
• L'IOC — sa valeur, son genre, et son origine : le feed, le plancher semé, ou les jeux de données.
• Le verdict — le message porte-t-il l'indicateur, ou seulement son adresse ?
• L'activité — commune à toutes les technologies qui décrivent le même geste.
• Le lot — l'identifiant qu'api-sender écrit à côté du code HTTP du lot.

Pour retrouver le message sur la plateforme : dans l'intake de cette technologie, autour de cet instant, chercher la valeur que le verdict dit présente.

À chaque construction d'une journée — à minuit, au redémarrage, après un rafraîchissement du feed —, une ligne de synthèse dit combien de gestes et de messages de menace la journée prévoit, combien des indicateurs du catalogue viennent du feed, et quel indicateur chaque hôte compromis vise aujourd'hui. C'est un avertissement quand la journée balise sans qu'aucune règle CTI puisse s'y apparier.

Pourquoi aucune alerte ?

1. Aucun indicateur du feed. La synthèse dit 0 du feed : la clé est posée, mais le feed n'a pas été interrogé, ou n'a rien rendu (voir plus haut). Les balises visent le plancher semé.
2. La journée a été planifiée avant le rafraîchissement. Un rafraîchissement réussi replanifie désormais la journée, et la ligne de synthèse s'écrit de nouveau.
3. L'indicateur ne figure pas dans le message. Les pare-feu, les sockets d'EDR et les agents d'endpoint (FortiGate, Palo Alto NGFW, Cortex, CrowdStrike, HarfangLab, l'agent Sekoia, SentinelOne) n'écrivent qu'une adresse — et pour un domaine ou une URL du feed, cette adresse est dérivée dans une plage de documentation qu'aucune règle CTI ne connaît. Le nom n'apparaît que chez les proxies (Netskope, Zscaler), dans Windows (connexion réseau Sysmon) et dans Defender — et dans les journaux DNS, que seules produisent les campagnes qui résolvent un domaine malveillant — « Balise vers le serveur de commande », « Téléchargement de charge ». Une rotation réduite au battement de l'implant ne résout plus rien.
4. Les gestes de détection n'émettent rien dans la rotation. Reconnaissance, vol d'identifiants, persistance… sont réservés aux alertes : seul un scénario lancé à la demande les émet (voir plus haut).
5. La technologie n'émet pas : non retenue par la communauté, coupée après une série d'échecs, ou sans clé d'intake.

Éditer un scénario greffé prend effet au tic suivant, comme n'importe quel réglage de la communauté : enregistrer ses étapes touche la date de modification des communautés qui le greffent. Seules les minutes pas encore envoyées changent ; les gestes déjà partis restent tels qu'ils sont partis.

Ce que le lot ne fait pas

• Les gestes de détection — reconnaissance, force brute, vol d'identifiants, malware, rebond, exfiltration, persistance — ne nomment toujours aucune destination, et seul un scénario lancé les émet.
• Une seule rotation par communauté. Une seconde demanderait un second jeu d'heures sans campagne ; deux scénarios dans la même rotation disent déjà « l'un ou l'autre ».
• Une connexion à risque porte encore l'adresse de l'utilisateur, pas celle d'un attaquant : l'adresse source d'un geste d'authentification est celle de l'entité.
• Les indicateurs expirés ne sont pas balayés : le rafraîchissement remplace les lignes du feed en bloc, ce qui suffit tant qu'il tourne. Sans lui, le catalogue vieillit sans le dire.
• Les familles d'alertes du projet d'origine — Elevate, Sigma, POI — ne sont pas portées : un lancement joue les gestes d'un scénario, pas ces jeux de règles.