AI-Powered
Threat Detection

Objetivos de la semana

Hasta ahora hemos trabajado conceptos fundamentales de ciberseguridad y análisis de amenazas. En esta semana damos un salto importante: vamos a construir mentalmente y técnicamente un sistema capaz de observar una infraestructura, detectar comportamientos sospechosos y generar información accionable para un analista.

¿Qué es realmente un SOC?

Un SOC no es simplemente un dashboard lleno de alertas. Es un sistema operativo de seguridad compuesto por personas, procesos, tecnología, datos y procedimientos de respuesta.

La visión simplista

Logs
  ↓
SIEM
  ↓
Alertas
  ↓
Analista

Esta arquitectura es incompleta. Un SOC moderno necesita mucho más contexto.

Arquitectura moderna

                     ┌──────────────────────┐
                     │      ENDPOINTS       │
                     │ Linux / Windows / VM │
                     └──────────┬───────────┘
                                │
                                ▼
                     ┌──────────────────────┐
                     │      TELEMETRY       │
                     │ Logs / Events / FIM   │
                     └──────────┬───────────┘
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                 │
              ▼                 ▼                 ▼
           WAZUH              ZEEK            SURICATA
          Endpoint             NSM               IDS
              │                 │                 │
              └─────────────────┼─────────────────┘
                                ▼
                       ┌────────────────┐
                       │      SIEM      │
                       └───────┬────────┘
                               │
                    ┌──────────┴──────────┐
                    ▼                     ▼
                 RULES                   ML
                    │                     │
                    └──────────┬──────────┘
                               ▼
                         CORRELATION
                               │
                               ▼
                         RISK SCORE
                               │
                               ▼
                         AI ASSISTANT
                               │
                               ▼
                          ANALYST
                               │
                               ▼
                            SOAR
                               │
                               ▼
                           RESPONSE

SIEM, SOAR, XDR y UEBA

La materia prima de la detección

Un sistema de seguridad solamente puede detectar aquello que tiene suficiente información para observar. Por eso la arquitectura de telemetría es una de las decisiones más importantes de un SOC.

Fuentes principales

Ejemplo: un login

Supongamos que aparece este evento:

2026-08-29 03:14:21
user=admin
source_ip=185.42.10.21
action=login
result=success

¿Es malicioso? No podemos saberlo todavía.

Necesitamos contexto:

• ¿Dónde estaba el usuario?
• ¿Es habitual que utilice esa IP?
• ¿Es habitual que acceda a esa hora?
• ¿Qué dispositivo utilizó?
• ¿Hubo MFA?
• ¿Qué hizo después del login?
• ¿La IP tiene reputación negativa?
• ¿Hubo otros usuarios comprometidos?

Esto introduce uno de los conceptos más importantes del SOC:

Construyendo el núcleo SIEM/XDR

Wazuh será una de las piezas principales de nuestro laboratorio. Es una plataforma open source que combina capacidades SIEM y XDR, utilizando agentes y componentes centrales para recopilar, analizar, indexar y visualizar eventos.

La arquitectura central actual está compuesta por:

Endpoint
   │
   ▼
Wazuh Agent
   │
   ▼
Wazuh Server
   │
   ▼
Wazuh Indexer
   │
   ▼
Wazuh Dashboard

El servidor analiza eventos mediante decoders y rules, mientras que el indexador almacena la información para posteriores búsquedas y visualización. :contentReference[oaicite:1]{index=1}

¿Qué recopila el agente?

• Logs de sistema
• Eventos de aplicaciones
• File Integrity Monitoring
• Inventario
• Configuración
• Vulnerabilidades
• Eventos de seguridad

La arquitectura modular del agente permite configurar diferentes fuentes de datos y capacidades de monitorización. :contentReference[oaicite:2]{index=2}

Instalación para el laboratorio

Para el laboratorio puedes utilizar una VM Linux dedicada. Una instalación all-in-one es especialmente apropiada para entornos de laboratorio y pequeñas instalaciones. :contentReference[oaicite:3]{index=3}

