CTC-1002: Antrhopic bloquea un Agentic AI creado sobre Claude hecho por ciberatacantes que hackea organizaciones completamente autónomo

Durante este año hemos ido viendo cómo el mundo de tener Agentic AI para explotación completa de organizaciones era algo que se estaba desarrollando a toda velocidad. Este año he ido siguiendo este proceso poco a poco, por medio de la publicación de un trabajo de investigación tras otro. Al mismo tiempo, los reportes de OpenAI sobre los usos maliciosos de sus productos nos han enseñado cómo iban utilizándose la IA de forma autónoma para campañas de fraude, desinformación, y fases de la intrusión de sistemas. 

Figura 1:  CTC-1002: Antrhopic bloquea un Agentic AI creado

sobre Claude hecho por ciberatacantes que hackea

organizaciones completamente autónomo

Ahora Anthropic, que ya publicó en Agosto cómo los ciber-bad-actors estaban utilizando sus capacidades en forma de Vibe Coding para atacar organizaciones, nos presenta en su último informe de hace apenas unos días llamado "Disrupting the first reported AI-orchestrated cyber espionage campaign" cómo un grupo al que ha llamado CTC-1002 ha hecho el uso de las capacidades de Agentic AI para la explotación a escala de organizaciones con una arquitectura totalmente automatizada.

GTG-1002 represents multiple firsts in AI-enabled threat actor capabilities. The actor achieved what we believe is the first documented case of a cyberattack largely executed without human intervention at scale—the AI autonomously discovered vulnerabilities in targets selected by human operators and successfully exploited them in live operations, then performed a wide range of post-exploitation activities from analysis, lateral movement, privilege escalation, data access, to data exfiltration. Most significantly, this 2 marks the first documented case of agentic AI successfully obtaining access to confirmed high-value targets for intelligence collection, including major technology corporations and government agencies.

Que traducido al español para los que prefieren esta lengua dice:

GTG-1002 representa varios hitos pioneros en las capacidades de actores de amenazas potenciados por inteligencia artificial. El actor logró lo que se considera el primer caso documentado de un ciberataque ejecutado en gran medida sin intervención humana y a escala: la IA descubrió de forma autónoma vulnerabilidades en objetivos seleccionados por operadores humanos y las explotó con éxito en operaciones reales. Posteriormente, realizó una amplia gama de actividades de post-explotación, incluyendo análisis, movimiento lateral, escalado de privilegios, acceso a datos y exfiltración de información. Lo más significativo es que este caso marca la primera instancia documentada de una Agente AI que obtuvo con éxito acceso a objetivos confirmados de alto valor para la recopilación de inteligencia, entre ellos grandes corporaciones tecnológicas y agencias gubernamentales.

No es nada que no nos experabamos tras ver los trabajos de Incalmo, de Cybersecurity AI, de explotación autónoma de Web Sites o creación automática de exploits de escalación de privilegios para Linux, como ejemplo, de los que os he ido contando cosas, y que merece la pena que te los leas para entender mejor dónde estamos hoy.

• LLM as Hackers: Autonomus Linux Privilege Escalation Attacks con Agentes AI
• Vibe Hacking con Cybersecurity AI (CAI): Agentes AI autónomos para ciberseguridad ofensiva y defensiva
• ¿Se puede reemplazar a un Pentester con un Agente de IA basado en LLMs? Cómo realizar ataques completos a redes complejas con agentes de Inteligencia Artificial
• LLM Agents can autonomouslly hack websites
• LLM Agents can Autonomously Exploit One-day Vulnerabilities
• LLMs as Hackers: Autonomous Linux Privilege Escalation Attacks
• On the Feasibility of Using LLMs toExecute Multistage Network Attacks

El informe completo, que lo puedes y lo deberías leer, está en el siguiente enlace donde puedes ver que es apenas de 10 páginas donde resumen cuál es la arquitectura del Agentic AI construido para colarse de manera automática dentro de organizaciones.

Figura 2: Disrupting the first reported AI-orchestrated cyber espionage campaign

