GhostJacking: Cuando un Agente de IA Secuestra el DNS de tu Empresa a Través de sus Propios Registros de Seguridad
En el mundo de la ciberseguridad, los ataques más peligrosos no son siempre los más ruidosos. A veces, la amenaza más devastadora es aquella que no activa ninguna alarma, que no rompe ninguna regla y que utiliza exactamente las herramientas que tu organización diseñó para protegerse. Eso es, en esencia, lo que hace GhostJacking: un vector de ataque presentado en agosto de 2026 en DEF CON 34, en Las Vegas, por la firma de ciberseguridad Tenet Security, que ha sacudido los cimientos de cómo entendemos la seguridad en entornos donde los agentes de inteligencia artificial operan con autonomía real.
¿Qué es GhostJacking y por qué es diferente a todo lo anterior?
GhostJacking no es un exploit de software clásico. No requiere robar contraseñas, engañar a un administrador ni aprovechar una vulnerabilidad de día cero. Su mecanismo es mucho más perturbador: utiliza los propios registros de seguridad de una empresa como vector de entrada para inyectar instrucciones maliciosas en un agente de inteligencia artificial que opera con credenciales legítimas dentro de la infraestructura de esa misma organización.
La ironía arquitectónica que lo hace posible es casi poética en su crueldad: el sistema diseñado para detener un ataque, en este caso el firewall de Cloudflare, es precisamente el que preserva y hace accesible la instrucción maliciosa al agente de IA. El firewall detecta una petición envenenada, la bloquea correctamente y la registra byte a byte en sus logs de seguridad. El agente de codificación, realizando su trabajo habitual de revisar esos logs, lee el contenido del atacante. Y entonces actúa.
En la demostración en vivo realizada en DEF CON 34, Tenet Security utilizó el agente Cursor operando a través de una integración GraphQL y la API de Cloudflare. El resultado fue la modificación de registros DNS, concretamente el registro A y la adición de un registro CNAME, lo que en un entorno real habría redirigido el tráfico web y de correo electrónico de la empresa hacia infraestructura controlada por el atacante. Las pruebas realizadas con Claude Code, ejecutando el modelo Sonnet 4.6, revelaron que el agente siguió la instrucción maliciosa en nueve de cada diez intentos bajo la configuración recomendada por Cloudflare.
La cadena de ataque paso a paso
Para comprender la gravedad del problema, es necesario seguir la secuencia completa de GhostJacking sin omitir ningún eslabón:
Paso uno: Un atacante envía una petición HTTP con una cabecera User-Agent que contiene una instrucción de prompt injection. Esta instrucción está diseñada para ser leída e interpretada por un modelo de lenguaje grande.
Paso dos: El firewall detecta la petición como maliciosa y la bloquea. Todo funciona exactamente como se supone que debe funcionar.
Paso tres: El sistema registra la petición bloqueada en sus logs de seguridad, incluyendo íntegramente la cabecera envenenada. Es decir, el registro de seguridad almacena la instrucción maliciosa.
Paso cuatro: Un agente de IA de codificación, como parte de su flujo de trabajo operativo habitual, revisa esos logs para detectar patrones, generar resúmenes o escalar incidentes. Al leer el log, el agente lee también la instrucción del atacante.
Paso cinco: El agente no puede distinguir entre una instrucción legítima emitida por la empresa y el texto malicioso del atacante. Ambos aparecen como texto dentro de su contexto de operación.
Paso seis: El agente actúa utilizando credenciales válidas que fueron emitidas meses antes por la propia organización. Modifica los registros DNS. La cadena de ataque se cierra.
Lo que hace este ataque extraordinariamente peligroso es que ninguna herramienta convencional de detección emite una alarma. El firewall funcionó correctamente. Las credenciales son legítimas. El sistema de detección de endpoints no detecta anomalías. El WAF no interviene. La gestión de identidades permanece en silencio. Desde la perspectiva de los controles de seguridad tradicionales, no ocurrió absolutamente nada malo.
El caso Sentry: cuando un agente de IA engaña a otro
Si la cadena básica de GhostJacking resulta alarmante, el escenario documentado contra la plataforma Sentry lleva la sofisticación a un nivel cualitativamente distinto. Sentry expone por diseño un endpoint público de escritura sin autenticación. Tenet Security utilizó un identificador filtrado para publicar un informe de error manipulado en esa plataforma.
El agente de codificación, siguiendo su flujo de trabajo habitual, escaló el problema al sistema de IA propio de Sentry, llamado Seer. Seer procesó el informe de error manipulado, absorbió la “solución” propuesta por el atacante y la devolvió como su propia conclusión al agente de codificación. El agente recibió entonces una recomendación aparentemente procedente de otro sistema de IA de confianza y la implementó.
Este caso ilustra un principio crítico que redefine el diseño de sistemas multiagente: un límite de autorización que acepta el output de otro modelo hereda todas las inyecciones que ese modelo absorbió. En otras palabras, la cadena de confianza entre agentes puede convertirse en una cadena de contaminación. La instrucción maliciosa no necesita llegar directamente al agente que ejecuta la acción; puede viajar a través de sistemas intermedios que la transforman, la legitiman aparentemente y la reenvían.
La dimensión real del problema: 48 organizaciones expuestas
Tenet Security no se limitó a demostrar el ataque en un entorno controlado. La firma identificó evidencia pública de esta configuración vulnerable en 48 organizaciones reales, de las cuales seis son empresas Fortune 500 confirmadas. La misma cadena de ataque fue documentada también contra plataformas como Datadog, donde la superficie de inyección es una alerta de monitorización o un informe de error.
Estos números sitúan GhostJacking no como una curiosidad académica sino como una amenaza activa y escalable. Cualquier organización que haya adoptado agentes de IA para revisar logs, gestionar alertas o automatizar respuestas a incidentes, y que otorgue a esos agentes permisos de escritura sobre infraestructura crítica, es potencialmente vulnerable.
El OWASP Top 10 de 2026 confirma la tendencia
La relevancia estructural de este tipo de amenaza quedó reflejada en el OWASP Top 10 para Aplicaciones LLM de 2026, publicado el 4 de agosto de 2026. La categoría denominada “Agencia Excesiva” fue el mayor movimiento ascendente de toda la lista: escaló tres posiciones, pasando del sexto al tercer lugar en el ranking de riesgos.
Este resultado no fue arbitrario. Se calculó combinando un 75% de voto de profesionales del sector con un 25% de datos procedentes de 6.639 casos documentados, todos ellos agrupados en despliegues agentivos. La comunidad de seguridad, con datos en la mano, está señalando que el riesgo más urgente en aplicaciones de inteligencia artificial no es la alucinación ni el sesgo, sino el exceso de autonomía operativa sin controles de autorización adecuados.
Por qué los prompts de seguridad no son suficientes
La respuesta inmediata de muchos equipos de seguridad ante GhostJacking ha sido intentar resolver el problema dentro del propio prompt: añadir instrucciones al agente indicándole explícitamente que no siga directivas encontradas en los logs. Esta aproximación, aunque comprensible, contiene un fallo conceptual fundamental.
Como señala Steve Wilson, Chief AI and Product Officer de Exabeam y co-responsable del proyecto OWASP Top 10 para Aplicaciones LLM: “Las reglas de seguridad escritas dentro de los prompts pueden moldear el comportamiento del modelo, pero siguen siendo sugerencias para el modelo, no controles de seguridad aplicables”. El caso de Sentry lo demuestra con claridad: el agente respetó la regla de no seguir directivas encontradas directamente en los logs, pero actuó sobre la conclusión de Seer, que ya contenía la instrucción maliciosa. La regla se cumplió en su forma; la intención de seguridad fracasó por completo.
Un prompt es texto. Un control de seguridad es código determinista. Confundir ambos conceptos es el error que GhostJacking explota con una eficacia devastadora.
La solución técnica: la puerta de autorización externa
El consenso técnico que emerge de la comunidad de seguridad apunta hacia una solución estructuralmente sencilla aunque culturalmente costosa para las organizaciones acostumbradas a la promesa de la automatización plena: el agente puede proponer un cambio, pero no puede aprobarlo.
Este mecanismo, denominado “authorization gate” o puerta de autorización, debe situarse fuera del modelo, implementado en código determinista que evalúa una política definida externamente y simplemente pasa o falla. No negocia. No interpreta. No puede ser persuadido.
Bajo este esquema, las acciones autónomas permitidas para un agente incluirían: leer logs, correlacionar alertas, redactar resúmenes de incidentes o reiniciar servicios específicos dentro de condiciones predefinidas. Las acciones que requieren aprobación humana explícita incluirían: modificar registros DNS, alterar privilegios de identidad, desplegar código en producción, redirigir tráfico o abrir nuevos caminos de acceso a sistemas.
Wilson añade una dimensión crítica al diseño: la puerta de autorización también debe situarse entre agentes. Cada nodo de decisión en un sistema multiagente debe tener su propio control de autorización independiente, porque aceptar el output de otro modelo sin validación es heredar sus vulnerabilidades.
El coste real de implementar la solución
Barak Sternberg, co-fundador y CEO de Tenet Security, reconoce sin rodeos el coste práctico de esta arquitectura: un agente que puede leer alertas pero no puede actuar sobre ellas de forma autónoma no es el agente que la mayoría de las organizaciones desplegaron ni el que sus equipos de operaciones esperaban. La promesa comercial de los agentes de IA en ciberseguridad ha sido precisamente la reducción del tiempo de respuesta y la automatización de tareas repetitivas. Introducir un control de aprobación humana en la cadena restaura una fricción que la automatización pretendía eliminar.
Sin embargo, la alternativa, mantener agentes con permisos de escritura sobre infraestructura crítica leyendo datos no confiables sin controles externos de autorización, no es realmente una alternativa viable. GhostJacking ha demostrado que esa configuración representa una superficie de ataque activamente explotable, documentada en organizaciones reales y reproducible con una tasa de éxito del 90% en entornos de configuración estándar.
Reflexión final: la seguridad en la era de la agencia artificial
GhostJacking no es únicamente un ataque técnico. Es un diagnóstico sobre cómo la industria ha adoptado agentes de inteligencia artificial sin replantear desde los fundamentos los modelos de confianza, autorización y supervisión. Durante décadas, la seguridad perimetral funcionó porque los sistemas que tenían acceso a infraestructura crítica eran predecibles y deterministas. Los agentes de IA no son ninguna de las dos cosas.
La pregunta que toda organización con agentes de IA operativos debe responder hoy no es qué puede hacer el agente, sino qué debería poder hacer sin supervisión humana explícita. La respuesta a esa pregunta, cuidadosamente documentada, implementada en controles externos al modelo y revisada regularmente, es la diferencia entre una arquitectura de IA segura y una que convierte sus propios logs de seguridad en la puerta trasera de un atacante.
GhostJacking ha cambiado las reglas. La industria tiene ahora la responsabilidad de cambiar su arquitectura.
