Detecter la persistance : un guide de chasse blue team

Une intrusion est rarement un instant unique. Apres qu'un adversaire a pris pied, sa premiere priorite est de s'assurer de pouvoir revenir meme si la machine redemarre, que le mot de passe change ou que le point d'entree initial est ferme. Cette capacite s'appelle la persistance, et la chasser est l'une des activites de plus grande valeur qu'une blue team realise. Ce guide adopte une posture defensive : nous decrivons les categories de persistance pour que vous en reconnaissiez les traces, nous concentrons sur la telemetrie, les Event IDs et les flux de chasse qui les revelent, et terminons par le durcissement. Le but est d'enseigner la detection et l'eradication, pas de donner a quiconque une recette pour rester cache. Si vous trouvez la persistance de maniere fiable, vous transformez une compromission persistante en un incident contenu.

Ce qu'est la persistance et pourquoi elle compte#

La persistance est tout mecanisme permettant a un adversaire de maintenir l'acces a un systeme a travers des interruptions comme les redemarrages, les deconnexions ou les reinitialisations de credentials. Dans le cadre MITRE ATT&CK, c'est la tactique TA0003, et elle est au coeur de la raison pour laquelle les intrusions deviennent durables. La verite inconfortable pour les defenseurs est que l'eradication echoue des que la persistance est manquee : vous pouvez retirer le malware, faire tourner un mot de passe et reconstruire un service, mais si l'attaquant a laisse une tache planifiee, un compte illicite ou une entree de demarrage modifiee, il revient tout simplement. C'est pourquoi la reponse aux incidents inclut toujours une chasse deliberee a la persistance avant de declarer un systeme propre. Trouver la charge initiale n'est pas la ligne d'arrivee ; trouver chaque point d'appui l'est.

L'etat d'esprit persistance pour les defenseurs#

Une chasse efficace part d'une premisse simple : un attaquant qui veut survivre a un redemarrage doit laisser quelque chose que le systeme d'exploitation executera automatiquement. Cette contrainte est votre avantage, car l'ensemble des endroits ou l'OS cherche des choses a executer est fini et bien documente. Plutot que de poursuivre des possibilites infinies, vous enumerez les emplacements de demarrage automatique connus et demandez, pour chacun, si ce qui y reside est attendu. La discipline est le baselining : savoir a quoi ressemble le normal pour que les anomalies ressortent. Une tache planifiee creee a trois heures du matin par un utilisateur qui ne script jamais, un service pointant vers un binaire dans un dossier temporaire, ou un nouveau compte administrateur local ne sont pas subtils une fois que vous avez une reference a comparer.

Ou se cache la persistance sous Windows#

Sous Windows, les defenseurs devraient examiner regulierement un ensemble connu de points d'extensibilite de demarrage automatique. Cela inclut les cles de registre Run et RunOnce, les taches planifiees, les services Windows, les dossiers de demarrage, les abonnements aux evenements WMI et l'abus de mecanismes legitimes comme l'ordre de recherche des DLL ou les fonctions d'accessibilite. La persistance par compte compte tout autant : comptes locaux ou de domaine nouvellement crees, utilisateurs ajoutes a des groupes privilegies et scripts d'ouverture de session modifies. Des outils comme Sysinternals Autoruns sont concus precisement pour enumerer ces emplacements, et les combiner a la telemetrie Sysmon vous donne la visibilite sur la creation de processus, la modification du registre et le chargement d'images. Le but en examinant chaque emplacement n'est pas de memoriser chaque technique mais de reperer l'entree qui n'y a pas sa place, puis de pivoter vers qui l'a creee et quand.

Ou se cache la persistance sous Linux#

Sur les systemes Linux et Unix, la surface de demarrage automatique est differente mais tout aussi enumerable. Les taches cron et les timers et units systemd sont des points d'appui frequents, tout comme les fichiers de demarrage de shell modifies tels que les scripts profile et rc, les cles SSH autorisees ajoutees et les definitions de service nouvelles ou alterees. Les attaquants abusent aussi des taches planifiees qui s'executent en root et des fichiers de configuration charges au demarrage. Defensivement, vous examinez ces emplacements par rapport a une reference connue, surveillez les fichiers dont les dates de modification recentes qu'aucun ticket de changement n'explique, et surveillez l'ajout de cles SSH aux comptes. Auditd et la telemetrie de l'endpoint aident en enregistrant l'execution des processus et les changements de fichiers, si bien qu'une entree cron apparaissant hors de votre pipeline de deploiement devient un signal plutot qu'une surprise decouverte des semaines plus tard.

