# TP Détection d’intrusion en environnementWindows et Active Directory
* Aurélien BOUTAUD - e2004685
* Vazeille Alexandre - e2004704

## Signature SIGMA
Après avoir mis en place le lab, nous avons pris en main les signatures SIGMA en créant une règle pour Mimikatz puis nous l'avons converti en une règle SPL pour tester son bon fonctionnement.
La règle SIGMA que nous avons créée est la suivante :

title : Mimikatz CLI
id: b7f5a902-6d78-44eb-91be-91218eb8f6cd
description: Detects Mimikatz commands.
references:
  - https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Windows%20-%20Mimikatz.md
status: experimental
author: bava
date: 2023/09/01
modified: 2023/09/01
tags:
  - attack.s0002
  - attack.lateral_movement
  - attack.credential_access
logsource:
  product: windows
detection:
     keywords:
        - 'dpapi::masterkey'
        - 'eo.oe.kiwi'
        - 'event::clear'
        - 'event::drop'
        - 'gentilkiwi.com'
        - 'kerberos::golden'
        - 'kerberos::ptc'
        - 'kerberos::ptt'
        - 'kerberos::tgt'
        - 'Kiwi Legit Printer'
        - 'lsadump::'
        - 'mimidrv.sys'
        - '\mimilib.dll'
        - 'misc::printnightmare'
        - 'misc::shadowcopies'
        - 'misc::skeleton'
        - 'privilege::backup'
        - 'privilege::debug'
        - 'privilege::driver'
        - 'sekurlsa::'
    filter:
        EventID: 15  # Sysmon's FileStream Events (could cause false positives when Sigma rules get copied on/to a system)
    condition: keywords and not filter
falsepositives:
    - Legitimate administration use but user must be check out
level: medium
fields:
    - Image
    - User
    - CommandLine
    - ParentCommandLine

La requête SPL correspondante est la suivante :

"dpapi::masterkey" OR "eo.oe.kiwi" OR "event::clear" OR "event::drop" OR "gentilkiwi.com" OR "kerberos::golden" OR "kerberos::ptc" OR "kerberos::ptt" OR "kerberos::tgt" OR "Kiwi Legit Printer" OR "lsadump::" OR "mimidrv.sys" OR "\\mimilib.dll" OR "misc::printnightmare" OR "misc::shadowcopies" OR "misc::skeleton" OR "privilege::backup" OR "privilege::debug" OR "privilege::driver" OR "sekurlsa::" NOT EventID=15

Splunk nous remonte l'évènement suivant :

<Event
	xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
	<System>
		<Provider Name='Microsoft-Windows-Sysmon' Guid='{5770385f-c22a-43e0-bf4c-06f5698ffbd9}'/>
		<EventID>1</EventID>
		<Version>5</Version>
		<Level>4</Level>
		<Task>1</Task>
		<Opcode>0</Opcode>
		<Keywords>0x8000000000000000</Keywords>
		<TimeCreated SystemTime='2023-01-09T23:06:33.656576500Z'/>
		<EventRecordID>2299079</EventRecordID>
		<Correlation/>
		<Execution ProcessID='2240' ThreadID='3004'/>
		<Channel>Microsoft-Windows-Sysmon/Operational</Channel>
		<Computer>client.bava.local</Computer>
		<Security UserID='S-1-5-18'/>
	</System>
	<EventData>
		<Data Name='RuleName'>-</Data>
		<Data Name='UtcTime'>2023-01-09 23:06:33.632</Data>
		<Data Name='ProcessGuid'>{8e50dd02-9df9-63bc-1104-000000001a00}</Data>
		<Data Name='ProcessId'>9816</Data>
		<Data Name='Image'>C:\Users\lade\Downloads\mimikatz.exe</Data>
		<Data Name='FileVersion'>2.2.0.0</Data>
		<Data Name='Description'>mimikatz for Windows</Data>
		<Data Name='Product'>mimikatz</Data>
		<Data Name='Company'>gentilkiwi (Benjamin DELPY)</Data>
		<Data Name='OriginalFileName'>mimikatz.exe</Data>
		<Data Name='CommandLine'>mimikatz.exe  sekurlsa::krbtgt</Data>
		<Data Name='CurrentDirectory'>C:\Users\lade\Downloads\</Data>
		<Data Name='User'>CLIENT\lade</Data>
		<Data Name='LogonGuid'>{8e50dd02-8ef4-63bc-7a24-090000000000}</Data>
		<Data Name='LogonId'>0x9247a</Data>
		<Data Name='TerminalSessionId'>1</Data>
		<Data Name='IntegrityLevel'>High</Data>
		<Data Name='Hashes'>SHA1=D1F7832035C3E8A73CC78AFD28CFD7F4CECE6D20,MD5=E930B05EFE23891D19BC354A4209BE3E,SHA256=92804FAAAB2175DC501D73E814663058C78C0A042675A8937266357BCFB96C50,IMPHASH=1355327F6CA3430B3DDBE6E0ACDA71EA</Data>
		<Data Name='ParentProcessGuid'>{8e50dd02-8f4e-63bc-a300-000000001a00}</Data>
		<Data Name='ParentProcessId'>7840</Data>
		<Data Name='ParentImage'>C:\Windows\System32\cmd.exe</Data>
		<Data Name='ParentCommandLine'>"C:\Windows\system32\cmd.exe" </Data>
		<Data Name='ParentUser'>CLIENT\lade</Data>
	</EventData>
