PowerShell : transformer la journalisation en contexte d’investigation

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

PowerShell fait partie des outils de travail de nombreuses équipes Windows. Sa présence dans une alerte ne permet donc pas de conclure à une compromission.

Pour le SOC, la question utile est de savoir quel traitement a été exécuté, par quel compte et dans quel contexte.

Les faits confirmés

Microsoft documente la journalisation des blocs de script de Windows PowerShell et l’événement 4104 dans le journal opérationnel correspondant.

L’éditeur avertit également que des informations sensibles peuvent apparaître dans ces journaux et recommande d’examiner la protection de leur contenu. Source : Microsoft Learn.

La méthode proposée par Seculogik

Avant d’activer une collecte plus détaillée, recensez les usages administratifs attendus. Identifiez les équipes, les comptes, les outils d’orchestration et les plages habituelles d’intervention. Cette base de contexte doit pouvoir évoluer sans devenir une liste d’exceptions permanentes.

Sur une machine de test, produisez ensuite une activité bénigne dont vous connaissez le contenu. Vérifiez son apparition locale, sa transmission et sa lisibilité dans l’outil d’analyse.

Contrôlez ce qui arrive aux événements longs ou répartis sur plusieurs enregistrements : un extrait incomplet peut modifier la compréhension du traitement.

Pour une alerte réelle, partez du compte et de la machine, puis cherchez les événements de processus et d’authentification disponibles autour de l’exécution.

Les logs PowerShell apportent une pièce au dossier ; ils ne décrivent pas nécessairement toute la chaîne d’activité.

Évaluer une combinaison de signaux

Nous proposons d’examiner plusieurs questions : l’usage est-il attendu sur ce poste ? Le compte intervient-il habituellement ici ? Un changement était-il approuvé ? Le comportement observé correspond-il au but annoncé ?

Existe-t-il une activité connexe qui renforce ou affaiblit l’hypothèse ?

Un mot-clé isolé ou un mécanisme d’encodage ne devrait pas suffire à produire une conclusion définitive. Documentez la raison de l’escalade et ce qui reste à confirmer.

Protéger l’information collectée

Le SOC doit connaître les personnes autorisées à lire ces journaux, leurs destinations et leur durée de conservation. Évitez de transmettre automatiquement leur contenu intégral à des services externes d’enrichissement ou à un assistant IA.

Commencez par un groupe pilote et un scénario d’usage précis. Vérifiez la version de PowerShell réellement installée : les instructions Windows PowerShell 5.1 ne doivent pas être appliquées indistinctement à toutes les éditions.

L’objectif est une visibilité interprétable, avec une collecte testée et un accès maîtrisé.

Sources

• Microsoft Learn, about_Logging, Windows PowerShell 5.1 : https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_logging?view=powershell-5.1