En la arquitectura se puede ver cómo hay un Operador Humano que es el que controla al Agentic AI. Este con una arquitectura similar a la descrita por Incalmo o Cybersecurity AI, cuenta con un conjunto de MCPs que le ofrecen herramientas para todas las fases del ataque, desde la fase de reconocimiento, de descubrimiento de vulnerabilidades, de creación de exploits - con una herramienta de validación de exploits externa - de explotación de las vulnerabilidades, de elevación de privilegios, y movimientos laterales dentro de la organización. Vamos, un ataque completo.

Figura 3: Arquitectura del Agentic AI de CTC-1002

Clic en la imagen para verla en grande

Para cada una de esas fases hay diseñado un flujo en el que hay una cierta interacción con un Operador Humano que va validando los resultados, con herramientas vía MCPs, con búsqueda de información en la web, o con la validación mediante otro modelo LLM que revisa que lo que se está haciendo es correcto. En la imagen siguiente tenéis los flujos de las diferentes fases muy bien descritos.

Figura 4: Flujos de las fases de explotación.

Clic en la imagen para verla en grande

Para entender mejor el flujo de estas fases, en el documento tienes algunos ejemplos de qué es lo que ha ido haciendo el Agentic AI en algunas situaciones. Por ejemplo, en esta tabla se ven las tareas del Agente IA para descubrir una vulnerabilidad de Server-Side Request Forgery en el backend de un Web Server, cómo generar un exploit con un payload personalizado, y solicita la revisión del Operador Humano.

Figura 5: Descubrimiento, validación y explotación de una vulnerabilidad

SSRF en un Web Server.

Una vez que el Operador Humano aprueba la explotación, entonces ejecuta el exploit y realiza una serie de tareas de post-explotación para completar el proceso y continuar el proceso sobre los nuevos activos descubiertos.

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

En el siguiente ejemplo se ve el flujo de extracción de información de una base de datos a partir de credenciales recolectadas en el proceso de explotación de la organización. En él se puede ver cómo hace un mapa de la base de datos, extrae los hashes de las cuentas de la base de datos, identifica las más privilegiadas, crea una cuenta para tener persistencia en la base de datos, se descarga los datos, y los analiza para generar un informe final de inteligencia que es exfiltrado cuando el Operador Humano lo aprueba.

Figura 7: Exflitración de datos de una base de datos.

El trabajo es técnicamente perfecto, y sí, Anthropic dice que ha trabajado para acabar con las operaciones de este grupo, pero las capacidades de crear estos agentes, esta arquitectura, y estas herramientas ya existen, se conocen, están en el mercado, y han subido el nivel de las capacidades de los atacantes. Será con Claude, con GPT5.1 o con Llama 5, pero tienen estas capacidades a su alcance. Tienen el Railgun disponible, así que más vale que si trabajas como CISO te tomes en serio estas nuevas amenzas.

Figura 8: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Como decía ayer, los equipos de Red Team, de Blue Team y los Ciberatacantes han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Nuevo Libro: "Hacking Web Applications: Client-Side Attacks" de @0xWord

Ayer ya se puso a la venta el nuevo libro de 0xWord, titulado "Hacking Web Applications: Client-Side Attacks" y escrito por el gran Enrique Rando, que ya tiene en su haber la participación en los libros de "Hacking con Buscadores", "Hacking Web Applications: SQL Injection" y "Hacking Web Technologies", además de decenas de artículos escritos por aquí.

Figura 1: Nuevo libro de 0xWord "Hacking Web Applications: Client-Side Attacks"

El texto se centra en algo fundamental en los test de intrusión, como son los Client-Side Attacks, y que tantas veces hemos visto como primera fase de un APT de muchos de los grandes incidentes de seguridad que llegan a los medios de comunicación.

Figura 2: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

En palabras del propio autor, el libro tiene la siguiente descripción:

"Usuarios, navegadores y aplicaciones web. Cada cual con sus propios problemas, formando un curioso triángulo. Personas que, como suele decirse, son el eslabón más débil de la ya de por sí frágil cadena de la seguridad. Navegadores cuya complejidad, siempre en aumento, los convierte en poco menos que nuevos sistemas operativos con fallos y características susceptibles de ser usadas con fines ilegítimos. Y programas que, de forma casi inevitable, presentan fallos. 

