PowerShell : activer la journalisation des commandes et scripts

I. Présentation

L'utilisation de Windows PowerShell par les attaquants et les malwares est désormais chose commune, la puissance de ce moteur et ce langage est utilisée depuis plusieurs années (nous vous en parlions déjà sur IT-Connect en 2014). Il faut savoir que par défaut, PowerShell ne laisse pas beaucoup de traces de son exécution dans la plupart des environnements Windows.

Cette tendance doit mener à une vigilance accrue des équipes de sécurité qui doivent impérativement se mettre à surveiller l'exécution de commandes PowerShell sur les systèmes protégés. Dans cet article, nous allons voir comment activer la journalisation des commandes et scripts PowerShell exécutés sur un système Windows. Il existe trois moyens différents d'activer la journalisation des commandes PowerShell.

II. PowerShell et Transcript

Le transcript (littéralement transcription) est une méthode historique utilisée pour journaliser l'exécution de commandes PowerShell. Cette méthode comporte des manquements, mais c'est toujours mieux que de ne rien journaliser :).

La transcription crée un enregistrement unique de chaque session PowerShell comprenant toutes les entrées et sorties, exactement telles qu'elles apparaissent dans le terminal PowerShell. Les transcriptions sont écrites dans des fichiers texte, un fichier par utilisateur et par session, comme ceci : 

Les transcriptions contiennent également des horodatages et des métadonnées pour chaque commande afin de faciliter l'analyse. Voici un exemple du contenu d'un fichier de transcription PowerShell :

Cependant, la transcription n'enregistre que ce qui apparaît dans le terminal PowerShell, ce qui n'inclura pas le contenu des scripts exécutés ou la sortie écrite vers d'autres destinations tel que le système de fichiers. Pour l'activer localement et pour une session donnée, nous pouvons utiliser la commande start-transcript :

PS C:\Users\admin> Start-Transcript
Transcription démarrée, le fichier de sortie est C:\Users\admin\Documents\PowerShell_transcript.DESKTOP-DBSUD32.g32CqxMk.20211227184120.txt
PS C:\Users\admin> write-host "Hello"
Hello
PS C:\Users\admin> Stop-Transcript
Transcription arrêtée, le fichier de sortie est C:\Users\admin\Documents\PowerShell_transcript.DESKTOP-DBSUD32.g32CqxMk.20211227184120.txt
PS C:\Users\admin>

Bien sûr, cela n'a aucun intérêt de tenter de surveiller l'activité d'un attaquant sur un système si il doit lui-même activer la journalisation. C'est pourquoi nous pouvons passer par les GPO pour l'activation de la transcription.

Pour activer la transcription au niveau GPO, il faut se rendre dans Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Windows PowerShell. Il faut ensuite passer le paramètre Activer la transcription PowerShell à Activé :

Par défaut, les transcriptions sont écrites dans le dossier Documents de l'utilisateur, mais cette configuration peut être modifiée vers n'importe quel emplacement accessible sur le système local ou sur le réseau. Il faut être conscient qu'un système de journalisation a peu de valeur s'il peut être supprimé ou désactivé par l'utilisateur lui-même et peut même s'avérer dangereux si des données sensibles peuvent y être consultées (par exemple : mots de passe saisis dans le terminal).

Dans l'idéal, la meilleure pratique consiste à externaliser les transcriptions du système et les envoyer sur un serveur de fichier. Ce répertoire distant doit être un partage réseau restreint en écriture seule (seule l'équipe de sécurité pourra y accéder en lecture par exemple). Attention tout de même, dans l'éventualité où un répertoire distant non accessible serait indiqué, les transcriptions ne seront plus enregistrées.

Pour modifier le répertoire d'écriture, il faut utiliser l'option correspondante dans le paramètre précédemment modifié :

Il est également conseillé de cocher l'option Inclure les en-têtes de l'appel. Cela permet simplement l'horodatage de chaque commande :

Pour activer ce même paramétrage au niveau de la base de registre, il faut modifier les registres suivants :

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription : EnableTranscripting = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription : EnableInvocationHeader = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription : OutputDirectory = ""

