Practica CTF con un coach de IA que explica en lugar de negarse

Los retos Capture the Flag son donde la mayoría de la gente de seguridad aprende el oficio. La forma más rápida de mejorar es tener un coach paciente que sepa cuándo dar una pista y cuándo callarse. Los asistentes convencionales son malos coaches para esto: pregunta cómo funciona un padding oracle en una máquina de CTF y a menudo recibirás un sermón sobre el acceso no autorizado en lugar de una explicación. Odin v1 responde a la pregunta, así que puedes dedicar tu tiempo a aprender en lugar de a reformular.

En este artículo te mostramos un flujo de trabajo para usar Odin v1 como coach en plataformas de CTF y laboratorios de práctica como picoCTF, Hack The Box, TryHackMe o tu propio laboratorio en Docker. Todo lo que verás aquí se aplica a objetivos que tienes permiso para atacar: la infraestructura del reto, un laboratorio que has montado tú o una máquina dentro del alcance de un evento. Nada cambia esa regla.

Por qué un coach es mejor que un solucionador

Podrías pegar un reto y pedir la flag. Pero no aprenderías nada y, en muchas plataformas, compartir o pedir soluciones de retos activos va contra las normas. El valor de un CTF está en el razonamiento que construyes: fijarte en la cabecera rara, reconocer un cifrado débil, saber qué herramienta usar. Un buen coach protege eso.

Por eso la configuración que verás a continuación hace dos cosas:

• Le indica al modelo que enseñe, no que resuelva, salvo que pidas explícitamente la respuesta completa.
• Estructura la ayuda como una escalera, desde un empujoncito hasta una explicación completa, para que tú elijas cuánto quieres desvelar.

La escalera de pistas

Acordad los niveles desde el principio. El modelo responde entonces al nivel que pidas y nunca se adelanta.

El nivel 4 es para después del evento o para máquinas retiradas. Durante una competición en directo, quédate entre el 1 y el 3 y respeta las normas del evento sobre la ayuda externa.

Un system prompt para el coaching

Pon las reglas en un system prompt para que todas las respuestas las sigan. Funciona con cualquier cliente compatible con OpenAI:

import osfrom openai import OpenAI
client = OpenAI(base_url="https://api.interodin.com/v1", api_key=os.environ["INTERODIN_API_KEY"])
COACH = """You are a CTF coach. The user works on legal practice targets: CTF challenges and their own labs.Answer at the hint level the user asks for (1 nudge, 2 concept, 3 method, 4 walkthrough).Never go above the requested level. If no level is given, use level 1.Explain the reasoning behind every hint, and suggest one thing the user can try next and what result would confirm it."""
history = [{"role": "system", "content": COACH}]
def ask(level: int, text: str) -> str:    history.append({"role": "user", "content": f"[level {level}] {text}"})    resp = client.chat.completions.create(model="odin-v1", messages=history)    answer = resp.choices[0].message.content    history.append({"role": "assistant", "content": answer})    return answer
print(ask(1, "Web challenge: a login form. Wrong passwords say 'invalid', but a quote in the username gives a 500 error."))

Al conservar el historial, el coach recuerda lo que ya has probado, así que la siguiente pista parte de ahí en lugar de repetir lo básico.

Retos web

La web es donde empieza la mayoría. Un intercambio típico en un reto de login para principiantes es así:

• Nivel 1: el coach te pregunta por qué una comilla simple cambiaría el comportamiento del servidor y qué tipo de código convierte la entrada del usuario en algo que se rompe con una comilla.
• Nivel 2: nombra la clase, inyección SQL, y explica cómo las consultas sin parametrizar mezclan datos y código.
• Nivel 3: describe cómo confirmarla de forma segura en un laboratorio: comparar las respuestas para condiciones verdaderas y falsas, averiguar el número de columnas e identificar después el motor de base de datos a partir de los mensajes de error o del comportamiento.

Pídele también que te explique la corrección. Poner por escrito por qué una consulta parametrizada cierra el agujero convierte una flag en conocimiento que puedes usar en una revisión de código el lunes.

Otros temas web en los que Odin v1 explica bien: server-side request forgery, deserialización insegura, errores con JWT (confusión de alg, secretos débiles), path traversal e inyección de plantillas. En cada caso, preguntar "¿cómo lo detectaría en mis propios logs?" es un buen seguimiento. El artículo sobre reglas de detección profundiza en ello.

Retos de criptografía

La cripto en los CTF consiste sobre todo en detectar el error: un nonce reutilizado, un exponente pequeño, el modo ECB, un cifrado casero. Pega el código del reto y la salida, y ve subiendo por la escalera.

Buenos prompts:

• "Nivel 2: aquí tienes el script de cifrado. ¿Qué propiedad de esta construcción debería hacerme sospechar?"
• "Nivel 3: creo que el exponente RSA es pequeño y el mensaje es corto. Explícame paso a paso por qué importa y cómo comprobarlo."
• "Explica las matemáticas de este ataque con un ejemplo de juguete que pueda verificar a mano."

El último es el más valioso. Pide números pequeños, compruébalos en una consola de Python y entenderás el ataque para siempre.

Reversing

Para reversing, pega el desensamblado o la salida del decompilador (Odin acepta texto, no binarios ni capturas de pantalla). Peticiones útiles:

• "Explica qué hace esta función, línea a línea, y renombra las variables con nombres que tengan sentido."
• "¿Qué comparación decide si la entrada se acepta?"
• "Este bucle parece un hash propio. ¿Qué necesitaría para invertirlo?"

Con una ventana de contexto de 1.000.000 tokens, odin-v1 puede recibir un listado decompilado grande en un solo mensaje, así que sigue las llamadas entre funciones en lugar de adivinar a partir de un fragmento.

Forense

Los retos de forense te dan una captura de paquetes, una imagen de memoria o una imagen de disco. Odin no puede abrir esos archivos directamente, pero lee muy bien la salida de las herramientas. Ejecuta tú las herramientas y pega el texto:

• resúmenes de conversaciones de tshark o listas de objetos HTTP
• listas de procesos y líneas de comandos de volatility
• salida de strings, metadatos de archivos, entradas de la línea de tiempo

Después pregunta "nivel 1: ¿qué te llama la atención aquí?". Te señalará el proceso padre extraño, el blob en base64 dentro de una consulta DNS o el user agent que no encaja. Para profundizar en el triage de scripts sospechosos, consulta el artículo sobre análisis de malware.

Redactar el writeup

El writeup es donde se fija lo aprendido, y es una buena práctica para los informes del futuro. Cuando resuelvas un reto, dale tus notas a Odin y pídele un borrador de writeup con estas secciones: resumen, reconocimiento, la vulnerabilidad, pasos de explotación, la flag (censurada si el evento lo pide) y cómo corregirlo. Después edítalo con tus propias palabras.

La misma habilidad se traslada directamente al trabajo profesional. El artículo sobre redacción de informes de pentest muestra cómo convertir las notas de un encargo en un informe listo para el cliente.

Consejos prácticos

• Usa odin-flash para preguntas rápidas. Consultas como "¿qué hace este filtro de tshark?" no necesitan el modelo grande. Cambia a odin-v1 para código largo o razonamientos de varios pasos.
• Pon un límite de gasto mensual a la clave que uses para practicar, para que un fin de semana largo de laboratorios nunca te dé un susto.
• Lleva un archivo de notas. Pega tus notas al principio de cada sesión nueva para que el coach empiece donde lo dejaste.
• Verifícalo todo. El modelo puede equivocarse. Confirma cada pista contra el objetivo antes de construir sobre ella.

Empieza ya

Crea una clave de API en la consola y sigue la guía de inicio rápido para enviar tu primera petición. Practica en plataformas de CTF y en tus propios laboratorios, sigue las normas del evento y mantente dentro de la Política de Uso Aceptable.