Santa Logs: un laboratorio para practicar trazabilidad básica en Windows
Un ejercicio de análisis de evidencias locales en Windows, leyendo el visor de eventos hasta correlacionar los indicios que abren un script cifrado.
Principiante · Windows
URL del reto: labs.thehackerslabs.com/machines/78
Por qué la diseñé
Santa Logs es un ejercicio de análisis de evidencias locales en Windows más que un laboratorio de explotación. Lo planteé para obligar a mirar los logs con atención cuando todavía no hay un SIEM, ni un stack de observabilidad, ni tooling forense que haga el trabajo por ti. El recorrido va de una lógica de investigación mínima, interpretar señales sencillas y ver cómo se relacionan entre sí.
El envoltorio navideño es lo de menos. La enseñanza es terrenal, saber leer eventos, separar ruido de señal y entender que una manipulación del sistema rara vez se explica con una sola pista aislada. Por eso lo monté alrededor de un visor de eventos acotado, una fuente de logs concreta y un artefacto cifrado que obliga a correlacionar antes de dar con la respuesta.
La máquina de un vistazo
Se entra con un usuario ya dado y, en lugar de una consola, lo primero que hay es el visor de eventos. Toda la actividad útil está en una sola fuente, y la investigación consiste en leer tres señales, un servicio con muchos accesos fallidos, una conexión que sí entró y una alerta de sistema, para después usar esos datos como clave de un script cifrado.
Cómo la monté, paso a paso
Se abre en el visor de eventos, no en una shell
La máquina arranca con el visor de eventos, no con una superficie de ataque. Esa decisión es a propósito, quería que el primer reflejo fuera revisar qué rastro había dejado la actividad previa, y no enumerar binarios, servicios o shares. Es la mentalidad con la que conviene empezar cuando lo que hay que reconstruir es qué pasó, y no qué se puede romper.
Una sola fuente de logs para no dispersar
Limité la visibilidad de los eventos a una única fuente, Santalogs. Con eso evito que la fase se convierta en una búsqueda caótica por Windows y fuerzo a interpretar el contenido. Quería enseñar que el valor está en saber dónde mirar y qué eventos merecen correlación, más que en tener muchos logs.
Las señales, ruido de FTP, un SSH que entró y una alerta de disco
Dentro de esa fuente sembré tres tipos de señal distintos. Primero, un montón de accesos fallidos por FTP, que por sí solos no comprometen nada pero representan la presión externa que se acaba normalizando en servicios expuestos. Después, frente a ese ruido, una conexión SSH que sí tuvo éxito desde una IP concreta, para enseñar que la pista útil muchas veces está en el acceso que funcionó y no solo en los errores. Y por último, una alerta de poco espacio en disco, un evento operativo que no es un hallazgo de intrusión pero que en un sistema comprometido puede ser ruido inocente o una consecuencia indirecta, y que conviene no descartar de forma automática.
El script que solo abre con lo que dicen los logs
La pregunta central gira alrededor de un malicious_script.py que no se puede inspeccionar ni modificar. Para abrirlo hay que componer una clave con lo visto antes, el recuento de fallos y la IP que sí entró. Ese era el objetivo, una relación explícita entre observar y actuar, que la solución salga de correlacionar datos ya vistos en el sistema, y no de la fuerza bruta ni de mirar el archivo. Más que criptografía o reversing, quería enseñar algo básico y reutilizable, que antes de intentar romper un artefacto conviene preguntarse qué contexto del sistema ya lo explica.
Qué quería enseñar
Santa Logs es un laboratorio de correlación básica sobre Windows con narrativa ligera y una intención concreta detrás, trabajar con indicios simples cuando todavía no hay un ecosistema de análisis maduro alrededor. Fija una secuencia mental, encontrar la fuente de evidencia, separar ruido de señal, sacar indicadores concretos y reutilizarlos para validar un artefacto sospechoso.
| Fase | Qué enseña | Error que representa |
|---|---|---|
| Visor de eventos | Localizar la fuente útil de evidencia | Depender de tooling externo para empezar a investigar |
| Fallos por FTP | Medir presión o actividad anómala sobre un servicio | Servicios expuestos con autenticaciones repetidas |
| Conexión SSH que entró | Ver un acceso válido entre el ruido | Poca vigilancia sobre los accesos que sí funcionan |
| Alerta de disco | Contextualizar el estado del sistema | Ignorar señales operativas que complementan el análisis |
| Descifrar el script | Correlacionar indicadores antes de actuar | Analizar ficheros sospechosos sin contexto |
Muchas investigaciones empiezan justo así, con acceso limitado, pocos datos y la necesidad de razonar antes de ejecutar. Santa Logs fija esa secuencia en pequeño, para que se quede.