alta research global

El ataque con IA agéntica no trae técnicas nuevas: trae escala

La CSA documentó un grupo que conectó una herramienta de pentesting autónoma a una lista de 170.000 objetivos. La conclusión útil no es comprar detección de IA: es que el cálculo de «somos muy chicos para que nos ataquen» dejó de funcionar.

·15 min de lectura ·Equipo Vantis
En 30 segundos
  • La CSA documentó a UAT-10147, un grupo con motivación financiera que construyó su operación alrededor de ~170.000 URLs expuestas a internet, repartidas en 17 archivos, y conectó una herramienta de pentesting autónoma directamente a esa lista.
  • Un ataque agéntico no significa una técnica nueva. Las vulnerabilidades explotadas son conocidas y tienen parche. Lo que cambia es que la IA automatiza, coordina, adapta y escala técnicas que ya existían.
  • La consecuencia para la detección es contraintuitiva: no necesitas un «SIEM para IA». Desde un registro no se puede saber que el atacante usa un modelo. Lo que sí se detecta es la cadena de comportamiento que la automatización produce.

Qué pasó

El 25 de agosto de 2026, Cloud Security Alliance publicó una research note sobre UAT-10147, un grupo con motivación financiera y sin patrocinio estatal aparente, cuyo caso ilustra lo que la organización llama *AI agentic attack scaling*.

Lo relevante del caso está en la escala operativa. El grupo construyó su campaña alrededor de aproximadamente 170.000 URLs expuestas a internet, distribuidas en 17 archivos, y las conectó a un flujo automatizado. Las víctimas confirmadas abarcan Brasil, Bolivia, China, Canadá y Vietnam, en sectores de gobierno, educación, medios, tecnología y videojuegos.

Las piezas del pipeline documentadas:

Las vulnerabilidades usadas para el acceso inicial no son nuevas: Zimbra CVE-2022-27925, AjaxPro CVE-2021-23758, Alibaba Nacos CVE-2021-29441 y CVE-2021-29442, Telerik CVE-2019-18935. Todas tienen parche desde hace años.

Para evasión, el grupo recurrió a BYOVD —cargar un driver firmado pero vulnerable— usando RTCore64.sys (CVE-2019-16098) y DBUtil_2_3.sys (CVE-2021-21551) para desactivar de forma quirúrgica los callbacks del EDR, además de exclusiones de Windows Defender, tareas programadas disfrazadas como *Google Chrome Start*, y un rootkit de kernel basado en ftrace para ocultar procesos y conexiones.

Por qué importa acá

Acá está el punto que cambia el cálculo de riesgo para una empresa chilena, y no tiene que ver con inteligencia artificial: tiene que ver con economía.

Hasta ahora, un atacante con recursos limitados tenía que elegir a quién atacar. Escanear, validar y explotar cuesta tiempo de operador, y ese tiempo es caro. Por eso la mayoría de las pymes y organizaciones medianas operaban con una defensa implícita: *somos muy chicos, no valemos el esfuerzo*.

Esa defensa dejó de funcionar. Cuando el reconocimiento y la validación de 170.000 objetivos se automatizan, el costo marginal de agregar uno más tiende a cero. Ya no hay una priorización humana filtrando quién vale la pena. Si tu servidor está expuesto y tiene una vulnerabilidad conocida, entras a la lista por el solo hecho de existir.

Eso es lo que la CSA llama *democratización de la capacidad ofensiva*: una capacidad que antes requería un equipo especializado con muchos operadores pasa a estar al alcance de muchas más personas.

La consecuencia práctica para la priorización es directa, y la propia CSA la señala: la superficie de ataque expuesta pasa a ser una variable más urgente que el atraso de parches en general. No porque parchar deje de importar, sino porque lo que está expuesto a internet se descubre y se explota en horas, mientras que lo interno conserva algo de margen.

Para una organización sujeta a la Ley 21.663, esto refuerza algo que la norma ya pide: gestión de superficie de exposición y velocidad de parcheo como capacidades permanentes, no como proyectos.

Análisis propio de Vantis

La pregunta que casi todo el mundo hace al leer un caso así es cuál herramienta comprar para detectar ataques con IA. La respuesta es que probablemente ninguna, y vale la pena explicar por qué con precisión.

Desde un registro no se puede determinar que el atacante está usando un modelo de lenguaje. No hay un campo que diga *«generado por IA»*. Lo que sí queda registrado es lo que la automatización produce: una cadena de comportamiento que se ve así:

> reconocimiento sistemático → múltiples payloads → cambio de estrategia → explotación → ejecución → persistencia → mando y control

Cada eslabón por separado es ruido. La cadena completa es la señal. Y eso se detecta con los controles que ya tienes: WAF, EDR/XDR, gestión de identidades, MFA, gestión de vulnerabilidades, gestión de superficie expuesta, SIEM, SOAR y registro en la nube. Lo nuevo que hay que construir no es una plataforma: es visibilidad y correlación de comportamientos automatizados y adaptativos.

Hay un segundo hallazgo, de método, que ordena el trabajo de arquitectura. Tres marcos que suelen presentarse como competidores en realidad responden preguntas distintas y se usan en capas:

MAESTRO modela la arquitectura agéntica: qué herramientas puede usar el agente, qué permisos tiene, qué APIs invoca, qué datos lee, qué límites de confianza cruza, y qué pasa si recibe instrucciones maliciosas o toma una decisión incorrecta.

MITRE ATLAS cataloga técnicas contra sistemas de IA y aprendizaje automático: inyección de prompt, envenenamiento de datos, robo de modelo, abuso de capacidades.

MITRE ATT&CK sigue describiendo lo que el atacante hace dentro de tu red, que en este caso fue lo de siempre: explotar una aplicación expuesta, escalar privilegios, desactivar defensas, persistir.

Ninguno reemplaza a los otros. MAESTRO tampoco reemplaza a STRIDE: lo complementa cuando la arquitectura incorpora agentes. Confundirlos lleva al error clásico de adoptar un marco nuevo y abandonar el que sí estaba funcionando.

CVE-2022-27925, CVE-2019-18935, CVE-2021-29441 — Vulnerabilidades conocidas y parchadas hace anios: la novedad no esta en la tecnica
Respaldan: CSA Research Note UAT-10147
RTCore64.sys y DBUtil_2_3.sys — BYOVD para desactivar callbacks de EDR. Drivers firmados pero vulnerables
Respaldan: CSA Research Note UAT-10147
~170.000 URLs en 17 archivos — La escala del listado es lo que elimina la priorizacion humana de objetivos
Respaldan: CSA Research Note UAT-10147
Hacia dónde va

La CSA plantea dos recalibraciones que conviene tomar en serio.

La primera: una operación de explotación autónoma ya no indica un actor patrocinado por un Estado. Durante años, la escala y la coordinación se leían como firma de un actor sofisticado con presupuesto. Ese supuesto dejó de ser válido, y quien lo mantenga va a clasificar mal los incidentes que reciba.

La segunda: hay que esperar que las listas de objetivos crezcan a medida que el costo de escanear y validar siga cayendo. Eso convierte la gestión de superficie expuesta y la velocidad de parcheo en las dos inversiones más duraderas que se pueden hacer, por encima de cualquier herramienta específica.

Y hay una consecuencia para el desarrollo de software que aún no se discute lo suficiente: si el atacante genera capacidades más rápido de lo que el defensor las cataloga, la seguridad tiene que moverse hacia el diseño —límites de confianza, contención por arquitectura, gobierno del agente— y no solo hacia el catálogo de amenazas conocidas.

MARCO PREGUNTA QUE RESPONDE MAESTRO 1 MITRE ATLAS 1 MITRE ATT&CK 1 Que puede hacer el agente si lo manipulan Como se ataca al sistema de IA Que hace el atacante en mi red
Tres marcos, tres preguntas distintas No compiten ni se reemplazan. Cada uno responde algo que los otros dos no responden, y por eso se usan en capas. Fuente: Elaboración propia sobre MAESTRO, MITRE ATLAS y MITRE ATT&CK

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

La decisión de gobierno que este research obliga a tomar es de priorización, no de compra. Si la superficie expuesta pasa a pesar más que el atraso general de parches, el presupuesto y la atención tienen que moverse hacia allá.

Y una recalibración de criterio para quien clasifica incidentes: la escala y la coordinación ya no son evidencia de un actor estatal. Un informe que concluya «sofisticado, probablemente patrocinado» solo por el volumen está usando un supuesto vencido.

  • Reordenar la priorización de parcheo poniendo la superficie expuesta por delante.
  • Actualizar los criterios de atribución en el proceso de clasificación de incidentes.
  • Incorporar guías de explotación generadas por IA al modelado de amenazas propio.
