SOAR

SOAR (Orquestación, Automatización y Respuesta de Seguridad) es un conjunto de funciones que se utilizan para proteger los sistemas de TI de las amenazas. Este software permite a los equipos de seguridad integrar y coordinar herramientas individuales en flujos de trabajo de respuesta a amenazas. Se utiliza principalmente para acelerar, simplificar y escalar los esfuerzos de seguridad, fortaleciendo la capacidad para proteger el entorno y responder a las amenazas de seguridad. Imaginemos que se trata de un director de orquesta para la seguridad de los sistemas informáticos. Tenemos montón de músicos (herramientas de seguridad) cada uno tocando su instrumento (protegiendo el sistema), pero sin coordinación entre ellos. Aquí es donde entra el SOAR, que actúa como el director, asegurándose de que todos los músicos toquen al unísono para crear una melodía armoniosa (un sistema seguro). En resumen, el SOAR ayuda a que todas las herramientas de seguridad trabajen juntas de manera eficiente para proteger los sistemas de las amenazas cibernéticas.

En esta última entrega abordaremos configuración del Splunk SOAR de nuestro laboratorio y la implementación de un playbook. En los playbooks se definen los pasos que se deben seguir para detectar, investigar y responder a incidentes de seguridad de forma eficiente y sistemática. Siguiendo con las comparaciones, podríamos decir que se trata de una receta que detalla qué herramientas usar, en qué órden y cómo para resolver un problema específico. 

Instalación de Apps

En la implementación del playbook que se ejecutará en Splunk SOAR haremos uso de las aplicaciones que se muestran a continuación:

• Splunk: Posibilitará la conexión a la instancia de Splunk Enterprise y ejecutar comandos SPL. En nuestro caso de uso lo utilizaremos para enriquecer con más información los datos del evento recibido.
• Windows Remote Management: Permitirá ejecutar comandos a través de la administración remota WinRM en la instancia de Windows Server utilizando el protocolo WS-Management.

 A través de las acciones que incluyen modelaremos el playbook, permitiendo integrarnos con otros sistemas y aplicar lógicas predefinidas.

Configuración de assets

A medida que se agregan nuevas aplicaciones, se espera que defina un asset en el que la aplicación pueda ejecutar una acción. Las aplicaciones están desarrolladas para un producto específico y cada acción de una aplicación puede indicar una expresión regular para una versión del producto en concreto que admite. Los assets también especifican el producto y la versión del activo.

En este ejemplo realizaremos la configuración del asset para la aplicación Windows Remote Management a modo de ejemplo, siendo el procedimiento similar para el resto de assets.

Información genérica del asset

En la primera pestaña de la configuración del asset introducimos información genérica que nos ayude a identificarlo posteriormente:

Configuración particular del asset

En la pestaña de configuración del aset introducimos la información característica del asset para la aplicación.

Antes de comenzar, necesitaremos tener activo WindowsRM en nuestro servidor Windows. Normalmente ya se encuentra activo por defecto, sin embargo, si no fuese así podríamos activarlo ejecutando el siguiente comando en Powershell:

winrm quickconfig

Para consultar la configuración actual de WindowsRM ejecutamos:

winrm get winrm/config

Donde podremos ver los parámetros que a continuación utilizaremos en la configuración del asset:

Para ello introducimos la IP del servidor Windows, el protocolo por defecto lo dejamos en http, al igual que el puerto 5985 e introducimos nuestros credenciales de acceso utilizando el tipo de autenticación NTLM.

Validación de la conectividad

Tras finalizar la configuración del asset la guardamos y validamos la conexión:

Implementación del playbook

En esta sección describiremos el desarrollo y la lógica aplicada para dar respuesta al incidente basado en el dumping de credenciaes a través del sistema operativo. Las pruebas de validación permitirán que los equipos de seguridad tengan un papel más estratégico en la respuesta a incidentes, teniendo la tranquilidad y seguridad de que el automatismo para mitigar o recuperarse del incidente funcionará en un escenario real.

A continuación describiremos las diferentes fases del playbook:

Enriquecimiento

En esta primera fase obtendremos información adicional para complementar los datos de la alerta original. En primer lugar realizaremos una consulta al servidor Splunk Enterprise ya que únicamente se ha reportado el sourceHostName para identificar la máquina y necesitaríamos obtener la dirección IP para posteriormente actuar directamente sobre el servidor.

A continuación y de forma paralela ejecutaremos a través de WinRM los comandos necesarios para:

• Obtener el detalle de las conexiones abiertas. Permitirá identificar si existen conexiones sospechosas e inusuales en el servidor afectado.
  
  
  
  
• Identificar si el usuario reportado sigue autenticado. En este paso es importante señalar que para la prueba de laboratorio se utiliza un usuario local, sin embargo en un escenario real el usuario normalmente no se trataría de forma local y podríamos encontrar integraciones con soluciones como Active Directory, Okta o CyberArk.
  
  
  
  
• Creación de prompt interativo. Por último, una vez realizado el enriquecimiento de la alerta a través de diferentes fuentes de datos, crearemos un prompt mediante el cual mostraremos toda la información recolectada al operador de seguridad y que le permitirá decidir si continuar o no con el resto de la ejecución del playbook, consistente en la contención del incidente.
  
  
  

Contención

Una vez se ha confirmado a través del enriquecimiento que existe alguna conexión sospechosa en la máquina y que el usuario reportado tiene sesión en el servidor Windows, la detección del credential dumping parece legítima. En esta fase activaremos la respuesta al incidente deshabilitando el usuario reportado para posteriormente forzar el cierre de la sesión iniciada en la maquina remota. Mediante estas acciones automáticas evitaremos que el actor malicioso logre establecer la persistencia o pase a una etapa posterior en su ataque como un movimiento lateral.
En esta fase, realizaremos iniciaremos de forma secuencial las siguientes acciones:

• Deshabilitar el usuario afectado. Se procederá a conectar con el servidor remoto Windows y se deshabilitará el usuario reportado. Esto no impedirá que si tiene una sesión activa, pueda seguir operando.
  
  

• Obtención del Session ID del usuario. Obtenemos el identificador de la sesión existente del usuario en el servidor Windows para posteriormente poder actuar sobre ésta.
  
  

• Logout del usuario. A través del identificador de la sesión y de la acción predefinida logoff user lograremos forzar el cierre de la sesión del usuario, impidiendo al atacante poder continuar.
  
  

Configuración final y activación del playbook

Una vez implementada la lógica del playbook, estableceremos la configuración que permitirá que éste ejecute de forma automática.
Para ello deberemos prestar especial atención al label asignado en el campo Operates on, el cual deberá ser idéntico al que establecimos en la configuración de la alerta que definimos en Splunk Enterprise del anterior artículo, ya que nos permitirá asociar playbooks y por lo tanto realizar el triggering de éstos.

Por último, accederemos a la opción principal Playbooks > Internal Repositories y activaremos el playbook creado:

Ejecución y validación de todo el flujo de emulación completo

Aunque durante la implementación del playbook podemos validar su funcionamiento mediante el Playbook Debugger en este último paso validaremos el flujo completo. Para ello, basándonos ya en todos los pasos cubiertos a lo largo de estos tres artículos realizaremos lo siguiente:

1. Ejecución de test automático con Atomic Red Team. Con la utilidad Invoke ejecutaremos el test T1003.001, el cual efectuará diferentes acciones en el servidor Windows simulando el volcado de credenciales desde la memoria del proceso LSASS.
2. Recolección de logs de Sysmon. A través del Universal Forwarder recogeremos todos los logs generados por Sysmon y serán enviados de forma automática a Splunk Enterprise.
3. Detección mediante alerta en Splunk Enterprise. A través de una búsqueda específica lograremos identificar entre todos los logs generados por Sysmon evidencias de un volcado de memoria en el servidor Windows.
4. Ejecución de Playbook. Una vez se ejecute la alerta en Splunk Enterprise, se iniciará el triggering del playbook asociado en Splunk SOAR, ejecutando todas las acciones programadas en éste, entre las cuales se encuentran la deshabilitación del usuario y cierre de sesión de éste.

Conclusiones

En esta serie de artículos hemos implementado un laboratorio completo el cual nos permitirá automatizar la emulación de adversarios. Con este laboratorio podremos implementar casos de uso a partir de pruebas atómicas y sencillas de replicar y evaluar de forma recurrente diferentes tácticas y técnicas que se utilizan en ataques de seguridad permitiéndonos además, optimizar y afinar la detección y mitigación mediante alertas y automatizaciones.

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