Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Windows
Dificultad: principiante

Sobre este CTF

Santa Logs no nació como un laboratorio de explotación, sino como un ejercicio de análisis básico sobre evidencias locales en un sistema Windows. Lo planteé con una idea muy concreta: obligar a mirar los logs con atención cuando todavía no hay un SIEM, ni un stack de observabilidad, ni tooling forense avanzado que haga el trabajo por nosotros.

La máquina está construida para que el recorrido tenga sentido desde una lógica de investigación mínima. No se trata de encadenar trucos, sino de interpretar señales sencillas pero útiles: intentos fallidos de acceso, una conexión válida que destaca frente al ruido, una alerta operativa y un artefacto sospechoso cuyo valor no está solo en existir, sino en cómo se relaciona con lo anterior.

El contexto navideño sirve de envoltorio, pero la enseñanza buscada es bastante terrenal: saber leer eventos, separar ruido de señal y entender que una intrusión o una manipulación del sistema rara vez se explica por una sola pista aislada. Por eso diseñé la máquina alrededor de un visor de eventos muy acotado, una fuente de logs específica y un script cifrado que obliga a correlacionar datos antes de obtener la respuesta final.

Información técnica

Punto de partida del laboratorio

El acceso inicial de la máquina está definido de forma explícita:

Usuario: santa
Password: Cl@us

Una vez dentro, el laboratorio no abre con una consola ni con una superficie de ataque clásica, sino con algo más deliberado: el visor de eventos. Esa decisión de diseño no es casual. Quería que el primer reflejo del jugador no fuese enumerar binarios, servicios o shares, sino revisar qué rastro había dejado la actividad previa en el sistema.

También limité la visibilidad de los eventos para centrar la lectura en una única fuente, Santalogs. Eso reduce dispersión y fuerza a interpretar el contenido, no a perder tiempo navegando por registros irrelevantes.

Revisión inicial de eventos

Al abrir el visor de eventos, el sistema no muestra registros útiles en los canales habituales. Toda la actividad de interés está concentrada en Santalogs.

Eso tiene dos objetivos. El primero es didáctico: evitar que la fase se convierta en una búsqueda caótica dentro de Windows. El segundo es técnico: enseñar que, en un entorno real, muchas veces el valor no está en “tener muchos logs”, sino en saber dónde mirar y qué eventos merecen correlación.

Aquí el laboratorio plantea tres preguntas muy concretas, pero cada una representa una dimensión distinta del análisis:

• volumen de ruido o presión sobre un servicio
• identificación de un origen que sí consiguió acceso
• señales operativas que pueden contextualizar la actividad

Intentos fallidos de acceso por FTP

La primera evidencia relevante es el recuento de intentos fallidos de acceso por FTP. En los logs registrados aparecen 50.

Ese dato, por sí solo, no compromete el sistema, pero sí representa una situación muy común fuera del CTF: servicios expuestos que acumulan autenticaciones fallidas y terminan normalizando comportamientos que no deberían verse como rutinarios. La intención aquí era que el jugador entendiera que incluso un dato simple, como un contador de fallos, puede ser el primer indicador de presión externa o de actividad anómala.

El valor pedagógico de esta fase no está en responder “50”, sino en reconocer qué significa ese número dentro del contexto de un servicio accesible y observable.

Conexión SSH exitosa

Frente al ruido de FTP, los logs también muestran una conexión SSH exitosa desde la IP 192.168.1.101.

Aquí la máquina cambia de registro. Ya no hablamos de intentos fallidos, sino de una evidencia positiva de acceso. Quise que esta parte sirviera para enseñar una idea básica pero importante: en una investigación inicial no todo el peso debe recaer sobre los errores; muchas veces la pista útil está en el acceso que sí funcionó.

La IP identificada se convierte después en una pieza reutilizable dentro de la cadena. Eso refuerza otro aprendizaje que me interesaba introducir: los indicadores no suelen vivir aislados. Una dirección IP observada en autenticación puede reaparecer en otros artefactos y ganar valor precisamente por esa repetición.

Alerta operativa sobre espacio en disco

Otro de los eventos registrados deja un mensaje de advertencia claro:

Low disk space

Esta fase existe para romper una lectura demasiado lineal del laboratorio. No todo en los logs tiene que ser una credencial, una IP o un acceso. También hay eventos operativos que, en un contexto real, ayudan a entender el estado del sistema y a formular hipótesis.

Quería que apareciera una alerta que no fuese un “hallazgo de intrusión” en sentido estricto, pero que sí recordara algo importante: los problemas de capacidad, almacenamiento o mantenimiento también forman parte del análisis. En una máquina comprometida, estos avisos pueden ser ruido inocente o una consecuencia indirecta de actividad maliciosa. Aprender a no descartarlos de forma automática también forma parte del ejercicio.

La clave para descifrar el script sospechoso

La pregunta central del laboratorio gira alrededor de malicious_script.py. El archivo no puede inspeccionarse ni modificarse directamente, de modo que obliga a trabajar con el contexto disponible.

La clave obtenida a partir de los logs es:

FTP25_SMB192.168.1.101

Aquí la intención de diseño era bastante clara: construir una relación explícita entre observación y acción. El jugador no recibe la solución por fuerza bruta ni por inspección directa del archivo, sino por correlación de datos vistos previamente en el sistema.

La cadena resume bien el propósito de la máquina:

• un servicio con intentos fallidos
• una IP que sí consiguió acceso
• un artefacto cifrado que depende de esa información previa

No buscaba enseñar criptografía ni reversing, sino una disciplina más básica y más reutilizable: antes de intentar romper un artefacto, conviene preguntarse qué contexto del sistema ya lo explica.

Validación del artefacto y obtención de la flag

Al ejecutar el script, el sistema solicita la clave obtenida en la fase anterior. Al introducirla correctamente, devuelve la flag final:

oscar_feliz_navidad

La resolución final es sencilla a propósito. No me interesaba rematar la máquina con una fase artificiosa, sino cerrar el recorrido confirmando que toda la investigación previa tenía una utilidad práctica. La flag no representa aquí un premio técnico complejo, sino la validación de que se ha entendido la relación entre los eventos y el artefacto.

Ese cierre encaja con la filosofía general del laboratorio: la dificultad no está en herramientas avanzadas ni en explotación profunda, sino en leer bien una secuencia pequeña de evidencias y convertirla en una respuesta coherente.

Qué quería enseñar al diseñar Santa Logs

Santa Logs está pensado como un laboratorio de correlación básica sobre Windows con una narrativa ligera, pero con una intención muy concreta detrás: enseñar a trabajar con indicios simples cuando todavía no existe un ecosistema de análisis maduro alrededor.

La máquina no pretende simular un incidente complejo. Lo que busca es fijar una secuencia mental útil:

1. identificar la fuente de evidencia adecuada
2. distinguir entre ruido y señal
3. extraer indicadores concretos
4. reutilizarlos para validar un artefacto sospechoso

Esa cadena tiene sentido más allá del entorno CTF, porque muchas investigaciones reales empiezan exactamente así: con acceso limitado, con pocos datos y con la necesidad de razonar antes de ejecutar.

Recursos y referencias

• Visor de eventos de Windows
• Revisión manual de registros personalizados
• Correlación básica de indicadores entre servicios y artefactos locales
• Análisis controlado de scripts cifrados en laboratorio