// Proyecto: Análisis de logs web con IA en Obsidian
// Herramientas: Obsidian + BMO IA (GLM5)
// Categoría: Log Analysis · Incident Response
// Estado: Compromiso identificado mediante correlación de logs
// Entorno: Mi Bóveda personal de Obsidian
0x00 — Introducción
DISCLAIMER
Este análisis tiene finalidad educativa y de práctica profesional. Las IPs, rutas, artefactos y evidencias descritas pertenecen a un escenario de laboratorio utilizado para reforzar metodología Blue Team, análisis de logs e investigación de incidentes.
Todos ya sabemos la importancia de la IA y saber usarla en nuestro beneficio.
En este laboratorio he querido probar algo muy concreto y es que según avanzaba en el aprendizaje de uso de Obsidian, hasta qué punto una bóveda puede convertirse en un entorno práctico para analizar logs de seguridad cuando se combina con un asistente de IA contextual como BMO.
La idea no era que la IA sustituyera al analista, sino usarla como copiloto forense:
- Mostrarle notas
- Pedirle hipótesis
- Validar sus conclusiones contra evidencias
- Avanzar paso a paso hasta reconstruir una cadena de ataque.
El caso parte de logs web relacionados con un entorno WordPress.
A simple vista había ruido, múltiples códigos HTTP, varias IPs y rutas sospechosas.
El objetivo era responder una pregunta básica para cualquier analista SOC
Pregunta
¿Estamos viendo únicamente reconocimiento y fuerza bruta, o existe evidencia suficiente para declarar un compromiso real del servidor?
0x01 Primer contacto con el access log
Mi análisis empieza dentro de Obsidian, sobre una nota de logs llamada access_12_Jan_2021_15.
La primera petición a BMO fue sencilla: analizar lo visible y detectar patrones relevantes.
BMO detectó una anomalía inicial: la IP 172.21.0.1 concentraba la mayor parte del tráfico.
Esa IP podía representar un gateway, un proxy, un contenedor interno o una fuente de actividad automatizada.
No era todavía una conclusión de compromiso, pero sí una primera hipótesis de investigación.
Imagen 1 — BMO analiza la nota inicial del access log y detecta la concentración de tráfico en 172.21.0.1.
0x02 Segmentación por códigos HTTP
El siguiente paso fue pasar del log bruto a una vista agregada por códigos HTTP.
En análisis web, esta segmentación permite separar errores, intentos bloqueados, reconocimiento, redirecciones y peticiones exitosas.
| Código | Volumen | Lectura defensiva |
|---|---|---|
| 200 OK | 1445 | Actividad exitosa. Puede incluir tráfico legítimo o post-explotación. |
| 403 Forbidden | 163 | Intentos contra recursos protegidos. |
| 404 Not Found | 272 | Reconocimiento, enumeración y búsqueda de rutas sensibles. |
| 500 Server Error | 5 | Posible error generado por explotación o pruebas agresivas. |
Imagen 2 — Agregación de códigos HTTP en la nota 00_CODIGO.
BMO priorizó los códigos 403, 404, 500 y 200.
Esta priorización es importante ya que los errores muestran intentos y reconocimiento, pero los 200 pueden mostrar acciones que sí tuvieron éxito.
Cambio de enfoque
Un código 403 puede indicar bloqueo.Un 404 puede indicar reconocimiento.
Un 200 sobre una ruta maliciosa puede ser la diferencia entre intento y compromiso.
0x03 BMO me genera un playbook
Una vez visto el reparto por códigos, pedí a BMO que interpretara el escenario y propusiera próximos pasos.
La respuesta fue útil porque transformó la observación en una metodología.
Playbook propuesto
- Aislar la IP 172.21.0.1.
- Inspeccionar URIs asociadas a 403 y 404.
- Analizar la diferencia entre el log inicial y el volumen agregado.
- Buscar evidencia de éxito, no solo intentos bloqueados.
Imagen 3 — BMO genera un perfil inicial del incidente y propone un playbook.
Imagen 4 — Primer paso del playbook: volver a 172.21.0.1 y aislar su comportamiento.
0x04 — Aislamiento de 172.21.0.1
Al abrir la nota específica de 172.21.0.1, el volumen era mucho más claro, se ven 1035 peticiones, con mayoría de respuestas 200 OK.
BMO interpretó ese comportamiento como actividad automatizada o concentrada a través de un proxy/contenedor.
Aquí el análisis empezó a tomar forma, ya no bastaba con mirar IPs externas, también había que entender qué papel jugaba este origen interno.
Imagen 5 — Análisis específico de 172.21.0.1.
Imagen 6 — BMO concluye que el patrón no parece humano, sino automatizado o intermediado.
0x05 Forbidden no significa irrelevante
El siguiente filtro fue el código 403 Forbidden.
Aunque un 403 indica que el servidor ha bloqueado el acceso, para un analista sigue siendo una señal muy útil porque significa que el atacante ha tocado una ruta real o protegida.
En este punto apareció una ruta especialmente sensible: /wp-login.php?itsec-hb-token=adminlogin.
Observación
Si un atacante conoce una URL de login ofuscada mediante un token de seguridad, la defensa por oscuridad ya ha perdido parte de su valor.
El 403 bloquea, pero la ruta ha sido descubierta.
Imagen 7 — Primer análisis de 403 Forbidden.
Imagen 8 — BMO perfila a los malos asociados al código 403 y prioriza IPs críticas.
0x06 El valor del 404
Después del 403, filtré por 404 Not Found.
Un 404 no confirma explotación, pero sí revela intención.
Es una ventana directa a lo que el atacante está buscando.
BMO interpretó estos errores como una fase clara de enumeración con paneles de administración, rutas ocultas, plugins vulnerables, backups, ficheros temporales y posibles webshells.
Imagen 9 — Análisis de 404 Not Found como fase de reconocimiento.
Imagen 10 — BMO resume el 404 en fases: escaneo, explotación y persistencia/verificación.
0x07 Peticiones POST
Hasta aquí había señales de reconocimiento, fuerza bruta e intentos bloqueados.
Pero el punto de inflexión llegó al analizar las peticiones POST.
En un incidente web, los POST suelen ser más reveladores que los GET porque implican envío de datos, subida de archivos, autenticación o ejecución de acciones.
Esto es crítico
BMO identificó peticiones POST exitosas contra
/wp-content/uploads/simple-file-list/fr34k.php.
La combinación de ruta, método POST, código 200 OK y contexto previo apunta a una webshell activa.
Imagen 11 — Análisis de POST. Aparece fr34k.php como evidencia crítica.
0x08 Simple File List o el vector de entrada
Con la webshell localizada, había que entender cómo llegó al servidor.
BMO conectó el hallazgo con rutas del plugin Simple File List, especialmente endpoints relacionados con subida y gestión de archivos.
Rutas relevantes
/wp-content/plugins/simple-file-list/ee-upload-engine.php
/wp-content/plugins/simple-file-list/ee-file-engine.php
/wp-content/uploads/simple-file-list/fr34k.php
Imagen 12 — BMO relaciona las peticiones POST con el plugin Simple File List y la subida de la webshell.
0x09 Reconstrucción de la Kill Chain
Con todas las piezas sobre la mesa, BMO reconstruyó una cadena de ataque coherente y lógica, la verdad impresionante:
Preparación, reconocimiento, explotación, persistencia y acción sobre el objetivo.
| Fase | Evidencia | Interpretación |
|---|---|---|
| Preparación | 172.21.0.1 | Actividad interna, posible proxy/contenedor o punto automatizado. |
| Reconocimiento | 403 y 404 | Enumeración de login, plugins, rutas sensibles y posibles webshells. |
| Explotación | Simple File List | Abuso de funcionalidad de subida o gestión de archivos. |
| Persistencia | fr34k.php | Webshell ubicada en uploads. |
| Acción | POST 200 OK | Interacción real con la webshell. |
Imagen 13 — BMO reconstruye el mapa de la cadena de ataque y emite veredicto de compromiso.
Veredicto
El servidor ha sido comprometido.
La evidencia fuerte no es un único indicador, sino la correlación entre reconocimiento, abuso de plugin, subida de archivo PHP y peticiones POST exitosas contra la webshell.
0x0A Plan de contención y remediación
En este tipo de incidente, bloquear una IP no es suficiente. Si existe una webshell accesible, el atacante puede cambiar de origen y seguir interactuando con el servidor.
Plan de respuesta:
- Eliminar /wp-content/uploads/simple-file-list/fr34k.php.
- Deshabilitar, eliminar o parchear urgentemente Simple File List.
- Revisar otros PHP sospechosos dentro de /wp-content/uploads/.
- Rotar credenciales de administrador de WordPress.
- Auditar usuarios, plugins, temas y cambios recientes.
- Buscar archivos .bak, .save, .swp y copias expuestas.
- Revisar integridad de wp-config.php.
- Correlacionar IPs ofensivas con otros logs disponibles.
0x0B Qué aportó realmente BMO IA
La IA no “resolvió” el caso sola. Lo que hizo fue acelerar el razonamiento.
BMO ayudó a resumir, priorizar, correlacionar y mantener una narrativa de investigación dentro de Obsidian.
El analista sigue siendo quien decide qué preguntar, qué validar, qué descartar y cuándo una hipótesis tiene suficiente evidencia para convertirse en conclusión.
Valor operativo
Obsidian funciona como base de conocimiento. BMO funciona como capa conversacional sobre esa base.
La combinación permite documentar, investigar y explicar incidentes de forma mucho más ordenada.
0x0C BMO como asistente sobre la bóveda
Dos días después del análisis del incidente, probé otra capacidad interesante: usar BMO como asistente experto sobre mi propia bóveda de Obsidian.
Le pedí que asumiera un rol senior en ciberseguridad y que identificara conceptos obligatorios para un analista. Después le pedí trazabilidad: citar las notas .md desde las que había obtenido la información.
Imagen 14 — BMO como asistente experto utilizando contexto de la bóveda de Obsidian.
Imagen 15 — BMO cita las notas Markdown utilizadas como fuente de conocimiento.
0x0D Lecciones aprendidas
- La IA funciona mejor cuando el analista le proporciona contexto estructurado.
- Los códigos HTTP ayudan a priorizar, pero no sustituyen la correlación.
- Los 403 y 404 muestran intención, pero los POST exitosos pueden confirmar acción.
- Una webshell no se confirma solo por el nombre del archivo, sino por contexto, método, código y ruta.
- Obsidian puede funcionar como un laboratorio SOC personal para documentar investigaciones.
- BMO aporta velocidad, pero el criterio analítico sigue siendo humano.
0x0E Conclusión
Este caso demuestra que una IA integrada en Obsidian puede ser muy útil para un analista de ciberseguridad, siempre que se use como apoyo y no como sustituto del criterio técnico.
BMO ayudó a pasar de una nota de access log a una investigación completa con todo lo necesario:
Detección de anomalía, segmentación por códigos HTTP, generación de playbook, análisis por IP, revisión de 403/404, correlación con POST, identificación de webshell y reconstrucción de kill chain.
La IA no reemplaza al analista, pero puede multiplicar su capacidad
[ EOF ]
"Security is not a product, it's a mindset."