Faisons à présent un test. Je suis un utilisateur et j'ouvre PowerShell pour télécharger un exécutable malveillant :

> Invoke-WebRequest -Uri https://www.it-connect.fr/wp-content-itc/uploads/2017/06/IT-Connect_Flat_072017_Small_v2.png -OutFile logo-ITConnect.png

Voici la trace laissée dans la transcription :

Grâce aux transcriptions, je peux affirmer que l'utilisateur admin a téléchargé un fichier à 11h36 le 29/12/2021. À présent j'exécute un script PowerShell qui fait la même opération, sans aucune sortie dans le terminal. Voici la trace laissée dans la transcription :

Comme indiqué précédemment, la faiblesse de cette solution est qu'elle ne journalise que les entrées/sorties du terminal, l'utilisation d'un script est donc un moyen de contourner la journalisation par la transcription. Dans le cadre d'une activité malveillante, on peut facilement imaginer que le script utilisé ait été supprimé à la suite de son utilisation, nous n'avons alors aucune trace de ce qu'il s'est passé. Heureusement, d'autres solutions existent :).

III. PowerShell et Script Block Logging

Le script block logging enregistre les blocs de code au fur et à mesure qu'ils sont exécutés par le moteur PowerShell, capturant ainsi l'intégralité du contenu du code exécuté par un attaquant, y compris les scripts et les commandes.

Il enregistre notamment le code "désobfusqué" au fur et à mesure de son exécution. Par exemple, en plus d'enregistrer le code obfusqué d'origine, le script block logging enregistre les commandes décodées passées avec l'argument -EncodedCommand de PowerShell, ainsi que celles obfusquées avec XOR, Base64, ROT13, etc, en plus du code obfusqué d'origine. Le script block logging n'enregistrera cependant pas la sortie du code exécuté. Ces évènements seront journalisés dans la console de journalisation classique Windows et porteront l'ID d'évènement 4104. Les blocs de code dépassant la longueur maximale d'un message de journal d'évènements sont fragmentés en plusieurs entrées.

Il faut cependant savoir qu'à partir de PowerShell 5.0, le système enregistre automatiquement les blocs de code si leur contenu correspond à une liste de commandes ou de techniques de script suspectes, même si le script block logging n'est pas activé. Ces blocs suspects sont enregistrés au niveau avertissement dans l'ID d'évènement 4104, à moins que le script block logging ne soit explicitement désactivé. Cette fonctionnalité garantit que certaines informations nécessaires aux investigations (forensic) sont enregistrées pour une activité suspecte connue, même si la journalisation n'est pas activée.

L'activation du script block logging capturera toutes les activités, pas seulement les commandes considérées comme suspectes par le processus PowerShell. Cela permet d'identifier toute l'étendue de l'activité de l'attaquant. Les blocs qui ne sont pas considérés comme suspects seront également enregistrés dans l'ID d'évènement 4104, mais avec des niveaux verbose ou information.

Pour activer le script block logging au niveau GPO, il faut se rendre dans Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Windows PowerShell. Il faut ensuite passer le paramètre Activer la journalisation de blocs de scripts PowerShell à Activé :

Pour activer ce même paramétrage au niveau de la base de registre, il faut modifier le registre suivant :

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging : EnableScriptBlockLogging = 1

Faisons à présent le même test que tout à l'heure. J'exécute une commande de téléchargement de fichier :

> Invoke-WebRequest -Uri https://www.it-connect.fr/wp-content-itc/uploads/2017/06/IT-Connect_Flat_072017_Small_v2.png -OutFile logo-ITConnect.png

Les évènements journalisés peuvent être trouvés localement dans l'Observateur d'évènements -> Journaux des applications et des services -> Microsoft -> Windows -> PowerShell -> Operationnal :

Cette commande est journalisée dans l'ID d'évènement 4104. Si j'exécute un script contenant cette commande, voilà ce que l'on pourra voir dans l'observateur d'évènements :

