CONTEXTO PERSONAL Soy analista de seguridad sin experiencia laboral previa en un SOC.
Este post es una simulación educativa montada en casa con herramientas locales y open source (Splunk + LLM local + Obsidian), basada en el dataset público BOTSv3 (empresa ficticia froth.ly).
No hay datos reales de ninguna empresa, ni infraestructura ajena comprometida. El objetivo es demostrar que cualquiera puede aprender el flujo de trabajo de un SOC real desde su propio equipo, sin costes y sin experiencia previa.
Imagina que acabas de empezar en tu primer trabajo como analista de seguridad (N1).
Tu empresa se llama froth.ly y usa Splunk como SIEM.
A las 10:15 de la mañana de tu primer día suena una notificación en Slack:
Possible SSH Brute Force Attack Host objetivo:
mars.i-08e52f8b5a034012dOrigen:167.114.13.150(41 intentos) ·5.101.40.81(12 intentos) Prioridad: ALTA
Tu patata se acelera. No tienes ni idea de qué hacer.
Pero aquí es donde empieza la aventura.
En este post te llevo por el ciclo de vida completo de una alerta simulando tal y como se trabaja en cualquier SOC del mundo con su detección, triage, investigación, enriquecimiento, escalada y documentación.
- Splunk local con licencia de desarrollador y el dataset BOTSv3 (2M+ eventos reales de un entorno empresarial ficticio)
- Qwen 35B A3B MoE (LLM local) como mentor que me guía paso a paso
- Obsidian Vault como cerebro: playbooks, inteligencia de IPs (Cyber Radar) y plantillas a falta de un SIEM real.
- Slack + Jira para simular el ChatOps y el ITSM de un SOC moderno
0x00 El ciclo de vida de una alerta
Antes de empezar, este es el esquema mental que hice:
1. DETECCIÓN → El SIEM correlaciona eventos y genera una alerta
2. TRIAGE → El analista N1 valida: ¿alerta real o falso positivo? ¿prioridad?
3. INVESTIGACIÓN → ¿Quién? ¿Qué? ¿Cuándo? ¿Dónde? ¿Cómo? (logs, timeline)
4. ENRIQUECIMIENTO → IOCs: reputación de IPs, usuarios, hosts (Cyber Radar / Threat Intel)
5. DECISIÓN → ¿Incidente real? ¿Contengo? ¿Escalo a N2?
6. ESCALADA → Informe estructurado + ticket + notificación al nivel superior
7. DOCUMENTACIÓN → Timeline, evidencia, informe final (auditable)
8. CIERRE → Lecciones aprendidas, mejora de detecciones
Este post sigue exactamente ese flujo.
Cada sección = una fase del ciclo de vida.
0x01 - La alerta llega a Slack
Fase: DETECCIÓN
En un SOC moderno, el SIEM no te pide que escribas queries para encontrar ataques porque tiene reglas de correlación (búsquedas guardadas) que monitorizan los logs 24/7.
Cuando la regla se dispara como con >10 intentos de login SSH fallidos desde la misma IP esto genera una alerta que se notifica al canal de chat del equipo.
En mi simulación, la alerta llega al canal #soc-alertas de Slack vía un webhook que emula exactamente lo que haría Splunk con su acción de alerta:
¿Qué estoy viendo? Una alerta con:
- Severidad (ALTA) → me dice cuánta prisa tengo
- Host objetivo (
mars.i-08e52f8b5a034012d) → qué máquina está bajo ataque - Orígenes (
167.114.13.150,5.101.40.81) → desde dónde atacan - Contexto (dataset, analista asignado) → metadatos del incidente
No te fies hay que validar los datos.
0x02 - Triage
Cuando una alerta se confirma como candidata a incidente, en un SOC real se materializa en un ticket en el sistema ITSM (Jira Service Management, ServiceNow, Helix…)
El ticket estandariza el trabajo: tiene ID, severidad, asignación y un flujo de estados (Abierto → En investigación → Escalado → Resuelto).
Ticket: INC-2026-0807-001
Tipo: Incidente de Seguridad (Brute Force SSH)
Severidad: Alta
Asignado a: Sammi (Analista N1)
Estado: En investigación
Esto es memoria de trabajo. Todo lo que hagas debe quedar reflejado y si mañana te atropella un autobús, otro compi debe poder continuar tu investigación solo con el ticket.
0x03 - Investigación
Ahora toca confirmar con datos.
Abro Splunk (la sesión expira a menudo) y ejecuto la primera query
¿Es cierto que hay decenas de intentos fallidos de SSH contra mars?
search index=botsv3 sourcetype=linux_secure (invalid OR preauth)
| rex "(?:from|by) (?<src_ip>\d+\.\d+\.\d+\.\d+)"
| stats count as intentos_fallidos, values(host) as objetivo by src_ip
| where intentos_fallidos > 10 | sort - intentos_fallidos
src_ip intentos_fallidos objetivo
167.114.13.150 41 mars.i-08e52f8b5a034012d
5.101.40.81 12 gacrux.i-0920036c8ca91e501, mars.i-08e52f8b5a034012d
La alerta es real 41 intentos fallidos contra mars y 12 contra mars y gacrux desde dos IPs.
Siempre se empieza por confirmar la alerta con los datos crudos. Una alerta sin validar no es un incidente, es una hipótesis.
0x04 - Mi pánico y la IA
Soy nuevo, estoy en mi primer día no tengo experiencia y me sueltan a los lobos y…
Aquí es donde entra mi arma secreta: un LLM local (Qwen 3.6 35B A3B MoE) que corre en mi propia GPU (RTX 5060 Ti 16GB).
Sin enviar un solo dato a la nube, privado.
Lo arranco en el puerto 8081 y le escribo en Pi Agent lo que me acaba de pasar:
Sammi: Acabo de confirmar un brute force SSH contra mars. ¿Qué hago ahora?
Qwen:
- Verifica en el SIEM — confirma los intentos fallidos (41 desde 167.114.13.150, 12 desde 5.101.40.81)
- Busca logins exitosos y eventos
acceptedde esas IPs.- Si hay uno, escala ya a N2
- Investiga las IPs — VirusTotal, Shodan: reputación, ASN, país,
- ¿IP de nube o Tor?
- Verifica cuentas comprometidas logins de root o cuentas privilegiadas
- Busca movimiento lateral — conexiones SSH salientes desde mars hacia otros hosts internos
- Comprueba persistencia cronjobs, claves nuevas en
authorized_keys, scripts en/tmp- Escala a N2 si hay login exitoso desde IPs atacante, movimiento lateral, persistencia, IPs vistas en otros incidentes o exfiltración
Los SOC se usan playbooks (procedimientos estandarizados) para no improvisar.
Mi “playbook” vive en Obsidian y lo consulto vía RAG con la IA local.
0x05 - Enriquecimiento
Antes de investigar a fondo, el analista enriquece los IOC´s
¿Quién está detrás de esas IP´s?
En un SOC real usas VirusTotal, GreyNoise o AbuseIPDB
En mi SOC personal uso una base de inteligencia local en Obsidian con una plantilla estilo GreyNoise IP Report que se actualiza a diario por cron jobs basada en BMO de Obsidian y ya lo hablé en un post anterior
167.114.13.150→ IP de hosting/VPS (típico origen de brute force automatizado)5.101.40.81→ IP de hosting, mismo comportamiento91.207.175.249→ FALSO POSITIVO que aparece en logs de tráfico HTTP pero es el parámetromip=de Google CDN, no es un atacante
No toda IP sospechosa es un atacante. Distinguir tráfico legítimo (CDNs, rastreadores) del malicioso es la habilidad.
0x06 - Movimiento lateral
El brute force es la puerta.
La pregunta crítica: ¿Alguien entró?
Ejecuto la query de Accepted publickey para ver logins exitosos con clave
search index=botsv3 sourcetype=linux_secure Accepted
| rex "Accepted publickey for (?<user>\S+) from (?<src_ip>\d+\.\d+\.\d+\.\d+) port \d+ ssh2: (?<algo>\S+) (?<fingerprint>SHA256:\S+)"
| stats values(src_ip) as origenes, dc(src_ip) as num_origenes, values(host) as hosts by user, fingerprintSe observa SHA256:Z1RO5UMCuK3+NOcX0XWO1atA1+fhYXeYomgkTarWrmQ para el usuario ec2-user fue usada en 4 logins exitosos desde 3 IP´s distintas contra mars y gacrux:
time user src_ip key_fp
2018-08-20 11:29:09 ec2-user 157.97.121.132 SHA256:Z1RO5UM...
2018-08-20 16:03:47 ec2-user 91.207.175.249 SHA256:Z1RO5UM...
2018-08-20 16:11:42 ec2-user 166.170.40.8 SHA256:Z1RO5UM...
2018-08-20 16:18:34 ec2-user 166.170.40.8 SHA256:Z1RO5UM...
Eso es movimiento lateral
Entre los orígenes aparece 91.207.175.249, la misma IP que vimos en el enriquecimiento como posible tráfico de Google CDN (mip=).
En un contexto HTTP era benigna; en este contexto es un origen de login SSH.
La lección es que la misma IP puede ser legítima en un flujo y sospechosa en otro contexto del log manda
Confirmo con sesiones interactivas (query Q3, comando who) en BOTSv3 los comandos viven en el sourcetype osquery:results, y encuentro 20 eventos del comando who en gacrux entre las 16:48 y las 17:02 parece alguien con sesión interactiva en un segundo host:
Aquí el objetivo del analista no es quedarse en la alerta inicial, sino seguir el rastro completo del atacante (cadena de ataque / kill chain).
0x07 Escalada
Esto ya supera mi nivel de N1 además no tengo ni experiencia
Hay que escalar a N2 con un informe estructurado, siguiendo la plantilla del SOC.
La IA local me ayuda a redactarlo con la evidencia recopilada:
INC-2026-0807-001:
- Tipo: Brute Force SSH y Movimiento Lateral
- Severidad: ALTA
- Estado: ESCALADO A N2
- Ticket: KAN-253
- IOCs: IPs
167.114.13.150(41) ·5.101.40.81(12) · usuarioec2-user· claveSHA256:Z1RO5UMCuK3+NOcX0XWO1atA1+fhYXeYomgkTarWrmQ· hostsmars+gacrux - MITRE ATT&CK T1078 (Valid Accounts) · T1021.004 (SSH) · T1090.1 (Proxy interno)
- Acción requerida N2: bloquear IPs en firewall, rotar/revocar clave RSA forense en mars y gacrux y buscar otros hosts con la misma clave
Un informe de escalada debe contener toda la evidencia para que el nivel superior actúe sin repetir tu trabajo, eso lo sé muy bien de mi trabajo actual
0x08 El SOC de tu casa
He pasado mi primer día como analista.
He seguido el flujo completo detectar → triage → investigar → enriquecer → escalar → documentar.
Y no necesité un SOC empresarial de millones.
Dejé el ticket KAN-253 cerrado con los comentarios de cierre
En el proyecto Jira había 268 tickets con [SIEM] Windows Critical Errors, uno cada 5 minutos, sin deduplicación).
Mi incidente real era uno más entre el ruido.
Ese es el verdadero problema nº1 de los SOC´s las fatigas por exceso de alertas y tanta alerta que las importantes se pierden.
Mi primer día también me enseñó eso.
Lecciones:
- La alerta es el principio, nunca el final
- Valida siempre con datos crudos
- Enriquecer los IOCs evita falsos positivos
- Sigue el rastro completo del atacante (kill chain)
- Escalar con un buen informe es parte del trabajo
- La IA local + RAG multiplica la velocidad de un analista novato
- Las alertas automáticas sin tuneo ahogan el SOC: deduplica y prioriza
El stack completo (100% local y open source):
- Splunk (licencia de desarrollador, 10 GB/día) + dataset BOTSv3
- Qwen 3.6 35B A3B MoE en GPU local (RTX 5060 Ti 16GB)
- Obsidian Vault como cerebro (playbooks, plantillas etc…)
- Slack + Jira para el Chat/ITSM
- Pi Agent como orquestador de LLM + llamacpp
Para esto hace falta mucha curiosidad con ganas de aprender y de trabajar, yo tendría menos titulitis o pedir experiencia ilimitada a personas
Distinguir donde hay personas sin actitudes y carentes de aptitudes, porque se relajan, porque tienen FP o carreras ¿Y ya está? ¿Terminó tu conocimiento? por eso no me sorprende…si ya muchos no se acuerdan ni de abrir un CMD.
Una última cosa…la IA ha venido a quedarse, usarla en tu beneficio no sustituye tu criterio y guía (Human in The Loop) por tanto no te hace menos por usarla, si necesitas orientación sobre todo al principio y tu compañero no te contesta en el chat la incidencia, todo puede ir a peor…
Saber implementar esto es ORO, gracias a horas de esfuerzo he aprendido a usar la IA en múltiples aspectos y me siento orgulloso.