Persistance cloud et d'identite#

La persistance moderne est de plus en plus fondee sur l'identite et vit au-dessus de tout hote individuel. Dans les environnements cloud et SaaS, les attaquants cherchent un acces durable via de nouvelles credentials plutot que des fichiers : une access key fraiche sur un principal de service, une relation de federation ou de confiance ajoutee, une application OAuth dotee de larges permissions deleguees, ou une regle cachee de transfert de courrier. Comme ces mecanismes sont des fonctions administratives legitimes, ils se fondent dans le decor sauf si vous surveillez le log d'audit. Chassez les cles et enregistrements d'applications nouvellement crees, les changements de confiance de role et de federation, et les octrois de consentement a des applications inconnues. Le principe defensif reflete le monde des hotes : enumerez le petit ensemble d'endroits ou un acces durable peut etre plante, etablissez une reference de ce qui est attendu, et traitez tout ajout inexplique a l'identite comme un point d'appui potentiel.

Signaux de detection et telemetrie#

La chasse a la persistance ne vaut que la telemetrie qui la sous-tend. Sous Windows, les Event IDs pertinents pour la securite sont inestimables : 4698 enregistre la creation de taches planifiees, 7045 marque l'installation d'un nouveau service, 4720 montre la creation de compte, et 4732 enregistre un membre ajoute a un groupe a securite activee. Sysmon ajoute des evenements granulaires de creation de processus, de registre et de chargement d'images qui attrapent des techniques que la politique d'audit par defaut manque. Sous Linux, auditd et l'historique du shell offrent une visibilite equivalente, et les plateformes EDR unissent les deux mondes avec une detection comportementale. Le signal le plus puissant reste toutefois la comparaison a une reference : alertez sur l'apparition vue pour la premiere fois d'une entree de demarrage automatique, d'un service pointant vers un chemin inhabituel, ou d'une creation de compte hors de votre processus de provisionnement. L'anomalie bat la signature quand les adversaires vivent sur le terrain.

Un flux de chasse pratique#

Transformez les concepts en une routine reproductible. Commencez par enumerer les emplacements de demarrage automatique sur votre parc avec des outils qui rapportent les cles run du registre, les taches planifiees, les services et les elements de demarrage, ou leurs equivalents Linux et cloud. Ensuite, etablissez la reference : comparez l'etat actuel a un instantane connu comme bon ou a la majorite d'hotes similaires, car les valeurs aberrantes sont ou vous regardez d'abord. Puis enrichissez chaque candidat en demandant qui l'a cree, quand, depuis quel compte et s'il existe un enregistrement de changement correspondant. Correlez avec les logs de processus et d'authentification pour construire une chronologie, et enfin validez si l'entree est benigne ou malveillante avant d'agir. Documentez ce que vous trouvez pour que la prochaine chasse parte d'une meilleure reference, et reinjectez les motifs confirmes dans des detections automatisees.

Attenuation et durcissement#

Detection et prevention se renforcent mutuellement. Reduisez la surface de persistance en imposant le moindre privilege afin que peu de comptes puissent creer des services, des taches planifiees ou de nouveaux utilisateurs en premier lieu. Exigez l'authentification multifacteur et surveillez l'appartenance aux groupes privilegies pour que les points d'appui par compte soient difficiles a planter et rapides a remarquer. Centralisez et protegez les logs dans un endroit que l'attaquant ne peut editer, et activez les politiques d'audit et la configuration Sysmon ou auditd qui rendent la persistance visible. L'allowlisting d'applications limite ce qui peut s'executer depuis le demarrage automatique tout court. Dans le cloud, restreignez qui peut frapper des credentials et accorder le consentement, et alertez sur les changements de confiance et de federation. Chaque controle qui retrecit ou un acces durable peut etre plante retrecit aussi l'espace que vous devez chasser.

Pieges frequents#

