Rédiger un rapport de triage

Le triage n’est terminé que lorsque quelqu’un d’autre peut agir en conséquence. Vous avez peut-être identifié le fichier, lu ses chaînes et ses imports, mesuré son entropie et écrit une règle YARA, mais si ces connaissances restent dans l’historique de votre terminal, le SOC ne sait toujours pas s’il faut isoler l’hôte, l’équipe détection n’a aucune règle à déployer, et l’analyste suivant refera votre travail de zéro.

Un rapport de triage est le produit de la première étape de l’entonnoir d’analyse présenté dans Qu’est-ce que l’analyse de malwares ?. Il est court, il se rédige en quelques heures plutôt qu’en quelques jours, et il existe pour appuyer des décisions. Cette leçon couvre ce qu’il contient, comment formuler ce que vous savez et ce que vous ne faites que soupçonner, et comment le partager. Elle se termine par un exemple de rapport complet et un lab chronométré.

Un rapport existe pour appuyer des décisions

Tout rapport de triage répond à quatre questions, dans cet ordre d’urgence :

1. Est-ce malveillant ? Ou bénin, ou potentiellement indésirable, ou inconnu.
2. Que fait-il ? Ses capacités, au niveau de détail que permet le triage.
3. Que bloquer et que rechercher ? Les IOC (indicateurs de compromission) et le contenu de détection.
4. Faut-il une analyse plus approfondie ? Et si oui, quelles questions restent ouvertes.

Si un lecteur ne trouve pas la réponse à la question 1 dans les dix premières secondes, le rapport a échoué, quelle que soit la qualité de son contenu technique.

Écrire pour vos lecteurs

Des personnes différentes lisent des parties différentes du même rapport :

La réponse non technique vient donc en premier, suivie de sections de plus en plus techniques, chacune utilisable indépendamment.

Anatomie d’un rapport de triage

Résumé (BLUF)

L’essentiel d’abord (bottom line up front). Deux à cinq phrases : ce qu’est le fichier, le verdict avec sa confiance, la ou les deux capacités qui comptent, et l’action la plus importante. Aucun nom d’outil, aucun hexadécimal, aucun jargon qu’un manager devrait aller chercher. Rédigez-le en dernier, placez-le en premier.

Verdict et confiance

Une ligne pour chaque élément : le verdict (malveillant, suspect, potentiellement indésirable, bénin, inconnu), la famille si elle est identifiée, et la confiance. Puis une courte justification qui renvoie aux sections de preuves plus bas.

Identification du fichier

Un tableau contenant tout ce qu’il faut pour retrouver ce fichier exact : noms de fichier observés, taille, type, MD5, SHA-1, SHA-256, et les hashs de similarité vus dans Identifier et hacher les fichiers (imphash, ssdeep ou TLSH). Ajoutez la provenance du fichier (hôte, chemin, e-mail, ticket), la date de collecte, et l’horodatage de compilation avec une note indiquant qu’il peut être falsifié.

Capacités rattachées à ATT&CK

Listez ce que l’échantillon peut faire, chaque capacité avec sa preuve et un identifiant de technique MITRE ATT&CK comme T1140 ou T1071.001. Les identifiants ATT&CK offrent aux threat hunters et aux ingénieurs détection un vocabulaire commun, et permettent à une équipe CTI de comparer cet échantillon à d’autres. La sortie de capa vue dans Lire les capacités à partir des imports est un bon point de départ, mais chaque rattachement que vous publiez engage votre responsabilité : vérifiez-le.

Ne rattachez que ce que les preuves étayent, et précisez de quel type de preuve il s’agit. Un import de CreateRemoteThread est la preuve d’une capacité, pas la preuve que l’échantillon l’utilise.

Indicateurs de compromission

Séparez les IOC selon l’endroit où un défenseur les cherchera :

• Indicateurs hôte : hashs, chemins et noms de fichiers, mutex, pipes nommés, clés de registre, noms de services, noms de tâches planifiées, chemins PDB.
• Indicateurs réseau : domaines, IP, URL, user-agents, motifs d’URI, certificats TLS ou empreintes JA3/JA4.

Donnez à chaque IOC un type, une valeur et une courte note de contexte : « mutex créé au démarrage, probablement une vérification d’instance unique » est bien plus utile qu’une chaîne brute. Signalez les IOC qui n’ont été vus qu’en statique, car ils peuvent être inutilisés ou servir de leurres.

