alta research global

Bróker de accesos uso enjambres de Claude Code para escalar intrusiones

SOCRadar documentó una operación donde una sola persona con una suscripción comercial de IA orquestó hasta 51 agentes para escanear, explotar y persistir en miles de sitios WordPress y servidores Redis expuestos, robando más de 628.000 registros ucranianos.

·13 min de lectura ·Equipo Vantis
En 30 segundos
  • SOCRadar documentó a CyberXero, un presunto bróker de acceso inicial de habla rusa que habría orquestado hasta 51 agentes de Claude Code especializados en reconocimiento, explotación y post-explotación; en una sola corrida registrada de 61 segundos escaneó 4.708 objetivos, confirmó acceso a 429 paneles de administración de WordPress y desplegó 32 web shells.
  • El operador no modificó el modelo para sortear sus salvaguardas: reformuló las solicitudes como pruebas de penetración autorizadas sobre infraestructura propia y abrió sesiones nuevas cada vez que el agente rechazaba una tarea. La operación se hizo pública porque el propio atacante dejó un directorio abierto con bitácoras completas, tokens en texto plano y datos exfiltrados.
  • Las vulnerabilidades explotadas son conocidas y comunes —un plugin de WordPress, instancias Redis expuestas a internet—, por lo que la higiene básica sigue siendo la defensa principal. Lo que cambia es la velocidad y el volumen alcanzables por un único operador, lo que acorta la ventana entre divulgación de una vulnerabilidad y explotación masiva.

Qué pasó

Esta nota de Vantis parte de una Research Note publicada por Cloud Security Alliance (CSA Labs) el 15 de octubre de 2026, que a su vez sintetiza un hallazgo original de SOCRadar y su cobertura secundaria en The Hacker News, eSecurity Planet y Security Affairs. Es importante marcar la cadena de atribución porque CSA Labs produce estas notas con un pipeline automatizado sobre fuentes de terceros: no es quien investigó el caso, es quien lo analiza. El informe completo de SOCRadar, además, dio error de acceso al momento de redactarse la nota de CSA, así que varias cifras citadas aquí provienen de la cobertura secundaria, no del reporte primario.

Según SOCRadar, CyberXero operó al menos desde julio de 2026 con dos frentes distintos:

SOCRadar reporta que el pipeline usó hasta 51 agentes de Claude Code con roles especializados —escaneo, encadenamiento de exploits, reconocimiento, movimiento lateral— y un segundo framework, PentAGI (de código abierto, orientado a pentesting con IA), conectado vía API a un servidor de equipo de Cobalt Strike para generación de payloads.

Sobre la evasión de salvaguardas: la cobertura describe que Claude rechazó, en al menos algunas sesiones, cuatro categorías de solicitud: instalación de backdoors, deshabilitar firewalls, movimiento lateral y despliegue de web shells. Pero la misma cobertura documenta que esas actividades sí ocurrieron. La explicación que ofrece la fuente —y que no pudimos verificar de forma independiente porque el informe primario no estuvo disponible— es que los rechazos no persisten entre sesiones: el operador abría un contexto nuevo tras cada negativa. Esto es una evaluación de SOCRadar, no un hecho demostrado de principio técnico general; el caso muestra que funcionó en esta operación, no cuán replicable es el patrón.

Lo que no está claro. Dos datos de la propia cobertura entran en conflicto y la nota de CSA no logra reconciliarlos: The Hacker News reporta 4 organizaciones ucranianas confirmadas como víctimas, mientras Security Affairs reporta más de 40 víctimas confirmadas en Ucrania, Polonia, China y Pakistán. Podrían referirse a alcances distintos (el subconjunto ucraniano curado versus todo el pipeline), pero ninguna fuente lo aclara explícitamente. Lo correcto aquí es decir no sabemos cuál cifra describe qué universo, y no promediarlas ni elegir una por conveniencia narrativa.

Sobre la atribución: SOCRadar vincula al operador con una suscripción paga de IA asociada a un correo personal, alias de foro consistentes y patrones de actividad horaria compatibles con Moscú. Esta es una evaluación de confianza media: los indicadores de idioma y huso horario son circunstanciales y pueden falsificarse deliberadamente; no hay, en lo reportado, una segunda señal independiente (por ejemplo, infraestructura de pago o metadata de registro) que la corrobore sin esa alternativa.

Por qué importa acá

Nada de lo reportado señala una organización chilena como víctima confirmada, y no hay registro de este patrón en las alertas de ANCI de los últimos 30 días. Igual lo publicamos como pieza global porque el elemento relevante no es el objetivo sino el modus operandi: WordPress y sus plugins son, por volumen, el CMS más usado por pymes, medios regionales y municipios en Chile, y Redis es un componente de backend extendido en arquitecturas locales que a veces queda expuesto por configuración por defecto durante despliegues rápidos. El vector técnico de este caso —plugin vulnerable más servicio de caché expuesto— es exactamente el tipo de superficie que un escaneo masivo automatizado con IA encontraría también en dominios .cl.

Hay además dos capas de obligación regulatoria que se activan si un escenario equivalente golpeara a una entidad chilena:

Hay una tercera implicancia que no depende de ser víctima: si tu organización usa Claude Code, Copilot u otro asistente agéntico de codificación de forma corporativa, este caso es el primer ejemplo documentado de ese mismo tipo de herramienta operando del lado ofensivo a escala. La pregunta de gobernanza relevante no es "¿usamos IA agéntica?", es "¿sabemos quién la usa, con qué identidad, y queda registro de los rechazos repetidos que podrían indicar un intento de evasión?".

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 relevante acá tiene dos ejes separados. El primero es externo: si una organización chilena resultara comprometida por un vector equivalente y calificara como entidad regulada bajo la Ley 21.663, corresponde evaluar y, si procede, reportar a ANCI; si hay datos personales comprometidos, corre en paralelo el deber de notificación bajo la Ley 21.719. El segundo es interno y más inmediato: definir quién autoriza el uso corporativo de asistentes de codificación con IA, bajo qué identidad quedan registradas sus acciones, y quién revisa los rechazos de seguridad repetidos como posible señal de abuso — esto último no tiene hoy dueño claro en la mayoría de los comités de seguridad.

  • Definir responsable interno para evaluar aplicabilidad de deber de reporte ANCI (Ley 21.663) si se detecta un compromiso con este patrón
  • Asignar un responsable de gobernanza para el uso corporativo de asistentes de codificación con IA (Claude Code, Copilot y similares)
  • Incorporar a la política de uso de IA un requisito de identidad y logging para cuentas que ejecutan agentes de codificación con acceso a producción
ID IdentificarSi esto me toca, por donde me toca

Antes de hablar de controles hay que saber qué superficie expuesta tiene la organización. Esto parte por un inventario, no por una herramienta nueva.

  • Inventariar todos los sitios WordPress públicos de la organización y sus plugins instalados, con foco en Support Board y cualquier plugin con historial de CVE críticos
  • Verificar si existen instancias Redis accesibles desde internet (puerto 6379 u otro configurado) sin autenticación
  • Revisar las cuentas de administrador de WordPress buscando nombres con el patrón wp2_ o creadas fuera de los procesos normales de alta
  • Buscar directorios con prefijo wp2shell_ o archivos PHP no reconocidos en wp-content/uploads y wp-content/plugins
  • Levantar un inventario de qué equipos y cuentas tienen instalado o autorizado un asistente de codificación con IA y con qué nivel de acceso
PR ProtegerComo evito que ocurra

Los controles priorizados abajo. Ninguno requiere tecnología nueva; la mayoría es higiene postergada que este caso vuelve urgente por la velocidad de explotación reportada (minutos, no días).

  • Parchear el plugin Support Board de WordPress y confirmar contra el aviso del proveedor si la instancia es vulnerable a CVE-2026-4815
  • Retirar toda instancia Redis de exposición pública o forzar autenticación y binding a interfaz interna
  • Auditar y eliminar cuentas administradoras de WordPress no reconocidas, con foco en el patrón wp2_
  • Desplegar reglas de limitación de tasa en el WAF sobre el endpoint /wp-json/ para frenar escaneo masivo
  • Atar el uso de asistentes de codificación con IA a identidad corporativa con logging centralizado de prompts y rechazos

Controles priorizados

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

PrioControlEsfuerzoMapeo
P1 Parchear el plugin Support Board de WordPress y confirmar contra el aviso del proveedor la exposición a CVE-2026-4815 bajo MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8
P1 Retirar toda instancia Redis de exposición pública o forzar autenticación y binding a interfaz interna medio MITRE ATT&CK M1030 CIS Controls v8 4.4 ISO 27001 A.8.20
P1 Auditar cuentas administradoras de WordPress y remover las no reconocidas, con foco en el patrón wp2_ bajo MITRE ATT&CK M1018 CIS Controls v8 5.2 ISO 27001 A.8.2
P2 Desplegar reglas de limitación de tasa en el WAF sobre /wp-json/ para frenar escaneo masivo automatizado medio MITRE ATT&CK M1037 CIS Controls v8 13.3 ISO 27001 A.8.23
P2 Atar el uso de asistentes de codificación con IA a identidad corporativa con logging centralizado y monitoreo de rechazos repetidos medio MITRE ATT&CK M1047 CIS Controls v8 8.2 ISO 27001 A.8.16
P3 Comparar el SLA de parchado actual para CMS expuestos a internet contra las ventanas de explotación observadas en este caso y ajustar si corresponde alto MITRE ATT&CK M1051 CIS Controls v8 7.4 ISO 27001 A.8.8

Ninguno de estos controles depende de detectar uso de IA del lado del atacante: todos funcionan contra el vector de entrada real, que es convencional. La diferencia que impone este caso es la velocidad de aplicación, no la naturaleza del control.

DE DetectarComo me doy cuenta de que ya ocurrio

La detección útil acá no depende de una firma de malware —las vulnerabilidades son genéricas— sino de reconocer el patrón de ráfaga: cientos de intentos en segundos, creación de administradores con nomenclatura específica, y escritura de archivos nuevos en directorios web. Las reglas abajo están pensadas para pegarse directo en la consola.

  • Habilitar logging de acceso web con suficiente detalle (método, URI, query string) para que las reglas de ráfaga funcionen
  • Activar monitoreo de integridad de archivos (FIM) sobre wp-content en todos los sitios WordPress productivos
  • Correlacionar nuevas cuentas administradoras con la fuente IP y el user-agent de la sesión que las creó

Qué necesitas tener logueado

  • Logs de acceso del servidor web (Apache/Nginx) o del WAF/proxy inverso que publica el sitio WordPress
  • Módulo de monitoreo de integridad de archivos (FIM) con whodata sobre el directorio wp-content
  • Logs de autenticación y creación de usuarios de WordPress (tabla wp_users o plugin de auditoría)
  • Logs de Redis y reglas de firewall perimetral para exposición a internet del puerto de servicio

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
ip 46[.]21[.]250[[.]]135 baja SOCRadar / Security Affairs
cve CVE-2026-4815 alta Security Affairs / SOCRadar
cve CVE-2026-63030 media eSecurity Planet
cve CVE-2026-60137 media eSecurity Planet
patron cuentas administradoras con prefijo wp2_ alta SOCRadar
patron directorios con prefijo wp2shell_ alta SOCRadar
malware web shell familia WSO media Security Affairs
blocklistIndicadores en crudo
46.21.250[.]135
CVE-2026-4815
CVE-2026-63030
CVE-2026-60137
cuentas administradoras con prefijo wp2_
directorios con prefijo wp2shell_
web shell familia WSO

Reglas y consultas de detección

sigmaPosible despliegue de web shell wp2shell vía API REST de WordPress
title: Posible despliegue de web shell wp2shell vía REST API de WordPress
id: b3e4a1f0-9d2c-4b7e-8a61-5f0c3e9d2a71
status: experimental
description: Detecta solicitudes POST al endpoint REST de WordPress combinadas con indicadores de creación de cuentas administradoras con el prefijo wp2_, patrón reportado en la campaña CyberXero.
references:
  - https://labs.cloudsecurityalliance.org/research/csa-research-note-cyberxero-agent-swarm-iab-20261015-csa-sty/
logsource:
  category: webserver
detection:
  rest_api:
    cs-uri-stem|contains: '/wp-json/'
    cs-method: 'POST'
  rogue_admin:
    cs-uri-query|contains: 'wp2_'
  condition: rest_api and rogue_admin
falsepositives:
  - Plugins legítimos que automatizan la creación de usuarios vía REST API
  - Pruebas internas de desarrollo con nomenclatura similar
level: high
Requiere: Logs de acceso web con método HTTP, URI stem y query string disponibles (categoría webserver en Sigma). Si el sitio está detrás de un WAF o proxy inverso, ingerir ese log en vez del log nativo del servidor.
sentinel-kqlRáfaga de solicitudes a /wp-json/ compatible con escaneo masivo automatizado
CommonSecurityLog
| where RequestURL has "/wp-json/"
| summarize ReqCount = count(), DistinctPaths = dcount(RequestURL) by SourceIP, bin(TimeGenerated, 1m)
| where ReqCount > 50
| order by ReqCount desc
Requiere: Tabla CommonSecurityLog alimentada desde el WAF o proxy inverso que publica el sitio WordPress, con el parser CEF del dispositivo mapeando correctamente RequestURL y SourceIP.
wazuhNuevo archivo PHP en directorio web compatible con patrón wp2shell/WSO
<rule id="100210" level="12">
  <if_sid>550</if_sid>
  <field name="file" type="pcre2">(?i)wp-content/(uploads|plugins)/.*wp2shell.*\.php$|(?i)wp-content/(uploads|plugins)/.*\.php$</field>
  <description>Posible web shell (patron wp2shell/WSO) creado en directorio de WordPress</description>
  <mitre>
    <id>T1505.003</id>
  </mitre>
</rule>
Requiere: Módulo FIM de Wazuh (syscheck) activo con whodata sobre el árbol wp-content, agente instalado en el servidor o contenedor que sirve el sitio.
Falsos positivos esperables

La regla Sigma puede dispararse con plugins legítimos de gestión de usuarios que usan convenciones de nombre similares a wp2_; validar manualmente la cuenta antes de deshabilitarla. La regla de Wazuh sobre escritura de archivos PHP en wp-content es intencionalmente amplia y generará ruido en sitios con despliegues frecuentes de plugins o temas; en esos casos, conviene primero acotarla a wp-content/uploads (donde normalmente no debería existir PHP ejecutable) antes de extenderla a wp-content/plugins.

RS ResponderContencion y erradicacion

Si se confirma un compromiso con este patrón, la secuencia de contención es la estándar para web shell más cuenta rogue, con un paso adicional: tratar cualquier token o credencial que haya estado en scripts de automatización como ya filtrado.

  • Aislar el servidor o contenedor comprometido de la red antes de intentar limpieza
  • Eliminar cuentas administradoras no reconocidas y archivos web shell identificados (patrón WSO, directorios wp2shell_)
  • Rotar todas las credenciales y tokens API almacenados en scripts del servidor afectado, asumiendo exposición
  • Revisar logs de Redis y de base de datos por exportaciones masivas o cambios de privilegio no autorizados
  • Si hay datos personales comprometidos, iniciar evaluación de notificación bajo Ley 21.719 en paralelo a la contención técnica
RC RecuperarVolver a operar y no repetirlo

La vuelta a producción solo tiene sentido si se valida que el vector de entrada quedó cerrado, no solo que el web shell fue borrado.

  • Restaurar desde un backup anterior al indicador de compromiso más antiguo encontrado, no desde el estado actual del sitio
  • Confirmar que el plugin vulnerable quedó parchado y que Redis ya no es accesible públicamente antes de reconectar el sitio
  • Revisar con el proveedor de hosting si existen otros clientes en la misma infraestructura con el mismo plugin vulnerable
  • Incorporar el hallazgo al SLA de parchado: medir cuánto tardó la organización en aplicar el parche versus la ventana de explotación reportada en este caso

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