# Comprobar sistema
uname -a

# Comprobar memoria
free -h

# Comprobar almacenamiento
df -h

# Comprobar CPU
nproc

La documentación oficial de Wazuh proporciona un asistente de instalación para desplegar los componentes centrales.

# Ejemplo conceptual

curl -sO <WAZUH_INSTALLER>

sudo bash <WAZUH_INSTALLER>

Puertos que debes conocer

Estos son puertos habituales de la arquitectura y pueden modificarse según la configuración. :contentReference[oaicite:4]{index=4}

Ejercicio rápido

Zeek: observar la red

Zeek es un analizador pasivo de tráfico de red utilizado ampliamente para Network Security Monitoring. Una de sus grandes ventajas es que convierte tráfico observado en logs estructurados que pueden ser utilizados por sistemas de análisis externos.

Entre sus registros podemos encontrar información relacionada con conexiones, DNS, HTTP, TLS y otros protocolos. :contentReference[oaicite:5]{index=5}

Modelo mental

Network Traffic
       │
       ▼
     Zeek
       │
       ├── conn.log
       ├── dns.log
       ├── http.log
       ├── ssl.log
       └── files.log
             │
             ▼
            SIEM

Ejemplo de conn.log

ts
uid
id.orig_h
id.orig_p
id.resp_h
id.resp_p
proto
service
duration
orig_bytes
resp_bytes

Imagina que un servidor interno comienza a generar:

10.10.20.15 → 185.10.20.30:443
10.10.20.15 → 185.10.20.31:443
10.10.20.15 → 185.10.20.32:443
...
10.10.20.15 → 185.10.20.99:443

Una conexión HTTPS no es necesariamente sospechosa. Pero el patrón puede serlo.

Suricata: detección basada en firmas y eventos

Suricata complementa a Zeek aportando capacidades IDS/IPS y generación de eventos estructurados.

Arquitectura conceptual

Traffic
   │
   ▼
Suricata
   │
   ├── Alerts
   ├── DNS
   ├── HTTP
   ├── TLS
   ├── Flow
   └── Anomalies
          │
          ▼
       eve.json
          │
          ▼
         SIEM

EVE permite generar eventos en JSON y puede incluir alertas, flujos, metadatos y eventos específicos de protocolo. :contentReference[oaicite:6]{index=6}

Ejemplo

{
  "event_type": "alert",
  "src_ip": "10.10.10.20",
  "dest_ip": "203.0.113.50",
  "src_port": 49120,
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "severity": 2,
    "signature": "Suspicious HTTP Activity"
  }
}

¿Zeek o Suricata?

En una arquitectura madura no necesariamente tenemos que elegir uno u otro. Podemos utilizar ambos.

Diseñar detecciones

Detection Engineering consiste en convertir conocimiento sobre amenazas en detecciones que puedan ejecutarse automáticamente sobre la telemetría disponible.

IOC vs IOA

Ejemplo: brute force SSH

Supongamos que vemos:

Failed password for admin
Failed password for admin
Failed password for admin
Failed password for admin
Failed password for admin
Failed password for admin

Successful login for admin

Una regla simple podría detectar:

IF

failed_logins >= 5

AND

successful_login == true

WITHIN

5 minutes

THEN

raise_high_severity_alert()

Pero hay un problema

¿Qué ocurre si un administrador se equivoca cinco veces?

Tendremos un falso positivo.

Por eso necesitamos contexto:

Risk =
    FailedAttempts
  + NewSourceIP
  + NewCountry
  + UnusualHour
  + PrivilegedAccount
  + ThreatIntel
  + PostLoginActivity

Detection as Code

Una detección madura debería poder versionarse.

detections/
│
├── ssh/
│   ├── brute_force.yml
│   └── unusual_login.yml
│
├── windows/
│   ├── powershell.yml
│   └── privilege_escalation.yml
│
└── network/
    ├── dns_tunneling.yml
    └── port_scan.yml

Esto permite utilizar Git, revisión por pares, testing y CI/CD también en Detection Engineering.

De las reglas a las anomalías

Las reglas son excelentes cuando conocemos el patrón. El Machine Learning resulta especialmente interesante cuando queremos encontrar comportamientos que no hemos descrito explícitamente.

Regla tradicional

IF failed_logins > 10
THEN alert

Detección estadística

IF login_count > normal_baseline + threshold
THEN suspicious

Machine Learning

Learn normal behavior
        ↓
Model behavior
        ↓
Detect deviations
        ↓
Generate anomaly score

Ejemplo de features

Isolation Forest

Isolation Forest es especialmente útil como algoritmo introductorio para anomaly detection. La idea fundamental es que los outliers suelen poder aislarse mediante menos particiones que los puntos normales. :contentReference[oaicite:7]{index=7}

Instalación

python3 -m venv venv

source venv/bin/activate

pip install numpy pandas scikit-learn matplotlib

Ejemplo práctico

import pandas as pd

from sklearn.ensemble import IsolationForest


df = pd.DataFrame({
    "login_count": [
        4, 5, 3, 6, 5,
        4, 5, 7, 6, 4,
        80
    ],

    "bytes_out": [
        1000, 1200, 900, 1100, 1300,
        1000, 950, 1250, 1000, 1150,
        950000
    ]
})


features = [
    "login_count",
    "bytes_out"
]


model = IsolationForest(
    contamination=0.05,
    random_state=42
)


model.fit(df[features])


df["prediction"] = model.predict(
    df[features]
)


df["anomaly_score"] = model.decision_function(
    df[features]
)


print(df)

Interpretación

Una salida aproximada podría mostrar:

login_count   bytes_out   prediction

4             1000        1
5             1200        1
3             900         1
6             1100        1
80            950000     -1

El valor -1 indica una observación clasificada como outlier por el modelo.

Behavior Analytics

Una de las aplicaciones más interesantes de Machine Learning en ciberseguridad consiste en construir perfiles de comportamiento para usuarios y entidades.

Ejemplo

Tenemos un usuario:

Carlos

Normal:

08:00–18:00
Madrid
Laptop corporativo
VPN
20–50 operaciones/hora

Un día aparece:

03:17
New country
New device
New IP
850 file downloads
Multiple privilege changes

Ningún evento individual tiene por qué ser crítico. Pero juntos constituyen un patrón de alto riesgo.

Entity Risk Score

Risk Score =

    Authentication Risk
  + Device Risk
  + Network Risk
  + Behavior Risk
  + Threat Intelligence
  + Privilege Risk

El resultado podría ser:

USER: Carlos

Risk Score: 91/100

Authentication      20
Device              15
Network             18
Behavior            25
Privilege             8
Threat Intel          5

De eventos aislados a incidentes

La correlación es el mecanismo que transforma señales individuales en una historia de ataque.

Ejemplo completo

Sin correlación

Alert 1
Alert 2
Alert 3
Alert 4
Alert 5

Con correlación

Possible Account Compromise
        │
        ├── Unusual Login
        ├── Privilege Escalation
        ├── PowerShell
        ├── External Connection
        └── Data Transfer
                │
                ▼
        HIGH CONFIDENCE INCIDENT

Enrichment

Una alerta sin contexto puede obligar al analista a realizar muchas búsquedas manuales.

Podemos enriquecer automáticamente:

IP
 │
 ├── Reputation
 ├── ASN
 ├── Country
 ├── Organization
 ├── Known Abuse
 └── Threat Intelligence

Ejemplo

Original Event:

src_ip=203.0.113.25


Enriched:

country=Unknown
asn=64500
reputation=suspicious
known_campaign=true
confidence=0.87

Ahora el analista tiene más contexto para decidir.

Introduciendo la Inteligencia Artificial

Ahora llegamos al elemento diferencial del proyecto: utilizar IA no para sustituir los sistemas de seguridad, sino para ayudar al analista a interpretar grandes cantidades de información.

Arquitectura

                    SECURITY EVENTS
                          │
                          ▼
                     SIEM / XDR
                          │
                          ▼
                    CORRELATION
                          │
                          ▼
                    INCIDENT DATA
                          │
                          ▼
                    AI SECURITY
                      AGENT
                          │
            ┌─────────────┼─────────────┐
            │             │             │
            ▼             ▼             ▼
        Summarize      Investigate    Recommend
            │             │             │
            └─────────────┼─────────────┘
                          ▼
                       ANALYST

Ejemplo de prompt de investigación

You are a Tier-2 SOC analyst.

Investigate the following incident.

User:
admin

Events:
- successful login from unknown IP
- privilege escalation
- PowerShell execution
- unusual outbound traffic
- anomaly score: 0.92

Tasks:

1. Build a timeline.
2. Identify suspicious behavior.
3. Identify possible attack stages.
4. List missing evidence.
5. Recommend investigation steps.
6. Do not assume maliciousness without evidence.

Respuesta esperada

Assessment:

The event sequence is consistent with
possible account compromise.

Evidence:

1. Unusual authentication source.
2. Privileged activity shortly after login.
3. PowerShell execution.
4. Abnormal outbound traffic.

Confidence:
MEDIUM-HIGH

Missing evidence:

- MFA result
- Process tree
- Destination reputation
- Command line
- Endpoint timeline
- DNS activity

Recommended next steps:

1. Validate the login.
2. Inspect process tree.
3. Investigate destination IP.
4. Review authentication history.
5. Check for lateral movement.

La IA no decide sola

El conocimiento del SOC

Un LLM genérico no conoce necesariamente las reglas, procedimientos, arquitectura y documentación interna de nuestra organización.

Por eso introduciremos RAG:

Documents
   │
   ▼
Chunking
   │
   ▼
Embeddings
   │
   ▼
Vector Database
   │
   ▼
Retriever
   │
   ▼
LLM
   │
   ▼
Grounded Answer

Fuentes posibles

• Procedimientos SOC
• Runbooks
• Playbooks
• Arquitectura de red
• Inventario
• Políticas de seguridad
• Threat Intelligence
• Documentación de herramientas
• Histórico de incidentes

Ejemplo

El analista pregunta:

"¿Qué procedimiento debemos seguir
cuando detectamos una posible cuenta comprometida?"

El sistema RAG recupera:

RUNBOOK-ACCOUNT-COMPROMISE
POLICY-IDENTITY-07
PLAYBOOK-INCIDENT-04

La IA responde basándose en esos documentos.

Laboratorio: construir un mini SOC

Este es el laboratorio principal de la semana. El objetivo no es instalar herramientas por instalar. Queremos construir un flujo completo.

Arquitectura del laboratorio

                ┌──────────────┐
                │ Linux Server │
                └──────┬───────┘
                       │
                       ▼
                 Wazuh Agent
                       │
                       ▼
                ┌──────────────┐
                │    Wazuh     │
                │    Server    │
                └──────┬───────┘
                       │
                       ▼
                ┌──────────────┐
                │   Indexer    │
                └──────┬───────┘
                       │
                       ▼
                ┌──────────────┐
                │  Dashboard   │
                └──────────────┘


       Network Traffic
              │
       ┌──────┴──────┐
       ▼             ▼
     Zeek         Suricata
       │             │
       └──────┬──────┘
              ▼
             SIEM

Fase 1 · Preparar laboratorio

mkdir ai-soc-lab

cd ai-soc-lab

mkdir logs
mkdir scripts
mkdir detections
mkdir models
mkdir reports

Fase 2 · Crear eventos sintéticos

Antes de atacar un entorno real vamos a utilizar datos controlados.

