TA0003 Persistance : rester quand tout est redémarré

TA0003 Persistance : rester quand tout est redémarré

Cinquième tactique de la matrice ATT&CK Enterprise. L’objectif, selon le MITRE : l’adversaire cherche à maintenir son point d’appui. La définition précise ce contre quoi : les redémarrages, les changements d’identifiants, et les autres interruptions susceptibles de couper son accès.

Explication de la marmotte

Le visiteur indélicat ne compte pas sur la porte par laquelle il est entré : elle sera réparée. Il laisse donc une fenêtre déverrouillée, double la clé de la cave, se fait inscrire sur la liste des livreurs autorisés, et pose un petit aimant sur le capteur de la porte de service. Quatre précautions indépendantes, pour qu’aucune réparation ne lui coûte son accès. TA0003 est cette liste de précautions.

→ Lire l’explication complète de la marmotte

L’objectif de l’attaquant

Survivre aux événements qui, normalement, mettent fin à un accès. C’est la tactique qui transforme un incident en présence durable, et sa particularité est d’être redondante par construction : un attaquant soigneux n’installe pas une persistance mais trois ou quatre, de natures différentes, de sorte que la découverte de l’une n’emporte pas les autres.

Cette redondance commande toute la réponse à incident. Elle explique pourquoi retirer le maliciel trouvé ne termine jamais une intervention, et pourquoi la question « peut-on nettoyer cette machine ? » n’a presque jamais de bonne réponse : sujet que le site traite dans décider d’assainir ou de reconstruire.

Les techniques, et ce qu’elles couvrent

Vingt-deux techniques, qui se rangent selon ce à quoi elles s’accrochent.

Le démarrage et l’ouverture de session. T1547 (exécution automatique au démarrage ou à l’ouverture de session), T1037 (scripts d’initialisation), T1543 (créer ou modifier un processus système), T1112 (modifier le registre) et T1653 (paramètres d’alimentation, qui empêchent une machine de s’éteindre). Le terrain Windows de ces techniques est décrit par registre Windows, GPO et services : fonctionnement et attaques.

Le temps et les événements. T1053 (tâche planifiée), T1546 (exécution déclenchée par un événement) et T1205 (signalisation de trafic, où un paquet d’apparence anodine réveille une porte dérobée en attente). Ces techniques ont l’avantage, pour l’attaquant, de ne laisser aucun processus suspect visible entre deux déclenchements.

Les identités. T1078 (comptes valides), T1136 (créer un compte), T1098 (manipulation de compte : ajout d’une clé, d’un facteur d’authentification, d’une délégation) et T1556 (modifier le processus d’authentification). Ce sont les persistances les plus difficiles à trouver, parce qu’elles ne se cachent pas : elles ressemblent à de l’administration. Auditer les comptes orphelins après un départ décrit l’exercice qui les révèle, et détecter la persistance IAM dans AWS sa version en nuage, où une clé d’accès ajoutée à un rôle vaut mieux qu’un implant.

Les logiciels légitimes. T1505 (composant logiciel serveur, c’est-à-dire le module ajouté à un serveur web ou de base de données), T1176 (extensions logicielles, notamment de navigateur : voir la politique de sécurité des extensions), T1137 (démarrage d’une application bureautique), T1554 (compromission d’un binaire de l’hôte), T1671 (intégration d’application en nuage) et T1525 (implanter une image interne, dans un registre de conteneurs). La logique est constante : se faire charger par un composant que personne ne soupçonne et que les mises à jour n’écrasent pas.

Sous le système. T1542 (démarrage pré-système) atteint le micrologiciel, le chargeur d’amorçage ou l’enregistrement de démarrage. C’est la persistance la plus rare et la plus coûteuse à traiter, puisqu’elle survit à la réinstallation du système. Les contrôles correspondants sont décrits par l’attestation distante TPM et le démarrage mesuré et sécuriser le micrologiciel UEFI, réseau et BMC.

