Aviso para los propietarios de aplicaciones web: las vulnerabilidades más fáciles de explotar ahora lo son aún más

Este artículo forma parte de una serie en curso de los especialistas en operaciones de seguridad de primera línea de Sophos, en la que comparten los conocimientos que utilizan para reforzar nuestro servicio de Detección y Respuesta Gestionadas (MDR), líder en el sector, y defender a los clientes frente a las amenazas en constante evolución en la era de la IA.

El sector de la ciberseguridad lleva años preparándose para hacer frente a atacantes que automatizan el reconocimiento, el escaneo de vulnerabilidades y los ataques a credenciales. Lo que está cambiando ahora es el grado en que la automatización puede conectar esas actividades individuales en un flujo de trabajo de intrusión sostenido.

Las recientes investigaciones de Respuesta a Incidentes de Sophos ilustran este cambio. Los incidentes afectaron a organizaciones sin relación entre sí, de diferentes sectores, y los atacantes utilizaron distintas vías de acceso inicial. Sin embargo, los patrones operativos eran sorprendentemente similares: reconocimiento rápido, pruebas repetitivas, descubrimiento de credenciales, intentos de escalada de privilegios, movimiento lateral, validación del acceso a los datos, persistencia y limpieza sistemática.

Las pruebas apuntan al uso de sistemas compatibles con herramientas que funcionan a la velocidad de una máquina, probablemente asociadas al uso de un agente de IA o un marco de orquestación. No encontramos cadenas de agente de usuario ni firmas específicas que indicaran el uso de herramientas basadas en IA. Sin embargo, la velocidad, el alcance, la repetición y la adaptabilidad observadas en los incidentes demuestran por qué cada vez es más difícil distinguir entre un operador experto, la automatización mediante scripts y un atacante asistido por IA.

Y lo que es más importante, puede que pronto los defensores se den cuenta de que la distinción importa menos que el resultado.

De técnicas aisladas a un proceso de ataque de principio a fin

El análisis de seguridad tradicional suele examinar el comportamiento del atacante como un conjunto de técnicas individuales:

• Inyección SQL

• Implementación de web-shell

• Descubrimiento de credenciales

• Escalada de privilegios

• Acceso a servicios remotos

• Movimiento lateral

• Recopilación de datos

• Eliminación de registros o artefactos

Si las miras por separado, ninguna de estas técnicas es nueva. Lo que destacó en estos incidentes fue la rapidez con la que se articularon para formar secuencias de ataque coherentes. Los entornos y las rutas de acceso eran diferentes. El comportamiento del atacante, no. Como cualquier atacante, el atacante realizó un reconocimiento para identificar posibles puntos débiles en los sistemas. A continuación, el atacante aprovechó esos puntos débiles y avanzó para alcanzar sus objetivos.

Patrón de incidente n.º 1: el acceso a la base de datos se convierte en acceso a la empresa

En un caso, el actor malicioso convirtió el acceso a la infraestructura SQL en una intrusión más amplia en la empresa.

La actividad observada incluyó:

1. Enumeración de aplicaciones web

El actor malicioso examinó varias aplicaciones web en paralelo e intentó enumerar directorios con distintos grados de éxito. Esto es típico del escaneo ciego de aplicaciones, cuando el adversario desconoce los subdirectorios o la estructura de la aplicación.

2. Sondeo de aplicaciones web y SQL

El actor malicioso lanzó repetidas técnicas de inyección SQL contra los sistemas conectados a Internet. Estas técnicas acabaron permitiendo la activación con éxito de xp_cmdshell. También cabe destacar que el atacante interrumpió la enumeración de aplicaciones web que había realizado antes de activar con éxito xp_cmdshell.

3. Ejecución de comandos a través de servicios de bases de datos

La telemetría posterior mostró que los procesos de SQL Server iniciaban shells de comandos y PowerShell, lo que concuerda con el uso de xp_cmdshell. El atacante utilizó comandos comunes de descubrimiento, probó la ejecución remota de comandos, enumeró servidores vinculados y evaluó si podía usar la funcionalidad de SQL para llegar a otros hosts.