Por si fuera preciso empeorar las cosas, todo esto ocurre no en el Centro de Proceso de Datos, donde todo es más fácil de gestionar, sino en los puestos de usuario. Lejos del confortable control del personal informático, quizá a cientos de kilómetros gracias a la conectividad que Internet proporciona. Lejos del servidor de aplicaciones, sí, pero interactuando con la parte cliente de éstas. Lejos del servidor de bases de datos, pero cerca, muy cerca, de los datos y de la gestión que de ellos se realiza. 

Este escenario presenta sus propias vulnerabilidades y sus ataques característicos. Quizá los más conocidos sean los de Cross Site Scripting, sobre los que tanto se ha hablado y cuyas repercusiones no siempre se ha sabido explicar. Pero hay otros, menos populares pero igual de devastadores, como Cross Site Request Forgery o Clickjacking. O técnicas como las de Typosquatting, abuso de nombres de dominio internacionalizados o Tabnabbing. O manipulaciones de la interfaz de usuario de los navegadores y de las características, cada vez más avanzadas, que éstos ofrecen gracias a las APIs asociadas a HTML 5. O prácticas habituales en el desarrollo de aplicaciones web que pueden tener consecuencias inesperadas. 

Este libro trata de esos “enemigos olvidados”, presentándolos a través una serie de pruebas de concepto que ponen en evidencia no sólo lo fácil que puede llegar a ser explotarlos sino también cuán graves que pueden ser sus efectos."

Pero para que veas los detalles completos, tienes el índice del libro subido a SlideShare.

Figura 3: Índice el Libro "Hacking Web Applications: Client-Side Attacks"

Éste es el libro número 50 de 0xWord, un hito para nosotros, así que probablemente hagamos algún acto en Madrid (o en Móstoles) para celebrarlo, en el que podáis estar con muchos de los escritores para compartir experiencias y charlas.

Saludos Malignos!

Cómo usar una "debilidad" de SSRF en Microsoft.com para hacer una PoC de SQL Injection

Durante este verano hemos estado muy activos reportando algunas vulnerabilidades descubiertas por el motor de Faast en algunas empresas tecnológicas. Utilizando la visión del Pentesting Persistente que marca nuestra forma de ver cómo se debe abordar la seguridad de los sistemas expuestos a Internet de las empresas, en entornos hacking friendly hemos estado reportando un buen número de bugs que están corrigiendo.

Figura 1: Cómo usar una "debilidad" de SSRF en Microsoft.com para hacer una PoC de SQL Injection

Hoy os vengo a hablar de uno de estos reportes que no ha sido tomado como un bug de seguridad, y que por tanto no va a ser modificado, para que veáis cómo funciona esto. Se trata de un Server-Side Request Forgery en una web pública de Microsoft.com. Los SSRF son "debilidades" de las aplicaciones web que permiten a un atacante inyectar una URL en el sistema que fuerza al servidor de backend a hacer una petición a un servidor controlado por el atacante, tal y como se describe en el CWE (Common Weaknesses Enumeration) del Mitre que tenéis a continuación. Dependiendo del entorno, esta debilidad se puede convertir en un "bug" o no.

Figura 2: Descripción de las debilidades Server-Side Request Forgery (SSRF)

Este tipo de "debilidades" pueden ser utilizados en muchos entornos para conseguir otros objetivos como se explica en el libro de Hacking Web Technologies donde hablamos de ella. Desde hacer un escaneo de puertos de un servidor de forma anónima con un XSPA (Cross-Site Port Attack) hasta atacar un servidor con un SQL Injection. El peligro además es que, como el que realiza la petición es un servidor de la organización, este podría ser utilizado para hacer los ataques de XSPA o SQLi a servidores internos de la DMZ, como se explica en este artículo que os dejé publicado hace poco más de un año "Cómo usar un SSRF para hacer un XSPA a un servidor de la DMZ".

SSRF en Microsoft.com