ID IdentificarSi esto me toca, por donde me toca

La pregunta central es una sola: ¿qué de lo tuyo aparecería en una lista de 170.000 URLs? Eso se responde mirándose desde fuera, no desde el inventario interno.

Y una segunda, específica de este caso: ¿tienes visibilidad de qué drivers se cargan en tus servidores? El BYOVD es invisible para quien no está mirando esa capa.

  • Enumerar la superficie expuesta a internet desde fuera, con las IP públicas propias.
  • Verificar que Zimbra, Telerik, Nacos y componentes similares estén parchados o retirados.
  • Confirmar que el EDR registra carga de drivers, no solo procesos.
PR ProtegerComo evito que ocurra

Tres controles concretos salen directo del caso. Confirmar que la lista de bloqueo de drivers vulnerables cubre explícitamente RTCore64.sys y DBUtil_2_3.sys — Microsoft publica una lista de bloqueo, pero no siempre está activa por defecto.

Tratar todo driver de kernel firmado pero no reconocido como disparador de investigación de alta prioridad, no como evento informativo.

Y lo más importante y menos glamoroso: velocidad de parcheo en lo expuesto. Todas las vulnerabilidades de acceso inicial de este caso tenían parche disponible desde hacía años.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Enumerar la superficie expuesta a internet desde fuera y parchar o retirar todo lo que aparezca con vulnerabilidad conocida. Es el control que decide si entras o no en la lista de objetivos. medio MITRE ATT&CK M1051 CIS Controls v8 12.4 ISO 27001 A.8.8
P1 Confirmar que la lista de bloqueo de drivers vulnerables cubre explícitamente RTCore64.sys y DBUtil_2_3.sys, y que está activa. En muchos parques está disponible pero no habilitada. bajo MITRE ATT&CK M1050 CIS Controls v8 10.5 ISO 27001 A.8.7
P2 Tratar todo driver de kernel firmado pero no reconocido como disparador de investigación de alta prioridad, no como evento informativo. bajo CIS Controls v8 8.11 ISO 27001 A.8.16
P2 Implementar detección de hooks de ftrace en servidores Linux, comparando periódicamente la tabla viva contra una línea base tomada tras una instalación limpia. medio CIS Controls v8 3.14 ISO 27001 A.8.16
P2 Desplegar las siete reglas de la cadena y correlacionarlas por host y ventana temporal. El valor está en que varias disparen juntas, no en cada una por separado. medio CIS Controls v8 13.11 ISO 27001 A.8.16
P3 Incorporar los runbooks de explotación generados por IA al modelado de amenazas propio: son un insumo nuevo que cambia qué tan rápido un atacante convierte un hallazgo en un compromiso. medio CIS Controls v8 17.1 ISO 27001 A.5.7

Lo notable de esta lista es lo poco novedosa que es. Ninguno de estos controles se inventó para la IA agéntica, y ese es justamente el punto: lo que cambió no es el catálogo de defensas, es la velocidad con que el atacante encuentra a quien no las aplicó.

DE DetectarComo me doy cuenta de que ya ocurrio

El principio que ordena todo: no intentes detectar «IA», detecta la cadena.

Los siete casos de uso que dejamos abajo cubren la cadena completa: reconocimiento automatizado (UC-01), intento de explotación (UC-02), servidor web engendrando una shell (UC-03), servidor web hablando hacia afuera (UC-04), abuso de driver vulnerable (UC-05), exclusión agregada al antivirus (UC-06) y manipulación de ftrace en Linux (UC-07).

El valor no está en cada regla por separado — cada una tiene su ruido. Está en que varias disparen sobre el mismo host en una ventana corta. Por eso la consulta de Splunk cuenta cuántas etapas distintas se activaron: dos etapas valen más que veinte eventos de una sola.

Una advertencia sobre UC-05: la ausencia del indicador no descarta compromiso. Un rootkit de kernel con ftrace existe precisamente para que las capas superiores no vean nada.

Qué necesitas tener logueado

  • Registros del servidor web con URI, método y código de respuesta, para el reconocimiento
  • Telemetría de EDR con creación de procesos, línea de comandos y relación padre-hijo
  • Eventos de carga de driver en Windows (Sysmon evento 6 o equivalente del EDR)
  • Eventos de archivo y de módulos de kernel en servidores Linux
  • Registros del WAF, para correlacionar con errores de aplicación