4. Intentos de escalada de privilegios

El atacante preparó o ejecutó herramientas compatibles con la suplantación de tokens y la escalada de privilegios de cuentas de servicio. En algunos casos, el atacante utilizó archivos de salida para comprobar si los comandos habían alcanzado un contexto de seguridad con privilegios más elevados. La telemetría disponible mostró varios eventos de escalada de privilegios.

5. Descubrimiento y recopilación de credenciales

La actividad incluyó búsquedas en archivos de configuración y de scripts, intentos de guardar subárboles sensibles del Registro de Windows, detección de acceso a credenciales relacionadas con LSASS e inspección de credenciales almacenadas y secretos de aplicaciones. Los controles de los endpoints bloquearon parte de la actividad de recolección de credenciales.

6. Movimiento lateral a gran escala

El atacante consultó recursos compartidos administrativos, probó el acceso SQL remoto, utilizó WMI y tareas programadas, y creó tareas remotas configuradas para ejecutarse con cuentas con privilegios. El atacante probó varios servidores de forma sucesiva y rápida.

Una vez habilitado xp_cmdshell, el atacante lo ejecutó bajo la cuenta del servidor de bases de datos. En este caso, como en muchos otros, se trataba de una cuenta de servicio en el servidor con altos privilegios. Esta secuencia muestra cómo una cuenta de servicio o un contexto de ejecución de una base de datos puede convertirse en un punto de partida para explorar toda la empresa. Esto no es nada nuevo.

Esto es típico de la actividad que se observa con operadores humanos, pero la velocidad del pivote y la telemetría posterior apuntaban a acciones automatizadas. Un servidor de base de datos puede parecer un activo de aplicación especializado, pero su alcance de red, sus credenciales de servicio, los servidores vinculados, las herramientas administrativas y el acceso a otros sistemas pueden convertirlo en un potente punto de pivote para los atacantes. Desde el inicio de la enumeración de aplicaciones web hasta la obtención de xp_cmdshell transcurrió 1 hora y 45 minutos. El tiempo en el objetivo hasta que el equipo de seguridad aisló los hosts fue de 30 minutos.

Patrón de incidente n.º 2: una subida de archivos se convierte en una vía de acceso a la nube y a los datos

La segunda investigación siguió una ruta diferente, pero dio lugar a una secuencia de ataque igualmente amplia.

La actividad de la aplicación indicaba un uso indebido de las funciones de gestión de cuentas o de restablecimiento de contraseñas, seguido del acceso a datos de la aplicación relacionados con los clientes y del uso de un endpoint que aceptaba archivos ejecutables en el servidor. A continuación, el atacante desplegó varios web shells en distintos servidores web.

Una vez establecido, el atacante actuó con rapidez:

1. Enumeración de aplicaciones web

Al igual que en el incidente anterior, observamos que el actor malicioso sondeaba varias aplicaciones web en paralelo. Sin embargo, cabe destacar que, una vez subido el shell web a la primera, el escaneo de otras aplicaciones continuó. Al final, el atacante explotó dos aplicaciones web, aunque se trataba de la misma base de código, ya que eran la versión de desarrollo y la de producción del mismo sitio.

2. Ejecución del shell web

Los procesos de trabajo de IIS iniciaron shells de comandos con identidades del grupo de aplicaciones. El atacante realizó comprobaciones de identidad, enumeró sitios web y grupos de aplicaciones, enumeró usuarios y administradores, y exploró los directorios accesibles.

3. Recopilación de configuraciones y claves secretas

El atacante leyó varios archivos web.config y buscó claves privadas, certificados, perfiles de implementación, archivos de entorno, archivos de instalación desatendida y credenciales de Windows. Solo se centró en los archivos web.config de los directorios de las aplicaciones, pero también buscó en varias unidades, donde encontró nombres principales de servicio (SPN) de aplicaciones que ya no se usaban. Más tarde observamos que esos SPN recopilados intentaban iniciar sesión desde direcciones IP sospechosas.