En el caso de Microsoft el SSRF se encuentra en una URL pública, accesible por cualquiera desde Internet, que se utiliza para acceder a un Feed RSS. Éste es un entorno clásico para localizar este tipo de debilidades, tal y como se describía en el artículo de "Utilizar los Buscadores como arma de destrucción masiva" y en una web corporativa como la de Microsoft.com tal vez no debería estar público. Sin embargo, es verdad que algunos sistemas necesitan que esto funcione así y si ellos han determinado que no es un problema será que lo tienen controlado y no existe riesgo alguno en que esté público.

Figura 3: Confirmación de que el MSRC lo ha investigado y no hay riesgo

Sea como fuere, ya que en el artículo de hace un año nuestro compañero Ricardo usó el SSRF para hacer un XSPA, ayer le pedí a otro compañero de ElevenPaths - en este caso al gran Ioseba Palop que está cuidando el core de Faast con mimo y ternura desde hace años - que preparase una PoC con un SQL Injection, para que se viera cómo funciona esto, y lo tenéis en el siguiente vídeo.

Figura 4: Ataque SQLi a un servidor web vía SSRF en Microsoft.com

La demo es muy sencilla, hemos dejado una web vulnerable a un SQL Injection que permite hacer un Shutdown, es decir, hemos dejado corriendo el servidor SQL Server con privilegios de administrador a propósito, para hacer que el servidor de Microsoft.com, a través del SSRF, apague el motor de bases de datos desde Internet.

Esto es algo así como cuando Leonard, Koothrappali, Sheldon y Wolovich apagan y encienden las luces del salón a través de Internet solo por ver que se puede hacer, pero si ese servidor fuera uno interno en la DMZ de Microsoft, probablemente funcionaria igualmente. Sí, están todos menos Penny.

Figura 5: Todos menos Penny felices por encender las luces desde Internet

Este tipo de debilidades son importantes en muchos entornos, por eso nosotros prestamos mucha atención a todas ellas en nuestra knowledge base, pero a veces los equipos de seguridad las evalúan y deciden que el riesgo es bajo y no deben aplicar ninguna medida correctora más allá de las que tienen, como en el caso del HTTP Parameter Pollution de Apple.com, donde no implicaba riesgos de seguridad a pesar de existir la debilidad en la aplicación web.

Saludos Malignos!

Time-Based XSPA (Cross-Site Port Attack) en DBKISS

No hace demasiados días os hablé de un bug de Time-Based XSPA en los scripts de instalación de WordPress, y hoy os quiero hablar de otro caso similar con un WebGUI para administrar motores de bases de datos MySQL y PostgreSQL que se llama DBKiss. Es un bug curioso que en este caso se explota bien con el driver de PostgreSQL. Os lo explico en este post.

Figura 1: Time-Based XSPA (Cross-Site Port Attack) en DBKiss

Los bugs de XPSA (Cross-Site Port Attack) se basan en la explotación de un SSRF (Server-Side Request Forgery) mediante la que un atacante fuerza a la aplicación a realizar una determinada conexión a un servicio que se encuentra en un servidor corriendo por un puerto para poder así escanear los puertos de un servidor objetivo. En este caso, aprovechándonos de que la aplicación vulnerable es un WebGUI que muchos usuarios implanta en sus sitios web para gestionar la base de datos MySQL de WordPress o de cualquier otro CMS, basta con manipular los datos de la cadena de conexión.

Figura 2: Un DBKiss gestionando el MySQL de un WordPress

Hay que tener cuidado con publicar estos scripts a la ligera, pues muchas veces son herramientas en proceso de desarrollo o con vulnerabilidades conocidas. Basta con ver el código fuente de DBKiss para darse cuenta de que aún le quedan muchas cosas que corregir a esta herramienta antes de poder instalarse y publicarse a Internet, ya que se estarían asumiendo muchos riesgos.

Figura 3: Cosas aún por solucionar en los comentarios de DKiss (XSS y CSRF)

El peligro de poner estos scripts vulnerables a estas técnicas de XSPA es que el servidor objetivo al que se quiere escanear puede estar dentro de la DMZ, es decir, con direccionamiento en la red local, ya que basta con que el servidor web tenga conectividad con ellos. Con un aplicación web vulnerable a XSPA en un servidor de la DMZ, un atacante podría hacer un mapa detallado de todos los servidores y todos los puertos que estos tienen abiertos.

Time-Based XSPA en DBKiss

En el caso de los ataques de Time-Based XSPA, el atacante mide el tiempo de respuesta de cada conexión para saber si es un resultado que indica que el puerto está abierto, o un un resultado que indica que el puerto está cerrado. Para esto, en las cadenas de conexión a bases de datos el bug se aprovecha de que la configuración de la conexión no tenga un Time-Out bien configurado que evite que el atacante pueda medir las diferencias temporales en las respuestas sin error.

Figura 4: Con la conexión al puerto 80 usando el driver de PostgreSQL el tiempo de respuesta es corto

Como se puede ver, si forzamos una conexión con DBKiss contra un servidor con un puerto abierto, en este caso contra el puerto 80 de la web de Eleven Paths utilizando el driver de PostgreSQL, podemos ver que se obtiene un tiempo de respuesta muy corto.

Figura 5: Con el puerto cerrado el tiempo de respuesta es muy alto y salta el Time-Out por defecto

Si hacemos lo mismo contra un puerto que esté cerrado, lo que pasamos a obtener es un tiempo de respuesta muy largo que llega a generar un Time-Out en la web, es decir, que el tiempo configurado por defecto de Time-Out en la conexión de la base de datos es mayor que el Time-Out configurado en el servidor web.

Figura 6: Hay que configurar el Time-Out en la conexión a PostgreSQL para evitar este leak

Al final, estas vulnerabilidades abren la captura de información de la infraestructura de una organización a un atacante que en un APT será de gran utilidad para poder planificar el siguiente paso del ataque. Cuidado con lo que publicas en tu servidor web.

Saludos Malignos!

Cómo explotar un SSRF (Server Side Request Forgery) y hacer un XSPA (Cross Site Port Attacks) a una DMZ

Las vulnerabilidades SSRF (Server Side Request Forgery) y los ataques de XSPA (Cross Site Port Attacks) son dos fallos de seguridad que van casi siempre de la mano. Los bugs de SSRF se producen en aplicaciones web inseguras que permiten a un atacante forzar al servidor web a realizar peticiones desde dentro del sistema hacia el exterior. Usando esas conexiones, los ataques de XSPA tratan de conocer, en base a las respuestas obtenidas, la lista de puertos que se encuentran abiertos o por el contrario cerrados en el servidor al que se fuerza la conexión.

Figura 1: Cómo explotar un SSRF y hacer un XSPA a una DMZ

Es importante tener claro que estas vulnerabilidades afectan al Back-End y que vienen conducidas por una mala validación en el Front-End o API al poder ser manipuladas las direcciones a las que se le van a realizar peticiones desde el Back-End. La principal ventaja para un atacante de que las peticiones sean realizadas desde dentro de la red en la que se encuentra el sistema vulnerable es que le van a permitir acceder a sitios que de otra manera no podría (pivoting), tal como sucede cuando estamos conectados a nuestro router y podemos acceder a las maquinas conectadas a nuestra red local.

SSRF & XSPA en buscadores y paneles de administración con CSPP 

Estos fallos son muy típicos, y ya los hemos visto en un buen número de sitios. En el artículo de Buscadores como arma de destrucción masiva se hablaba de posibles ataques de SSRF utilizando la indexación maliciosa o los agregadores de noticias, que permitían por ejemplo que un servidor lanzara un ataque de SQL Injection sin interacción alguna del atacante.

Figura 2: Ejemplo de utilización de un agregador de noticias para realizar ataques SSRF

Un caso curioso de SSRF son los paneles de administración expuestos en Internet, como sitios de configuración de impresoras HP que permiten escanear la DMZ completa, o los casos de bugs de Connection String Parameter Polution, tanto de bases de datos MySQL como de tecnologías .NET. Con ellos hemos visto lo fácil que es realizar ataques de XSPA (Cross Site Port Attacks) aprovechando estas vulnerabilidades de SSRF o CSPP, como en el caso de las herramietnas MyLittleAdmin.

