IoC ou TTP pour détecter une compromission

Parcours « Débuter en cybersécurité » — étape 11/12

← 10Ransomware-as-a-Service et double extorsion12Réagir aux premières minutes d’un incident suspecté →

IoC ou TTP pour détecter une compromission

Un indicateur de compromission, ou IoC (Indicator of Compromise), relie une trace observable à une activité hostile connue. C’est précieux pour bloquer vite, mais cette valeur décroît brutalement dès que l’adversaire renouvelle son infrastructure ou recompile son outil. La détection durable s’appuie donc sur les TTP (Tactics, Techniques and Procedures), c’est-à-dire les comportements nécessaires à l’attaque, pas seulement sur ses accessoires jetables.

Explication de la marmotte

Un indicateur ressemble à une photo d’un cambrioleur prise devant une porte. Elle aide à reconnaître cette personne si elle repasse, mais elle ne détecte pas son complice, son nouveau manteau ou une autre entrée. Chercher ses habitudes permet de surveiller plus longtemps, avec davantage de travail.

→ Lire l’explication complète de la marmotte

IoC : traces précises, durée de vie courte

Un IoC est une valeur technique attribuable à une campagne, un logiciel malveillant ou une infrastructure d’attaque. Les catégories courantes sont les suivantes :

• le condensat cryptographique, ou hash, d’un fichier malveillant, par exemple SHA-256 ;
• l’adresse IP d’un serveur de commande et contrôle, ou C2 (Command and Control) ;
• le nom de domaine utilisé pour distribuer une charge ou recevoir des ordres ;
• une URL, un chemin de téléchargement ou un certificat TLS (Transport Layer Security) particulier ;
• une signature réseau, telle qu’une séquence d’octets, un en-tête HTTP (Hypertext Transfer Protocol) ou un motif DNS (Domain Name System).

Le hash est l’IoC le plus fragile. Modifier une ressource embarquée, recompresser l’exécutable ou changer son empaqueteur suffit à produire une nouvelle empreinte. Une règle qui bloque uniquement un SHA-256 bloque donc un échantillon, pas une famille malveillante. C’est une mesure de confinement ponctuelle, jamais une stratégie de détection.

L’adresse IP de C2 tient parfois quelques heures. Les réseaux de diffusion de contenu, les serveurs compromis, les fournisseurs de machines virtuelles et le DNS dynamique permettent une rotation rapide. Bloquer une IP reste rationnel lorsqu’une connexion est en cours ou qu’une campagne est active, mais convertir chaque adresse reçue en règle pare-feu permanente fabrique une liste de dettes techniques. Elle grossit, ralentit les investigations et finit par bloquer des services légitimes recyclés par un hébergeur.

Les domaines vivent un peu plus longtemps lorsqu’ils sont intégrés à une infrastructure d’hameçonnage ou à un mécanisme de génération de domaines. Ils restent pourtant éphémères face à une révocation rapide, un changement de registraire ou une bascule vers un autre domaine. Un domaine récemment enregistré n’est pas malveillant par nature. Le traiter comme tel sans contexte produit des faux positifs, notamment sur les services de test, les acquisitions et les filiales qui découvrent soudain la joie d’un blocage DNS centralisé.

Le compromis central est net : les IoC donnent une réponse rapide, déterministe et automatisable, mais paient cette vitesse par une couverture étroite et périssable. Il faut les consommer pour le blocage immédiat et le pivot d’investigation, avec une date d’expiration explicite. Il ne faut pas mesurer la maturité de détection au nombre de lignes dans une liste noire. Ce compteur flatte les slides et nourrit surtout les fichiers CSV.

La surface de menace doit être évaluée selon le type d’indicateur. Un hash agit sur les postes où l’exécution est observée. Une IP agit sur le trafic visible depuis le point de contrôle. Un domaine agit sur les requêtes DNS collectées. Une signature réseau exige que le trafic ne soit pas chiffré de bout en bout, ou qu’une inspection TLS soit légalement et techniquement possible. L’absence d’observation rend l’IoC inopérant, pas discret.

