Comment importer dans MISP les IOC d’un échantillon de malware ?

Exportez-les en événement MISP au format JSON : chaque indicateur devient un attribut avec un type MISP (url, domain, ip-dst, hostname|port, regkey, mutex, sha256…) et une catégorie. Dans MISP, utilisez Event actions, puis Import from, puis MISP JSON. Vérifiez les drapeaux to_ids avant de publier.

Que signifie neutraliser (defang) un IOC ?

Réécrire un indicateur réseau pour qu’il ne puisse pas être cliqué ou résolu par accident : http devient hxxp, les points deviennent [.], @ devient [@]. Les valeurs neutralisées servent aux rapports et à la messagerie ; les exports destinés aux outils gardent les valeurs d’origine.

D’un fichier PE aux IOC : MISP, STIX 2.1 et règle YARA

En bref. Chaînes, configurations décodées et code émulé fournissent tous des indicateurs — URL, domaines, IP, clés de registre, mutex, canaux nommés, empreintes. Le PE Parser les rassemble dans un onglet IOC, masque le bruit habituel et les exporte en CSV, en liste neutralisée, en événement MISP ou en bundle STIX 2.1, pour un fichier ou tout un lot. Il peut aussi ébaucher une règle YARA à partir des chaînes les plus distinctives du fichier.

D’où viennent les indicateurs

Les chaînes statiques, ASCII et UTF-16, plus le texte décodé du Base64.
Les configurations malveillantes décodées : serveurs C2, user-agents, canaux nommés et mutex des balises Cobalt Strike et de quelques familles de RAT (lire une configuration de balise).
Les chaînes récupérées dans le code par émulation — chaînes de pile et chaînes décodées qu’une extraction classique ne voit pas (chaînes de pile).
Le fichier lui-même : MD5, SHA-1, SHA-256, l’imphash et le chemin PDB.

Ce qui est extrait, ce qui est filtré

L’onglet regroupe les indicateurs par type : C2 (hôte:port), URL, domaine, IPv4, adresse onion, e-mail, user-agent, clé de registre, chemin, canal nommé, mutex, PDB, portefeuilles de cryptomonnaie (Bitcoin, Ethereum, Monero) et empreintes.

Les binaires regorgent de texte qui ressemble à un indicateur sans en être un. Quelques règles gardent la liste utile :

Les domaines doivent avoir un vrai domaine de premier niveau, et sont écartés s’ils ressemblent à un espace de noms .NET (System.IO, Newtonsoft.Json) ou à un nom de fichier (readme.md, setup.py).
Les adresses IP qui ressemblent à des numéros de version (6.0.0.0, 1.2.3.4) sont écartées.
L’infrastructure connue — autorités de certification (URL de CRL et OCSP dans les fichiers signés), schémas XML, Microsoft — et les adresses privées ou de boucle locale sont gardées mais masquées derrière une case Afficher les connus.

Chaque indicateur indique où il a été trouvé ; cliquez l’offset pour voir les octets dans la vue hexadécimale.

Neutralisation

Les indicateurs sont affichés neutralisés par défaut — hxxps[://]evil[.]example/gate, 10[.]0[.]0[.]1, user[@]example[.]com — pour qu’un rapport ou un message ne se transforme pas en clic ou en requête DNS accidentels. Décochez Neutraliser pour voir les valeurs brutes. La liste texte neutralisée est faite pour les humains ; les exports CSV, MISP et STIX portent les valeurs d’origine (le CSV contient les deux).

Exporter

Format	Usage
CSV	Tableurs, filtrage rapide ; type, valeur, valeur neutralisée, source, offset, fichier et empreinte du fichier par ligne
Liste texte neutralisée	Rapports et tickets
Événement MISP (JSON)	Import dans MISP : un attribut par indicateur avec son type et sa catégorie MISP ; `to_ids` activé pour les indicateurs réseau et les empreintes, pas pour les chemins
Bundle STIX 2.1	TIP et SIEM qui acceptent STIX : un objet indicator par IOC avec un motif STIX (`[domain-name:value = '…']`, `[file:hashes.'SHA-256' = '…']`, `[network-traffic:…]`)

Depuis l’onglet IOC d’un fichier, vous exportez ce fichier ; depuis le menu Exporter de la barre d’outils, tout le lot (ou la plage horaire en cours), analyses de code déjà lancées comprises.

Dans MISP, relisez avant de publier : l’événement est créé non publié, et ce qui est marqué connu est laissé de côté sauf si vous avez choisi de l’afficher.

Une ébauche YARA à partir des mêmes éléments

Ébaucher une règle YARA construit une règle à partir du fichier :

d’abord les chaînes les plus distinctives — valeurs C2, URL, chemin PDB, mutex, canaux nommés — puis du texte long et spécifique, en écartant noms d’API, messages du runtime du compilateur et chaînes issues de données compressées ;
une condition qui exige un en-tête MZ, une borne de taille et soit deux chaînes fortes, soit une part des plus faibles, soit l’imphash du fichier ;
un bloc meta avec le SHA-256 et la date.

La règle s’ouvre dans le panneau YARA, où vous pouvez la lancer sur tous les fichiers chargés d’un coup : touche-t-elle les autres échantillons de la famille, et seulement eux ? Ajustez, relancez, puis copiez le résultat dans votre jeu de règles. C’est une ébauche — l’idée est de partir des bonnes chaînes, pas de se passer de tests.

Limites

Correspondance de texte. Un indicateur est ce que le fichier contient, pas ce qu’il a utilisé. Une URL dans un message d’aide reste une URL.
Empreintes des fichiers reconstruits. Les fichiers dépaquetés par l’outil sont reconstruits ; leurs empreintes ne correspondent à aucun fichier ayant existé sur disque et ne doivent pas être partagées comme IOC de fichier.
Les chaînes cachées restent cachées sauf si l’analyse du code les récupère, ou si le fichier est d’abord dépaqueté.

Combiné à la vue par lot, cela transforme un dossier d’exécutables suspects en un jeu d’IOC relu en quelques minutes — sans envoyer un seul fichier.