Nous avons bien ici notre commande de lancement du script, puis dans l'évènement suivant, la ligne de commande exécutée par le script, dont on retrouve par ailleurs le nom dans "Chemin d'accès :".

Nous allons maintenant passer à un cas un peu plus complexe qui est le cas d'un script contenant une commande encodée. L'encodage en base64 est la manière la plus basique de "dissimuler" une commande en PowerShell, cela permettra par exemple de ne pas faire apparaitre en clair la directive Invoke-WebRequest, qui permet de faire une requête HTTP, dans un script ou un terminal.

Pour ce faire, j'encode une première fois ma commande PowerShell en base64 :

>> [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes("Invoke-WebRequest -Uri https://www.it-connect.fr/wp-content-itc/uploads/2017/06/IT-Connect_Flat_072017_Small_v2.png -OutFile logo-ITConnect.png"))
CgBJAG4AdgBvAGsAZQAtAFcAZQBiAFIAZQBxAHUAZQBzAHQAIAAtAFUAcgBpACAAaAB0AHQAcABzADoALwAvAHcAdwB3AC4AaQB0AC0AYwBvAG4AbgBlAGMAdAAuAGYAcgAvAHcAcAAtAGMAbwBuAHQAZQBuAHQALQBpAHQAYwAvAHUAcABsAG8AYQBkAHMALwAyADAAMQA3AC8AMAA2AC8ASQBUAC0AQwBvAG4AbgBlAGMAdABfAEYAbABhAHQAXwAwADcAMgAwADEANwBfAFMAbQBhAGwAbABfAHYAMgAuAHAAbgBnACAALQBPAHUAdABGAGkAbABlACAAIABsAG8AZwBvAC0ASQBUAEMAbwBuAG4AZQBjAHQALgBwAG4AZwA=

Puis une deuxième fois : 

>> [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes("powershell -e CgBJAG4AdgBvAGsAZQAtAFcAZQBiAFIAZQBxAHUAZQBzAHQAIAAtAFUAcgBpACAAaAB0AHQAcABzADoALwAvAHcAdwB3AC4AaQB0AC0AYwBvAG4AbgBlAGMAdAAuAGYAcgAvAHcAcAAtAGMAbwBuAHQAZQBuAHQALQBpAHQAYwAvAHUAcABsAG8AYQBkAHMALwAyADAAMQA3AC8AMAA2AC8ASQBUAC0AQwBvAG4AbgBlAGMAdABfAEYAbABhAHQAXwAwADcAMgAwADEANwBfAFMAbQBhAGwAbABfAHYAMgAuAHAAbgBnACAALQBPAHUAdABGAGkAbABlACAAIABsAG8AZwBvAC0ASQBUAEMAbwBuAG4AZQBjAHQALgBwAG4AZwA="))
cABvAHcAZQByAHMAaABlAGwAbAAgAC0AZQAgAEMAZwBCAEoAQQBHADQAQQBkAGcAQgB2AEEARwBzAEEAWgBRAEEAdABBAEYAYwBBAFoAUQBCAGkAQQBGAEkAQQBaAFEAQgB4AEEASABVAEEAWgBRAEIAegBBAEgAUQBBAEkAQQBBAHQAQQBGAFUAQQBjAGcAQgBwAEEAQwBBAEEAYQBBAEIAMABBAEgAUQBBAGMAQQBCAHoAQQBEAG8AQQBMAHcAQQB2AEEASABjAEEAZAB3AEIAMwBBAEMANABBAGEAUQBCADAAQQBDADAAQQBZAHcAQgB2AEEARwA0AEEAYgBnAEIAbABBAEcATQBBAGQAQQBBAHUAQQBHAFkAQQBjAGcAQQB2AEEASABjAEEAYwBBAEEAdABBAEcATQBBAGIAdwBCAHUAQQBIAFEAQQBaAFEAQgB1AEEASABRAEEATABRAEIAcABBAEgAUQBBAFkAdwBBAHYAQQBIAFUAQQBjAEEAQgBzAEEARwA4AEEAWQBRAEIAawBBAEgATQBBAEwAdwBBAHkAQQBEAEEAQQBNAFEAQQAzAEEAQwA4AEEATQBBAEEAMgBBAEMAOABBAFMAUQBCAFUAQQBDADAAQQBRAHcAQgB2AEEARwA0AEEAYgBnAEIAbABBAEcATQBBAGQAQQBCAGYAQQBFAFkAQQBiAEEAQgBoAEEASABRAEEAWAB3AEEAdwBBAEQAYwBBAE0AZwBBAHcAQQBEAEUAQQBOAHcAQgBmAEEARgBNAEEAYgBRAEIAaABBAEcAdwBBAGIAQQBCAGYAQQBIAFkAQQBNAGcAQQB1AEEASABBAEEAYgBnAEIAbgBBAEMAQQBBAEwAUQBCAFAAQQBIAFUAQQBkAEEAQgBHAEEARwBrAEEAYgBBAEIAbABBAEMAQQBBAEkAQQBCAHMAQQBHADgAQQBaAHcAQgB2AEEAQwAwAEEAUwBRAEIAVQBBAEUATQBBAGIAdwBCAHUAQQBHADQAQQBaAFEAQgBqAEEASABRAEEATABnAEIAdwBBAEcANABBAFoAdwBBAD0A

J'exécute enfin ma commande en spécifiant -encodedcommand (ou -e), ce qui indique à PowerShell qu'il va devoir décoder la commande avant de l'exécuter, la commande qu'il obtiendra contiendra encore une fois un -encodedcommand, et la troisième commande qu'il obtiendra exécutera enfin une requête pour télécharger un fichier via HTTP.

powershell -EncodedCommand  cABvAHcAZQByAHMAaABlAGwAbAAgAC0AZQAgAEMAZwBCAEoAQQBHADQAQQBkAGcAQgB2AEEARwBzAEEAWgBRAEEAdABBAEYAYwBBAFoAUQBCAGkAQQBGAEkAQQBaAFEAQgB4AEEASABVAEEAWgBRAEIAegBBAEgAUQBBAEkAQQBBAHQAQQBGAFUAQQBjAGcAQgBwAEEAQwBBAEEAYQBBAEIAMABBAEgAUQBBAGMAQQBCAHoAQQBEAG8AQQBMAHcAQQB2AEEASABjAEEAZAB3AEIAMwBBAEMANABBAGEAUQBCADAAQQBDADAAQQBZAHcAQgB2AEEARwA0AEEAYgBnAEIAbABBAEcATQBBAGQAQQBBAHUAQQBHAFkAQQBjAGcAQQB2AEEASABjAEEAYwBBAEEAdABBAEcATQBBAGIAdwBCAHUAQQBIAFEAQQBaAFEAQgB1AEEASABRAEEATABRAEIAcABBAEgAUQBBAFkAdwBBAHYAQQBIAFUAQQBjAEEAQgBzAEEARwA4AEEAWQBRAEIAawBBAEgATQBBAEwAdwBBAHkAQQBEAEEAQQBNAFEAQQAzAEEAQwA4AEEATQBBAEEAMgBBAEMAOABBAFMAUQBCAFUAQQBDADAAQQBRAHcAQgB2AEEARwA0AEEAYgBnAEIAbABBAEcATQBBAGQAQQBCAGYAQQBFAFkAQQBiAEEAQgBoAEEASABRAEEAWAB3AEEAdwBBAEQAYwBBAE0AZwBBAHcAQQBEAEUAQQBOAHcAQgBmAEEARgBNAEEAYgBRAEIAaABBAEcAdwBBAGIAQQBCAGYAQQBIAFkAQQBNAGcAQQB1AEEASABBAEEAYgBnAEIAbgBBAEMAQQBBAEwAUQBCAFAAQQBIAFUAQQBkAEEAQgBHAEEARwBrAEEAYgBBAEIAbABBAEMAQQBBAEkAQQBCAHMAQQBHADgAQQBaAHcAQgB2AEEAQwAwAEEAUwBRAEIAVQBBAEUATQBBAGIAdwBCAHUAQQBHADQAQQBaAFEAQgBqAEEASABRAEEATABnAEIAdwBBAEcANABBAFoAdwBBAD0A

