Bonjour à tous. Aujourd'hui, nous allons voir un exemple où un attaquant a réussi à contourner Windows Defender, mais a échoué - un agent de sécurité. Oui, il s'agit encore une fois de mimikatz. Comment, en lançant mimikatz, pour contourner Windows Defender, vous pouvez lire ici. Et aujourd'hui, comme je l'ai promis, pensez à quelque chose pour l'équipe «bleue». Si cela aide au moins quelqu'un, ce n'est pas en vain. Alors allons-y.Beaucoup a été écrit sur la pile ELK (Elasticsearch, Logstash, Kibana) (y compris sur le Habré), et aujourd'hui nous allons l'utiliser, ou pour être plus précis, un ELK dopé à nos besoins de chasse aux menaces.Le ELK de chasse, ou HELK
Le diagramme HELK ressemble à ceci:
Passons à l'installation.En tant que serveur où HELK sera situé, j'ai choisi, comme le conseille le développeur:tomhunter@helk:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
L'installation est simple et s'effectue en 2 commandes:git clone https://github.com/Cyb3rWard0g/HELK
tomhunter@helk:~/HELK/docker$ sudo ./helk_install.sh
Remarque: il se peut que l'on vous demande d'allouer plus de RAM pour l'installation. J'utilise 10 Go.
Parmi les
options d'installation proposées, j'ai choisi KAFKA + KSQL + ELK + NGNIX + ELASTALERT . Et maintenant j'attends. Et, si nous avons tout fait correctement, nous verrons le chéri:
avec le serveur terminé, préparons le client. Ce sera une machine Windows 10. Nous devons y installer Sysmon.Nous avons également besoin d'un fichier de configuration: git clone https://github.com/olafhartong/sysmon-modular
Générez la configuration: . .\Merge-SysmonXml.ps1
Merge-AllSysmonXml -Path ( Get-ChildItem '[0-9]*\*.xml') -AsString | Out-File sysmonconfig.xml
Courir: PS C:\Users\Tomhunter\Documents\sysmon-modular> .\Sysmon64.exe -i .\sysmonconfig.xml
Nous allons également installer winlogbeat , supprimer le fichier winlogbeat.yml et en créer un nouveau en copiant raw.githubusercontent.com/Cyb3rWard0g/HELK/master/configs/winlogbeat/winlogbeat.yml dedansRemarque: ici, nous devons également changer l'adresse IP en celle souhaitée (dans mon cas, les hôtes: ["192.168.31.97:9092"].
Installer: PS C:\Users\Tomhunter\Desktop\winlogbeat-7.6.2-windows-x86_64> .\install-service-winlogbeat.ps1
Remarque: vous devez activer le service à la main ou redémarrer le système.
Tout est prêt, voyons ce que nous obtenons.Nous commençons mimikatz sur Windows 10.
Et, après avoir entré la cybana (dans mon cas, c'est 192.168.31.97 , les informations d'identification par défaut: helk: chasse), nous voyons une alerte. Dans sa forme brute, cela ressemble à ceci: les
alertes peuvent être envoyées par e-mail, en mou, etc.Mais nous sommes beaucoup plus intéressés par la façon dont cela fonctionne, comprenons.Un peu de théorie
Après avoir démarré mimikatz avec Windows 10, le message suivant vole:
Quelle est la règle qui a émis l'alerte qui m'a dérouté? (spoiler: pas le nom du fichier mimikatz.exe). Jetons un coup d'œil à la règle elle-même:sudo docker exec -it helk-elastalert bash
cat /opt/sigma/rules/windows/sysmon/sysmon_mimikatz_detection_lsass.yml
EventID: 10. Ceci est notre ProcessAccess.TargetImage: C: \ windows \ system32 \ lsass.exe. C'est bien, mais mimikatz n'est pas le seul à se tourner vers lsass.
GrantedAccess: 0x1410 ou 0x1010.Et ici tout se met en place. J'explique.Jetons un coup d'œil au code source de mimikatz, à savoir, nous sommes intéressés par le fichier kuhl_m_sekurlsa.c et la fonction kuhl_m_sekurlsa_acquireLSA ().
En ce qui concerne le site Web de Microsoft, nous voyons quePROCESS_QUERY_LIMITED_INFORMATION (0x1000)
PROCESS_VM_READ (0x0010)
PROCESS_QUERY_INFORMATION (0x0400)
En utilisant «OU» au niveau du bit, nous obtenons notre accès accordéRemarque: plus tôt dans la règle sigma, il n'y avait que la détection 0x1410, probablement en raison du fait que les anciennes versions de mimikatz faisaient les deux demandes (PROCESS_QUERY_INFORMATION et PROCESS_QUERY_LIMITED_INFORMATION), cependant, mimikatz est passé avec 0x1010, vous avez donc dû corriger la règle vous-même. Maintenant, il n'y a pas un tel problème, et tout fonctionne hors de la boîte.
Ainsi, si dans le kiban nous mettons le filtreevent_id: 10 AND process_target_name: "* lsass.exe" AND process_granted_access: "0x1010", alors nous n'aurons que notre mimikatz.
De l'agréable: il existe des règles pour mimikatz_inmemory, mimikatz_trough_winrm et même safetycatz (version .NET de mimikatz avec ses propres puces).Que pouvez vous faire d'autre?
Bien entendu, les règles ne se limitent pas au mimikatz, il y en a beaucoup. Ils sont divisés en catégories application, cloud, conformité, linux, réseau, proxy, web et windows. Les catégories sont divisées en sous-catégories. Par exemple, Windows est divisé en intégré, malware, autre, powershell, process_creation, sysmon.Et qui sait, peut-être en incluant la journalisation PowerShell dans le GPO, vous recevrez des alertes selon ces règles:
Cela semble être tout. Abonnez-vous à la chaîne, comme, cliquez sur la cloche.