TTP : détection des comportements récurrents

Les TTP décrivent ce que fait l’adversaire pour atteindre son objectif. Une tactique est l’intention, par exemple persister ou exfiltrer. Une technique est le moyen général, par exemple créer une tâche planifiée. Une procédure est l’implémentation observée, par exemple le nom d’une tâche, la commande exacte et le compte utilisé.

Les TTP survivent davantage aux changements d’infrastructure, car l’attaquant doit toujours obtenir des identifiants, exécuter du code, élever ses privilèges, se déplacer et exporter des données. Les outils changent. Certaines contraintes opérationnelles, beaucoup moins. Un groupe peut remplacer son domaine C2 en une minute, mais contourner durablement les journaux d’authentification, les contrôles de privilèges et les restrictions de sortie demande plus qu’un nouveau nom de domaine.

La détection moderne doit partir d’une hypothèse comportementale : « un compte de service ne doit pas ouvrir de session interactive », « un serveur applicatif ne doit pas créer de tâche planifiée », « une station bureautique ne doit pas résoudre puis contacter des domaines nouveaux à cadence algorithmique ». Cette méthode prolonge le threat hunting et l’observation réseau : l’IoC accélère le pivot, l’hypothèse révèle les activités inconnues.

Une règle TTP doit conserver son contexte. Détecter powershell.exe n’est pas une détection, c’est une alarme incendie posée sur la cafetière. Détecter le lancement de PowerShell par une application de messagerie, suivi d’un téléchargement distant, puis de la création d’une persistance, forme en revanche une séquence exploitable. La corrélation doit inclure le parent du processus, l’identité, l’hôte, la ligne de commande, les connexions sortantes et l’horodatage.

Les TTP ne garantissent pas l’attribution à un groupe. Plusieurs acteurs emploient les mêmes techniques, parfois parce qu’elles sont efficaces, parfois parce que les tutoriels publics ont fait le travail pédagogique à leur place. Une alerte comportementale établit un écart à un modèle attendu, pas une certitude sur l’auteur ni sur l’intention. La qualification reste humaine et doit recouper les actifs concernés, les changements prévus et les journaux disponibles.

MISP, STIX et TAXII : partager sans avaler le bruit

MISP (Malware Information Sharing Platform) est une plateforme de partage et de structuration du renseignement sur la menace. Elle regroupe des événements, des attributs, des relations, des niveaux de confiance et des marquages de diffusion. Sa valeur n’est pas seulement de recevoir une liste d’IP : elle permet de conserver le contexte, la source, la date d’observation et les liens entre artefacts.

STIX (Structured Threat Information Expression) est un format de représentation du renseignement sur la menace. TAXII (Trusted Automated Exchange of Intelligence Information) est un protocole d’échange de ces informations. Une organisation peut ainsi récupérer automatiquement des objets structurés depuis une communauté, un prestataire ou une équipe sectorielle, puis les distribuer à son SIEM (Security Information and Event Management), à son EDR (Endpoint Detection and Response), à son DNS filtrant ou à son pare-feu.

L’automatisation sans politique de confiance est une mauvaise idée avec une belle API. Chaque flux doit être classé par source, périmètre, fraîcheur, confiance et action autorisée. Un flux communautaire peut alimenter une recherche rétrospective dans les journaux, sans déclencher un blocage. Un flux validé et spécialisé peut être autorisé à créer un blocage DNS temporaire. Un flux commercial n’obtient pas une présomption d’exactitude parce qu’il arrive en JSON (JavaScript Object Notation).

Les métadonnées décident de la qualité opérationnelle :

• first_seen et last_seen pour déterminer l’âge réel ;
• niveau de confiance attribué par la source et niveau de confiance local ;
• type d’indicateur et protocole observé ;
• campagne, famille de logiciel ou technique associée ;
• durée de vie maximale, ou TTL (Time To Live), avant désactivation ;
• marquage de partage, notamment TLP (Traffic Light Protocol), qui limite la rediffusion.

Un IoC reçu sans date, sans source ni contexte doit être considéré comme une piste, pas comme une règle de blocage. Le renseignement arrive fréquemment après la détection publique, donc après la rotation de l’infrastructure. L’attaquant n’attend pas la réunion de gouvernance pour changer de domaine. L’intérêt du partage demeure réel : rechercher rétrospectivement un domaine dans les journaux DNS ou un hash dans les inventaires peut révéler une compromission passée, même si le blocage arrive trop tard.

Exemple : rechercher un IoC DNS et borner son usage

Le premier traitement d’un domaine hostile consiste à rechercher son apparition, puis à appliquer une expiration au blocage. La commande suivante interroge Elasticsearch via son API REST (Representational State Transfer), en supposant des journaux DNS indexés avec Elastic Common Schema. Elle ne remplace pas une règle de détection TTP, elle fournit les hôtes à investiguer.

# Rechercher sur 30 jours les résolutions du domaine signalé.
# Remplacer ELASTIC_URL et API_KEY par des variables d'environnement protégées.
curl --fail --silent \
  -H "Authorization: ApiKey ${API_KEY}" \
  -H "Content-Type: application/json" \
  "${ELASTIC_URL}/logs-dns-*/_search" \
  -d '{
    "size": 100,
    "query": {
      "bool": {
        "filter": [
          { "term": { "dns.question.name": "cdn-update-example.net" } },
          { "range": { "@timestamp": { "gte": "now-30d/d" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": "asc" }],
    "_source": [
      "@timestamp",
      "host.name",
      "user.name",
      "process.name",
      "destination.ip",
      "dns.answers.data"
    ]
  }'

Un résultat doit déclencher une collecte ciblée : processus à l’origine de la résolution, connexions postérieures, fichier exécuté, compte utilisé et persistance éventuelle. Bloquer le domaine sans rechercher les connexions antérieures laisse peut-être une session C2 déjà établie, un implant local ou des identifiants volés. Le DNS ne remonte pas le temps, malgré les promesses d’une plateforme « pilotée par intelligence artificielle ».

Les secrets d’API utilisés pour récupérer des flux STIX/TAXII ou interroger un SIEM doivent être stockés dans un gestionnaire de secrets, limités au périmètre requis et tournés. Leur exposition permettrait d’empoisonner les règles de détection, d’exfiltrer les recherches et parfois de désactiver des alertes. Ce n’est pas un détail d’intégration : le pipeline de renseignement est une surface d’administration.

Cycle de vie, supervision et reprise des indicateurs

Un IoC doit suivre un cycle de vie explicite : réception, normalisation, enrichissement, décision, diffusion, expiration et archivage. La normalisation élimine les doublons et valide les types. L’enrichissement ajoute réputation, résolution DNS, propriétaire d’adresse, certificats associés et correspondances internes. La décision associe une action proportionnée : observer, rechercher, alerter ou bloquer.

L’expiration est obligatoire. À défaut de donnée contraire, une IP et un domaine destinés au blocage doivent recevoir un TTL court, puis être réévalués à partir d’observations locales. Les hashes peuvent être conservés davantage pour la recherche historique, mais leur blocage doit être révisé lors des changements de produit ou des collisions de nommage. Le retrait automatique d’un IoC doit être journalisé avec sa source, sa date, sa règle cible et le motif. Sans cela, le déblocage devient un rituel archéologique.

La supervision porte sur quatre plans : échec de récupération du flux, variation anormale du volume d’indicateurs, taux de faux positifs et efficacité de détection. Une hausse brutale de domaines peut signaler une source mal configurée. Une chute à zéro peut signaler une panne d’API. Dans les deux cas, laisser tourner la chaîne en silence revient à installer un détecteur de fumée sans pile, version entreprise.

Les sauvegardes doivent inclure la configuration de scoring, les règles de transformation, les listes d’autorisation, les clés d’API chiffrées et l’historique des décisions. Restaurer seulement les IoC bruts restaure du bruit ; restaurer le contexte et les règles permet de retrouver le comportement attendu. La reprise doit aussi empêcher la réinjection massive d’indicateurs expirés après restauration. Une sauvegarde qui ressuscite les blocages de l’an dernier n’est pas une reprise, c’est une séance de spiritisme réseau.

🐝 Ce qui arrive si on s’en passe

Sans cette chaîne, la détection repose sur ce qui reste visible au moment exact de l’attaque : une fois l’infrastructure renouvelée, plus rien ne raccroche les traces entre elles. Un signalement externe arrive alors sans moyen de le convertir en recherche : impossible de dire depuis quand un domaine est résolu, quels postes l’ont contacté, ni où s’arrête le périmètre touché. La qualification se fait au cas par cas, sans date d’observation ni source, donc sans possibilité de rejouer une décision ou de justifier un blocage lors d’un audit. Les règles accumulées sans expiration restent actives indéfiniment et coupent un jour un service légitime hébergé sur une adresse recyclée, sans que le motif initial soit retrouvable. La reprise après incident hérite alors de listes brutes, sans contexte ni historique de décisions.

🦫 Explication de la marmotte 🍫

Un indicateur de compromission est une donnée qui a été liée à une attaque : le nom d’un site utilisé par l’attaquant, l’adresse d’une machine distante, ou la signature d’un fichier dangereux. Les outils de sécurité comparent leurs journaux et leurs connexions avec ces données. Lorsqu’une correspondance apparaît, ils peuvent prévenir une équipe ou bloquer une communication.

Cette méthode échoue souvent avec le temps. Un attaquant peut changer l’adresse de sa machine, créer un nouveau nom de site ou modifier légèrement son fichier. L’ancien indicateur ne correspond alors plus à rien. Il faut donc conserver sa date, sa source et une durée maximale d’utilisation. Un indicateur ancien sert surtout à rechercher une attaque passée dans les journaux.

La détection cherche aussi les comportements. Une attaque doit souvent lancer un programme inhabituel, voler un compte, créer un accès durable ou envoyer des données vers l’extérieur. Ces actions restent observables même si les noms, les fichiers et les adresses changent. Elles demandent toutefois plus de données et une analyse du contexte pour éviter de signaler une activité normale.

Des plateformes permettent de recevoir des indicateurs envoyés par d’autres victimes ou par des spécialistes. Avant de les bloquer automatiquement, il faut vérifier leur date, leur origine et leur niveau de confiance. Un renseignement reçu trop tard, faux ou incomplet peut bloquer un service légitime et masquer le vrai problème.

À lire aussi

• Pourquoi la threat intelligence commerciale alarmeAnalyse des incitations économiques et des biais d'attribution des fournisseurs de threat intelligence commerciale, avec une méthode de consommation critique.
• Comment attribuer techniquement une cyberattaqueL’attribution d’une cyberattaque repose sur des faisceaux d’indices probabilistes, distincts de la décision politique de désigner officiellement un État ou un groupe.
• Collecter et fiabiliser les logs de sécuritéCollecter, horodater, normaliser et contrôler les événements de sécurité conditionne la détection autant que le choix du SIEM.
• Comment calibrer les alertes d’un SIEM sans noyer le SOCLa théorie de la détection explique pourquoi un SIEM trop bavard épuise les analystes, tandis qu’un SIEM silencieux masque les menaces réelles.

Pages voisines

La citent

• Comment attribuer techniquement une cyberattaque
• Monter un CSIRT interne, missions, services FIRST et rattachement
• CCCS Canada et ACSC Australie dans les Five Eyes
• Centraliser les journaux Sysmon des postes Windows
• CERT-EU réponse aux incidents des institutions européennes
• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense

IoC ou TTP pour détecter une compromission

Elle cite

• ⇄Lien dans les deux sens :Comment formuler une hypothèse de threat hunting
• ⇄Lien dans les deux sens :Partager le renseignement sur la menace avec ISAC, MISP et STIX
• Normaliser les logs avec OCSF, ECS ou CIM

⇄ : les deux pages se citent l’une l’autre.