Superviser PowerShell

Introduction

Ce huitième et dernier chapitre aborde la supervision de sécurité d’un SI avec une focalisation sur PowerShell. En effet, les chapitres précédents ont tous montré que toutes les techniques d’attaque et de défense ne sont pas "absolues" (aucun système ne sera jamais invulnérable). Il n’existe pas d’actions offensives indétectables, ni de systèmes d’information invulnérables. Dans ce contexte, la maîtrise et la bonne connaissance du SI sont des éléments indispensables à sa sécurisation. Dans ce but, la mise en place d’une supervision de sécurité est un élément majeur qui permet une meilleure visibilité, tout en permettant également d’améliorer la compréhension de l’activité de son système d’information.

Ce chapitre va donc se concentrer sur la gestion des logs dans un environnement Windows et PowerShell. Il y sera d’abord abordé la supervision avec Sysmon sur les machines du Lab. Nous verrons ainsi comment tracer les actions réalisées avec PowerShell, et comment transmettre ces journaux vers un serveur de collecte. Nous verrons une technique possible pour les relayer à un serveur syslog. Nous installerons enfin une petite instance du logiciel Splunk pour indexer...

Collecter les logs Windows et Sysmon

> $logs = Get-EventLog -LogName Security -InstanceId 4624 

> $log[0].Message 

> [regex]::match($log[0].Message, '^\s+Nom du compte  
:\s+([^\n]*)', 
[System.Text.RegularExpressions.RegexOptions]::Multiline).
Groups[1].Value 

$computer = @('WIN10-BEAUFORT') 
$logs = Get-EventLog -ComputerName $computer -LogName Security 
-InstanceId 4624 
Foreach($log in $logs){ 
 $compte = [regex]::match($log.Message,'^\s+Nom du compte  
:\s+([^\n]*)', 
[System.Text.RegularExpressions.RegexOptions]::Multiline).Groups[1].
Value 
 $compte 
} 

Les logs PowerShell

Malgré tous les mécanismes de protection du système d’information que nous avons vus jusqu’ici, il n’est pas impossible qu’un attaquant prenne pied dans le SI. Comme les premiers chapitres l’ont montré, PowerShell peut se transformer en arme entre leurs mains. Si la phase de compromission initiale est passée sans détection de la part des défenseurs, il y a fort à parier que l’attaquant utilisera PowerShell à un moment ou à un autre.

Dans une optique de défense en profondeur, la supervision de PowerShell est donc un élément particulièrement intéressant. Techniquement, nous avons déjà un début de supervision dans la section précédente, puisque sysmon remonte tous les lancements de processus avec la ligne de commande associée. Il est en conséquence déjà possible de rechercher tous les lancements de PowerShell.exe, avec l’option dédiée -EncodedCommand.

Néanmoins, cette approche va rapidement manquer en verbosité, ce qui empêchera les analystes de savoir ce qu’il s’est passé. De plus, elle ne verra rien des accès interactifs à la console. Il est donc nécessaire de faire journaliser PowerShell à un niveau plus élevé pour fournir aux équipes de détection et de réponse un maximum d’informations. Heureusement, PowerShell fournit de nombreux moyens pour tracer sa propre activité.

1. Logs PowerShell

Comme cela a déjà été rapidement montré au chapitre Sécuriser PowerShell, PowerShell génère tout de même par défaut quelques logs.

 Sur Win10-Beaufort, ouvrez l’Observateur d’événements et rendez-vous dans Journaux des applications et des services, Microsoft, Windows, PowerShell et ouvrez le journal Operational :

Dans la configuration par défaut, ces logs sont très peu verbeux, mais il arrive qu’on y trouve des traces utiles sur l’exécution, comme celles issues d’un script potentiellement malveillant repéré automatiquement par PowerShell, de commandes distantes, ou encore de tentatives de modification du contexte de sécurité d’une...

Surveiller avec un SIEM

Les SIEM (Security Information and Event Management) sont les solutions dédiées à l’analyse des gros volumes de données. Ces logiciels sont très utilisés en sécurité pour collecter, normaliser, stocker puis alerter, analyser et représenter des informations à partir des journaux de systèmes d’information. On peut les voir comme de grosses boîtes noires capables d’avaler d’énormes volumes de logs et d’y appliquer ensuite des recherches ou des règles de détection.

L’essai d’un SIEM du marché sur les journaux PowerShell collectés est un bon sujet pour terminer ce chapitre sur la supervision. Il existe de nombreux SIEM, commerciaux ou libres. On citera par exemple Graylog, LogRhythm, Microsoft Sentinel, Elastic ELK ou bien Splunk. Ce livre ne portant pas spécifiquement sur les SIEM, nous ne rentrerons pas dans les détails de leur fonctionnement basé sur les technologies NoSQL et d’indexation.

Dans la suite de cette section, nous allons utiliser la version d’essai du logiciel Splunk Enterprise, d’une part parce qu’il fait partie des principaux SIEM du marché, d’autre part car il est possible de transformer la version d’essai en une version gratuite (Splunk Free). Cette version gratuite est limitée à 500 Mo de journaux injectés par jour et est fournie sans certaines fonctions comme l’alerting. Cette version Splunk Free vous permet ainsi de continuer à travailler à titre personnel ensuite. Enfin, l’installation packagée du logiciel le rend simple à déployer dans notre contexte.

1. Installer une instance Splunk

Nous allons donc déployer le logiciel Splunk sur notre serveur de collecte.

 Pour commencer, sur la machine Kali, rendez-vous avec un navigateur sur le site officiel (https://www.splunk.com) sur lequel il est nécessaire de vous inscrire. Vous pouvez ensuite cliquer sur Free Splunk, qui vous redirige vers cette page : https://www.splunk.com/en_us/download.html

 Cliquez sur Splunk Enterprise puis téléchargez le fichier .deb pour une installation Linux avec Download Now :

 Vous pouvez soit télécharger le fichier directement, soit utiliser la fonction Download...