Figura  3: XSPA en MyLittleAdmin for SQL Server

Como se ve, aprovechando la ventaja de que sea el Back-End el encargado de realizar peticiones internamente y que estas a su vez puedan ser manipuladas, permitiría a un atacante apuntar a direcciones IP internas y ya sea visualizando la respuesta o en base a tiempos dibujar un mapa de los activos de la red interna o conocer los puertos abiertos. A continuación les dejo una serie de enlaces donde se documenta cómo explotaron este fallo en sitios de Yahoo!, Facebook o Coinbase, por poner solo algunos ejemplos:

• Yahoo! SSRF/XSPA Vulnerability
• XSPA / SSRF bug with Facebook's Developer Web Application
• SSRF/XSPA Bug in Coinbase

SSRF/XSSA usando ScreenShots

El siguiente caso que les traigo me pareció interesante, vendría a ser algo así como SSRF/XSSA aprovechando un sistema implementado para hacer ScreenShots en aplicaciones web. Esto es algo similar a lo que se publicó por aquí en el artículo de "Jugando con los ojos", donde aprovechando un sistema de captura de pantallas en distintos navegadores se hacían ataques a terceros servidores.

En este caso se trata de una aplicación web hecha en ruby on rails que a través de un sencilla interfaz web, recibe una URL o dominio que luego es enviada a un servicio externo que consulta en su base de datos quién es el propietario del dominio - lo que viene a ser un Whois -. Una vez el servicio Whois devuelve una respuesta a la aplicación web, ésta - además de imprimir dichos datos a través del navegador- seguidamente realizará una captura de pantalla levantando un navegador que visitará la misma dirección.

Figura 4: Funcionamiento normal de la web con el screenshot de Google

Como se puede ver en el navegador aparece en la parte inferior derecha una imagen de la página principal de google.com, al inspeccionar el elemento se puede comprobar que el nombre de la imagen parece ser un Hash MD5 por los 32 caracteres de longitud, que efectivamente corresponde a la concatenación del dominio más un slash tal que así google.com/.

Figura 5: Nombre de la imagen vinculada al screenshot

Escaneando la DMZ interna

Entonces, recordando la ventaja que supone que sea el servidor web el encargado de realizar la petición, por su conectividad con el resto de máquinas de su red interna, se podría realizar un escaneo completo de la DMZ. Para ello sería cuestión de ir probando a enviar por el parámetro uri, diferentes direcciones IP locales con la esperanza de obtener capturas de pantalla de máquinas de la red interna que tengan corriendo en el puerto 80 aplicaciones con interfaz web. Para ello bata con lanzar varias peticiones enviado varias direcciones IP locales, desde la 192.168.0.1 a la 192.168.0.24, y una vez el servicio externo hubiese procesado la dirección IP y devuelto la respuesta, se realizaría la captura de pantalla contra el servidor web en dicha dirección IP.

Figura 6: Resultados del escaneo completo de la DMZ

Ya por último teniendo un listado de las rutas a las imágenes que contiene las capturas realizadas, bastaría con acceder a cada una de ellas para comprobar si contenían algo interesante o simplemente estaban en blanco.

Figura 7: Resultados obtenidos con Burp

Después de realizar peticiones e intentar acceder a cada uno los enlaces con las imágenes, pude ver que algunas tenían un peso mayor que otras, dando a entender que algunas capturas realizadas contra algunas direcciones IP locales SÍ contenían información,  y por lo consiguiente alguna aplicación web corriendo sobre la máquina con dicha dirección IP. Ordene el listado de las imágenes por peso y fui visualizando cada una de ellas, algunas contenían información muy sensible y otras simplemente el típico banner de un servidor Apache.

Nota de reflexión final

Por supuesto, este tipo de vulnerabilidades son muy peligrosas, ya que desde el servidor no solo se puede hacer el escaneo de puertos, sino que se pueden hacer ataques de SQL Injection a servidores internos, Heartbleed o ShellShock, por poner algunos casos, así que hay que tener mucho cuidado con ellas.

Autor: Ricardo Martín (@ricardo090489)
Security QA Engineer en Eleven Paths