Hola a todos. Hoy veremos un ejemplo en el que un atacante logró evitar Windows Defender, pero falló: un guardia de seguridad. Sí, nuevamente se trata de mimikatz. Cómo, al iniciar mimikatz, evitar Windows Defender, puede leer aquí. Y hoy, como prometí, considere algo para el equipo "azul". Si al menos ayuda a alguien, no es en vano. Entonces vamos.Se ha escrito mucho sobre la pila ELK (Elasticsearch, Logstash, Kibana) (incluso en el Habré), y hoy la usaremos, o para ser más precisos, un ELK dopado a nuestras necesidades para la caza de amenazas.The Hunting ELK, o HELK
El diagrama HELK tiene este aspecto: pasemos
a la instalación.Como el servidor donde se ubicará HELK, elegí, como aconseja el desarrollador:tomhunter@helk:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
La instalación es simple y se realiza en 2 comandos:git clone https://github.com/Cyb3rWard0g/HELK
tomhunter@helk:~/HELK/docker$ sudo ./helk_install.sh
Nota: se le puede pedir que asigne más RAM para la instalación. Yo uso 10 GB.
De las opciones de instalación propuestas, elegí KAFKA + KSQL + ELK + NGNIX + ELASTALERT . Y ahora solo esperando. Y, si hicimos todo bien, veremos lo apreciado:
con el servidor terminado, preparemos al cliente. Será una máquina con Windows 10. Necesitamos instalar Sysmon en ella.También necesitamos un archivo de configuración: git clone https://github.com/olafhartong/sysmon-modular
Genere la configuración: . .\Merge-SysmonXml.ps1
Merge-AllSysmonXml -Path ( Get-ChildItem '[0-9]*\*.xml') -AsString | Out-File sysmonconfig.xml
Correr: PS C:\Users\Tomhunter\Documents\sysmon-modular> .\Sysmon64.exe -i .\sysmonconfig.xml
También instalaremos winlogbeat , eliminaremos el archivo winlogbeat.yml y crearemos uno nuevo copiando raw.githubusercontent.com/Cyb3rWard0g/HELK/master/configs/winlogbeat/winlogbeat.yml .Nota: aquí también debemos cambiar la dirección IP a la deseada (en mi caso hosts: ["192.168.31.97:9092"].
Instalar en pc: PS C:\Users\Tomhunter\Desktop\winlogbeat-7.6.2-windows-x86_64> .\install-service-winlogbeat.ps1
Nota: debe habilitar el servicio a mano o reiniciar el sistema.
Todo está listo, veamos qué obtenemos.Comenzamos mimikatz en Windows 10.
Y, después de haber ingresado al cybana (en mi caso es 192.168.31.97 , credenciales predeterminadas: helk: hunting) vemos una alerta. En su forma cruda, se ve así: las
alertas pueden enviarse a usted mismo por correo electrónico, con holgura, etc.Pero estamos mucho más interesados en cómo funciona esto, comprendamos.Poco de teoría
Después de iniciar mimikatz con Windows 10, el siguiente mensaje vuela:
¿Cuál es la regla que emitió la alerta que me confundió? (spoiler: no es el nombre del archivo mimikatz.exe). Echemos un vistazo a la regla en sí:sudo docker exec -it helk-elastalert bash
cat /opt/sigma/rules/windows/sysmon/sysmon_mimikatz_detection_lsass.yml
EventID: 10. Este es nuestro ProcessAccess.Imagen de destino: C: \ windows \ system32 \ lsass.exe. Esto es bueno, pero mimikatz no es el único que recurre a lsass.
Acceso concedido: 0x1410 o 0x1010.Y aquí todo cae en su lugar. Yo explico.Echemos un vistazo al código fuente de mimikatz, es decir, estamos interesados en el archivo kuhl_m_sekurlsa.c y la función kuhl_m_sekurlsa_acquireLSA ().
Volviendo al sitio web de Microsoft, vemos quePROCESS_QUERY_LIMITED_INFORMATION (0x1000)
PROCESS_VM_READ (0x0010)
PROCESS_QUERY_INFORMATION (0x0400)
Usando bit a bit "O" obtenemos nuestro acceso concedidoNota: anteriormente en la regla sigma solo había detección 0x1410, esto probablemente se deba al hecho de que las versiones anteriores de mimikatz hicieron ambas solicitudes (PROCESS_QUERY_INFORMATION y PROCESS_QUERY_LIMITED_INFORMATION), sin embargo, mimikatz pasó con 0x1010, por lo que tuvo que ajustar la regla usted mismo. Ahora no hay tal problema, y todo funciona fuera de la caja.
Por lo tanto, si en el kiban colocamos el filtroevent_id: 10 AND process_target_name: "* lsass.exe" AND process_granted_access: "0x1010", solo tendremos nuestro mimikatz.
De lo agradable: hay reglas para mimikatz_inmemory, mimikatz_trough_winrm e incluso safetycatz (versión .NET de mimikatz con sus propios chips).¿Qué más puedes hacer?
Las reglas, por supuesto, no se limitan a mimikatz, hay muchas de ellas. Se dividen en categorías de aplicación, nube, cumplimiento, linux, red, proxy, web y windows. Las categorías se dividen en subcategorías. Por ejemplo, Windows se divide en incorporado, malware, otros, powershell, process_creation, sysmon.Y quién sabe, quizás al incluir el registro de PowerShell en el GPO, recibirá alertas de acuerdo con estas reglas:
eso parece ser todo. Suscríbase al canal, haga clic en el timbre.