Deux entrées à part. T1133 (services distants externes) est la persistance la plus économique : un accès par réseau privé virtuel ou passerelle, avec des identifiants valides, n’a rien à installer. Et T1668 (contrôle exclusif) décrit l’attaquant qui verrouille la ressource compromise pour en évincer ses concurrents : rappel utile qu’un système compromis l’est parfois par plusieurs acteurs qui ne se souhaitent pas du bien.

Ce qu’on peut détecter, et par quoi

La persistance est, paradoxalement, la tactique la plus détectable de la matrice : parce qu’elle laisse quelque chose derrière elle. Encore faut-il regarder au bon endroit.

Les points d’ancrage, par inventaire différentiel. Tâches planifiées, services, clés de registre d’exécution automatique, extensions installées, modules de serveur web : la méthode consiste à établir une référence et à comparer. Une tâche planifiée nouvelle sur un serveur de production est un événement, pas un détail. C’est tout l’objet de détecter la persistance d’un attaquant après incident.

Les modifications d’identité, dans les journaux d’annuaire et de nuage. Création de compte, ajout d’une clé publique, enregistrement d’un facteur d’authentification, ajout d’une application autorisée dans un locataire : ces événements sont peu nombreux, donc surveillables un par un. Dans la pratique, ce sont eux qui révèlent les intrusions sérieuses, et personne ne les lit.

Les traces d’exécution passées. Pour établir qu’un programme a tourné (et quand), AmCache, ShimCache et leurs pièges décrit les artefacts disponibles et ce qu’ils ne prouvent pas.

L’intégrité du démarrage. Pour les persistances pré-système, aucune inspection depuis le système en marche n’est fiable : seule l’attestation à distance, fondée sur des mesures enregistrées par le matériel, apporte une réponse.

Et une mise en garde : la détection de persistance se fait à froid, par comparaison, pas par alerte. Une organisation qui attend qu’un outil signale « persistance détectée » attendra longtemps ; une organisation qui compare chaque semaine la liste de ses tâches planifiées trouvera.

Ce que le défenseur peut faire

Tenir une référence de ce qui doit démarrer. Services, tâches, extensions, modules : la liste légitime existe rarement par écrit, et c’est précisément ce qui rend la comparaison impossible. L’établir est un travail ingrat d’une journée, qui rend tous les autres possibles.

Traiter les modifications d’identité comme des alertes. Un compte créé hors du processus d’arrivée, un facteur d’authentification ajouté à un compte à privilèges, une clé d’accès émise pour un rôle de service : trois événements rares, trois alertes légitimes.

Révoquer vraiment. Puisque les persistances les plus discrètes sont des accès valides, la fin d’intervention ne consiste pas à supprimer des fichiers mais à invalider des accès : renouveler les secrets, révoquer les sessions, retirer les délégations. Le cycle complet de réponse à incident place correctement cette étape, qu’on sacrifie presque toujours à la hâte de redémarrer.

Décider de reconstruire quand on ne peut pas prouver la propreté. C’est la conséquence de la redondance : on ne démontre pas l’absence de persistance sur une machine compromise, on la rebâtit.

Sources

• TA0003, Persistence, MITRE ATT&CK Enterprise v20 : objectif et vingt-deux techniques.
• Jeu de données STIX Enterprise ATT&CK 19.2 : identifiants et périmètre des techniques citées.

🐝 Ce qui arrive si on s’en passe

Une organisation qui termine son incident en supprimant le fichier trouvé croit avoir fini, et c’est le scénario qui se répète le plus souvent. Deux semaines plus tard, l’accès revient : la tâche planifiée créée le premier jour est toujours là, ou la clé publique ajoutée au compte de service, ou le module greffé au serveur web. La seconde intervention coûte plus cher que la première, non pas à cause du travail technique mais parce que la confiance est entamée : il faut désormais démontrer la propreté de l’ensemble du parc, exercice impossible faute de référence des configurations légitimes. Et dans les cas les plus coûteux, l’attaquant a atteint le micrologiciel, de sorte que la réinstallation du système ne change rien : l’organisation réinstalle trois fois une machine qui rappelle son opérateur à chaque démarrage.

