Comment attribuer techniquement une cyberattaque

Attribuer une intrusion ne consiste pas à coller un drapeau sur une adresse IP ni à reconnaître trois lignes de code vues dans un rapport public. L’objectif opérationnel est d’estimer quels moyens, quelles motivations et quelles capacités l’adversaire peut encore mobiliser, puis de décider avant que le dossier soit intellectuellement confortable.

→ Lire l’explication complète de la marmotte

Attribution technique : un jugement probabiliste, pas un verdict

L’attribution technique cherche à relier une activité hostile observée à un groupe suivi, parfois appelé acteur de menace. Elle repose sur un faisceau d’indices : tactiques, techniques et procédures, souvent abrégées TTP pour Tactics, Techniques and Procedures ; infrastructure réseau ; charge utile ; habitudes de compilation ; fenêtres d’activité ; choix des victimes ; erreurs opératoires.

Aucun de ces éléments ne suffit isolément. Une adresse IP peut être louée, compromise ou utilisée comme relais. Un domaine peut être enregistré sous une fausse identité. Un outil malveillant peut être acheté, volé ou publié. Un fuseau horaire déduit de l’activité peut refléter une équipe distribuée, une tâche planifiée ou un opérateur insomniaque. L’horloge d’un serveur compromis ne révèle pas la géopolitique, elle révèle surtout que quelqu’un a configuré une horloge.

La recommandation est nette : exprimer une attribution sous forme d’hypothèse avec niveau de confiance et preuves contradictoires. Par exemple : « activité cohérente avec le groupe X, confiance modérée, principalement fondée sur la chaîne d’exécution et trois domaines historiquement associés ». Écrire « attaque menée par X » sans qualifier l’incertitude transforme une hypothèse de renseignement en fait médiatique. C’est pratique pour les slides, moins pour une réponse à incident.

Le compromis central est direct : augmenter l’exigence de preuve réduit les faux positifs d’attribution, mais retarde les décisions ; agir sur une hypothèse accélère le confinement, mais expose à une erreur de ciblage. Pour une organisation victime, il faut trancher en faveur de l’action défensive précoce. Bloquer une infrastructure, révoquer des identifiants ou isoler un segment ne nécessite pas un communiqué ministériel. Une certitude parfaite arrive généralement après la crise, parfois avec les dinosaures.

L’attribution doit donc rester séparée de la qualification de l’incident. Une compromission d’identité, une exfiltration et un mouvement latéral sont des faits observables. Le nom supposé de l’opérateur est une interprétation. Les deux données n’ont ni le même niveau de preuve, ni les mêmes destinataires, ni les mêmes conséquences.

TTP, infrastructure et artefacts : construire le faisceau de preuves

Les TTP décrivent la manière d’opérer : accès initial, persistance, élévation de privilèges, déplacement latéral, collecte et exfiltration. Une séquence rare est plus informative qu’une technique courante. L’usage de PowerShell seul ne signifie rien, car PowerShell est aussi utilisé par les administrateurs, les éditeurs et probablement quelques imprimantes mal élevées. Une combinaison précise de commandes, de chemins, de délais, de méthodes d’authentification et de mécanismes de nettoyage peut devenir discriminante.

L’infrastructure apporte des indices exploitables quand elle est corrélée, jamais lorsqu’elle est traitée comme une identité. Relever les domaines, certificats TLS (Transport Layer Security), serveurs de commande, résolveurs DNS (Domain Name System), fournisseurs d’hébergement et périodes d’activation permet de construire un graphe. Un domaine partagé avec une campagne antérieure peut renforcer une hypothèse, mais un adversaire compétent réemploie aussi des ressources d’autrui pour produire du bruit.

