0xe7/wonkavisionDetecta tickets Kerberos falsificados mediante el volcado de datos de sesión y tickets, la puntuación de anomalías y la generación de indicadores de registros de eventos de Windows para la respuesta a incidentes basada en SIEM.
WonkaVision es una herramienta de prueba de concepto (POC) para analizar tickets de Kerberos e intentar determinar si son falsificados. Esta herramienta fue creada por Charlie Clark y Andrew Schwartz.
Cabe señalar que esta POC no está pensada para ser una aplicación empresarial lista para producción, sino para generar ideas sobre cómo detectar mejor los tickets falsificados y, al mismo tiempo, publicar los IOAs descubiertos.
Charlie Clark es el autor principal de esta base de código.
Gran parte del código para volcar la información de sesión, volcar los tickets de Kerberos y descifrar/cifrar los tickets de Kerberos se tomó de Rubeus. El código de GetNCChanges se adaptó del MakeMeEnterpriseAdmin de Vincent Le Toux.
Tiene 3 funciones:
/createkeys - Crea un par de claves pública/privada para que lo utilicen el volcador y el analizador/dump - Se ejecuta en servidores/estaciones de trabajo, vuelca los datos de sesión con los tickets de Kerberos asociados/analyze - Se ejecuta contra un directorio que contiene todos los archivos de volcado, analiza todas las sesiones y tickets dentro de los volcados, genera puntuaciones y escribe en el registro de eventosWonkaVision tiene las siguientes dependencias:
La presentación de diapositivas de la charla está aquí.
WonkaVision está licenciado bajo la licencia BSD 3-Clause.
Genera un par de claves pública y privada utilizando el algoritmo de intercambio de claves Diffie-Hellman de Curva Elíptica (ECDH) con la curva P-256. De forma predeterminada, escribe las claves en la terminal como blobs codificados en base64, pero tiene el argumento /outdir:PATH para escribir las claves en archivos.
SI SE ESCRIBEN EN ARCHIVOS, EL ARCHIVO private.key DEBE PROTEGERSE COMO SI FUERA LA CLAVE KRBTGT
Ejemplo 1:
C:\WonkaVision>WonkaVision.exe /createkeys
====================PublicKey====================
RUNLMSAAAABN/odC5C5W7meBvf6rKmWOoVW9qRTRcyCJBFuvRbEvMFuMa8cV20W1e+rRd4f9jSfr5vDVJ0+I/SJsZI1ondws
==================End PublicKey==================
====================PrivateKey====================
RUNLMiAAAABN/odC5C5W7meBvf6rKmWOoVW9qRTRcyCJBFuvRbEvMFuMa8cV20W1e+rRd4f9jSfr5vDVJ0+I/SJsZI1ondwsto7Fc/J4akdJdCix51F0ELLKWlsdMDlkYx2shFEV3AA=
==================End PrivateKey==================
Ejemplo 2:
C:\WonkaVision>WonkaVision.exe /createkeys /outdir:.
[!] Writing key files to ., be sure to protect the private key as if it was the krbtgt key!
[*] Written public key to .\public.key
[*] Written private key to .\private.key
C:\WonkaVision>dir
Volume in drive C is System
Volume Serial Number is 22BC-4361
Directory of C:\WonkaVision
10/14/2022 01:10 PM <DIR> .
10/14/2022 01:10 PM <DIR> ..
10/14/2022 01:10 PM 104 private.key
10/14/2022 01:10 PM 72 public.key
10/14/2022 01:08 PM 1,383,424 WonkaVision.exe
3 File(s) 1,383,600 bytes
2 Dir(s) 71,813,464,064 bytes free
Vuelca la información de sesión de las sesiones que contienen tickets de Kerberos, incluidos los propios tickets de Kerberos en formato KERB-CRED. Lo hace ejecutando LsaCallAuthenticationPackage para solicitar información de sesión, información sobre la caché de tickets y solicitar tickets como KERB-CREDs (de la misma manera que lo hace el comando dump de Rubeus).
Se requieren 2 argumentos principales:
/publickey:KEY - clave pública que se utilizará para el cifrado de los datos volcados/dumpdir:DIR - directorio para almacenar los datos volcadosUna vez que los datos han sido volcados, WonkaVision hace lo siguiente:
/publickey:KEY para derivar una clave simétrica/dumpdir:DIREs posible especificar sesiones concretas (con el argumento /luid:X), usuarios (con el argumento /user:USER), servicios (con el argumento /service:SVC) y/o servidores (con el argumento /server:Y), pero estos aún no han sido muy probados.
Ejemplo:
WonkaVision.exe /dump /publickey:\\server\dumpshare\public.key /dumpdir:\\server\dumpshare\dumps
Analiza los volcados creados con el comando /dump. Recorre recursivamente todos los subdirectorios a los que apunta /dumpdir:DIR y lee cualquier archivo .json que encuentre. Una vez que deserializa el archivo json, recorre todas las sesiones almacenadas en él y todos los tickets dentro de las sesiones y los analiza con la mayor profundidad posible, asignando una puntuación a cada desviación de lo esperado que encuentre. Después, suma estas puntuaciones para producir una puntuación total y genera 2 tipos diferentes de eventos de Windows, 9988 y 9989, para WonkaVision Session y WonkaVision Ticket respectivamente, que contienen todos los problemas descubiertos.
Es posible especificar /creduser:USER, /creddomain:DOMAIN y /credpass:PASSWORD para usar credenciales alternativas para las consultas LDAP y la sincronización con DC. Sin embargo, esto no se recomienda en producción; se implementaron para facilitar un poco la depuración de problemas.
Se requieren 2 argumentos principales:
/privatekey:KEY - clave privada utilizada para descifrar los volcados cifrados/dumpdir:DIR - directorio donde se almacenan los volcados cifradosEjemplo:
WonkaVision.exe /analyze /privatekey:C:\keys\private.key /dumpdir:C:\dumpshare\dumps
Aunque WonkaVision devolverá el resultado del análisis a través de la terminal, se puede encontrar una descripción más detallada del análisis de Indicadores de Ataque (IOA) en el canal de Registro de Eventos de Aplicaciones de Windows. Es aquí donde un analista obtendrá una mayor visión y contexto en cuanto a la Puntuación Total, los IOAs específicos, la(s) razón(es) de los IOAs y las puntuaciones de las herramientas. Se escriben dos eventos, 9988 (Evento de Sesión) y 9989 (Evento de Ticket), respectivamente. Se puede encontrar una muestra de eventos aquí.
El siguiente es un ejemplo de un Evento de Sesión de WonkaVision (9988):
El siguiente es un ejemplo de un Evento de Ticket de WonkaVision (9989):
Ejemplo de un posible Golden Ticket falsificado con Mimikatz en registros EVTX:
Como se indicó anteriormente, los registros de WonkaVision se escriben en el canal de Registro de Eventos de Aplicaciones de Windows. Si se configura, estos registros pueden reenviarse a un SIEM (por ejemplo, Splunk, Sentinel, etc.).
También se puede utilizar una consulta sugerida con el registro de eventos WinEvnet "Classic" de Splunk:
index="wv_demo_wineventlog" source="WinEventLog:Application" (Total_Score>=8) | table _time,Total_Score,User,Machine_Name,Service_Principal_Name,Mimikatz_Score,Rubeus_Score,Impacket_Score,Cobalt_Strike_Score,IOA_Reasons
Ejemplo de un posible Golden Ticket falsificado con Mimikatz en WonkaVision dentro de Splunk:
Ejemplo de un posible Golden Ticket falsificado con Rubeus desde WonkaVision en Splunk:
El registro con Sentinel también se puede realizar. Sin embargo, esto puede requerir un análisis adicional. A continuación se muestra un ejemplo de consulta de Jonathan Johnson (@jsecurity101) sobre cómo puede aparecer WonkaVision analizado en Sentinel:
Event
| where Computer contains "asgard" and Source contains "Wonka"
| extend ParsedEventData=parse_xml(EventData)
| extend Data=ParsedEventData.DataItem.EventData.Data
| parse-where Data with *
"Total Score: " TotalScore:string
"Session: " Session:string
"Machine Name: " MachineName:string
"User: " User:string
"Service Principal Name: " ServicePrincipalName:string
"IOAs: " IOAs:string
"SessionUser: " IOA_SessionUser:string
"KDCCalled: " IOA_KDCCalled:string
"Mimikatz Score: " TScore_MimikatzScore:string
"Impacket Score: " TScore_ImpacketScore:string
"Rubeus Score: " TScore_RubeusScore:string
"Cobalt Strike Score: " TScore_CobaltStrikeScore:string
"IOA Reasons: " IOA_Reasons:string
| where IOA_SessionUser contains "thor"
Ejemplo de un posible Golden Ticket falsificado desde WonkaVision en Sentinel:
Demo 1 - Creación de Golden Ticket:
Demo 2 - Creación de par de claves y volcado de sesión/ticket:
Demo 3 - Análisis de volcado y salida de eventos de Windows:
Demo 4 - Sniffer de red de Kerberos:
El POC de Sniffer de Tráfico Kerberos que demostramos en nuestra charla (Demo 4) se implementó con SharpPCap, pero podría modificarse fácilmente para usar sockets sin procesar, eliminando esa dependencia y la necesidad de instalar npcap en el sistema.
Como solo era un POC mínimo, la mayoría de los indicadores que se implementaron fueron los indicadores no cifrados mencionados en la charla de Charlie en YASCON 2020, detallados en la diapositiva 18 de esta presentación, aunque se podrían implementar muchos más.