En esta segunda entrega de la serie, abordaremos la emulación y detección del volcado del credenciales. Para ello, utilizaremos la instancia de Splunk Enterprise a modo de SIEM e implementaremos una regla específica para la identificación de eventos que nos sugieran este tipo de ataque. Posteriormente realizaremos una prueba atómica a través de la utilidad Invoke de Atomic Red Team que nos permitirá emular el acceso a la memoria a través del proceso LSASS para el volcado de credenciales. 

Credential Dumping 

El volcado de credenciales o credential dumping es un ataque que busca extraer credenciales de sistemas, como contraseñas o tokens, normalmente desde la memoria RAM. Este tipo de memoria volátil es un objetivo bastante común para los atacantes ya que almacena temporalmente información privilegiada para facilitar el acceso y la operatividad del sistema. La obtención de esta información a través de un volcado de memoria es a menudo un precursor de otros ataques, como movimientos laterales, escalada de privilegios o la exfiltración de datos. Para la simulación que realizarmeos abordaremos la extración de credenciales a través del proceso LSASS (Local Security Authority Subsystem Service) el cual es un proceso del sistema operativo Windows responsable de:

• Autenticar usuarios en el sistema
• Aplicar políticas de seguridad
• Gestionar credenciales administrativos

Se trata de una técnica bastante común en la que los atacantes intentan acceder a la información almacenada en la memoria LSASS ya que puede contener credenciales no solo de usuarios actuales si no también de administradores de dominio.

Envío de eventos desde Splunk Enterprise a Splunk SOAR

Para poder enviar los datos recogidos de la detección a través de la alerta específica que posteriormente crearemos, necesitaremos instalar la aplicación Splunk App for SOAR Export

Posteriormente configuraremos la conexión entre Splunk Enterprise y Splunk SOAR a través de Splunk App for SOAR Export siguiendo los siguientes pasos:

1. Por defecto la conexión se establece validando el certificado SSL, por lo tanto en nuestro caso deshabilitaremos esta opción, para ello ejecutamos la siguiente petición contra el servidor de Splunk Enterprise:

   curl -ku '<username>:<password>' https://<splunkaddress>:8089/servicesNS/nobody/phantom/configs/conf-phantom/verify_certs\?output_mode\=json -d value=0

    

2. En Splunk SOAR creamos un nuevo usuario de tipo «automation» y copiamos el token.
   
    
3. Creamos un nuevo servidor e introducimos el token:
   
    
4. Una vez creada la referencia al nuevo servidor, podremos verlo en el listado de servidores:
   
    
5. Por último, verificamos que podemos enviar datos a Splunk SOAR, para ello, ejecutamos la siguiente consulta en Splunk Enterprise:

   | makeresults 
   | eval src_ip="123.45.66.77" 
   | sendalert sendtophantom param.phantom_server="automation (https://10.0.0.100)" param.sensitivity="amber" param.severity="low" param.label="events"

   
   y en Splunk SOAR deberemos recibir un evento con el nombre «Adhoc search result»:

   

Configuración de la alerta en Splunk Enterprise

La detección de indicios de lectura de memoria LSASS se realiza mediante la monitorización de los eventos Sysmon y el filtrado de permisos de acceso específicos (0x1010 y 0x1410) en el proceso lsass.exe. 

Para detectar lecturas de la memoria LSASS utilizaremos como base la búsqueda definida en el Security Content de Splunk, la cual se mapea con el framework MITRE:

`sysmon` EventCode=10 TargetImage=*lsass.exe GrantedAccess IN ("0x01000", "0x1010", "0x1038", "0x40", "0x1400", "0x1fffff", "0x1410", "0x143a", "0x1438", "0x1000") CallTrace IN ("*dbgcore.dll*", "*dbghelp.dll*", "*ntdll.dll*") 
| rename process_name AS deviceProcessName, dest AS sourceHostName, TargetUser AS sourceUserId, SourceUser AS sourceUserName
| table SourceImage, SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess, process_path, technique_id,deviceProcessName, sourceHostName, sourceUserId, sourceUserName

NOTA: Es importante señalar que pueden producirse falsos positivos debido a acciones legítimas que impliquen un acceso a la memoria LSASS. Es por ello que abordaremos en la tercera entrega la investigación, triaje y respuesta al incidente a través de Splunk SOAR.

Para crear una nueva alerta, nos dirijimos al menú de Splunk, Searches, reports, and alerts y pulsamos en New Alert. A continuación describiremos las diferentes secciones de configuración de una alerta.

1. Configuración específica de la alerta
   Introducimos título, descripción y la búsqueda ajustada a nuestro sistema que nos permitirá identificar la condición en la que se ha producido un acceso a la memoria LSASS. Por último configuraremos su scheduling para que se ejecute cada hora.
   