🦫 Explication de la marmotte 🍫

Un attaquant qui vient d’entrer dans un système sait que son accès est fragile : la machine sera redémarrée, le mot de passe changé, la faille corrigée. Sa première tâche consiste donc à s’assurer de pouvoir revenir. C’est l’étape appelée persistance.

Les moyens sont nombreux, et presque tous consistent à se raccrocher à un mécanisme normal du système. Une tâche planifiée qui relance son programme chaque matin. Un service installé parmi les dizaines de services légitimes. Une extension ajoutée au navigateur. Un module greffé sur le serveur web. Un compte créé discrètement, ou une clé d’accès ajoutée à un compte existant : ce dernier cas étant le plus difficile à repérer, car il ressemble exactement au travail d’un administrateur.

La règle que suivent les attaquants expérimentés est la redondance : ils en installent plusieurs, de natures différentes. Ainsi, la découverte de l’une ne leur coûte pas les autres.

Il en résulte deux conséquences pratiques. D’abord, un incident ne se termine pas quand on a trouvé et supprimé « le virus » : il se termine quand on a vérifié tous les points d’ancrage possibles, et invalidé tous les accès, mots de passe, clés, sessions. Ensuite, cette vérification n’est possible que si l’on sait à quoi ressemble la normale. Une liste écrite des services, tâches planifiées et modules légitimes d’un serveur n’a l’air de rien ; c’est pourtant le seul document qui permette de répondre, un jour d’incident, à la question « cette tâche planifiée a-t-elle toujours existé ? ».

Enfin, il existe des persistances qui survivent au formatage, installées dans le logiciel interne du matériel lui-même. Elles sont rares, coûteuses, et c’est contre elles que servent les mécanismes de démarrage vérifié dont disposent les machines récentes.

À lire aussi

• TA0002 Exécution : faire tourner son code chez quelqu'un d'autreLa tactique ATT&CK TA0002 : exécuter du code contrôlé par l'attaquant sur un système. Vingt-deux techniques, des interpréteurs aux injections de prompt ajoutées en v20, et ce qui se détecte vraiment.
• TA0001 Accès initial : les onze façons d'entrerLa tactique ATT&CK TA0001 : obtenir le premier point d'appui dans un réseau. Les onze techniques d'entrée, de l'hameçonnage aux comptes valides, ce qui est détectable et ce qui réduit la surface.
• TA0004 Élévation de privilèges : passer d'un compte ordinaire à l'administrationLa tactique ATT&CK TA0004 : obtenir des permissions plus élevées. Treize techniques, de l'injection de processus à l'évasion de conteneur, et pourquoi la moitié d'entre elles sont partagées avec la persistance.
• TA0043 Reconnaissance : ce que l'attaquant apprend avant d'entrerLa tactique ATT&CK TA0043 : rassembler de l'information pour préparer l'opération. Les douze techniques, ce qui est détectable et ce qui ne l'est pas, et ce que le défenseur peut réduire.

Pages voisines

La citent

• TA0004 Élévation de privilèges : passer d'un compte ordinaire à l'administration
• TA0006 Accès aux identifiants : voler plutôt que forcer
• CICD-SEC-1 : mécanismes de contrôle de flux insuffisants
• CICD-SEC-9 : validation d'intégrité des artefacts défaillante

TA0003 Persistance : rester quand tout est redémarré

Elle cite

• ⇄Lien dans les deux sens :MITRE ATT&CK : les quinze tactiques de l'attaquant
• Assainir ou reconstruire : la décision qui engage toute une remédiation
• Attestation distante TPM et démarrage mesuré
• Comment auditer les comptes orphelins après un départ
• Comment sécuriser firmware UEFI, réseau et BMC
• Détecter la persistance d’un attaquant après incident
• Détecter la persistance IAM dans AWS
• Politique de sécurité des extensions navigateur en entreprise

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