El Rincon de Jose

Foto de Manikandan Annamalai en Unsplash

Por defecto, los sistemas Linux (como Debian) registran eventos básicos del sistema, pero no auditan en detalle quién ejecuta qué comando ni qué archivos exactos se leen o modifican en tiempo real.

El agente de Wazuh por sí solo no "inventa" los eventos de Linux; los lee de los registros del sistema.
Al instalar auditd, este genera un registro ultradetallado en /var/log/audit/audit.log. El agente de Wazuh lee ese archivo en tiempo real y se lo envía al Wazuh Manager
Al instalar auditd, este genera un registro ultradetallado en /var/log/audit/audit.log. El agente de Wazuh lee ese archivo en tiempo real y se lo envía al Wazuh Manager
Ahí es donde entra auditd (el Demonio de Auditoría del kernel de Linux):

Para que Wazuh pueda decir "¡Ojo! Este comando es la técnica T1078 (Cuentas Válidas) o T1059 (Intérprete de Comandos)", necesita información rica y estructurada. auditd le proporciona exactamente los campos que las reglas de Wazuh necesitan para activar el etiquetado MITRE.

Linux por defecto registra:

- syslog

- journald

- mensajes del kernel

- logs de servicios (sshd, sudo, apache, etc.)

Pero Linux NO registra:

- ejecución de comandos (`execve`)

- lectura de ficheros sensibles (`/etc/passwd`, `/etc/shadow`)

- cambios de permisos

- cambios de propiedad

- accesos a claves SSH

- accesos a ficheros críticos

- cambios en binarios del sistema

- acciones de escalada de privilegios

- acciones de persistencia

- acciones de evasión

- acciones de descubrimiento

- acciones de credenciales

Todas esas acciones son técnicas MITRE ATT&CK.

Y Linux solo puede detectarlas si au1. Visibilidad profunda a nivel de Kernel auditd se conecta directamente al núcleo del sistema operativo. Cada vez que un usuario (o un atacante) ejecuta un comando en la terminal —como cuando tú cuando ejecutas sudo ls /root—, auditd registra los detalles exactos:
Qué comando se ejecutó (ls).
Con qué privilegios (root vía sudo).
Quién lo lanzó realmente (el usuario jose / uid=1000).
La fecha, hora y proceso asociado.ditd está instalado.

Tenemos dos tipos de alertas:

Alertas PAM (Pluggable Authentication Modules)

Son los avisos que genera el sistema de autenticación de Linux cada vez que alguien intenta entrar, inicia o cierra sesión, o cambia de usuario (por ejemplo, al hacer ssh, meter una contraseña o ejecutar sudo).
¿Para qué sirven en el SOC? Son la primera línea de defensa. Te avisan de accesos ilegítimos, intentos de fuerza bruta (múltiples fallos de contraseña) o elevaciones de privilegio no autorizadas.

Alertas MITRE (ATT&CK)

No son un tipo de log en sí, sino una etiqueta estandarizada que Wazuh le pega a una alerta para catalogar qué técnica o táctica de ataque está usando el sospechoso, basándose en el marco global de ciberseguridad MITRE ATT&CK.
¿Para qué sirven en el SOC? Dan contexto estratégico. En lugar de decirte solo "un usuario falló la clave", la etiqueta MITRE te dice "están usando la técnica T1110.001 (Adivinación de contraseñas)".
En el proyecto: Es el puente hacia OpenCTI. Gracias a que la alerta trae el código T1078 o T1110.001, Shuffle sabe qué ir a buscar a OpenCTI para traer la explicación teórica del ataque y meterla en TheHive.

"Las alertas PAM nos indican el evento técnico que ha ocurrido en el sistema Linux (ej: fallo de inicio de sesión), mientras que el mapeo MITRE ATT&CK categoriza dicho evento bajo una técnica de ataque estandarizada a nivel mundial, permitiendo activar la inteligencia de amenazas en OpenCTI."

auditd es el “SIEM interno” del kernel Linux

Es el componente que:

- intercepta llamadas al sistema

- registra acciones del usuario

- registra accesos a ficheros

- registra ejecuciones de comandos

- registra cambios en el sistema

- genera eventos de seguridad

- envía esos eventos al agente Wazuh

Sin auditd:

Linux no detecta técnicas MITRE

Wazuh no recibe eventos críticos

Shuffle no recibe MITRE

OpenCTI no puede correlacionar

TheHive no puede crear casos con MITRE

Por eso auditd es obligatorio en cualquier SOC Linux.

1. Instalar auditd en Debian 12

sudo apt update
sudo apt install auditd audispd-plugins -y

Esto instala:
el demonio auditd
el sistema de reglas
el plugin audispd para enviar eventos a Wazuh

2. Verificar que auditd está activo

sudo systemctl status auditd

Si no está activo:

sudo systemctl start auditd
sudo systemctl enable auditd

3. Verificar que ahora sí existe auditctl

sudo auditctl -l

Vemos como todavía no existen reglas en este punto.

