WS-017, une station de travail intégrée au domaine, déclenche une alerte après le lancement de powershell.exe sous un compte inhabituel. Le tri initial confirme l’exécution de scripts suspects mais s’arrête là, passant à côté d’un mécanisme de persistance qui subsiste après l’arrêt du processus PowerShell. L’attaquant n’avait pas besoin d’une nouvelle vulnérabilité sur la station de travail ; il lui fallait simplement un compte de domaine utilisable et un moyen d’amener un hôte à exécuter son action.
La question pour le défenseur est de savoir si l’alerte PowerShell correspondait à un événement d’exécution isolé ou à une étape d’une séquence plus vaste. Au cours des sept prochaines leçons, nous transformerons les traces laissées sur WS-017 en une chronologie étayée, identifierons les changements survenus et déterminerons la réponse justifiée par les preuves. Une conclusion solide nomme l’hôte, le compte, l’action, l’heure et l’artefact qui la fondent, plutôt que de se baser uniquement sur l’intitulé de l’alerte.
Le cas le plus simple est un événement d’exécution montrant ACME\svc_backup lançant powershell.exe sur WS-017 à 09h24. Cet enregistrement établit qu’un processus a démarré sous cette identité. Il ne précise pas comment le compte a accédé à l’hôte, quel script a été exécuté, si une persistance a été créée ou si le processus a réussi. Chaque artefact ultérieur permet de répondre à l’une de ces questions plus spécifiques.
Règle d’investigation
Considérez chaque alerte comme un point de départ. Corroborez les informations qu’elle contient par des preuves spécifiques à l’hôte avant de déterminer la portée, la cause ou l’impact de l’incident.
Pour éviter que des enregistrements sans rapport ne conduisent à une interprétation erronée, chaque laboratoire utilise les mêmes paramètres fixes. L’hôte est WS-017, intégré au domaine ACME.LOCAL. L’utilisateur interactif attendu est ACME\j.smith. L’identité suspecte est ACME\svc_backup, un compte de service dont l’utilisation sur une station de travail utilisateur nécessite une explication. La fenêtre temporelle de l’incident s’étend du 14/09/2026 à 09h10 jusqu’à 10h05 (heure locale).
Ces constantes nous permettent de corréler les preuves sans supposer d’emblée que chaque événement est malveillant. Un enregistrement du journal de sécurité peut identifier une entité (principal) via des champs tels que SubjectUserName et déterminer le type de session grâce à LogonType. Le chemin de l’image du processus, le chemin dans le Registre et la configuration d’un service ne prennent tout leur sens que lorsqu’ils sont reliés à WS-017 et à cette fenêtre temporelle. Si un enregistrement mentionne un autre hôte ou se situe en dehors de la période concernée, nous ne le conservons que si des éléments de preuve établissent un lien direct.
Dans ce cas, le groupe local des administrateurs constitue une limite critique. Le compte ACME\j.smith doit opérer en tant qu’utilisateur standard, tandis que les actions effectuées par ACME\svc_backup peuvent impliquer des privilèges d’administration. Un même fichier exécutable revêt une signification différente pour l’enquête selon qu’il s’exécute sous un compte capable d’installer des services, d’écrire des clés de registre à l’échelle du système ou de modifier les paramètres de sécurité.
Le périmètre de l’enquête associe l’identité de domaine, la limite des privilèges locaux et la période de l’incident au sein d’une vue unique :
Ce diagramme définit le périmètre pour toutes les questions ultérieures. Nous analysons l’activité sur la machine WS-017 durant la période de 55 minutes indiquée, puis nous élargissons le champ d’investigation uniquement si un élément de preuve pointe au-delà de cette limite.
Une fois le périmètre de l’enquête défini, les sources de preuves doivent être sélectionnées en fonction des questions auxquelles elles permettent de répondre, et non parce qu’un canal de journalisation semble plus fiable ou faisant davantage autorité. Le journal des événements Windows consigne l’activité du système d’exploitation et de la sécurité, tandis que Sysmon fournit une télémétrie détaillée du poste de travail lorsqu’il est configuré. La base de registre conserve des configurations qui peuvent persister au-delà de l’exécution d’un processus. Aucune source unique ne permet de démontrer l’intégralité de la séquence d’événements.
Pour la machine WS-017, les exercices pratiques ultérieurs s’appuieront sur quatre catégories de preuves :
Microsoft-Windows-Sysmon/Operational pour corréler la création de processus, l’activité réseau, la création de fichiers et les modifications du registre, lorsque Sysmon les a enregistrés.Microsoft-Windows-PowerShell/Operational pour déterminer les informations consignées par PowerShell concernant l’activité de script.HKLM et HKCU pour examiner les modifications de configuration à l’échelle de la machine et au niveau de l’utilisateur.Un événement système tel que le 7045 consigne l’installation d’un service par le Gestionnaire de contrôle des services (Service Control Manager), en incluant le nom du service, le chemin de l’exécutable, le type de démarrage et le compte de service associé. À lui seul, l’événement 7045 prouve la création d’un service, mais pas une intention malveillante. Il est nécessaire de comparer le chemin et le compte utilisés aux pratiques d’administration attendues, puis de corréler ces informations avec les événements de connexion et les traces de processus survenus à proximité temporelle. Si un service a été créé mais que le chemin de son exécutable n’a pas été collecté ou que la source d’audit pertinente est absente, l’enquête présente une zone d’ombre qui doit être explicitement signalée.
Les sources de preuves diffèrent par leur couverture, les champs qu’elles contiennent et leurs modes de défaillance :