Les artefacts de code incluent les chaînes internes, les formats de configuration, les algorithmes de chiffrement employés, les identifiants de campagne, les erreurs de compilation et les mécanismes de mise à jour. La similarité de code doit être mesurée sur des portions significatives et contextualisées. Comparer un hachage de fichier ne suffit pas : une recompilation modifie le résultat sans changer la logique. À l’inverse, une fonction copiée depuis un dépôt public ne prouve aucune filiation. La réutilisation de code est parfois un indice, parfois juste le résultat prévisible d’Internet.

Les métadonnées de compilation méritent encore moins de confiance isolément. Date, langue système, chemin de compilation ou fuseau horaire peuvent être modifiés. Elles ont de la valeur lorsqu’elles corroborent d’autres observations indépendantes. Une date interne cohérente avec l’enregistrement d’un domaine et le début d’activité d’un certificat pèse davantage qu’un champ laissé par défaut dans un exécutable.

Conserver les données brutes est une condition non négociable. Journaux réseau, journaux d’authentification, captures de mémoire, fichiers récupérés et horodatages doivent être stockés avec une empreinte cryptographique, une source et une heure de collecte en temps universel coordonné, abrégé UTC pour Coordinated Universal Time. Sans chaîne de conservation, l’analyse devient difficile à reproduire et les preuves se transforment en captures d’écran. Les captures d’écran sont l’encens de l’investigation : elles sentent la preuve, mais elles brûlent vite.

Les exigences de journalisation rejoignent les principes décrits dans l’architecture cybersécurité et dans les sujets de réseau et observabilité. Une attribution sans visibilité sur les identités, les flux sortants et les événements d’administration n’est pas une analyse incomplète : c’est une supposition décorée.

Faux drapeaux et contamination des indices

Un faux drapeau consiste à imiter volontairement les traces d’un autre acteur pour provoquer une attribution erronée. L’imitation peut viser la langue des messages, les chaînes de caractères, les outils, les heures d’activité, les cibles ou les méthodes de chiffrement. Elle peut aussi utiliser une infrastructure déjà connue d’un groupe adverse, par compromis ou par achat de ressources semblables.

Le risque n’est pas théorique. Plus un indicateur est connu publiquement, moins il est fiable comme preuve d’identité. Les signatures d’outils, les listes de domaines et les rapports ouverts servent autant aux défenseurs qu’aux attaquants. Réutiliser une signature publique pour faire accuser un tiers ne demande pas une capacité étatique ; cela demande surtout de savoir lire et de ne pas laisser son propre nom dans le fichier ZIP.

Les faux drapeaux se détectent rarement par un indice magique. Il faut chercher les incohérences : une imitation superficielle des outils sans la discipline opérationnelle habituelle ; des heures d’activité incompatibles avec les délais de réponse observés ; une infrastructure réutilisée sans les mécanismes de cloisonnement caractéristiques ; des erreurs de langue trop parfaites ou trop caricaturales ; une cible qui ne correspond ni aux intérêts ni au modèle habituel du groupe supposé.

La défense ne doit pas dépendre de l’identité présumée. Une détection fondée sur le comportement, par exemple une création anormale de comptes privilégiés, une authentification impossible ou une exfiltration vers un service récemment créé, résiste mieux aux faux drapeaux qu’un blocage limité à une liste de domaines. Les contrôles d’identité restent donc centraux : désactiver les authentifications LDAP anonymes et en clair réduit une voie d’accès, quel que soit le logo imaginaire collé sur l’adversaire.

Attribution politique : une décision distincte de l’analyse

L’attribution politique désigne la décision officielle d’un État ou d’une organisation internationale de nommer publiquement un responsable, souvent un autre État ou un groupe soutenu par lui. Elle engage des relations diplomatiques, des sanctions, une coopération judiciaire, des mesures de rétorsion ou une communication de crise. L’analyse technique alimente cette décision, mais ne la détermine pas seule.

Les autorités disposent potentiellement de renseignements humains, judiciaires, financiers, diplomatiques ou issus d’interceptions légales qui ne seront pas publiés. L’absence de détail technique dans un communiqué officiel ne démontre donc pas l’absence de preuves. Inversement, une annonce publique très affirmative ne transforme pas automatiquement les indicateurs accessibles en certitude scientifique.