Lors de son exécution, voici les différentes entrées portant l'ID d'évènement 4104 que l'on peut trouver dans l'observateur d'évènements :

On voit ici que les différentes étapes de l'exécution de ma commande apparaissent, on voit notamment les deux résultats du décodage base64, ce qui nous permet de voir la commande finale exécutée (contenant le Invoke-WebRequest) dans l'évènement journalisé.

Cas plus complexe où l'on peut vraiment parler d'obfuscation. Voici la même commande Invoke-WebRequest obfusquée grâce à l'outil Invoke-Obfuscation :

((("{40}{112}{104}{88}{46}{20}{24}{77}{41}{13}{76}{35}{33}{31}{34}{79}{51}{27}{101}{48}{9}{85}{47}{7}{28}{32}{60}{63}{15}{114}{97}{42}{65}{86}{5}{23}{18}{82}{83}{75}{110}{116}{96}{30}{29}{94}{8}{16}{66}{61}{84}{2}{62}{11}{78}{80}{69}{4}{74}{91}{39}{10}{103}{53}{58}{70}{36}{22}{3}{90}{1}{44}{109}{6}{50}{115}{52}{25}{117}{102}{45}{107}{17}{14}{72}{73}{106}{64}{49}{105}{38}{108}{68}{98}{57}{89}{12}{56}{111}{55}{93}{26}{0}{21}{71}{95}{43}{19}{92}{99}{67}{54}{113}{37}{81}{100}{59}{87}" -f'T+','dbT2db','con','bT7db','ds/db','onnedb','017dbT+d','ps:/','T+d','T+d','/IT-','t','Fid','ebR','bT+','Tw','b','_d','dbT','b','bTndbT+dbTvo','dbT logo-IT','_0dbT+d','T+','ke','bT+dbTSmald','db','ues','/','dbT/','bT+','dbT','ww','e','+','+dbT','at','T+',' ','017/06',' iex((d','W','db','d','T+db','b','+d','T -Uri htt','db','d','bT','bTqdbT+dbT','d','dbT','dbTt','l','b','+','_','))','dbT+d','-dbT+d','tent-i','b','n','Tidb','Tp','necdbT+','O','ploa','FdbT+dbTl','Co','dbTv','dbT+d','T+dbT','T+d','dbT','-','c/','d','udbT+dbT','dbT.pngd','ct','.db','bT','b','T+dbTt-c',' ','IdbT','dbTt','T+','2','T','e','wdb','dbT+','d','T+','udbT','n','bT','t','dbTld','ConndbT+dbTectdbT+','T','bT+dbTg','bT2.p','T+dbT','-','T','bTf','T+dbT','b','db','.db','_','r','bT+'))-rEplaCE ([char]100+[char]98+[char]84),[char]39)|InvOKE-EXprESSIOn

Ça fait mal aux yeux n'est-ce pas ? :p Sachez que c'est sur ce format de commande que travaillent la plupart des analystes en investigation numérique. Ce résultat est très difficilement compréhensible par l'homme et pose également problème aux systèmes de détection automatique. La commande est pourtant générée par un script trouvé sur internet en quelques secondes et elle fonctionne à merveille. Pour information, voici quelques-unes des techniques d'obfuscation utilisées ici :

• Reordering : l'opérateur de formatage -f est utilisé afin de reconstituer une chaine de caractère ayant été divisée en plusieurs parties, ordonnée dans un sens qui rend complexe sa compréhension.
  • "{1}{0}"-f 'x','IE'
• Replacing: Consiste à écrire une commande incorrecte ou mal formatée, puis à remplacer certains caractères au dernier moment pour qu'elle retrouve une structure correcte pour son exécution.
  • +dbT','-','T','bTf','T+dbT','b','db','.db','_','r','bT+'))-rEplaCE ('dbT','')|
• Escaping character: Consiste à positionner des caractères ` au milieu d'une chaine de caractères afin de complexifier la compréhension de la commande par l'analyste.
  
  • Dans notre cas, les ` ([char]39) apparaissent après la phase de remplacement et sont positionnés à la place des dbT ([char]100+[char]98+[char]84)
• Up/Lower case : Écriture de commande ou mot-clé détectable en alternance de minuscule/majuscule afin de tromper des expressions régulières qui ne prendraient pas la casse en compte.
  • InvOKE-EXprESSIOn

Si vous êtes toujours là, voici la journalisation obtenue lors de l'exécution de cette commande :

Voilà qui est intéressant, trois évènements journalisés reconstituent la commande à chaque étape de sa reconstruction, et nous voyons à nouveau la commande exécutée en clair.

IV. PowerShell et le module Logging

Le module logging enregistre les détails de l'exécution au fur et à mesure de l'exécution, y compris l'initialisation des variables et les appels de commande. Le module logging enregistrera des portions de script, du code désobfusqué et des données de sortie. Cette journalisation capturera certains détails manqués par d'autres sources de journalisation PowerShell, bien qu'elle puisse ne pas capturer de manière fiable l'intégralité des commandes exécutées. Les événements de journalisation du module sont écrits dans l'ID d'événement (EID) 4103 et s'orientent sur l'utilisation de modules plutôt que le suivi de l'exécution d'une commande ou d'un script de A à Z.

Voici par exemple la journalisation générée par l'exécution de notre commande obfusquée :

On voit ici que trois évènements (EID 4013) ont été journalisés, chacun faisant apparaitre une étape de notre commande, correspondant à l'utilisation d'un module précis : Invoke-Expression, Invoke-WebRequest, Out-Default (la sortie). Le module ciblé par l'évènement est spécifié en première ligne (CommandInvocation) alors que les données utiles à un analyste sont dans la partie Contexte. 

Pour activer le module logging au niveau GPO, il faut se rendre dans Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Windows Powershell. Il faut ensuite passer le paramètre Activer l'enregistrement des modules à Activé :

Il ne faut pas oublier ici d'activer le module logging pour tous les modules (en fonction de ce que l'on souhaite) en positionnant un wildcard (*) dans Noms des modules. On peut se servir de cette option pour journaliser uniquement l'utilisation de certains modules, mais cela n'est pas recommandé, car il est presque impossible d'anticiper toutes les possibilités qu'utilisera un attaquant.

Pour activer ce même paramétrage au niveau de la base de registre, il faut modifier le registre suivant :

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging : EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames : * = *

IV. Pour aller plus loin : centralisation et corrélation

Nous voyons donc que ces trois méthodes de journalisation sont complémentaires, la transcription présente des manquements qui peuvent être problématiques pour mener à bien une investigation numérique ou pour de la surveillance des évènements de sécurité. Le script block logging et le module logging apparaissent comme des sources d'information pertinentes aussi bien pour de l'analyse forensic que pour l'envoi des journaux à un SIEM qui tentera ensuite d'y détecter des activités suspectes ou malveillantes.

Dans tous les cas, l'externalisation des journaux hors du système qui les produit et leur centralisation pour mener à bien des opérations de corrélation d'évènements et de détection des activités suspectes est clairement recommandée une fois que la journalisation des commandes PowerShell est activée. Je vous oriente vers cet article pour aller plus loin sur ce sujet : Centralisation des logs, un outil pour la sécurité.

Pour rappel, il s'agit d'un point non négligeable du guide d'hygiène informatique de l'ANSSI : 

Directive 36 : Activer et configurer les journaux des composants
Si toutes les actions précédentes ont été mises en œuvre, une centralisation des journaux sur un dispositif dédié pourra être envisagée. Cela permet de faciliter la recherche automatisée d’évènements suspects, d’archiver les journaux sur une longue durée et d’empêcher un attaquant d’effacer d’éventuelles traces de son passage sur les équipements qu’il a compromis.

N'hésitez pas à partager vos expériences et vos avis dans les commentaires de cet article 🙂