Introducción 

Como parte de mi trabajo de graduación disidí optar por conocer un poco más de como funciona un SOAR y que mejor manera que implementando uno, en esta publicación veremos el desarrollo completo del entorno de laboratorio, el mismo abarca desde diagrama de redes, requerimientos de hardware y software y el procedimiento de instalación de todas las herramientas necesarias para evaluar el flujo de respuesta a incidentes de todos los escenarios que estaremos probando. 

Laboratorio inicial

El diseño de laboratorio se estará instalando dentro de una máquina de escritorio virtualizada utilizando Proxmox básicamente el proceso de instalación se resumen en cuatros pasos claves:

1. Descarga de archivo .iso en la web oficial de Proxmox.
2. Crear una USB booteable para instalar el sistema.
3. Seleccionar discos para instalación y configuraciones generales.
4. Acceder vía web a la interfaz para administración de los recursos.

Una vez realizados los pasos mencionados anteriormente, cuando accedemos ala interfaz web veremos un panel de administración como el mostrado a continuación:

Diagrama de red (VMs, conexiones).

El diagrama muestra el diseño de laboratorio del flujo de gestión de incidentes, usando las tecnologías SIEM y SOAR, toda la infraestructura esta virtualizada sobre Promox, quien es el encargado de administrar los recursos del hardware para el levantamiento del sistema

El diagrama está dividido en dos partes:

• Parte superior (dentro del recuadro rojo): Representa el servidor SIEM y componentes SOAR.
• Parte inferior: Representa las máquinas involucradas en la generación y detección de incidentes.

Para el flujo de incidencia:

• Wazuh: Encargado de recibir logs y eventos de seguridad desde los dispositivos, analiza esos eventos y detecta anomalías.
• Cortex (SOAR): Analiza las alertas que llegan de TheHive, automatiza respuestas o análisis mediante «analyzers» y «responders», se encarga de procesar y enriquecer la información del incidente.
• TheHive (SOAR): Plataforma de gestión de casos, recibe la información procesada desde Cortex, los analistas de seguridad pueden investigar, coordinar y documentar la respuesta al incidente.

Despliegue de maquinas necesarias

La instalación del sistema operativo es la base para el despliegue de servicios necesarios para colocar en funcionamiento el SIEM. Para realizar le proceso de instalación de Wazuh server debemos seguir los pasos a continuación:

1. Siempre actualizar con sudo dpt update y sudo apt upgrade
2. Posteriormente utilizar: curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a. Estos pasos van a permitir una instalación limpia y nos va a permitir disminuir la probabilidad de error cuando tengamos que acceder al sistema.

Si todo está correcto debemos poder acceder al SIEM de Wazuh a través de su interfaz web en nuestro caso la URL es: https://192.168.x.x/ ,en la Figura a continuación se observa la interfaz lista para agregar los primeros agentes a monitorear.

Configuración de agentes

Los agentes son esos dispositivos finales que vamos a monitorear, para agregarlos dentro del servidor de Wazuh es importante seguir los siguientes pasos:

1. Dentro del apartado Endpoints en el servidor Wazuh colocar la opción Deploy new agent.
2. Seleccionar el sistema operativo que vamos a monitorear.
3. Colocar el nombre.
4. La herramienta genera u script que debemos pegar en el agente, por ejemplo: Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.12.0-1.msi -OutFile $env:tmp\wazuh-agent; msiexec.exe /i $env:tmp\wazuh-agent /q WAZUH_MANAGER=’192.168.x.x’ WAZUH_AGENT_NAME=’Prueba’

Los pasos descritos anteriormente, se muestran en la Figura a continuación:

Una vez completamos los pasos mostrados anteriormente podemos verificar el estado del servicio de Wazuh utilizando el siguiente comando: Get-Service | Where-Object {$_.Name -like «*wazuh*»}, el objetivo es identificar que el servicio esté activo, en la Figura mas adelante se observan los resultados al ejecutar el comando.

Si el servicio está detenido se debe iniciar el servicio de forma manual utilizando: NET START y el nombre del servicio en este caso WazuhSvc.

Instalación TheHive

En casos de que se utilice el mismo entorno para TheHive y Cortex es recomendable iniciar instalando TheHive por algunas razones mencionadas a continuación:

1. TheHive es el corazón del sistema de gestión de incidentes Cortex solo cobra sentido cuando tenemos una herramienta que le solicite ejecutar análisis en este caso TheHive.
2. TheHive delega tareas a Cortex Cuando estamos investigando un caso en TheHive (por ejemplo, un IOC como un hash o dominio), podemos lanzar un análisis automático o manual usando Cortex.
3. Evitamos errores de integración si instalamos primero Cortex sin tener TheHive, podemos tener Problemas configurando los analyzers si no sabemos cómo los va a usar TheHive, adicional a presentar dificultades para probar Cortex si no tenemos desde dónde lanzar los análisis.
4. TheHive configura parte del entorno automáticamente una vez instalado, podemos usar su interfaz para: verificar si Cortex está correctamente integrado, usar observables y analizadores directamente y ver resultados gráficos de Cortex en el contexto de un caso.

Para iniciar la instalación de TheHive debemos ejecutar el siguiente comando: wget -q -O /tmp/install.sh https://archives.strangebee.com/scripts/install.sh ; sudo -v ; bash /tmp/install.sh.

Una vez ejecutado veremos una lista de componentes para instalar, básicamente es un script que se encarga de realizar la instalación con sus dependencias, las opciones se muestran en la Figura a continuación:

Es importante mencionar que se debe actualizar todos los paquetes del sistema operativo antes de realizar la instalación, una ver se termine el proceso de instalación debemos ver una imagen, donde se especifica la URL a la que debemos acceder: http://192.168.x.x:9000/login   y que la instalación ha terminado.

Cuando accedemos a la URL mencionada anteriormente debemos ver una imagen con las mostrada en la Figura a continuación, nos indica que la plataforma está lista para empezar utilizarse.

Instalación de SOAR córtex

Para la instalación de Cortex como se mencionó anteriormente cuando ambos servicios están dentro de una máquina virtual no es recomendable el uso del script, es mejor realizar la instalación manual para evitar conflictos con paquetes y dependencias. Los pasos recomendados se muestran a continuación:

1. Importar la clave GPG del proyecto TheHive utilizando el comando:
   wget -qO- https://raw.githubusercontent.com/TheHive-Project/TheHive/master/PGP-PUBLIC-KEY | sudo gpg –dearmor -o /usr/share/keyrings/thehive-project-archive-keyring.gpg
2. Agregar el repositorio del proyecto TheHive utilizando el comando:
   echo «deb [signed-by=/usr/share/keyrings/thehive-project-archive-keyring.gpg] https://deb.thehive-project.org release main» | sudo tee /etc/apt/sources.list.d/thehive-project.list
3. Actualizar las listas de paquetes e instalar Cortex utilizando los comandos:
   sudo apt update
   sudo apt install cortex
4. Configurar application.conf utilizando el comando:
   sudo nano /etc/cortex/application.conf
5. Una vez ingresamos al directorio /etc/cortex/application.conf debemos como mínimo configurar los parámetros mostrados en la a continuación:

El archivo application.conf de Cortex define parámetros esenciales para su funcionamiento. La clave play.http.secret.key asegura funciones criptográficas internas del sistema, como el manejo de sesiones. La sección search configura la conexión con Elasticsearch, especificando la dirección local y el nombre del índice donde Cortex almacenará sus datos. La línea auth.provider = [local] indica que los usuarios serán autenticados localmente desde la propia base de datos. Por último, las directivas analyzer.urls y responder.urls indican tanto rutas locales como en línea desde donde Cortex puede cargar los analizadores y respondedores que permiten el análisis automático y respuesta ante incidentes.

Cuando ya se han configurado los parámetros en el archivo de configuración podríamos verificar estado del servicio y si no está activo entonces habilitarlo con los siguientes comandos:

Adicionalmente, se pueden verificar los logs usando el comando sudo journalctl -u cortex -f

Cuando nos aseguramos de que no hay problemas en la instalación podemos ingresar a la URL en nuestro caso: http://192.168.x.x:9001/, posteriormente que ingresamos el sistema va a solicitar que ingresemos un usuario y una clave con perfil de administrador, en la Figura a continuación podemos ver la interfaz de Cortex como administrador.

La herramienta cortex utilizando un perfil de administrador por defecto, no nos permite hacer uso de todas sus capacidades por lo que debemos crear un nuevo usuario con perfil de administrador de organización para hacer uso de los respondedores y analizadores, en la Figura a continuación se observa la interfaz de inicio de sesión de cortex utilizando un usuario que llamamos test, con permisos de administrador de organización, podemos observar en la parte superior que se agregan las funciones de Analyzer y Responders.