Indicadores de compromiso

OjoLos indicadores están defanged (hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.
TipoIndicadorConfianzaNota
hash RTCore64[.]sys alta Driver firmado pero vulnerable (CVE-2019-16098) usado para BYOVD
hash DBUtil_2_3[.]sys alta Driver firmado pero vulnerable (CVE-2021-21551) usado para BYOVD
user-agent Google Chrome Start media Nombre de tarea programada usado como disfraz de persistencia
blocklistIndicadores en crudo
RTCore64.sys
DBUtil_2_3.sys
Google Chrome Start

Reglas y consultas de detección

sigmaUC-01 · Reconocimiento automatizado a gran escala
title: Reconocimiento automatizado a gran escala contra la superficie expuesta
id: 1c7e4b93-8a26-4f51-9d38-2b6c0e5a7f14
status: experimental
description: >
  UC-01. No busca "IA": busca el comportamiento que la automatizacion produce.
  Una misma IP tocando muchos hosts, muchos puertos y muchas URLs, con alta tasa
  de 404 y 403, en poco tiempo. Es la primera etapa de la cadena agentica.
references:
  - https://labs.cloudsecurityalliance.org/research/
author: Vantis Chile SpA
date: 2026/08/27
logsource:
  category: webserver
detection:
  peticion:
    cs-method|expand: '%metodos%'
  respuesta_de_descarte:
    sc-status:
      - 403
      - 404
      - 405
  condition: peticion and respuesta_de_descarte | count(cs-uri-stem) by c-ip > 200
timeframe: 10m
falsepositives:
  - Rastreadores de buscadores legitimos. Filtrar por ASN y por user agent verificado
    mediante DNS inverso, no solo por la cadena declarada.
  - Escaneos de seguridad propios. Deben estar inventariados con IP de origen conocida.
level: medium
tags:
  - attack.reconnaissance
  - attack.t1595.002
Requiere: Registros del servidor web o del WAF, con IP de origen y código de respuesta
sigmaUC-05 · Carga de driver vulnerable conocido (BYOVD)
title: Carga de driver vulnerable conocido (BYOVD)
id: 3a8f1d62-5c94-4e07-b2a6-9f4e7c1b8035
status: stable
description: >
  UC-05. La CSA documento el uso de RTCore64.sys y DBUtil_2_3.sys para desactivar
  callbacks de EDR de forma quirurgica. Un driver firmado pero vulnerable es una
  llave legitima: el sistema lo acepta porque la firma es valida.
references:
  - https://labs.cloudsecurityalliance.org/research/
author: Vantis Chile SpA
date: 2026/08/27
logsource:
  product: windows
  category: driver_load
detection:
  drivers_conocidos:
    ImageLoaded|endswith:
      - '\RTCore64.sys'
      - '\DBUtil_2_3.sys'
      - '\dbutil_2_3.sys'
      - '\gdrv.sys'
      - '\iqvw64e.sys'
  ruta_sospechosa:
    ImageLoaded|contains:
      - '\Users\'
      - '\Temp\'
      - '\ProgramData\'
  condition: drivers_conocidos or (ruta_sospechosa and ImageLoaded|endswith: '.sys')
falsepositives:
  - Herramientas legitimas de monitoreo de hardware pueden cargar RTCore64.sys.
    Si existen en el parque, deben estar inventariadas por equipo, no ignoradas.
level: critical
tags:
  - attack.defense_evasion
  - attack.t1068
  - attack.t1562.001
Requiere: Sysmon evento 6 o telemetría equivalente de carga de drivers del EDR
splunkUC-03, UC-04 y UC-06 · La cadena, contada por etapas
index=edr OR index=windows earliest=-30d
| eval proc = lower(process_name), padre = lower(parent_process_name)
| eval cmd = lower(coalesce(process, command_line))
``` UC-03: servidor web engendrando una shell ```
| eval web_a_shell = if(match(padre, "(w3wp|httpd|nginx|apache2|tomcat|php-fpm)")
                        AND match(proc, "(powershell|cmd|bash|sh|wscript|cscript)"), 1, 0)
``` UC-06: exclusion agregada al antivirus ```
| eval exclusion = if(match(cmd, "(add-mppreference|set-mppreference).*exclusion"), 1, 0)
``` UC-04: proceso inesperado hablando hacia afuera ```
| eval salida_rara = if(match(padre, "(w3wp|httpd|nginx)") AND isnotnull(dest_ip)
                        AND NOT cidrmatch("10.0.0.0/8", dest_ip), 1, 0)
| where web_a_shell=1 OR exclusion=1 OR salida_rara=1
| eval senal = case(web_a_shell=1, "UC-03 web a shell",
                    exclusion=1,   "UC-06 exclusion de Defender",
                    salida_rara=1, "UC-04 web a C2")
| stats count AS eventos, values(senal) AS senales, values(cmd) AS comandos,
        min(_time) AS primero, max(_time) AS ultimo by host, user
| convert ctime(primero) ctime(ultimo)
``` La cadena completa vale mucho mas que cualquier senal suelta ```
| eval etapas = mvcount(senales)
| sort - etapas, - eventos
Requiere: index=edr con proceso, proceso padre, línea de comandos y destino de red
sentinel-kqlUC-07 · Manipulación de ftrace y módulos de kernel en Linux
// UC-07. En Linux no basta con vigilar el hooking clasico de la tabla de syscalls.
// El rootkit descrito por la CSA usa ftrace para ocultar procesos y conexiones.
// Esta consulta compara la tabla viva de hooks contra una linea base conocida.
DeviceFileEvents
| where Timestamp > ago(30d)
| where DeviceName in ((DeviceInfo | where OSPlatform == "Linux" | distinct DeviceName))
| where FolderPath has_any ("/sys/kernel/debug/tracing", "/proc/sys/kernel/ftrace_enabled",
                            "/lib/modules", "/etc/modules-load.d")
| where ActionType in ("FileCreated", "FileModified")
| project Timestamp, DeviceName, FolderPath, FileName,
          InitiatingProcessFileName, InitiatingProcessAccountName
| order by Timestamp desc

// Complemento en el propio host, para comparar contra linea base:
//   cat /sys/kernel/debug/tracing/enabled_functions
//   lsmod | sort
// Guardar el resultado tras una instalacion limpia y comparar periodicamente.
Requiere: Defender for Endpoint en servidores Linux, con DeviceFileEvents
Falsos positivos esperables

UC-01 va a marcar rastreadores legítimos de buscadores. Filtra por ASN y verifica el agente de usuario mediante DNS inverso, no por la cadena declarada, que se falsifica en un segundo. Y ten inventariadas las IP desde las que tú mismo escaneas.

UC-05 puede activarse con herramientas legítimas de monitoreo de hardware que cargan RTCore64.sys. Si existen en tu parque, deben estar inventariadas por equipo — no desactivadas de la regla.

Y la advertencia que importa más que las tres anteriores: la ausencia de hallazgos no prueba ausencia de compromiso. Un rootkit de kernel basado en ftrace existe exactamente para que estas consultas no devuelvan nada.

RS ResponderContencion y erradicacion

Si la cadena se confirma, hay un orden que importa. Con un rootkit de kernel en juego, la telemetría del propio host deja de ser confiable: el rootkit está ahí justamente para ocultarle cosas al EDR.

La evidencia que sirve es la de la red y la de sistemas externos al equipo comprometido. Y la restauración razonable de un servidor con sospecha de rootkit de kernel es la reinstalación, no la limpieza.

  • Aislar por red antes de apagar: preservar memoria si hay capacidad forense.
  • Usar telemetría de red y de otros sistemas: la del host comprometido no es confiable.
  • Comparar la tabla viva de hooks de ftrace y los módulos cargados contra la línea base.
  • Ante sospecha de rootkit de kernel, reinstalar el servidor en vez de limpiarlo.
RC RecuperarVolver a operar y no repetirlo

La lección de recuperación de este caso no es sobre el incidente: es sobre la exposición que lo hizo posible. Si el acceso inicial fue una vulnerabilidad con parche disponible desde hace años, el problema nunca fue la sofisticación del atacante.

La métrica que sirve: cuántos días pasan entre que un CVE crítico se publica y tu activo expuesto queda parchado. Ese número, y no la herramienta que compres, es lo que determina si entras o no en la próxima lista de 170.000.

  • Medir el tiempo de parcheo específicamente sobre activos expuestos a internet.
  • Dejar la enumeración externa de superficie como control recurrente, no puntual.
  • Ejercitar la correlación de la cadena en el SIEM con un ejercicio de equipo púrpura.

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado