Parcours d’apprentissage 9 - Labo 1 - Exercice 7 - Créer des détections

Scénario du labo

Vue d’ensemble du labo

Vous êtes un analyste des opérations de sécurité travaillant dans une entreprise ayant mis en œuvre Microsoft Sentinel. Vous allez travailler avec des requêtes KQL Log Analytics et à partir de là, vous allez créer des règles analytiques personnalisées pour vous aider à identifier les menaces et les comportements anormaux dans votre environnement.

Les règles analytiques recherchent des événements ou des ensembles d’événements spécifiques au sein de votre environnement, vous préviennent lorsque certains seuils ou conditions d’événements sont atteints, génèrent des incidents que votre centre des opérations de sécurité (SOC) doit trier et examiner, et répondent aux menaces grâce à des processus de suivi et de correction automatisés.

Important : les exercices de laboratoire du parcours d’apprentissage #9 se trouvent dans un environnement autonome. Si vous quittez le labo sans enregistrer, vous devrez réexécuter certaines configurations.

Temps estimé pour terminer ce labo : 30 minutes

Tâche 1 : détection des attaques de persistance

Important : les étapes suivantes sont effectuées sur une machine différente de celle que vous utilisiez précédemment. Recherchez les références de nom de machine virtuelle.

Dans cette tâche, vous allez créer une détection pour la première attaque de l’exercice précédent.

Connectez-vous à la machine virtuelle WIN1 en tant qu’Administrateur ou Administratrice avec le mot de passe : Pa55w.rd.
Dans le navigateur Edge, accédez au portail Azure à l’adresse https://portal.azure.com.
Dans la boîte de dialogue Connexion, copiez et collez le compte de messagerie du locataire fourni par l’hébergeur du labo, puis sélectionnez Suivant.
Dans la boîte de dialogue Entrer un mot de passe, copiez et collez le mot de passe du locataire fourni par l’hébergeur du labo, puis sélectionnez Connexion.
Dans la barre de recherche du portail Azure, tapez Sentinel, puis sélectionnez Microsoft Sentinel.
Sélectionnez votre espace de travail Microsoft Sentinel.
Sous la section Général, sélectionnez Journaux.
Réexécutez l’instruction KQL suivante pour rappeler les tables où nous disposons de ces données :
```
 search "temp\\startup.bat"
```
Remarque : un résultat avec l’événement peut prendre jusqu’à 5 minutes. Patientez jusqu’à ce que le résultat apparaisse. S’il n’apparaît pas, vérifiez que vous avez redémarré WINServer comme indiqué dans l’exercice précédent et que vous avez terminé la tâche 3 du labo du parcours d’apprentissage 6, exercice 2.
La table SecurityEvent semble avoir les données déjà normalisées et faciles à interroger. Développez la ligne pour afficher toutes les colonnes associées à l’enregistrement.
À partir des résultats, nous savons désormais que l’acteur de la menace utilise reg.exe pour ajouter des clés à la clé de Registre et que le programme se trouve dans C:\temp. Exécutez l’instruction suivante pour remplacer l’opérateur Search par l’opérateur Where dans notre requête :
```
 SecurityEvent 
 | where Activity startswith "4688" 
 | where Process == "reg.exe" 
 | where CommandLine startswith "REG" 
```
Il est important d’aider l’analyste du centre des opérations de sécurité en fournissant autant de contexte sur l’alerte que possible. Cela inclut la projection d’entités à utiliser dans le graphe d’investigation. Exécutez la requête suivante :
```
 SecurityEvent 
 | where Activity startswith "4688" 
 | where Process == "reg.exe" 
 | where CommandLine startswith "REG" 
 | extend timestamp = TimeGenerated, HostCustomEntity = Computer, AccountCustomEntity = SubjectUserName
```
Maintenant que vous disposez d’une bonne règle de détection, depuis la fenêtre Journaux, sélectionnez + Nouvelle règle d’alerte dans la barre de commandes, puis Créer une alerte Microsoft Sentinel. Une règle planifiée est alors créée. Conseil : vous devrez peut-être sélectionner le bouton représentant des points de suspension (…) dans la barre de commandes.

L’Assistant Règle analytique s’ouvre alors. Pour le type d’onglet Général :

Paramètre	Valeur
Nom	Démarrage de RegKey
Description	Démarrage de RegKey dans C:\temp
Tactique	Persistance
Niveau de gravité	Forte

Sélectionnez le bouton Suivant : Définir la logique de la règle >.
Sous l’onglet Définir la logique de règle, la requête Règle doit être déjà remplie avec votre requête KQL.

Configurez les entités sous Amélioration de l’alerte : mappage d’entités à l’aide des paramètres du tableau ci-dessous.