Une organisation victime ne doit pas attendre ce niveau de décision pour agir. Attendre l’attribution politique avant de révoquer les accès compromis revient à demander au feu d’indiquer sa nationalité avant d’ouvrir les sprinklers. L’équipe de réponse doit distinguer quatre décisions :

contenir les accès et les flux observés ;
préserver les éléments de preuve ;
informer les parties internes et contractuelles selon les procédures établies ;
transmettre les éléments qualifiés aux autorités compétentes lorsque nécessaire.

Le nom d’un groupe peut guider la recherche de persistance, les hypothèses sur l’exfiltration ou les scénarios de récidive. Il ne doit pas devenir le déclencheur unique de mesures de sécurité. Une organisation doit pouvoir répondre à l’activité observée même si le responsable reste « inconnu ».

Cette séparation évite aussi deux erreurs coûteuses : communiquer trop tôt une attribution fragile, puis devoir la corriger ; ou sous-estimer un incident parce que l’infrastructure ne correspond à aucun acteur célèbre. Les attaquants non catalogués compromettent très bien les environnements. Ils n’ont simplement pas encore de page marketing.

Exemple reproductible : corréler des domaines sans prétendre identifier un acteur

Une première corrélation peut repérer des domaines qui apparaissent dans plusieurs sources de journaux. Elle ne permet pas d’attribuer une attaque, mais elle produit une liste vérifiable pour investigation, blocage temporaire et recherche rétrospective.

Prérequis : disposer de journaux DNS au format JSON (JavaScript Object Notation), de jq et des utilitaires GNU sort, uniq et comm. Les horodatages doivent être normalisés en UTC avant comparaison.

# Extraire les domaines demandés depuis deux jeux de journaux JSON.
# Chaque ligne doit contenir un champ "query_name".
jq -r '.query_name // empty' dns-incident-a.jsonl \
  | tr '[:upper:]' '[:lower:]' \
  | sed 's/\.$//' \
  | sort -u > domaines-a.txt

jq -r '.query_name // empty' dns-incident-b.jsonl \
  | tr '[:upper:]' '[:lower:]' \
  | sed 's/\.$//' \
  | sort -u > domaines-b.txt

# Afficher uniquement les domaines communs aux deux périodes.
comm -12 domaines-a.txt domaines-b.txt

Un domaine commun peut être légitime, compromis, partagé par un fournisseur ou généré par un outil banal. La suite consiste à vérifier la première et dernière apparition, les postes concernés, les processus à l’origine des requêtes, les connexions sortantes associées et les identités actives au même moment. Sans ce contexte, la commande produit une intersection mathématique, pas une preuve.

Les listes de blocage doivent expirer ou être revues. Un blocage sans propriétaire ni date de révision finit par casser un service légitime, puis par être supprimé dans l’urgence. Le domaine suspect est alors débloqué avec tout le reste, dans la grande tradition du « ça marchait avant ».

Exploitation : conservation, rotation et réponse sans attribution finale

Les données nécessaires à l’attribution sont sensibles. Les journaux d’authentification exposent des identités, les captures réseau peuvent contenir des secrets, les images mémoire peuvent révéler des jetons de session et les échantillons malveillants peuvent être dangereux. L’accès doit être limité, journalisé et séparé des postes bureautiques. Un partage de fichiers généraliste n’est pas un coffre de preuve, même si son icône porte un petit cadenas rassurant.

Les clés de chiffrement utilisées pour protéger les preuves doivent être gérées séparément des systèmes compromis. Si une clé de déchiffrement réside sur le même domaine d’administration que les actifs touchés, l’attaquant peut altérer ou rendre illisible le corpus d’investigation. La gestion des clés et des identités relève des mêmes contraintes que les autres actifs critiques, détaillées dans la section cryptographie et dans les pages consacrées aux identités.