Neutralisez (defang) les indicateurs réseau pour que personne ne clique dessus ni ne les résolve automatiquement, et pour que les filtres de messagerie et les clients de chat ne les transforment pas en liens actifs :

Neutralisez dans la prose et les tableaux destinés aux humains ; fournissez un export lisible par machine (voir plus bas) avec les valeurs d’origine pour les outils.

Contenu de détection

Les règles YARA d’Écrire vos premières règles YARA, plus tout ce que vous avez produit d’autre : Sigma, requêtes EDR, signatures Suricata. Pour chaque règle, indiquez contre quoi elle a été testée (variantes, corpus de goodware) et son bruit attendu. Une règle non testée doit le dire.

Actions recommandées

Concrètes, attribuées et ordonnées : bloquer ces hashs, déployer cette règle en mode alerte seule pendant une semaine, rechercher ce mutex sur l’ensemble du parc, réinstaller cet hôte. Adaptez les actions au verdict et à la confiance ; un verdict à faible confiance ne doit pas déclencher de blocage sur tout le parc.

Questions ouvertes et étapes suivantes

Ce que le triage n’a pas pu établir, et l’analyse qui permettrait de l’établir : « La charge utile de deuxième étape est chiffrée dans RT_RCDATA ; une analyse dynamique ou la rétro-ingénierie du décodeur à 0x401A20 est nécessaire pour la récupérer. » Cette section est le passage de relais vers l’étape suivante de l’entonnoir, et elle vous oblige à rester honnête sur les limites du triage.

Notes de l’analyste et outillage

Qui l’a analysé, quand, en combien de temps, avec quels outils et quelles versions, et tout élément étrange que vous avez remarqué sans pouvoir l’expliquer. Les versions des outils comptent : les jeux de règles capa et les modules YARA évoluent, et un lecteur doit pouvoir reproduire vos résultats.

Dire à quel point vous êtes sûr

« C’est un malware » et « c’est peut-être un malware » conduisent à des actions très différentes : la confiance doit donc être explicite et utiliser des termes cohérents. Une convention courante, empruntée à l’analyse du renseignement :

Associez la confiance aux jugements, pas aux faits. « Le fichier importe WriteProcessMemory » n’a besoin d’aucun niveau de confiance : c’est observé. « L’échantillon injecte du code dans d’autres processus » est un jugement, et en a besoin.

Observé ou inféré

L’erreur la plus fréquente dans un rapport de triage consiste à présenter une inférence comme une observation. Séparez-les visiblement :

Des mots comme observé, présent, importe, contient signalent des faits. Estimer, probablement, suggère, compatible avec signalent une inférence.

Astuce : Lorsqu’une preuve statique contredit une hypothèse, dites-le. « Une chaîne de user-agent est présente, mais aucun import réseau n’a été observé ; la chaîne est peut-être inutilisée, ou les API réseau sont peut-être résolues à l’exécution » est un constat de triage parfaitement valable, et il indique à l’analyste suivant exactement quoi vérifier.

Partage : TLP, STIX et MISP

Étiquetez chaque rapport avec le Traffic Light Protocol (TLP 2.0, maintenu par le FIRST) pour que les destinataires sachent jusqu’où ils peuvent le diffuser :

Placez l’étiquette en tête du rapport et sur toute donnée exportée. Les rapports internes sur un incident en cours sont généralement en TLP:AMBER ou plus strict ; une analyse expurgée d’une famille grand public peut être en TLP:CLEAR.

Pour une consommation par des machines, les IOC circulent sous forme de données structurées plutôt que de prose. STIX 2.1 (un standard OASIS) modélise les indicateurs, les malwares, les relations et les motifs ATT&CK sous forme d’objets JSON, généralement échangés via TAXII. MISP est une plateforme de partage open source largement déployée, avec son propre format d’événements et d’attributs et un import/export STIX. Votre rapport renvoie à l’événement ou au bundle ; le rapport en prose reste la référence lisible par un humain.

Un modèle de rapport

Copiez ce squelette et remplissez-le. Chaque titre est conservé, même si son contenu est « rien d’observé », pour que les lecteurs sachent que vous avez vérifié.