timestamp,user,src_ip,event,success
03:10:00,admin,10.0.0.10,login,false
03:10:04,admin,10.0.0.10,login,false
03:10:07,admin,10.0.0.10,login,false
03:10:12,admin,10.0.0.10,login,false
03:10:20,admin,10.0.0.10,login,true
03:11:02,admin,10.0.0.10,privilege_change,true
03:11:20,admin,10.0.0.10,powershell,true
03:12:10,admin,10.0.0.10,network_connection,true

Fase 3 · Detectar brute force

import pandas as pd

df = pd.read_csv("logs/auth.csv")

failed = df[
    (df["event"] == "login") &
    (df["success"] == False)
]

counts = (
    failed
    .groupby("user")
    .size()
    .reset_index(name="failed_attempts")
)

print(counts)

Fase 4 · Generar score

def calculate_risk(
    failed_logins,
    privilege_change,
    powershell,
    unusual_network
):

    score = 0

    score += min(
        failed_logins * 5,
        30
    )

    if privilege_change:
        score += 20

    if powershell:
        score += 20

    if unusual_network:
        score += 20

    return min(score, 100)

Fase 5 · Clasificación

score = calculate_risk(
    failed_logins=5,
    privilege_change=True,
    powershell=True,
    unusual_network=True
)

print(score)

El resultado esperado será:

90

Y podremos establecer:

Fase 6 · Machine Learning

Ahora eliminaremos parte de las reglas y utilizaremos Isolation Forest sobre características de comportamiento.

features = [
    "failed_logins",
    "unique_destinations",
    "bytes_out",
    "dns_requests",
    "process_count"
]

model.fit(data[features])

data["prediction"] = model.predict(
    data[features]
)

Fase 7 · Correlación

IF

authentication_anomaly
AND
privilege_change
AND
process_anomaly

THEN

create_incident()

Fase 8 · Enrichment

incident = {

    "user": "admin",

    "risk_score": 92,

    "signals": [
        "unusual_login",
        "privilege_change",
        "powershell",
        "network_anomaly"
    ],

    "evidence": [
        "auth.log",
        "process.log",
        "network.log"
    ]
}

Fase 9 · AI Investigation

incident
   │
   ▼
Normalize
   │
   ▼
Enrich
   │
   ▼
Build context
   │
   ▼
LLM
   │
   ▼
Investigation report

Resultado final

INCIDENT #2026-00051

Title:
Possible Privileged Account Compromise

Risk:
92 / 100

Severity:
CRITICAL

Signals:

[+] Multiple failed logins
[+] Successful login
[+] Privilege change
[+] PowerShell execution
[+] Network anomaly

AI Assessment:

Possible account compromise.

Confidence:
0.89

Recommended actions:

1. Validate authentication.
2. Inspect endpoint process tree.
3. Investigate network destination.
4. Check lateral movement.
5. Review account activity.

Ejercicios prácticos

1 IP
   ↓
Many users
   ↓
Few attempts per user
   ↓
Short time window

IF

unique_users >= 10

AND

failed_attempts_per_user <= 5

AND

time_window <= 10 minutes

THEN

raise_password_spray_alert()

1200
1300
1100
1400
1250
1350
1280
1190
1250
987000

03:02 Login success
03:04 New privilege
03:05 PowerShell
03:06 DNS spike
03:07 External connection
03:08 900 MB outbound

Herramientas de la semana

Resolución de problemas

El agente no aparece

systemctl status wazuh-agent

journalctl -u wazuh-agent

ss -lntp

Comprobar:

• Conectividad
• DNS
• Firewall
• Credenciales / enrollment
• Configuración del agente
• Hora del sistema

Hay eventos pero no alertas

Esto es un problema clásico.

EVENT
  ↓
Collector
  ↓
Decoder
  ↓
Rule
  ↓
Alert

Si no aparece la alerta, hay que localizar en qué fase se está perdiendo el evento.

El modelo genera demasiadas anomalías

Posibles causas:

• Dataset pequeño
• Features incorrectas
• Contamination mal configurado
• Comportamiento normal mal definido
• Cambios recientes en infraestructura

Challenge · Build your AI SOC

Este es el proyecto final de la semana. Debes diseñar una primera versión funcional de un SOC capaz de combinar reglas, comportamiento y AI.

Escenario

Una empresa tiene:

• Linux servers
• Windows endpoints
• Firewall
• VPN
• Active Directory
• Internet-facing applications

Se sospecha que un usuario privilegiado ha sido comprometido.

Tu misión

Construye una arquitectura capaz de:

• Recopilar eventos
• Centralizar logs
• Detectar brute force
• Detectar comportamiento anómalo
• Correlacionar eventos
• Calcular riesgo
• Enriquecer indicadores
• Generar un incidente
• Utilizar IA para investigar
• Generar un informe

Entregables

Arquitectura mínima esperada

                    ENDPOINTS
                       │
                       ▼
                    WAZUH
                       │
                       ▼
                      SIEM
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
          RULES                  ML
             │                   │
             └─────────┬─────────┘
                       ▼
                   CORRELATION
                       │
                       ▼
                   RISK SCORE
                       │
                       ▼
                   AI ANALYST
                       │
                       ▼
                    REPORT

Bonus

Obtendrás puntos adicionales si implementas:

• Docker
• Git
• Automated tests
• Threat intelligence enrichment
• RAG
• MITRE ATT&CK mapping
• Automated response proposal
• Dashboard
• Metrics

Comprueba lo aprendido

¿Cómo sabemos si nuestro SOC funciona?

No basta con decir "tenemos muchas alertas". Necesitamos métricas.

El objetivo de la IA

La IA no debería utilizarse simplemente para generar más alertas.

Una aplicación mucho más interesante es:

                    BEFORE AI

1000 alerts
     ↓
Analyst
     ↓
Manual investigation
     ↓
100 incidents

                    WITH AI

1000 alerts
     ↓
Correlation
     ↓
Risk scoring
     ↓
AI enrichment
     ↓
100 prioritized incidents
     ↓
Analyst

El objetivo es aumentar la capacidad analítica del equipo.

Cómo evoluciona nuestro proyecto

A partir de esta semana, el proyecto deja de ser simplemente un conjunto de ejercicios.

Estamos construyendo progresivamente:

                    AI SECURITY PLATFORM

                           │
             ┌─────────────┴─────────────┐
             │                           │
         TELEMETRY                    IDENTITY
             │                           │
             ▼                           ▼
          SIEM/XDR                    USERS
             │                       DEVICES
             │                       ENTITIES
             ▼                           │
       DETECTION ENGINE                  │
             │                           │
       ┌─────┴─────┐                     │
       │           │                     │
      RULES        ML                    │
       │           │                     │
       └─────┬─────┘                     │
             ▼                           │
         CORRELATION ◄───────────────────┘
             │
             ▼
         RISK ENGINE
             │
             ▼
          AI SOC
             │
       ┌─────┼─────┐
       ▼     ▼     ▼
    RAG    LLM   TOOLS
       │     │     │
       └─────┼─────┘
             ▼
          ANALYST
             │
             ▼
           SOAR
             │
             ▼
          RESPONSE

Referencias y recursos

¿Qué has construido?

Si has completado todos los ejercicios, ya tienes los fundamentos necesarios para construir un sistema de detección moderno.

• Comprendes la arquitectura de un SOC
• Sabes qué es la telemetría
• Comprendes SIEM y XDR
• Has trabajado con Wazuh
• Has introducido Zeek
• Has introducido Suricata
• Has diseñado detecciones
• Has trabajado IOC e IOA
• Has utilizado Machine Learning
• Has probado Isolation Forest
• Has trabajado con risk scoring
• Has diseñado correlación
• Has introducido UEBA
• Has diseñado un AI SOC
• Has introducido RAG
• Has construido un mini pipeline de seguridad