Entité	Identificateur	Champ de données
Compte	FullName	AccountCustomEntity
Hôte	Nom d’hôte	HostCustomEntity

Pour la planification de la requête, définissez les éléments suivants :

Paramètre	Valeur
Exécuter la requête toutes les	5 minutes
Rechercher les données des dernières	1 jour

Remarque : nous générons volontairement de nombreux incidents pour les mêmes données. Cela permet au labo d’utiliser ces alertes.

Laissez les autres options par défaut. Sélectionnez le bouton Suivant : Paramètres d’incident >.
Sous l’onglet Paramètres d’incident, conservez les valeurs par défaut et sélectionnez le bouton Suivant : Réponse automatique >.
Dans l’onglet Réponse automatique, sous Règles d’automatisation, sélectionnez Ajouter.

Utilisez les paramètres de la table pour configurer la règle d’automatisation.

Paramètre	Valeur
Nom de la règle d’automatisation	Démarrage de RegKey
Déclencheur	Lorsqu’un incident est créé
Actions	Exécuter des playbooks
playbook	PostMessageTeams-OnIncident

Remarque : vous avez déjà attribué des autorisations au playbook. Il sera donc disponible.

Sélectionnez Appliquer
Sélectionnez **Suivant : Vérifier + créer > **.
Sous l’onglet Vérifier et créer, sélectionnez le bouton Enregistrer pour créer la règle Analytique planifiée.

Tâche 2 : détection des attaques par élévation de privilèges

Dans cette tâche, vous allez créer une détection pour la deuxième attaque de l’exercice précédent.

Dans le portail Microsoft Sentinel, sélectionnez Journaux dans la section Général au cas où vous vous seriez éloigné de cette page.
Exécutez l’instruction KQL suivante pour identifier toute entrée qui fait référence aux administrateurs :
```
 search "administrators" 
 | summarize count() by $table
```
Le résultat peut afficher des événements provenant de différentes tables, mais dans notre cas, nous voulons examiner la table SecurityEvent. L’EventID et l’événement que nous recherchons sont « 4732 – Un membre a été ajouté à un groupe local sécurisé ». Avec cela, nous allons identifier l’ajout d’un membre à un groupe privilégié. Exécutez la requête KQL suivante pour confirmer ce qui suit :
```
 SecurityEvent 
 | where EventID == 4732
 | where TargetAccount == "Builtin\\Administrators"
```
Développez la ligne pour afficher toutes les colonnes associées à l’enregistrement. Le nom d’utilisateur du compte ajouté en tant qu’administrateur ou administratrice ne s’affiche pas Le problème est qu’au lieu de stocker le nom d’utilisateur, nous avons l’identificateur de sécurité (SID). Exécutez le KQL suivant pour faire correspondre le SID au nom d’utilisateur ajouté au groupe Administrateurs :
```
 SecurityEvent 
 | where EventID == 4732
 | where TargetAccount == "Builtin\\Administrators"
 | extend Acct = MemberSid, MachId = SourceComputerId  
 | join kind=leftouter (
     SecurityEvent 
     | summarize count() by TargetSid, SourceComputerId, TargetUserName 
     | project Acct1 = TargetSid, MachId1 = SourceComputerId, UserName1 = TargetUserName) on $left.MachId == $right.MachId1, $left.Acct == $right.Acct1
```

Étendez la ligne pour afficher les colonnes résultantes. Dans la dernière, nous voyons le nom de l’utilisateur ajouté sous la colonne UserName1 que nous projetons dans la requête KQL. Il est important d’aider l’analyste des opérations de sécurité en fournissant autant de contexte sur l’alerte que possible. Cela inclut la projection d’entités à utiliser dans le graphe d’investigation. Exécutez la requête suivante :

 SecurityEvent 
 | where EventID == 4732
 | where TargetAccount == "Builtin\\Administrators"
 | extend Acct = MemberSid, MachId = SourceComputerId  
 | join kind=leftouter (
     SecurityEvent 
     | summarize count() by TargetSid, SourceComputerId, TargetUserName 
     | project Acct1 = TargetSid, MachId1 = SourceComputerId, UserName1 = TargetUserName) on $left.MachId == $right.MachId1, $left.Acct == $right.Acct1
 | extend timestamp = TimeGenerated, HostCustomEntity = Computer, AccountCustomEntity = UserName1

Maintenant que vous disposez d’une bonne règle de détection, dans la fenêtre Journaux, sélectionnez + Nouvelle règle d’alerte dans la barre de commandes, puis Créer une alerte Microsoft Sentinel. Conseil : vous devrez peut-être sélectionner le bouton représentant des points de suspension (…) dans la barre de commandes.