La rotation des comptes administratifs, certificats et secrets d’application doit suivre le périmètre réel de la compromission, pas seulement les comptes explicitement vus dans les journaux. Une rotation trop étroite laisse des mécanismes de persistance actifs. Une rotation globale sans séquencement peut arrêter les sauvegardes, les agents de supervision et les intégrations de sécurité au pire moment. Cartographier les dépendances avant la crise évite de découvrir que l’outil de réponse dépend du compte qu’il faut révoquer.

L’attribution ne garantit pas l’éradication, la récupération des données exfiltrées, l’absence de persistance ni l’identification de chaque opérateur. Elle ne remplace pas une analyse de compromission, une reconstruction de chronologie, des sauvegardes testées ni un plan de reprise. Le reste doit venir de la détection, du cloisonnement, de la gestion des identités et de procédures d’incident exercées avant que la salle de crise ne devienne un club de lecture de journaux incomplets.

🐝 Ce qui arrive si on s’en passe

Sans démarche d’attribution structurée, les indices entrent dans la ruche sans être triés. Les indicateurs circulent alors sans source, sans date de collecte ni niveau de confiance : impossible de savoir, six mois plus tard, pourquoi un domaine a été bloqué, ni de rejouer une recherche rétrospective quand les horodatages n’ont pas été normalisés en UTC. Les règles de détection se calent sur des noms de groupes plutôt que sur des comportements, et deviennent muettes dès que l’infrastructure change de fournisseur. Les éléments transmis aux autorités perdent leur valeur faute de chaîne de conservation et d’empreinte cryptographique. Les mêmes traces sont réanalysées à chaque incident, sans capitalisation, et une hypothèse fragile communiquée trop vite fige une lecture erronée qu’il faudra ensuite corriger publiquement.

🦫 Explication de la marmotte 🍫

Après une attaque, les équipes recueillent ce qui a été laissé dans les systèmes : adresses Internet contactées, fichiers déposés, comptes utilisés, heures d’activité, commandes lancées et données consultées. Elles vérifient d’abord que ces informations sont conservées sans modification, avec leur date et leur origine. Sinon, il devient difficile de savoir si une trace est authentique.

Ensuite, elles comparent ces traces avec des attaques déjà étudiées. Elles cherchent des habitudes qui reviennent ensemble : une méthode d’entrée, une manière de garder l’accès, des outils particuliers et des serveurs utilisés pour recevoir des données. Une seule ressemblance ne suffit pas. Beaucoup d’outils sont publics, volés ou copiés. Plus les indices sont variés et indépendants, plus l’hypothèse devient crédible.

Des attaquants peuvent aussi laisser volontairement des traces appartenant à un autre groupe. C’est pourquoi le résultat reste une estimation, avec un degré de confiance, et non une certitude absolue. L’analyse technique indique qui semble avoir mené l’attaque selon les preuves disponibles. Une autorité politique peut ensuite accuser officiellement un État, mais cette décision utilise aussi des informations non publiques et peut avoir des conséquences diplomatiques.

Pendant cette recherche, l’organisation ne doit pas attendre un nom définitif. Il faut couper les accès suspects, changer les secrets exposés, protéger les preuves, vérifier les sauvegardes et rechercher les mêmes traces ailleurs. Si l’attribution échoue ou change, ces mesures restent valables car elles répondent aux faits observés.

Pages voisines

La citent

Comment attribuer techniquement une cyberattaque

Elle cite

Comment attribuer techniquement une cyberattaque

Comment attribuer techniquement une cyberattaque

Attribution technique : un jugement probabiliste, pas un verdict

TTP, infrastructure et artefacts : construire le faisceau de preuves

Faux drapeaux et contamination des indices

Attribution politique : une décision distincte de l’analyse

Exemple reproductible : corréler des domaines sans prétendre identifier un acteur

Exploitation : conservation, rotation et réponse sans attribution finale

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines