L'accès initial n'est souvent que la première étape d'une intrusion. Après avoir obtenu une exécution sur un serveur ou un endpoint, un attaquant peut tenter de créer un mécanisme qui survit aux redémarrages, se reconnecte plus tard ou assure un accès continu.
La source définit une recherche de persistance multiplateforme couvrant les mécanismes courants de Windows et de Linux.
Mécanismes de persistance Windows
La partie Windows surveille l'exécution de :
schtasks.exe;sc.exe;reg.exe;wmic.exe.
Elle recherche ensuite des motifs de ligne de commande liés à la création de tâches, aux ajouts au registre, à l'exécution, aux modifications d'ImagePath de services ou à l'activité RunOnce.
Surveillance de la persistance basée sur des fichiers
La deuxième partie utilise la surveillance de l'intégrité des fichiers pour identifier les modifications sous :
/etc/cron.d/;/var/spool/cron/;SSH
authorized_keys;démarrage de Windows ;
System32\Tasks.
Requête de détection
(data.win.system.eventID:1 and data.win.eventdata.image:(*\schtasks.exe or *\sc.exe or *\reg.exe or *\wmic.exe) and data.win.eventdata.commandLine:(*create* or *add* or *run* or *ImagePath* or *RunOnce*)) or (rule.groups: syscheck and syscheck.event: (added or modified) and syscheck.path:(*/etc/cron.d/* or */var/spool/cron/* or */.ssh/authorized_keys or *\Start*Menu\Programs\Startup\* or *\System32\Tasks\*))
La source a enregistré 509 résultats au cours des 30 derniers jours.
Pourquoi la persistance est difficile à détecter
Chaque mécanisme de la requête a aussi des usages administratifs légitimes. Les tâches planifiées exécutent des sauvegardes et de la maintenance. Les services sont créés par des installations de logiciels. Les tâches cron soutiennent les opérations Linux. Les clés SSH autorisées peuvent faire partie de la gestion normale des accès.
La valeur pour la sécurité vient de l'identification des changements inattendus plutôt que du fait de considérer le mécanisme lui-même comme malveillant.
Processus d'investigation
Pour chaque correspondance, examinez :
processus créateur ;
compte utilisateur ou de service ;
ligne de commande exacte ;
tâche, service, valeur de registre, fichier cron ou clé SSH ciblés ;
horodatage par rapport à d'autres activités suspectes ;
rôle de l'hôte ;
si l'objet de persistance a effectivement été exécuté par la suite.
La persistance créée immédiatement après un événement RCE ou de shell suspect doit être traitée en priorité.
Réglage de la règle
Créez une base de référence des tâches planifiées, services, tâches cron et clés administratives connus.
Concentrez-vous ensuite sur :
nouveaux noms ;
chemins d'exécutables inhabituels ;
répertoires accessibles en écriture par l'utilisateur ;
commandes encodées ou obfusquées ;
comptes rares ;
exécution en dehors des fenêtres de changement.
Évitez d'exclure globalement un mécanisme entier.
Possibilités de corrélation
Cette recherche peut être combinée à d'autres détections de la source, notamment :
exécution de shell sur le serveur web ;
évasion des défenses ;
reverse shells ;
extraction d’identifiants ;
préparation de ransomware.
Une séquence d'exécution initiale suivie de persistance fournit un récit de l'incident bien plus solide.
Valeur opérationnelle
La chasse à la persistance est utile, car elle peut révéler l'activité d'un attaquant même après que l'événement d'exploitation initial est passé.
En surveillant à la fois les mécanismes de persistance basés sur des commandes et ceux basés sur des fichiers, les défenseurs peuvent identifier les tentatives de transformer un accès temporaire en contrôle durable.
