Hace poco participé en un certamen de ciberseguridad organizado por la ANCI (Agencia Nacional de Ciberseguridad) junto a la plataforma Hackrocks. Quiero dejar documentada la experiencia, tanto para compartirla con la comunidad como porque escribir el recorrido ayuda a consolidar lo aprendido.
Participé en dos categorías: en equipo, junto a Rhemati (la consultora con la que trabajo en proyectos de IA y automatización), donde quedamos en el puesto 98; y de forma individual, donde terminé en el puesto 69.
Qué es este tipo de certamen
Es un CTF (Capture The Flag): una competencia de ciberseguridad donde los participantes resuelven desafíos de distintas áreas —aplicaciones web, análisis forense, criptografía, ingeniería inversa, sistemas operativos, búsqueda de información— para encontrar una "bandera" (un texto oculto) que demuestra que el desafío fue resuelto. Cada bandera encontrada suma puntos, y el ranking se arma en base a quién consigue más puntos en el tiempo que dura el evento.
Todo ocurre en entornos de laboratorio controlados y aislados, provistos por los organizadores, sin tocar sistemas reales. El objetivo es formativo: entrenar las mismas habilidades que usa alguien que audita la seguridad de un sistema, pero sin ningún riesgo para servicios o personas reales.
Por qué me metí en esto
Como desarrollador, construyo sitios y sistemas todos los días. Participar en este tipo de certámenes me obliga a mirar ese mismo trabajo desde el otro lado: pensar como quien intenta encontrar la falla, no solo como quien la previene. Esa mirada es la que después aplico en los proyectos que entrego: cabeceras de seguridad, validación de datos, cuidado con los permisos, revisión de lo que un formulario o una API realmente permite hacer.
Lo que más disfruté del certamen fue su variedad. En un mismo evento pasé de revisar el comportamiento de aplicaciones web modernas, a hacer investigación con fuentes abiertas, y a terminar enfrentando un desafío de sistemas operativos bastante más avanzado. Esa mezcla obliga a cambiar de enfoque constantemente.
Algunos de los desafíos, en corto
Sin entrar en el detalle técnico —esto no es una guía de explotación, sino un resumen para quien quiera entender de qué se trataba cada tipo de ejercicio—, estos son algunos de los que trabajé:
- Una aplicación que confiaba demasiado en lo que el usuario le enviaba. Procesaba un formato de datos estructurado (YAML) sin las validaciones adecuadas, lo que terminaba permitiendo ejecutar código en el servidor. Es el mismo tipo de error que reviso cuando audito formularios o integraciones en proyectos reales: nunca asumir que lo que llega del usuario es seguro de procesar tal cual.
- Un panel que hacía de intermediario hacia la red interna. Permitía indicarle una URL de destino y la consultaba por uno, incluyendo direcciones internas que normalmente serían inalcanzables desde afuera. Ese tipo de falla (conocida como SSRF) se encadenaba con otra, de inyección en el motor de plantillas, para terminar de resolver el desafío. Curiosamente, el propio código de la página escondía una trampa dirigida a asistentes de IA, tratando de inducir a ejecutar un comando a ciegas: la detecté, no la seguí, y la reporté como hallazgo.
- Un ejercicio de investigación con fuentes abiertas (OSINT). Había que ubicar un lugar a partir de una fotografía, usando metadatos, pistas visuales (vegetación, arquitectura, señalética, sombras) y herramientas de búsqueda inversa de imágenes y mapas. Es un trabajo de paciencia y correlación de datos, muy distinto al resto de los desafíos.
- Una aplicación detrás de un proxy que, a simple vista, no mostraba nada. La página visible era solo una fachada; prestando atención a los códigos de respuesta del servidor se podía entender qué rutas existían de verdad detrás y cuáles no.
- El más exigente: un desafío de escalada de privilegios en el sistema operativo, tomando el control de una máquina virtual de prueba desde un usuario sin permisos hasta llegar a administrador. Entendí y documenté en detalle la causa del problema y la estrategia de explotación, con todas las protecciones modernas del sistema activas. Terminar de construir el ataque funcional quedó como el desafío técnico más grande del certamen, y lo sigo trabajando por mi cuenta como parte de mi aprendizaje en esta área.
Un paréntesis: cómo reaccionan los asistentes de IA ante este tipo de retos
Durante el certamen usé herramientas de IA como apoyo para analizar código y organizar ideas, igual que las uso en mi trabajo diario de desarrollo. Algo que noté, sobre todo en el desafío de escalada de privilegios en el sistema operativo, es que varios asistentes de IA reaccionan con cautela ante este tipo de ejercicio: se detienen a mitad de camino, piden confirmar el contexto, o directamente evitan avanzar hacia la parte final de construir un ataque funcional, aunque uno les explique que se trata de un laboratorio cerrado y autorizado por los organizadores.
Tiene sentido que sea así. Una técnica para tomar control de un sistema es la misma, la use alguien en un entorno de práctica legítimo o alguien con malas intenciones contra un sistema real; el asistente no tiene forma de verificar por sí solo en qué situación está. Frente a esa ambigüedad, estas herramientas están diseñadas para priorizar la prudencia antes que la utilidad inmediata. Es una limitación razonable y, en mi opinión, correcta: prefiero una IA que se detenga de más a una que ayude a cualquiera a construir un exploit sin hacer preguntas.
Lo que me llevo
- La versatilidad es clave. Pasar de una falla de validación de datos, a una de red interna, a investigación de fuentes abiertas y a un problema de sistema operativo, en el mismo evento, entrena a cambiar de enfoque rápido.
- El reconocimiento gana a la fuerza bruta. En casi todos los desafíos, el avance real llegó cuando dejé de adivinar y me puse a observar con atención: el comportamiento del sistema, los mensajes de error, los detalles que a simple vista parecen irrelevantes.
- Los fundamentos importan, siempre. Validar lo que llega del usuario, no confiar ciegamente en destinos externos, controlar bien los accesos, cuidar los detalles técnicos en profundidad. Cada desafío era, en el fondo, un fundamento de seguridad mal aplicado en el entorno de prueba, y esos mismos fundamentos son los que aplico al construir sitios para clientes reales.
- La ética enmarca todo. Entornos controlados, propósito formativo, y hasta detectar y reportar una trampa dirigida a asistentes de IA en vez de caer en ella.
Agradezco a la ANCI y a Hackrocks por la organización y la variedad de los ejercicios, y a mis compañeros de equipo en Rhemati por la experiencia compartida. Me queda el impulso de seguir profundizando en seguridad ofensiva, además de aplicarlo en cada proyecto que desarrollo.
Si te interesa que revise la seguridad de tu sitio o tu infraestructura, conversemos.