Configuración de Analizadores en Cortex

Los analizadores nos permiten verificar ciertos parámetros como dominios, ip, hash etc. Para el entorno de pruebas utilizado hemos decidido utilizar AbuseIPDB y virustotal.

AbuseIPDB es un proyecto dedicado a ayudar a combatir la propagación de hackers, spammers y actividad abusiva en Internet. Su misión es hacer que Internet sea un lugar más seguro proporcionando una lista negra centralizada para que los administradores web, administradores de sistemas y otros interesados informen y encuentren direcciones IP que se han asociado con actividad maliciosa en línea. Por otra parte, VirusTotal es una herramienta en línea gratuita que permite a los usuarios verificar la seguridad de archivos, páginas web, dominios, direcciones IP y funciones hash sospechosas, la plataforma integra más de 50 motores antivirus y más de 60 motores de detección, así como plataformas de sandbox online que ejecutan archivos y aplicaciones en máquinas virtuales especializadas en ciberseguridad.

Antes de iniciar a configurar cualquier analizador es importante tener en cuenta los parámetros de configuración que se solicitan, por ejemplo, en las Figuras que mostramos a continuación se detallan los parámetros obligatorios marcados con asterisco que solicita la plataforma AbuseIPDB en este caso solicita una llave que es utilizada para la conexión e intercambio de información entre la plataforma y cortex, adicionalmente se vemos la llave desde virus total.

Conexión de Cortex y TheHive

Para realizar la conexión de TheHive a Cortex es necesario direccionarse al apartado gestión de plataformas con el usuario de administrador, posteriormente en la sección de conectores veremos al final una sección llamada servidor, podremos gestionarla configuración básica que nos solicita una clave API para la gestión de la configuración, los destalles descritos se muestran en la Figura a continuación.

Desde Cortex en la sección usuario en el perfil de administrador de organización se muestra la sección de API Key.

Para confirmar que Cortex fue integrado de forma correcta deberíamos ver en TheHive una sección que indica la versión de Cortex y un estado OK, se muestra en la Figura a continuación:

Enviando alertas desde Wazuh manager a TheHive

Para integrar Wazuh con TheHive, clonamos el repositorio wazuh-thehive-integration-ep13 desde GitHub, que contiene un script personalizado (send_to_thehive.py) que permite enviar alertas automáticamente desde el Wazuh Manager al API de TheHive, a continuación, se detallan los pasos

1. Abrimos una terminal en el servidor Ubuntu y ejecutamos:
   
   cd /tmp git clone https://github.com/ls111-cybersec/wazuh-thehive-integration-ep13.git

   1 2	cd /tmp git clone https://github.com/ls111-cybersec/wazuh-thehive-integration-ep13.git

2. Luego copiamos los archivos a la carpeta de integraciones de Wazuh:
   
   sudo cp wazuh-thehive-integration-ep13/custom-w2thive* /var/ossec/integrations/

   1	sudo cp wazuh-thehive-integration-ep13/custom-w2thive* /var/ossec/integrations/

3. Aplicamos los permisos correctos:
   
   sudo chmod 755 /var/ossec/integrations/custom-w2thive.py sudo chmod 755 /var/ossec/integrations/custom-w2thive sudo chown root:ossec /var/ossec/integrations/custom-w2thive.py sudo chown root:ossec /var/ossec/integrations/custom-w2thive

   1 2 3 4

   sudo chmod 755 /var/ossec/integrations/custom-w2thive.py sudo chmod 755 /var/ossec/integrations/custom-w2thive sudo chown root:ossec /var/ossec/integrations/custom-w2thive.py sudo chown root:ossec /var/ossec/integrations/custom-w2thive

   Los comandos mencionados anteriormente, permiten ortogar permisos de ejecución y lectura al archivo, ya sea por el usuario root o el grupo ossec. Esto es importante porque Wazuh se ejecuta con el grupo ossec, y necesita poder acceder y ejecutar ese archivo. Una vez asignados los permisos veremos los scripts en color verde como la Figura a continuación.

Para permitir que WAZUH ejecute el script de integración, debemos agregar las siguientes líneas mostradas en la Figura , que corresponde al archivo de configuración del administrador ubicado en /var/ossec/etc/ossec.conf.

Se inserta la dirección IP para el servidor TheHive junto con la clave API.