TLP:<LABEL>
# Triage report: <file name or family> (<report ID>)
Analyst: <name> | Date: <YYYY-MM-DD> | Time spent: <minutes>

## 1. Executive summary
<2-5 sentences, plain language, verdict + confidence + key action>

## 2. Verdict
Verdict: <malicious | suspicious | PUA | benign | unknown>
Family: <name or "unidentified">
Confidence: <low | moderate | high>
Rationale: <1-3 bullets pointing at sections 4-5>

## 3. File identification
| Field | Value |   (names, size, type, MD5, SHA-1, SHA-256, imphash,
                     ssdeep/TLSH, compile time, source, collection time)

## 4. Capabilities
| Capability | Evidence (observed / inferred) | ATT&CK |

## 5. Indicators of compromise
### Host   | Type | Value | Context |
### Network | Type | Value (defanged) | Context |

## 6. Detection content
<rules, what they were tested against, expected noise>

## 7. Recommended actions
<ordered, concrete, with owners>

## 8. Open questions and next steps

## 9. Analyst notes and tooling
<tools and versions, environment, anything unexplained>

Exemple de rapport : LabImplant v1 (fictif)

Attention : Tout le contenu de cette section est un exemple fictif rédigé à propos du programme d’entraînement bénin compilé dans Écrire vos premières règles YARA. Il n’y a ni incident, ni hôte, ni acteur malveillant réels. Les hashs proviennent d’un build de ce programme ; les vôtres différeront.

TLP:CLEAR · Rapport TR-2026-0929-01 · Analyste : A. Analyst · 2026-09-29 · Temps passé : 30 minutes

1. Résumé

Un fichier nommé lab_implant.exe, trouvé dans le laboratoire de formation à l’analyse de malwares, a fait l’objet d’un triage statique. Nous estimons avec une confiance élevée qu’il n’est pas malveillant : il s’agit d’un programme d’entraînement qui contient des chaînes ressemblant à des artefacts d’implant (un user-agent personnalisé, un nom de mutex, un nom de pipe nommé et une chaîne de configuration), mais qui n’a aucune capacité réseau, de persistance ou d’injection. Aucun confinement n’est nécessaire. Une règle YARA a été produite pour que les copies du lab soient reconnues et ne soient pas remontées comme de vrais incidents.

2. Verdict

• Verdict : Bénin (artefact d’entraînement)
• Famille : Aucune ; programme interne du lab « LabImplant »
• Confiance : Élevée
• Justification : La table des imports ne contient que des fonctions du runtime C et de KERNEL32.dll liées par le runtime mingw-w64 (section 4) ; les chaînes évoquant un implant ne sont référencées par aucune API qui les utiliserait ; le code décode un blob de 5 octets en le texte demo! et affiche ses chaînes.

3. Identification du fichier

4. Capacités

VirtualProtect, VirtualQuery et Sleep figurent dans la table des imports. Ils sont importés par le code de démarrage du runtime mingw-w64, et non par les fonctions propres au programme, et ne sont pas considérés comme des preuves de capacité.

5. Indicateurs de compromission

Indicateurs hôte

Indicateurs réseau

6. Contenu de détection

MAL_Win_LabImplant_Strings version 1.2 (règle complète dans la leçon YARA). Testée : correspond aux builds v1 (-O0) et v2 (-O2, version 1.1) ; aucune correspondance lors d’une analyse de /usr/bin avec la vérification d’en-tête désactivée ; ne correspond pas à la copie packée avec UPX (SHA-256 4b956e927c41f7c4d9499840733f8cc44bad66b5893309d2d5d56d5dc92e9532), qui n’est détectée que par la règle de chasse générique SUSP_PE_FewSections_NoText. Bruit attendu : aucun connu.

7. Actions recommandées

1. Équipe du lab : ajouter la règle au scanner du lab avec l’étiquette training, pour que les copies du lab soient clôturées automatiquement plutôt que remontées.
2. SOC : aucune action sur les systèmes de production.
3. Ingénierie de détection : utiliser cet échantillon et cette règle comme test de non-régression du banc de test YARA.

8. Questions ouvertes et étapes suivantes

• Un futur build importera-t-il des API réseau ou de synchronisation ? Si oui, refaire le triage : le verdict repose sur leur absence.
• La variante packée avec UPX n’est pas couverte par la règle sur les chaînes. Si des builds packés sont distribués, ajouter un déploiement de la règle en analyse mémoire ou une règle pour l’image dépaquetée.

9. Notes de l’analyste et outillage

Analyse statique uniquement ; l’échantillon n’a pas été exécuté. Outils : file, strings, FLOSS, Python pefile, x86_64-w64-mingw32-objdump, YARA 4.5.4, Detect It Easy. Hôte d’analyse : VM de laboratoire isolée, sans réseau.

Lab : un triage chronométré de 30 minutes

Prenez l’un des binaires que vous avez compilés dans ce module : build/v2/lab_implant.exe, le lab_implant_upx.exe packé avec UPX, ou une variante issue des labs sur le hachage, les chaînes, les imports ou les packers. Pour un test honnête, demandez à un collègue d’en choisir un et de le renommer sample.bin. Lancez un chronomètre et suivez la liste de contrôle ; arrêtez-vous à 30 minutes quel que soit l’état d’avancement, car le triage se définit par sa limite de temps.

1. Suivez la liste de contrôle en consignant les constats directement dans le modèle :

   Minutes	Étape	Outils	À consigner dans le rapport
   0–3	Hacher et identifier le fichier ; noter la taille et le type réel	sha256sum, file, Detect It Easy	Section 3
   3–5	Recherche de réputation par hash uniquement ; vérifier votre propre dépôt	Recherche VirusTotal, dépôt interne	Section 3, notes
   5–9	En-têtes et sections : horodatage, noms de sections, tailles, entropie	pefile, PE-bear	Section 3 ; packer oui/non
   9–12	Si packé : identifier le packer, le noter, décider s’il faut l’unpacker maintenant	Detect It Easy, upx -t	Sections 2 et 8
   12–17	Chaînes : ASCII, UTF-16 et décodées, y compris les stackstrings et les chaînes chiffrées par XOR ; présélectionner les artefacts	strings, FLOSS	Candidats pour la section 5
   17–21	Imports et capacités ; séparer le bruit du runtime	pefile, capa	Section 4
   21–23	Ressources et overlay	pefile, Resource Hacker	Sections 4 et 5
   23–27	Rédiger et tester une règle YARA contre l’échantillon et un dossier de goodware	yara -s	Section 6
   27–30	Verdict, confiance, résumé, étapes suivantes	Votre jugement	Sections 1, 2, 7, 8

2. Remplissez chaque titre du modèle. Écrivez « rien d’observé » plutôt que de supprimer une section.

3. Étiquetez chaque affirmation des sections 4 et 5 comme observée ou inférée, et associez un niveau de confiance au verdict.

4. Neutralisez chaque indicateur réseau, puis échangez vos rapports avec un collègue (ou attendez un jour) et notez-le avec la grille ci-dessous.

Grille d’autoévaluation. Notez chaque ligne 0 (absent), 1 (partiel) ou 2 (fait) ; visez 16 ou plus sur 20.

Questions : Avez-vous terminé en 30 minutes, et quelle étape a débordé ? Lesquelles de vos affirmations sur les capacités changeraient s’il s’avérait que l’échantillon résout ses imports à l’exécution ? Si vous avez trié la copie packée avec UPX, que pouviez-vous honnêtement dire de ses capacités, et avec quelle confiance ? Votre résumé aurait-il un sens pour quelqu’un qui n’a jamais entendu parler d’un fichier PE ?

À retenir

• Un rapport de triage appuie des décisions : est-ce malveillant, que fait-il, que bloquer et que rechercher, faut-il une analyse plus approfondie.
• Commencez par l’essentiel et un verdict assorti d’une confiance explicite ; ordonnez le reste du moins technique au plus technique pour que chaque lecteur trouve sa partie.
• Séparez les faits observés des inférences, et associez les niveaux de confiance aux jugements, pas aux faits.
• Ne rattachez les capacités à ATT&CK que là où les preuves les étayent, séparez les IOC en hôte et réseau, et neutralisez chaque indicateur réseau.
• Incluez un contenu de détection testé, des actions recommandées concrètes, les questions ouvertes et les versions des outils, et étiquetez le rapport avec TLP avant de le partager, lui ou son export STIX/MISP.