Según CrowdStrike, los ciberataques de ARTEX AI se dirigieron contra organizaciones financieras surcoreanas en septiembre y octubre de 2026. Los registros expuestos mostraron que un atacante utilizó ARTEX, sesiones de Claude Code, proxies y varios modelos de lenguaje de gran tamaño para apoyar actividades de exfiltración de datos. Las pruebas documentan flujos de intrusión asistidos por IA, pero no demuestran que el Claude de Anthropic se viera comprometido ni identifican a un atacante concreto.
¿Qué ocurrió en los ciberataques de ARTEX AI?
Los ciberataques de ARTEX AI fueron una campaña de exfiltración de datos de 2026 dirigida contra organizaciones financieras surcoreanas. CrowdStrike relacionó los datos de configuración de ARTEX expuestos y los registros de Claude Code con la actividad el 7 de octubre de 2026. Los informes públicos mencionaron al menos siete empresas objetivo y datos asociados a unas 68.000 personas, aunque el número de organizaciones afectadas sigue sin confirmarse.
ARTEX es un de código abierto, un marco de pruebas de penetración multiagente que divide los objetivos entre agentes, invoca herramientas de seguridad y acumula información sobre activos y vulnerabilidades. Estas capacidades tienen usos legítimos en evaluaciones autorizadas. En manos de un atacante, el mismo flujo de trabajo puede acelerar el reconocimiento, las pruebas y la organización de la información robada.
CrowdStrike identificó infraestructura relacionada durante septiembre y octubre de 2026. En su informe del 7 de octubre describió una arquitectura de dos servidores que incluía un sistema principal ubicado en Hong Kong y un host de ARTEX en 38.244.50[.]120, además de nueve direcciones IP proxy asociadas a la actividad.
Los medios coreanos describieron una posible enumeración automatizada de un servicio de consulta del estado de préstamos y de un sistema de asistencia móvil para empleados en octubre de 2026. CrowdStrike no estableció de forma independiente el método de acceso inicial, por lo que esos informes no deben considerarse una prueba de cómo comenzaron las intrusiones.
¿Hackearon Claude o fue responsable de los ataques contra los bancos coreanos?
No se demostró que Claude fuera hackeado ni que fuera responsable de forma independiente de los ataques contra el sector financiero coreano. Las pruebas de CrowdStrike de octubre de 2026 mostraron sesiones de Claude Code funcionando dentro de un flujo de trabajo más amplio controlado por el atacante, que también utilizaba ARTEX, proxies, infraestructura ofensiva convencional y backends de modelos externos. Los investigadores no demostraron ni alegaron que el servicio de Anthropic se hubiera visto comprometido.
El 7 de octubre de 2026, unos directorios controlados por el atacante y expuestos públicamente dejaron al descubierto historiales de sesiones de Claude Code, archivos de memoria y un archivo de instrucciones CLAUDE.md. Estos artefactos ofrecieron una visión poco habitual de cómo interactuaba el operador con los agentes de programación. No demuestran que Claude seleccionara los objetivos, obtuviera el acceso inicial ni actuara sin dirección humana.
En una sesión, el operador preguntó dónde se suelen vender los datos robados de filtraciones coreanas y solicitó ayuda para localizar grupos coreanos de Telegrama venta de datos, según el informe de 2026 de CrowdStrike. Otra contenía posibles datos del operador, pero CrowdStrike advirtió explícitamente de que la información no podía vincularse de forma concluyente con el atacante.
La distinción es importante. Calificar el incidente de «hackeo de Claude» confundiría el uso indebido de una herramienta accesible con el compromiso de su proveedor. Surgen cuestiones similares en incidentes recientes de filtraciones de datos provocadas por agentes de IA, donde los permisos, los límites de ejecución y el comportamiento del operador importan más que el nombre de la marca del modelo.
¿Qué modelos y herramientas de IA utilizó el atacante?
Según CrowdStrike, la instalación observada de ARTEX utilizaba DeepSeek v4.1-flash como backend principal del modelo en octubre de 2026. Otras sesiones de Claude Code hacían referencia a GLM-5.3 y Grok 4.6. Por tanto, la campaña dependía de una cadena de herramientas multimodelo, en lugar de un único modelo autónomo que llevara a cabo todo el ataque.
| Componente | Función o pruebas observadas | Fuente y fecha |
|---|---|---|
| ARTEX | Marco de pruebas de penetración con múltiples agentes utilizado para dividir objetivos e invocar herramientas de seguridad | CrowdStrike, 7 de octubre de 2026 |
| DeepSeek v4.1-flash | Backend principal configurado para la instancia de ARTEX observada | CrowdStrike, 7 de octubre de 2026 |
| Claude Code | Las sesiones, los archivos de memoria y las instrucciones expuestos documentaron la actividad del operador | CrowdStrike, 7 de octubre de 2026 |
| GLM-5.3 y Grok 4.6 | Aparecían en registros adicionales de sesiones de Claude Code | CrowdStrike, 7 de octubre de 2026 |
| Infraestructura proxy | Se enumeraron nueve direcciones IP proxy asociadas | CrowdStrike, 7 de octubre de 2026 |
| Hosts de ARTEX expuestos en Internet | Se encontraron unas 600 direcciones IP adicionales; no todas se consideraron maliciosas | AhnLab, 6 de octubre de 2026 |
La investigación de AhnLab de octubre de 2026 encontró parte de la infraestructura relacionada con ARTEX ejecutando pasarelas de API de IA, servicios de gestión de la superficie de ataque, marcos de pruebas de penetración, herramientas de mando y control o CyberStrikeAI. Esta combinación demuestra por qué los equipos de defensa necesitan telemetría de toda la cadena de ejecución. Vigilar únicamente los prompts hace que pasen desapercibidos los escáneres, las shells, las pasarelas y las conexiones salientes que convierten la salida del modelo en acciones.
Los riesgos de seguridad agéntica no son exclusivos de ARTEX. También aparecen cuando la programación con IA introduce dependencias inseguras o cuando los atacantes despliegan agentes de IA en hosts de Docker comprometidos. En mi opinión, los equipos de seguridad que se centran únicamente en la seguridad de los modelos están vigilando el punto de control menos fiable.
¿Quién estaba detrás de los ciberataques de ARTEX AI?
No se ha atribuido los ciberataques de ARTEX AI a ningún actor de amenazas identificado. El 7 de octubre de 2026, CrowdStrike evaluó con confianza moderada que el operador probablemente hablaba chino y estaba motivado económicamente. El Instituto Nacional de Ciberseguridad de Hungría mantuvo la descripción de «atacante desconocido» al resumir las conclusiones el 9 de octubre de 2026.
El idioma y la infraestructura son indicios, no documentos de identidad. Un operador puede utilizar herramientas de traducción, servidores alquilados y artefactos deliberadamente engañosos. La posible información personal encontrada en una sesión de Claude constituye una prueba de atribución especialmente débil, porque CrowdStrike no pudo asociarla de forma concluyente con la persona que llevó a cabo los ataques.
AhnLab informó de unas 600 direcciones IP adicionales que alojaban instancias de ARTEX el 6 de octubre de 2026. Un día después, CrowdStrike enumeró nueve direcciones IP proxy correspondientes a la actividad investigada. Dividir 600 entre nueve da aproximadamente 66,7, pero ese cálculo no tiene valor de atribución porque las cifras describen conjuntos diferentes: exposición general en Internet frente a proxies vinculados a una campaña concreta.
Es un error que muchos resúmenes de amenazas pasan por alto. AhnLab advirtió en 2026 de que entre los aproximadamente 600 hosts podía haber sistemas de investigación legítimos. Bloquear todas las direcciones de ARTEX observadas sin validación podría interrumpir pruebas autorizadas y, al mismo tiempo, hacer poco frente a un operador que cambie de infraestructura.
¿Cómo deben defenderse los bancos frente a los ciberataques agénticos?
Los bancos deben protegerse frente a los ciberataques agénticos registrando cada invocación de agentes y herramientas, detectando automatización tasas anómalas, restringiendo los destinos salientes, separando las credenciales por tarea y preservando las pruebas inmediatamente después de un acceso anómalo a los datos. Las pruebas de ARTEX de 2026 demuestran que los controles sobre la ejecución, la identidad y la salida de red siguen siendo eficaces incluso cuando los atacantes cambian entre varios modelos de IA.
El objetivo práctico es que toda acción automatizada pueda atribuirse. Una solicitud al modelo, un comando de shell, una llamada a un escáner, un uso de credenciales y una transferencia saliente deben compartir suficientes identificadores y marcas de tiempo para que los investigadores puedan reconstruir la secuencia. Este enfoque convierte la automatización de alta velocidad en una cadena visible, en lugar de en un pico inexplicado.
Las organizaciones financieras deben priorizar los siguientes controles:
- Registrar los prompts de los agentes, las llamadas a herramientas, la creación de procesos, el uso de API y las conexiones con backends de modelos mediante marcas de tiempo sincronizadas de 2026.
- Generar alertas ante consultas o solicitudes repetidas que lleguen más rápido de lo habitual en los flujos de trabajo humanos, teniendo en cuenta la automatización autorizada.
- Restringir el tráfico saliente por destino y enrutar el tráfico de los agentes a través de proxies corporativos supervisados.
- Emitir credenciales específicas para cada tarea y con una duración breve, en lugar de compartir cuentas de servicio con permisos amplios entre agentes y herramientas.
- Conservar los registros, los archivos de memoria, las instrucciones y las pruebas de red inmediatamente después de un acceso o una exfiltración sospechosos.
Los controles oficiales de Claude Code de Anthropic documentados desde octubre de 2025 hasta octubre de 2026 incluyen el aislamiento del sistema de archivos y de la red, restricciones de dominio, enrutamiento mediante proxy corporativo y permisos gestionados de forma centralizada. Estas funciones pueden contribuir a la contención y la visibilidad, pero solo cuando las organizaciones las configuran en lugar de confiar en la configuración predeterminada.
La aplicación en tiempo de ejecución es la estrategia más sólida. Una política escrita sobre el uso de la IA no puede impedir que un agente acceda a un host no aprobado; una regla de salida sí puede hacerlo. El mismo principio sustenta el cambio de los documentos de políticas hacia los controles en tiempo de ejecución para la gobernanza de la IA y los enfoques aplicados mediante hardware para el aislamiento de agentes de IA.
Preguntas frecuentes sobre ARTEX y los ataques financieros surcoreanos
¿Es ARTEX un malware?
ARTEX es un marco de pruebas de penetración de código abierto y multiagente, que no es malware por naturaleza. Los ciberataques de ARTEX mediante IA demuestran cómo un marco de seguridad legítimo puede reutilizarse para llevar a cabo intrusiones no autorizadas y el robo de datos.
¿Cuántas empresas financieras surcoreanas se vieron afectadas?
Los informes públicos de octubre de 2026 mencionaron al menos siete empresas financieras surcoreanas, pero CrowdStrike declaró que el número de organizaciones afectadas seguía sin confirmarse. Los informes también relacionaron los incidentes con datos relativos a aproximadamente 68.000 personas.
¿Formaban parte del ataque los 600 servidores de ARTEX?
No hay pruebas que establezcan que todas las aproximadamente 600 direcciones IP que alojaban ARTEX y que AhnLab notificó el 6 de octubre de 2026 participaran en la campaña. AhnLab advirtió específicamente de que podrían estar incluidos sistemas legítimos de investigación.
¿Pueden los bancos bloquear ARTEX para detener los ataques asistidos por IA?
Bloquear la infraestructura conocida de ARTEX puede reducir la exposición, pero no puede impedir que los atacantes cambien de servidores, proxies, frameworks o backends de modelos. Los bancos necesitan detección basada en el comportamiento, salida restringida, credenciales segmentadas y registros completos de la ejecución de herramientas.