Es importante resaltar que para que se muestre el panel de alertas es necesario crear un usuario de administración de organización e iniciar sesión. Se debe crear usuario con permisos de administrador de organización e iniciar sesión con el mismo, para la conexión entre TheHive y Wazuh se tomó en cuenta un usuario adicional con perfil de analista.

Si la integración fue exitosa podremos observar las primeras alertas que llegan a la interfaz de TheHive, se muestra en la Figura a continuación.

Disminución de alertas

Para mantener una efectividad en cuanto al procesamiento de alarmas que llegan a TheHive es importante parametrizar las alertas provenientes de Wazuh, en el script utilizado para él envió de alertas, pero existe una variable lvl_threshold en el script que indica el nivel de alerta mínimo que se enviará a la casa. La variable se puede personalizar para que solo se envíen alertas relevantes en la Figura se muestra la configuración que se utilizó.

Las alertas de Wazuh tienen un nivel que va de 0 a 15:

0–2: información muy básica o ruido
3–6: advertencias moderadas
7–9: actividad sospechosa
10–15: ataques confirmados o críticos

En nuestro caso escogimos un nivel 7, a partir de ese nivel Wazuh marca las alertas como actividad sospechosa o significativa, como:

1. Creación/eliminación de cuentas de usuario.
2. Cambios en grupos de privilegios (como sudo o Administradores).
3. Modificaciones en archivos críticos de configuración (passwd, sudoers, etc.).
4. Cambios en políticas del sistema.
5. Actividades de escalamiento de privilegios.
6. Eventos que podrían estar relacionados con ataques internos o mal uso administrativo.

Resultados

Los resultados de las pruebas realizadas fueron exitosos, se tomó en cuenta un escenario en particular en donde se crean usuarios desde el endpoint con privilegios de administrador, básicamente este tipo de comportamiento en un endpoint puede resultar sospechoso porque no es común dentro de una red en producción.

Desde Kali usando xfreerdp /u:NombreDeUsuario /p:Contraseña /v:IP_del_equipo_Windows, logramos conectarnos al agente Windows y crear un usuario para simular un comportamiento malicioso. En la Figura se observa desde el endpoint la creación de un usuario con privilegios de administrador.

Posteriormente, en la Figura, se observa el flujo de alertas que llegan a TheHive una vez se realizó la simulación de creación de usuarios con privilegios de administrador

Capturas de casos en TheHive

Cuando se reciben alertas en TheHive tenemos la oportunidad de realizar análisis detallados en nuestro caso realizamos los estudios de las alarmas basados en los analizadores mencionados en la Figura se muestra el primer resultado del escaneo realizado por la integración con AbuseIPDB y VirusTotal.

Los resultados muestran que no se observó que la dirección IP asociada en el análisis 192.168.137.199, este relacionada con actividad maliciosa reportada en la plataforma, sin embargo, si este usuario hubiese sido creado a través de una conexión con servidor de comando control, probablemente los resultados fueran diferentes. Por otra parte, se realizó el análisis a través de la integración con VirusTotal los resultados de igual forma mostraron que no hay indicios de IP reportada como maliciosa en los motores de búsqueda que utiliza la plataforma.

Análisis y conclusiones

Las pruebas realizadas  en este caso creación de usuarios con privilegios de administrador cumplieron con el flujo de incidente esperado, adicional a los resultados que mostraron los analizadores; sin embargo, se deben probar otros tipos de posibles comportamientos maliciosos, uso de herramientas como mimikatz, instalación de aplicaciones, escaneos realizados a los endpoint, todo lo referente a las técnicas, taticas y procedimientos que nos brindan algunas bases de datos como MITRE ATT&CK, esto brindaría a la estructura de respuesta incidentes un flujo de alertas parametrizado de forma eficiente, evitando así falsos positivos en el reporte o análisis de casos.

La integración de Wazuh, TheHive y Cortex permite crear un entorno capaz de detectar amenazas en tiempo real, escalar incidentes a través de flujos automatizados y enriquecer observables mediante módulos analíticos. Wazuh demostró capacidades robustas como agente de monitoreo, recopilación de eventos, correlación y generación de alertas sobre múltiples plataformas. TheHive, por su parte, se consolidó como una plataforma efectiva para la gestión colaborativa de incidentes, permitiendo la clasificación, asignación y documentación de cada caso. Cortex fortaleció este ecosistema al ejecutar automáticamente analizadores sobre direcciones IP que fue el caso aplicado, reduciendo la carga de trabajo.