</Event>

## Cas d'usage
Une fois Splunk rapidement pris en main avec l'exercice précédent, nous nous sommes penchés sur l'exécutable qui nous a été fourni afin d'en comprendre son fonctionnement et de rédiger les requêtes Splunk correspondantes.

### Exercice 1
#### Analyse du fonctionnement
L'exécutable réalise plusieurs actions.
Un évènement récurrent que l'on retrouvera tout au long de nos investigations sera la création d'une clé de registre BAM (`HKLM\System\CurrentControlSet\Services\bam\State\UserSettings\S-1-5-21-2049402910-1774223977-1796254597-1003\\Device\HarddiskVolume2\ensibs2023.exe`).
Cette action est une action légitime qui n'a certainement pas été implémentée par le développeur de l'exécutable. Cette clé est un artefact forensique permettant de montrer des traces d'exécution de processus.

L'exécutable exécute 2 commandes "net", à savoir :
* `net group "domain admins" /domain` : L'exécutable répertorie tout les administrateur du domaine
* `net localgroup administrator` : L'exécutable répertorie tout les administrateurs locaux

Il répertorie également les relations de confiances des domaines à l'aide de nltest et de la commande `nltest /domain_trusts /all_trusts` ainsi que tout les privilèges qui lui sont attribués à l'aide de la commande `whoami /all`

Les Tactiques utilisées sont des tactiques de Discovery, dont des techniques de découverte de compte :
- T1087.001
- T1087.002
- T1482

#### Requêtes SPL
Nous avons choisi de faire plusieurs requêtes distinctes, car l'exécutable réalise plusieurs actions qui peuvent être utilisées dans un ordre indifférent et qui peuvent être individuellement un signe d'une action malveillante.
Afin de limiter les faux positifs, nous avons exclu la clé de registre BAM qui est légitime, ainsi que la commande `whoami /all` qui peut être utilisé légitimement par des administrateurs privilégiés ou non.

##### Première requête
`index="labensibs" CommandLine="net group \"domain admins\" /domain" IntegrityLevel!=High`

##### Seconde requête
`index="labensibs" CommandLine="net localgroup administrator" IntegrityLevel!=High`

##### Troisième requête
`index="labensibs" CommandLine="nltest /domain_trusts /all_trusts" IntegrityLevel!=High`

##### Requete Bonus
Nous avons également fait une règle permettant de signer l'exécutable par IMHASH qui se construit sur l'ordre de chargement des DLL :
`index="labensibs" "IMPHASH=D2B6E7BA751333CBC79D8A3528BA13E3"`

#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel :

### Exercice 2
#### Analyse du fonctionnement
L'exécutable exécute un programme en détournant la clé `runonce` (`HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\C4LC TH3 PL4N3T`) qui permet d'exécuter une commande (`calc.exe`) au lancement de la session utilisateur. L'avantage de cette clé pour un attaquant est qu'elle se supprime automatiquement du registre après exécution.
L'exécutable forcera l'exécution de la clé `runonce` nouvellement créé à l'aide de la commande `runeonce \r`.

#### Requêtes SPL
Nous avons là aussi décidé de dissocier les deux requêtes, car l'inscription de la clé de registre seule peut déjà être un signe d'une action malveillante.
##### Première requête
`index="labensibs" "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce"`

##### Seconde requête
`index="labensibs" CommandLine="runonce /r"`

#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel :

### Exercice 3
#### Analyse du fonctionnement
L'exécutable commence par créer un fichier `C:\Potator.exe` à la racine du disque `C:\`. Celui-ci ne sera pas directement exécuté, mais un service de type "Win32 Own Process" (0x10) en "user mode service" sera créé avec un type de démarrage manuel (3).
Une clé de registre permettant l'enregistrement du service sera également créée (`HKLM\System\CurrentControlSet\Services\Malicious Potato\ImagePath`).

#### Requêtes SPL
Nous avons choisi de créer de règles distinctes, car les deux évènements nous semblent intéressants indépendamment :
* La création d'un fichier à la racine du disque système (`C:\`) n'est pas un évènement classique et nécessite d'être investigué.
* La création d'un service à partir d'un exécutable se trouvant à la racine du disque système est un évènement qui ne semble pas être légitime.

##### Première requête
`index="labensibs" EventCode="11" | regex TargetFilename="^C:\\\\[^\\\\]*$"`