Plusieurs erreurs laissent survivre la persistance. Les repondeurs eradiquent la charge evidente et crient victoire sans enumerer les emplacements de demarrage automatique, si bien qu'une tache planifiee retablit silencieusement l'intrusion. Les equipes chassent sur l'hote mais oublient la persistance d'identite dans le cloud, laissant une access key qui survit a la reconstruction. Les references manquent, si bien qu'un service malveillant est indistinguable d'un legitime au premier coup d'oeil. La telemetrie n'est pas configuree, si bien que les Event IDs memes qui reveleraient une nouvelle tache ou un nouveau compte n'ont jamais ete enregistres. Et les enqueteurs trouvent un point d'appui et s'arretent, sans realiser que les attaquants en plantent couramment plusieurs par redondance. Le remede est une chasse systematique couvrant hotes et identites, appuyee par des references et une telemetrie complete, et une regle de ne jamais declarer propre apres n'en avoir trouve qu'un.

Checklist persistance blue team#

Utilisez ceci comme sequence de chasse. 1. Confirmez que la politique d'audit, Sysmon ou auditd et la centralisation des logs sont en place avant d'en avoir besoin. 2. Enumerez les points de demarrage automatique Windows : cles run, taches planifiees, services, dossiers de demarrage, abonnements WMI. 3. Enumerez les equivalents Linux : cron, systemd, fichiers rc de shell, cles SSH. 4. Enumerez la persistance d'identite : nouvelles cles, enregistrements d'applications, changements de confiance et de consentement. 5. Etablissez la reference de chacun contre des hotes connus comme bons ou des pairs et signalez les aberrants. 6. Enrichissez avec la correlation createur, horodatage et enregistrement de changement. 7. Construisez une chronologie a partir des Event IDs 4698, 7045, 4720, 4732 et des logs de processus. 8. Supposez la redondance : continuez a chasser apres la premiere trouvaille. 9. Remediez, puis reverifiez. 10. Reinjectez les motifs confirmes dans des detections automatisees.

FAQ : trouver un mecanisme de persistance suffit-il pour declarer un hote propre ?#

Non, et le supposer est l'une des erreurs les plus couteuses en reponse aux incidents. Les adversaires plantent couramment plusieurs mecanismes de persistance precisement pour qu'en retirer un ne les verrouille pas dehors. Si vous trouvez une tache planifiee malveillante, traitez-la comme un signal pour chasser plus fort, pas comme la fin de l'enquete, et enumerez chaque autre emplacement de demarrage automatique sur l'hote ainsi que la persistance fondee sur l'identite dans tout cloud connecte. Construisez une chronologie complete de ce que l'attaquant a fait et quand, car la persistance que vous trouvez pointe souvent vers le compte et la fenetre de temps ou d'autres points d'appui ont ete crees. Declarez un systeme propre seulement apres une enumeration complete, pas apres le premier succes.

FAQ : quelle telemetrie prioriser si mes ressources sont limitees ?#

Si vous devez commencer petit, priorisez les signaux qui revelent les points d'appui les plus courants. Sous Windows, activez l'audit pour la creation de taches planifiees, l'installation de services et les changements de comptes et de groupes, qui correspondent aux Event IDs 4698, 7045, 4720 et 4732, et deployez Sysmon pour la visibilite des processus et du registre. Sous Linux, activez auditd pour l'execution des processus et surveillez cron, systemd et les cles SSH autorisees. Dans le cloud, capturez le log d'audit d'identite et alertez sur les nouvelles credentials et les changements de confiance. Centralisez tout cela quelque part que l'attaquant ne peut alterer. Avec cela en place, vous couvrez une grande partie de la persistance du monde reel, et vous pouvez etendre la couverture selon les ressources.

Conclusion#

La persistance est ce qui transforme une breve intrusion en une longue, et la chasser est ce qui retransforme une longue en un incident contenu. L'avantage du defenseur est structurel : le systeme d'exploitation et les plateformes cloud cherchent des elements de demarrage automatique et des credentials durables dans un ensemble fini et documente d'endroits, si bien qu'une chasse disciplinee peut tous les couvrir. Activez d'abord la telemetrie, etablissez la reference de ce qui est normal, enumerez les points d'appui d'hote et d'identite, correlez les evenements de creation en une chronologie, et ne declarez jamais propre apres une seule trouvaille. Associez la detection au moindre privilege et a l'allowlisting pour qu'il y ait moins d'endroits ou planter un point d'appui des le depart. Menee avec constance, la chasse a la persistance est l'etape qui rend l'eradication reelle.