4. Descubrimiento de credenciales en la nube

El atacante ejecutó comandos que consultaban el servicio de metadatos de la instancia e intentaban recuperar credenciales temporales de la nube. También compiló y ejecutó una utilidad específica para acceder a metadatos en varios sistemas comprometidos.

5. Acceso a la base de datos de producción

El atacante usó las credenciales recuperadas o disponibles en el entorno para conectarse a los sistemas SQL de producción y de prueba. Enumeró bases de datos y tablas y envió consultas. Nuestra investigación reveló que el atacante ejecutó consultas, pero solo para obtener metadatos sobre la base de datos; no observamos una extracción masiva de datos.

6. Acceso a servicios internos

El atacante encontró credenciales para un servicio interno de transferencia de archivos, enumeró directorios, probó el acceso de escritura, solicitó varios archivos y sondeó el host en busca de otros servicios accesibles. Esto estaba relacionado con servicios FTP internos y aprovechó las credenciales obtenidas que se encontraban almacenadas en archivos de texto sin cifrar en los distintos sistemas. El atacante intentó acceder a RDP en varios sistemas remotos, pero sin éxito.

7. Escalada de privilegios y limpieza

El atacante descargó herramientas de escalada de privilegios, preparó cargadores personalizados, compiló utilidades utilizando software que ya estaba en el entorno y, más tarde, ejecutó comandos para borrar directorios temporales y copias de shells.

En este incidente, el actor malicioso tardó poco más de 3 horas en identificar y explotar una vulnerabilidad de subida de archivos. Una vez que el atacante subió y ejecutó con éxito los webshells, permaneció en el sistema objetivo durante 1 hora y 45 minutos antes de que el equipo de seguridad aislara los sistemas afectados.

La investigación confirmó la ejecución de shells web, la obtención de credenciales y configuraciones, la actividad de acceso a bases de datos, el acceso a servicios internos y los intentos de limpieza. También descubrimos que una aplicación empresarial crítica se estaba ejecutando en los mismos sistemas que un sitio mucho más antiguo y menos crítico. Aunque no la atacaron directamente, la aplicación crítica quedó afectada cuando explotaron el sitio más antiguo y vulnerable.

Por qué parece a una actividad de intrusión asistida por IA

En ambos incidentes mencionados anteriormente, los atacantes lograron el acceso inicial en menos de 3 horas. Un reciente informe de Gambit Security [1] documentó una campaña en la que los atacantes utilizaron herramientas de IA de código abierto para detectar y explotar vulnerabilidades en cientos de tiendas online. Entre el 10 y el 15 de septiembre de 2026, los investigadores identificaron 105 proyectos de ataque y al menos 27 organizaciones comprometidas en mayor o menor medida. La campaña descrita utilizaba tres componentes: Strix para la investigación de vulnerabilidades, Cairn para la explotación autónoma y Hermes para la orquestación y la orientación del operador.

Según el informe, las herramientas podían recibir objetivos generales, como obtener un shell o acceso de administrador, y luego seguir sondeando durante horas con una intervención humana limitada. Al parecer, la campaña costó una media de unos 25,46 dólares por análisis completado, y los ataques contra algunos objetivos solo costaron solo unos pocos dólares.

En los dos incidentes mencionados anteriormente, no había ninguna firma que indicara que un actor malicioso que utilizara IA estuviera a cargo. Para saber más sobre a qué nos enfrentábamos, tuvimos que ir a las fuentes. Mediante OSINT, descubrimos que los sistemas de origen implicados en estos incidentes ejecutaban:

• Cairn
• CyberStrike AI
• Cupcake-C2

Cairn es un motor de búsqueda en el espacio de estados, basado en inteligencia artificial y de código abierto, diseñado para resolver problemas complejos orientados a objetivos mediante la exploración de posibles rutas desde un estado inicial conocido hasta un resultado deseado. El proyecto se validó inicialmente en el ámbito de las pruebas de penetración autónomas, pero está pensado como un marco de resolución de problemas de uso más general.

CyberStrikeAI es un marco de pruebas de seguridad autónomo de código abierto impulsado por IA, diseñado para ayudar en las pruebas de penetración y en evaluaciones de seguridad complejas. El proyecto combina grandes modelos de lenguaje (LLM) con flujos de trabajo de toma de decisiones automatizados para explorar, analizar y perseguir objetivos de pruebas de seguridad con una intervención humana mínima.

CupcakeC2 es un marco de código abierto de comando y control (C2) diseñado para operaciones de «equipo rojo», emulación de adversarios e investigación en seguridad. Según el repositorio de GitHub del proyecto, cuenta con un agente basado en Rust, un servidor basado en Go compatible con el funcionamiento multiplataforma y la integración con el Protocolo de Contexto de Modelos (MCP).

Estas herramientas, junto con el uso de escáneres de vulnerabilidades web y servidores HTTP sencillos que alojaban herramientas de post-explotación —como webshells— y binarios de escalada de privilegios, ofrecen al atacante la oportunidad de explotar vulnerabilidades web expuestas a Internet con una interacción humana mínima, algo que hace unos años habría llevado mucho tiempo. Los dos casos de respuesta a incidentes describían un entorno en el que los atacantes que utilizan IA podían ser muy eficaces:

• Las aplicaciones expuestas a Internet ofrecían múltiples vías de exploración.

• Las cuentas de aplicaciones y servicios tenían acceso más allá de una sola carga de trabajo.

• Los archivos de configuración contenían o proporcionaban acceso a credenciales reutilizables.

• Los servidores web podían iniciar conexiones con bases de datos y servicios internos.

• Había disponibles compiladores nativos, PowerShell, shells de comandos y utilidades administrativas.

• Se podían repetir acciones similares rápidamente en muchos sistemas.

• El atacante ejecutaba comandos de limpieza después de probar las herramientas y los mecanismos de persistencia.

Esto subraya la importancia de las prácticas diarias de ciberseguridad. Un agente de ataque autónomo no necesita un exploit desconocido si el entorno expone suficientes controles mal conectados. El agente puede probar repetidamente debilidades comunes hasta que varias de ellas formen una ruta de ataque viable.

La verdadera ventaja es la persistencia, no la novedad

La actividad de intrusión basada en IA no debe entenderse simplemente como un «escaneo de vulnerabilidades más rápido». Su mayor ventaja es la persistencia operativa.

Un operador humano se cansa. Puede que abandone un objetivo difícil tras varios intentos fallidos. Un sistema autónomo puede enumerar otro directorio, descodificar otro archivo de configuración, probar el siguiente servicio, ajustar una consulta, crear una pequeña utilidad, probar unas credenciales diferentes y seguir así durante horas mientras el operador humano descansa o se toma una taza de té.

Defiéndete contra el flujo de trabajo, no solo contra la herramienta

Las organizaciones no identificarán de forma fiable los ataques impulsados por IA buscando una firma de «malware de IA». Las técnicas subyacentes siguen apareciendo como actividades habituales del sistema operativo, las aplicaciones, las bases de datos y la nube. En su lugar, los defensores deberían detectar la secuencia.

1. Trata el comportamiento de las aplicaciones como telemetría de seguridad

Los endpoints de autenticación, restablecimiento de contraseñas, subida de archivos, tareas administrativas y exportación de datos deberían generar registros de auditoría de alta calidad. Las solicitudes repetidas en las funciones de gestión de cuentas y subida de archivos deberían correlacionarse como una única cadena de comportamiento, en lugar de revisarse como eventos web inconexos.

2. Evita que los archivos subidos se conviertan en contenido ejecutable