##### Seconde requête
`index="labensibs" Channel=Security EventCode=4697 | regex ServiceFileName="^C:\\\\[^\\\\]*$"`

#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel.
À noter que le service étant déjà installé sur la machine après une première exécution ayant servi à l'analyse, le service n'est pas recréé par le programme. Nous n'avons donc pas d'alerte sur la seconde requête.

### Exercice 4
#### Analyse du fonctionnement
L'exécutable crée un fichier `C:\lsass.dmp` qui se trouve être (comme son nom peut l'évoquer) être un dump mémoire du processus `C:\Windows\system32\lsass.exe`. C'est une action commune des malwares, le processus lsass contient des identifiants en clair.

#### Requêtes SPL
Nous aurions pu signer spécifiquement le dump de mémoire de processus sur `C:\lsass.dmp`, mais un dump de mémoire de processus est rarement une action légitime, les processus pouvant contenir divers secrets, nous avons donc décidé de ne pas nous limiter à ce processus.
`iindex="labensibs" EventID=10 CallTrace="*C:\\Windows\\SYSTEM32\\dbgcore.DLL*" NOT "C:\\Windows\\system32\\WerFault.exe"`

#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel :

### Exercice 5
#### Analyse du fonctionnement

L'exécutable crée un Pipe contenant la chaine de caractère 'ENSIBS'. La création de Pipe est souvent utilisée par les malwares afin de procéder à des communications entre processus.

#### Requêtes SPL
Nous cherchons à détecter la génération des événements ayant pour EventID 17, qui correspond à la création d'un Pipe. Nous détectons lorsque la création vient d'un processus situé à la racine du disque.
`EventID="17" | regex Image="^C:\\\\[^\\\\]*$"`


#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel :

### Exercice 6
#### Analyse du fonctionnement
L'exécutable crée un tread dans le processus `C:\Windows\System32\notepad.exe` (à l'adresse `0x00000116902A0000`), qui est le processus dont nous avons indiqué le PID à l'exécutable. Cela lui permet d'injecter du code dans ce processus.
Les actions suivantes ne sont pas réalisées par notre exécutable, mais par le processus dont nous avons indiqué le PID (`notepad.exe`). Ce processus va donc créer un nouveau processus `calc.exe` en ligne de commande, puis va accéder à sa mémoire.

#### Requêtes SPL
La création de thread dans un autre processus est une action communément utilisée par les malwares afin de se dissimuler. Travaillant dans une infrastructure virtualisée, l'hyperviseur effectue notre action sur le système virtualisé (notamment pour les VMTools) ce qui engendre de faux positifs. Nous avons donc exclu le dossier du dit hyperviseur en "SourceImage" dans notre règle.
`index="labensibs" EventID=8 SourceImage!="C:\\Program Files\\VMware*"`

#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel :

### Exercice Bonus
#### Analyse du fonctionnement

L'exécutable exécute une commande powershell encodée en base64 (qui est également offusquée après décodage) et crée un fichier `PoWErShELl.exe` auquel il accède. La suite sera effectuée depuis ce nouvel exécutable.
`PoWErShELl.exe` fait un dump de`lsass.exe`, crée un Pipe qui n'est pas utilisée (`\PSHost.133180467963957995.3180.DefaultAppDomain.powershell`) et créée des fichiers qu'il supprime en boucle (`%LocalAppData%\Temp\__PSScriptPolicyTest_jqzpdqjo.dba.ps1` et `%LocalAppData%\Microsoft\Windows\PowerShell\StartupProfileData-NonInteractive`). Il crée puis supprime aussi un fichier une seule fois `C:\Users\lade\AppData\Local\Temp\__PSScriptPolicyTest_bnxpxngz.v5l.psm1`.
Il édite également le registre sur de multiples clés liées aux certificats (`CRLs/Certificats/AuthRoot/Trust`) ainsi qu'une autre qui est édité en boucle (`TargetObject'>HKU\S-1-5-21-2049402910-1774223977-1796254597-1003_Classes\Local Settings\MuiCache\10\52C64B7E\LanguageList`)

Un pop-up affichant "Your computer is infected !" apparait sur la machine.

#### Requêtes SPL
Nous avons vu que la localisation de l'exécutable ainsi que son nom sont faits pour complexifier les requêtes splunk (splunk n'étant, nativement, pas sensible à la case) en faisant passer l'exécutable pour un binaire légitime (Powershell.exe).
Nous avons fait une requête splunk afin de détecter ce genre de comportement (nous récupérons tous les exécutables étant nommé "Powershell" et exploitant la faiblesse de splunk sur la sensibilité à la case).
`index="labensibs" Image="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\Powershell.exe" | regex Image!="C:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1.0\\\\[pP]owershell.exe"`

#### Alertes
Nous avons transformé ces requêtes en alertes et relancé l'exécutable afin de vérifier que notre règle fonctionne bien dans un contexte opérationnel :