Un SOC necesita un “manojo de reglas” para que funcione correctamente.

¿QUÉ reglas debe tener un SOC en Linux?
Un SOC serio no instala “las mínimas”.
Instala las MITRE, las de integridad, las de credenciales, las de persistencia, las de escalada, las de red, las de descubrimiento.
Aquí tienes el manojo de reglas profesional que debe tener tu SOC.

REGLAS CRÍTICAS PARA MITRE ATT&CK (SOC profesional)
Ejecución de comandos (T1059 – Command Execution)

-a always,exit -F arch=b64 -S execve -k execve
-a always,exit -F arch=b32 -S execve -k execve

Detecta:
comandos ejecutados
scripts
binarios sospechosos
escalada con sudo
persistencia con cron
malware ejecutándose

Lectura de ficheros sensibles (T1003 – Credential Dumping)

-w /etc/passwd -p r -k passwd_read
-w /etc/shadow -p r -k shadow_read
-w /etc/group -p r -k group_read

Detecta:
intentos de volcado de credenciales
herramientas como cat, strings, grep
malware que intenta leer shadow
rootkits que intentan copiar passwd

Escalada de privilegios (T1548 – Abuse Elevation Control)

-w /usr/bin/sudo -p x -k sudo_exec
-w /etc/sudoers -p wa -k sudoers_change

Detecta:
uso de sudo
cambios en sudoers
escalada de privilegios
abuso de cuentas válidas

Persistencia (T1053 – Scheduled Tasks)

-w /etc/crontab -p wa -k cron_change
-w /etc/cron.d -p wa -k cron_d_change
-w /var/spool/cron -p wa -k cron_spool_change

Detecta:
cron jobs maliciosos

persistencia con tareas programadas

malware que se autoejecuta

Modificación de binarios del sistema (T1574 – Hijack Execution Flow)

-w /bin -p wa -k bin_change
-w /usr/bin -p wa -k usr_bin_change
-w /usr/sbin -p wa -k usr_sbin_change

Detecta:
reemplazo de binarios
inyección de malware
rootkits
troyanización de comandos

Cambios en servicios (T1543 – Create or Modify System Process)

-w /etc/systemd/system -p wa -k systemd_change
-w /usr/lib/systemd/system -p wa -k systemd_lib_change

Detecta:
persistencia mediante systemd
creación de servicios maliciosos
modificación de servicios legítimos

Cambios en claves SSH (T1098 – Account Manipulation)

-w /etc/ssh/sshd_config -p wa -k ssh_config_change

Detecta:
claves SSH añadidas
claves SSH eliminadas
cambios en configuración SSH

Cambios en usuarios (T1136 – Create Account)

-w /etc/passwd -p wa -k passwd_change
-w /etc/group -p wa -k group_change
-w /etc/gshadow -p wa -k gshadow_change

¿Cómo instalar TODAS estas reglas de forma persistente?
Paso 1: Crear archivo de reglas

sudo nano /etc/audit/rules.d/soc.rules

Paso 2: Pegar todas las reglas del SOC (las de arriba) y guardar el archivo

-a always,exit -F arch=b64 -S execve -k execve
-a always,exit -F arch=b32 -S execve -k execve
-w /etc/passwd -p r -k passwd_read
-w /etc/shadow -p r -k shadow_read
-w /etc/group -p r -k group_read
-w /usr/bin/sudo -p x -k sudo_exec
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/crontab -p wa -k cron_change
-w /etc/cron.d -p wa -k cron_d_change
-w /var/spool/cron -p wa -k cron_spool_change
-w /bin -p wa -k bin_change
-w /usr/bin -p wa -k usr_bin_change
-w /usr/sbin -p wa -k usr_sbin_change
-w /etc/systemd/system -p wa -k systemd_change
-w /usr/lib/systemd/system -p wa -k systemd_lib_change
-w /etc/ssh/sshd_config -p wa -k ssh_config_change
-w /etc/passwd -p wa -k passwd_change
-w /etc/group -p wa -k group_change
-w /etc/gshadow -p wa -k gshadow_change

Paso 3: Aplicarlas

sudo augenrules --load

Paso 4: Verificar

auditctl -l

Con esto ya tenemos las reglas cargadas.

Agente → Manager → Shuffle → OpenCTI → TheHive

Interpretación de audit.log en un SOC Linux

Ejecutando este comando

sudo tail -f /var/log/audit/audit.log

El archivo /var/log/audit/audit.log contiene los eventos generados por auditd, el subsistema de auditoría del kernel Linux. Cada acción relevante del sistema se registra mediante eventos estructurados que incluyen:
EXECVE → ejecución de comandos
SYSCALL → llamadas al sistema
PATH → accesos a ficheros
CWD → directorio de trabajo
PROCTITLE → comando completo ejecutado