Almacena las subidas controladas por el usuario fuera de las raíces web ejecutables, renómbralas mediante la aplicación, validarlas por su contenido en lugar de por su extensión y servirlas desde un almacenamiento aislado donde sea imposible la ejecución del lado del servidor.

3. Elimina los secretos de los archivos de configuración

La configuración de la aplicación no debe exponer contraseñas de bases de datos de larga duración, credenciales de la nube, claves privadas ni secretos de cuentas de servicio. Usa identidades gestionadas o almacenes de secretos centralizados, aplica duraciones cortas a las credenciales y renueva cualquier secreto expuesto a un host de aplicación comprometido.

4. Restringe las salidas del servidor de aplicaciones

Los servidores web y de bases de datos solo deben comunicarse con destinos y puertos explícitamente necesarios. Un proceso de trabajo de IIS comprometido no debería poder consultar metadatos en la nube, descargar ejecutables arbitrarios, escanear redes internas ni acceder a servicios administrativos ajenos.

5. Supervisa las relaciones anómalas entre procesos padre e hijo

Entre las detecciones de alto valor se incluyen:

• Procesos del servidor web que inician shells de comandos

• Servicios de bases de datos que ejecutan PowerShell

• Cuentas de servicio que ejecutan utilidades de reconocimiento

• Compiladores que generan ejecutables en directorios temporales

• PowerShell que carga ensamblados a partir de matrices de bytes descodificadas

• Procesos de aplicación que acceden a servicios de metadatos de instancias

• Tareas programadas de forma remota creadas por cuentas de bases de datos o de servicios web

6. Detecta secuencias de comportamiento

Un solo comando «whoami» puede no ser concluyente. Una secuencia de «whoami», enumeración de red, acceso a archivos de configuración, búsqueda de credenciales, intentos de conexión interna, preparación de herramientas y eliminación es mucho más significativa.

7. Diseña medidas de contención para ataques a velocidad de máquina

Los procedimientos de contención deben tener en cuenta que un atacante puede ejecutar cientos de acciones mientras un analista humano aún está reconstruyendo la cronología de los hechos. Si confirmas con alta certeza que un atacante ha comprometido un shell web o una cuenta de servicio, aíslalo automáticamente, revoca las credenciales, invalida los tokens de la nube y aplica restricciones temporales de salida.

El horizonte temporal del defensor ha cambiado

La lección es que las rutas de ataque que antes se consideraban difíciles de acceder y explotar por parte de operadores humanos ahora se prestan perfectamente a la ejecución autónoma. Un atacante ya no necesita investigar manualmente cada archivo, endpoint, cuenta, base de datos y host. Las herramientas basadas en IA pueden conservar el contexto, adaptar comandos, interpretar resultados, generar pequeñas utilidades y seguir probando hasta encontrar el siguiente paso viable. Estos hallazgos sugieren que esto ya no es una hipótesis. Los investigadores han observado sistemas autónomos llevando a cabo partes sustanciales de cadenas de intrusión del mundo real con un coste marginal bajo.

Los programas defensivos diseñados en función de la velocidad de un atacante humano tendrán dificultades en este entorno. La respuesta no es simplemente más alertas. Se trata de un diseño de aplicaciones más riguroso, límites de identidad más sólidos, una mejor segmentación, detección de comportamientos correlacionados y una contención capaz de funcionar a una velocidad comparable.

Puede que las técnicas individuales te resulten familiares. Pero la escala, la resistencia y la rentabilidad no lo son. Los propietarios de aplicaciones web orientadas al público deberían tomar medidas inmediatas para revisar la arquitectura de sus aplicaciones, reducir su superficie de ataque, realizar una evaluación del impacto empresarial de sus aplicaciones, llevar a cabo evaluaciones de seguridad de aplicaciones web y reducir el riesgo de que se vean comprometidas antes de que sea demasiado tarde.

Fuentes:

1. [1] https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company