2. Condiciones de activación
   Nos permitirá invocar la acción a ejecutar en base al número de resultados y sobre el conjunto de eventos o de forma independiente para cada uno de ellos. 
3. Acciones a ejecutar en la activación
   En esta sección de la configuración de la alerta podremos parametrizar acciones como el envío de un email informativo, la ejecución de un script, la creación de un webhook que conecte con otro sistema… las posibilidades son infinitas. En nuestro caso utilizamos el trigger Send to SOAR, el cual se añadirá a las opciones disponibles automáticamente tras la instalación del AddOn que anteriormente hemos realizado y nos permitirá enviar los eventos detectados a la instancia de Splunk SOAR. Para ello seleccionaremos la instancia de Splunk SOAR y establecemos algunos parámetros como la sensibilidad y severidad. Un aspecto a tener en cuenta es la asignación de un label específico. Este label permitirá asociar los eventos enviados a Splunk SOAR con playbooks específicos, los cuales se ejecutarán de forma automática cuando se reciban eventos taggeados con el label especificado.
   
   

Una vez parametrizada la alerta, guardamos la configuración pulsamos en Save y automáticamente la alerta quedará activada:

Emulación del dumping de credenciales con Atomic Red Team

Una vez configurado todo el sistema de detección en Splunk Enterprise es la hora de validar la regla anteriormente definida. Para ello nos valemos de la instalación de la utilidad Invoke abordada en Parte I, por lo que tan solo nos quedará ejecutar los test atómicos que deseemos.

Para ejecutar los test atómicos, abrimos una consola PowerShell como Administrador en el servidor Windows y tendremos dos opciones: ejecutar todos los tests de ataques que existen para la técnica T1003.001: OS Credential Dumping: LSASS Memory de Mitre o ejecutar un test de ataque en concreto.

Nota: La ejecución de tests es recomendable realizarla con el antivirus deshabilitado, ya que en algunos casos el test puede fallar al ser reconocidas las acciones como maliciosas.

• Ejecución de todos los tests de la técnica T1003.001:

  Invoke-AtomicTest T1003.001

   

• Ejecución del test 9 de la técnica T1003.001 Create Mini Dump of LSASS.exe using ProcDump:
  El robo de credenciales de la memoria lsass.exe puede lograrse a través del Sysinternals ProcDump. Este método utiliza el parámetro –mm para crear un mini volcado de lsass.exe. Una vez lo ejecutemos, podremos consultar el fichero generado en c:\windows\temp\lsass_dump.dmp
  

  Invoke-AtomicTest T1003.001-9

  

   

Para obtener más detalles sobre los tests que componen cualquer técnica, podemos ejecutar:

Invoke-AtomicTest T1003 -ShowDetailsBrief

También podremos consultar la documentación de Atomic Red Team, donde se explican cada una de las técnicas y se detallan los tests que las acompañan.

Una vez ejecutados los test, debemos eliminar los ficheros temporales generados durante las pruebas y restablecer los cambios que se hayan realizado en el sistema. Para ello ejecutamos el parámetro -Cleanup junto con la técnica que hayamos lanzado.

Invoke-AtomicTest T1003-001 -Cleanup

Validación de resultados

Tras la ejecución de los tests atómicos, Sysmon habrá generado numerosos eventos relacionados con la actividad en el sistema, por lo que si la regla implementada es correcta, deberíamos poder ver filtrados los eventos como resultado de nuestras pruebas. Ejecutando la búsqueda asociada a la alerta que previamente hemos configurado, confirmamos que efectivamente se han detectado indicios de ejecución de herramientas para el volcado de la memoria del proceso lsass.exe.

Si la alerta se ha ejecutado automáticamente según la planificación indicada, habrá recogido los eventos detectados y los habrá enviado a Splunk SOAR. Podremos consultarlos desde la opción Events del menú principal de Splunk SOAR:

Conclusiones

En esta segunda entrega hemos abortado la implementación de una alerta en Splunk para detectar un ataque del tipo credential dumping a través de lsass, y posteriormente hemos validado la regla mediante la ejecución de tests atómicos controlados. En la siguiente y última entrega, abordaremos la recepción de los eventos capturados en Splunk SOAR y cómo a través del desarrollo de playbooks podemos automatizar el incident response al ataque detectado.

Entregas de la serie:

• Automatización de la emulación de adversarios con Atomic Red Team (ART), Sysmon y Splunk Parte I: Configuración de la arquitectura
• Automatización de la emulación de adversarios con Atomic Red Team (ART), Sysmon y Splunk Parte II: Detección con Splunk y Simulación con Atomic Red Team
• Automatización de la emulación de adversarios con Atomic Red Team (ART), Sysmon y Splunk Parte III: Incident Response