Estos eventos permiten detectar técnicas MITRE ATT&CK como:
T1059 (Command Execution)
T1003 (Credential Access)
T1548 (Privilege Escalation)
T1053 (Scheduled Tasks)
T1098 (Account Manipulation)
El agente Wazuh recoge estos eventos, los envía al Manager y este los correlaciona con MITRE, permitiendo que el SOC automatice respuestas mediante Shuffle y genere casos en TheHive enriquecidos con inteligencia de OpenCTI.
Un ejemplo de esa salida del comando seria:

type=CWD cwd="/home/jose"

Significa:
Directorio de trabajo actual
Desde dónde se ejecutó el comando

Cómo Wazuh convierte auditd → MITRE ATT&CK.

Un simple evento del kernel (auditd) se convierte en una técnica MITRE como:
T1059 (Command Execution)
T1110 (Brute Force)
T1548 (Privilege Escalation)
T1003 (Credential Access)
T1098 (Account Manipulation)

El flujo completo.
auditd registra un evento del kernel
El agente Wazuh lo recoge
El Manager Wazuh lo decodifica
Una regla Wazuh lo clasifica
Wazuh asigna una técnica MITRE
El evento se envía al webhook de Shuffle
Shuffle decide si hay MITRE
Shuffle consulta OpenCTI
Shuffle crea un caso en TheHive
TheHive muestra MITRE + descripción + datos del evento

¿Qué hace auditd exactamente?
Auditd captura acciones del kernel:
ejecución de comandos (execve)
lectura de ficheros sensibles
cambios en binarios
cambios en systemd
cambios en cron
cambios en sudoers
cambios en usuarios
accesos a claves SSH
accesos a /etc/shadow
accesos a /etc/passwd
Cada acción genera un bloque como los que viste:
type=EXECVE
type=SYSCALL
type=PATH
type=CWD

type=PROCTITLE
Es el nivel más bajo de auditoría posible.

¿Qué hace el agente Wazuh?
El agente:
lee audit.log
extrae los eventos
los envía al Manager
añade metadatos (IP, hostname, usuario, etc.)
El agente NO correlaciona MITRE.
Solo transporta los eventos.

¿Qué hace el Manager Wazuh?
Aquí está la magia.
El Manager:
decodifica el evento
aplica reglas
asigna MITRE
genera una alerta JSON
Ejemplo real:

"mitre": {

"id": ["T1110.001"],

"tactic": ["Credential Access"],

"technique": ["Password Guessing"]

}

¿Cómo decide Wazuh qué técnica MITRE asignar?

Wazuh tiene:
decodificadores
reglas
mapeos MITRE
Ejemplo:
Si ve execve → T1059 (Command Execution)
Si ve lectura de /etc/shadow → T1003 (Credential Dumping)
Si ve fallos de login repetidos → T1110 (Brute Force)
Si ve sudo → T1548 (Privilege Escalation)
Si ve cambios en cron → T1053 (Scheduled Tasks)
Si ve cambios en systemd → T1543 (Create or Modify System Process)
Cada regla de Wazuh tiene un bloque MITRE:

"mitre": {

"id": ["T1110.001"],

"tactic": ["Credential Access"],

"technique": ["Password Guessing"]

}

¿Dónde se ve MITRE en Wazuh?

En:

/var/ossec/logs/alerts/alerts.json

Ejemplo:

"rule": {

"id": "5501",

"description": "PAM: Sesión de inicio de sesión abierta.",

"mitre": {

"id": ["T1078"],

"tactic": ["Valid Accounts"],

"technique": ["Abuse of Valid Credentials"]

}

Ese JSON es el que viaja a Shuffle.

¿Cómo llega MITRE a Shuffle?

Si MITRE existe → [ "T1110.001" ]
Si MITRE no existe → []
Por eso las condiciones en el lienzo de Shuffle que veremos mas adelante son:
MITRE presente → Http1 + Http2
MITRE ausente → Http3

¿Cómo usa Shuffle ese MITRE?

Si MITRE existe:
Consulta OpenCTI
Recupera descripción técnica
Enriquecimiento del caso
Crea caso en TheHive con MITRE + OpenCTI + Wazuh
Si MITRE no existe:
Crea caso simple
Solo con datos Wazuh
Sin OpenCTI

¿Cómo aparece MITRE en TheHive?

Ejemplo real del SOC que ya tengo funcionando:

Técnica MITRE: ["T1110.001"]

Nombre: "Adivinación de contraseñas"

Descripción OpenCTI: "Los adversarios sin conocimiento previo…"

Toda esta “chapa” es fundamental para comprender todo lo que viene detrás.

Nada funcionaria correctamente sin seguir estos primeros pasos, que aunque parecen algo engorrosos o difíciles de aplicar, no están nada mas lejos de la realidad.

Todo el ejercicio se basa en Linux...En concreto con los eventos que me esta generando ese Debian 12, o 13, como queráis instalarlo.

Si, jajajajajaja, sobrevivo a todo esto, también veremos como implementar un agente en un sistema Windows y ver que nos ofrece en TheHive.

Y por cierto. En Windows no tenemos que instalar auditd.

Barakaldo 22 de julio de 2026.