ARTEX: cómo un framework de pentest con IA gratuito se convirtió en un básico de los atacantes

Resumen

• ARTEX es un framework de pruebas de penetración con IA multiagente y código abierto: un backend en Go con una consola Next.js y una base de datos PostgreSQL, publicado en GitHub en julio de 2026. Un operador aporta un objetivo y una meta; agentes planificadores y trabajadores ejecutan las herramientas y registran activos, hallazgos y evidencias en un grafo compartido.
• En tres meses se usó contra bancos surcoreanos, en el compromiso de la cadena de suministro de ConnectWise Cloud Backup, en una campaña de VAPOR PANDA contra más de 200 organizaciones en 14 países y por un grupo cibercriminal con base en Camboya que Microsoft sigue como Storm-3358.
• El autor cerró el código el 8 de octubre de 2026. Wiz Research contó entonces más de 12,000 forks, y escaneos independientes de principios de noviembre encontraron entre unas 800 y 1,650 consolas expuestas, según lo que contara cada escáner.
• El framework no necesita una vulnerabilidad de software para llegar al acceso a la nube. Los responsables de incidentes de Unit 42 vieron a operadores convertir páginas de restablecimiento de contraseña y API expuestas en acceso a la nube en tan solo un día.
• Su firma es la velocidad y la repetición, no el sigilo: pulverizaciones de contraseñas a alrededor de un intento por segundo, ráfagas de 20 a 60 minutos, rotación de IP y de user-agent, y sesiones de 24 a 30 horas.
• Busque los artefactos: user-agents norma/0.4 y artex-enrich/1.0, descargas de source maps seguidas de llamadas a rutas de API internas, JWT alg:none y sondeo de callbacks OAuth.
• Cierre toda consola ARTEX que posea y después trate la identidad como el perímetro: consentimiento de aplicaciones, credenciales de service principals, asignaciones de roles y autenticación heredada.
• Es una herramienta de doble uso, no una CVE. CISA KEV: no aplicable (sin CVE; evaluado el 13 de noviembre de 2026). La mayoría de los intentos fallaron; el peligro es el coste de volver a intentarlo.

¿Por qué importa ARTEX ahora?

ARTEX importa porque automatizó la parte cara de las pruebas de penetración: encadenar debilidades ordinarias a velocidad de máquina. En los tres meses siguientes a su publicación en GitHub en julio de 2026 se usó contra bancos surcoreanos, en un compromiso de la cadena de suministro y en una campaña de espionaje contra 200 objetivos. Wiz Research informa de que un desarrollador chino lo publicó, de que ganó el reto de red team «Agent+» de Baidu en septiembre y de que se cerró el código el 8 de octubre, después de que los atacantes ya lo hubieran usado contra bancos surcoreanos (Wiz Research, 22 de octubre de 2026).

Es una trayectoria corta para una herramienta de seguridad. En noviembre, Microsoft había publicado dos informes sobre actores que la usan, CrowdStrike otros dos, la policía de Seúl había descrito un caso penal construido sobre ella y escáneres independientes contaban las consolas expuestas por miles. La herramienta no creó una nueva clase de vulnerabilidad. Cambió la velocidad a la que se pueden probar, reintentar y encadenar debilidades ordinarias.

El cambio importante es económico. Un pentester humano está limitado por sus horas, su atención y su habilidad. Una flota de agentes está limitada por tokens, proxies y objetivos. La evaluación de Microsoft de una campaña encontró varios casos en los que el tiempo entre el objetivo inicial y el acceso privilegiado a la nube fue inferior a tres horas (Microsoft, 21 de octubre de 2026). Unit 42 describe a operadores convirtiendo páginas públicas de restablecimiento de contraseña y API expuestas en acceso a la nube «a veces en menos de un día», sin explotar una sola vulnerabilidad de software (Unit 42, 11 de noviembre de 2026).

¿Qué es ARTEX?

ARTEX es un sistema de orquestación de agentes, herramientas y evidencias, no un escáner con un LLM atornillado. Un fork público del proyecto publica un README que describe un monolito en Go que incrusta un frontend Next.js, una base PostgreSQL y un runtime de agentes construido sobre el SDK norma del autor (README de ARTEX, un fork público del proyecto original). Cuatro roles comparten el trabajo: un agente Goals descompone el objetivo y extrae el alcance, un Planner produce la siguiente intención, los agentes Worker ejecutan herramientas y un MainAgent mantiene a un humano en el bucle.

Dos grafos sostienen el estado. El grafo de activos es global y compartido entre tareas: dominios raíz, subdominios, IP, servicios, aplicaciones y endpoints, agrupados por empresa. El grafo de exploración es por tarea: metas, intenciones, hechos, hallazgos y pistas, unidos por aristas como spawns, derived_from, yields y proves. Los agentes consultan ambos grafos como herramientas, de modo que un hecho descubierto por un worker se convierte en contexto para el siguiente plan.

El framework incluye lo que un operador necesita para llevar a cabo una campaña desde un navegador: un panel de tareas, un mapa de cobertura de activos, un proxy MITM que graba el tráfico con su propia CA, una pantalla de aprobación e interceptación de herramientas, soporte de servidores MCP, «skills» reutilizables, memoria de agentes y un instalador de un clic que arranca un contenedor Docker en el puerto 8787 (README). La imagen por defecto incluye ripgrep, curl, vim, npm y nmap. Microsoft añade que los agentes usan wget, clientes HTTP de Python y Chromium headless mediante Playwright por defecto (Microsoft); Wiz observó Impacket; Zscaler observó sqlmap y jadx en la compilación personalizada de un operador (Zscaler ThreatLabz).

Ese empaquetado es el punto. Una herramienta que antes exigía un equipo, una metodología y una plantilla de informe ahora arranca con docker compose up -d y una clave de API. Las mismas propiedades que la hacen útil para un tester autorizado la hacen útil para alguien que no está autorizado en absoluto.

Una breve historia de una herramienta que superó a su autor

ARTEX estuvo público menos de tres meses antes de que su autor lo retirara. La secuencia importa porque cada paso amplió la población que podía ejecutarlo.

• Julio de 2026: el proyecto se publica en GitHub como framework de código abierto con licencia AGPL-3.0 (Wiz; Security Affairs).
• Septiembre de 2026: Wiz informa de que ganó el reto de red team «Agent+» de Baidu. A finales de septiembre, entidades financieras surcoreanas empiezan a denunciar intrusiones; CrowdStrike vinculará después una consola ARTEX a la campaña.
• 8 de octubre de 2026: a las 10:50 UTC el autor publica un aviso de que la herramienta ha sido abusada, de que pasará a código cerrado y de que no habrá más versiones. El proyecto pasa a privado (BadByte, 4 de noviembre de 2026).
• 11 de octubre de 2026: Genians informa de que el repositorio de GitHub y la imagen Docker se han eliminado. Los forks y espejos permanecen (Security Affairs).
• Noviembre de 2026: unos 34 namespaces de Docker Hub publican imágenes llamadas artex, con unas 60,000 descargas combinadas. AntiFox, un fork de ARTEX 0.1.1, se usa en intrusiones de robo de credenciales de AWS y sigue en GitHub en la versión 2.0 (BadByte; BleepingComputer, 11 de noviembre de 2026).

Cerrar el código eliminó al mantenedor, no la capacidad. Wiz contó más de 12,000 forks cuando el proyecto pasó a privado. El ecosistema Docker llenó el hueco: BadByte encontró 34 namespaces publicando imágenes ARTEX, y el repositorio clon más popular no era una continuación limpia sino una versión troyanizada. Una imagen con backdoor, tomicdd/artex, añadía un manejador de inicio de sesión sin autenticación que ejecutaba comandos de shell como root y devolvía la salida; Docker la retiró el 5 de noviembre, pero 637 repositorios de GitHub seguían apuntando a ella ese día. Cubrimos ese incidente por separado en Malicious ARTEX Docker Image Hands Out Root Shells.

La ironía es útil para los defensores. Quien instala una herramienta ofensiva desde una imagen no verificada hereda los mismos riesgos que pretende explotar: una consola sin parches, un contenedor root, secretos en texto claro y un puerto público. El ecosistema ARTEX es ahora tanto una plataforma de ataque como un objetivo de cadena de suministro.

¿Cómo son los ataques?

Las campañas difieren en motivo y técnicas, pero comparten un patrón: encontrar una aplicación expuesta a Internet, usar flujos de identidad en lugar de corrupción de memoria y dejar que el agente itere hasta que algo se abra. La tabla no es una lista completa; es lo que establece la información pública.

Corea del Sur: un operador, tres modelos nombrados y una consola abierta

El informe de CrowdStrike del 7 de octubre describe una campaña contra bancos surcoreanos que comenzó a finales de septiembre. El actor dejó una consola ARTEX y directorios abiertos con historiales de sesiones de Claude Code, archivos de configuración de ARTEX y archivos de memoria de Claude. La instancia usaba DeepSeek v4.1 Flash como modelo principal, complementado con GLM-5.3 y Grok 4.6 para sesiones de Claude Code, y llegaba a DeepSeek a través del dominio revendedor xcai[.]pro (CrowdStrike).

Los propios archivos del operador aportaron la atribución. Un prompt de currículum contenía un nombre, un teléfono, un identificador de Telegram, una edad, una universidad y una ubicación; CrowdStrike advierte de que los detalles no pueden vincularse de forma definitiva al actor y de que una fecha de nacimiento del prompt contradecía a otra. Las sesiones también mostraban al operador preguntando a Claude dónde se venden los datos de brechas coreanos y qué grupos de Telegram abordar. BleepingComputer informa de que los bancos incluían Shinhan, KB Kookmin y Hana, de que se expusieron datos personales e información de tarjetas y de que algunos sistemas sufrieron caídas (BleepingComputer, 10 de octubre de 2026).

El seguimiento de Hunt.io añade el detalle de la infraestructura. La consola en 38.244.50[.]120 estaba en la red de Cogent en Los Ángeles con 15 puertos abiertos; la página de inicio de ARTEX aparecía en 443 y 8090 junto a una consola de administración Gemini2API y un servidor Tinyproxy. Un servidor de salto en Hong Kong albergaba 105 MB de herramientas, incluidos scripts que mantenían túneles SSH inversos, un script de consulta a FOFA, una lista de proxies rotativos y 19 skills personalizados con 147 usos registrados que cubrían auditoría de código, inyección web, elusión de WAF, pruebas de autenticación, Telegram Mini Apps, descompilación de APK y lógica de pagos (Security Affairs).

Storm-0940: de un escaneo a un compromiso de la cadena de suministro

Microsoft evalúa que Storm-0940, un actor alineado con el Estado chino y activo desde 2021, usó ARTEX ya en septiembre de 2026 contra cientos de organizaciones de aeroespacial, automoción, química, energía, servicios financieros, gobierno, legal, manufactura, medios, militar, semiconductores, software, tecnología y think tanks. Varias intrusiones alcanzaron acceso privilegiado a la nube en menos de tres horas (Microsoft).

El vínculo con la cadena de suministro es la parte que hay que estudiar. Microsoft evalúa que Storm-0940 fue responsable del compromiso de ConnectWise Cloud Backup, una aplicación multi-tenant. Tras adquirir las identidades de varias aplicaciones cloud de ConnectWise, los agentes se autenticaron en entornos de clientes con las credenciales robadas y pasaron a Microsoft Graph: reconocimiento, cambios de credenciales de aplicación para persistir, cambios de identidades, grupos y roles privilegiados, y lecturas masivas de secretos en Azure Key Vaults.

La pulverización de contraseñas paralela muestra el ritmo. Entre el 10 y el 14 de octubre, la infraestructura en 144.172.64[.]99 atacó 327 cuentas de ocho organizaciones. Microsoft registró más de 151,000 inicios de sesión fallidos, con un pico de 2,900 fallos por minuto el 11 de octubre y más de 111,000 fallos en un solo día. Cuarenta y ocho cuentas recibieron más de 1,000 fallos, y los bloqueos supusieron casi el 98 % de la actividad. No se observó ninguna autenticación correcta, emisión de token, llamada a Graph ni cambio de directorio en esa pulverización. El acceso a la cadena de suministro vino de las credenciales de aplicación robadas, no de adivinar una contraseña.

Esa distinción importa para los defensores. Una pulverización de contraseñas hace ruido y a menudo falla. Una aplicación multi-tenant de confianza que inicia sesión con una credencial válida es silenciosa, porque se supone que está ahí. La ventaja del agente es que puede hacer ambas cosas a la vez.

VAPOR PANDA: 200 objetivos en 11 días

El informe de CrowdStrike del 29 de octubre describe a otro actor vinculado a China, VAPOR PANDA, usando ARTEX desde el 17 de octubre contra más de 200 organizaciones en al menos 14 países durante una ventana de 11 días. Los objetivos incluían ministerios de Asuntos Exteriores de América Latina, Europa, Asia y Oriente Medio; organizaciones de semiconductores, defensa y think tanks en Estados Unidos; y operadores de telecomunicaciones en varias regiones. CrowdStrike confirmó post-explotación en nueve organizaciones y pulverización de credenciales contra al menos 12 más (CrowdStrike).

El detalle técnico es inusualmente concreto. En una farmacéutica estadounidense, el agente encadenó una aserción SAML sin firmar y un fallo XXE para consultar el servicio de metadatos de instancia de la nube, obtuvo un rol capaz de emitir comandos de administración a miles de instancias y escaló a una cuenta de administrador empresarial. En una segunda, desplegó webshells, abusó de un servicio de orquestación sin autenticación para obtener root en un contenedor de producción, leyó contraseñas LAPS y abusó de delegación restringida basada en recursos. Contra una entidad gubernamental griega, el operador aportó un export de directorio de 2022; el agente usó las claves sin rotar para falsificar un token de administrador y luego configuraciones VPN encontradas en correos enviados de un usuario para llegar a la red interna.

VAPOR PANDA también dirigió a los agentes para evadir defensas de endpoint. En una farmacéutica global, la instrucción era encontrar máquinas Windows del dominio sin Falcon, juzgando por tasklist y listados de carpetas, con la jerga de red team china «猎鹰» para el sensor de CrowdStrike. En una intrusión, los agentes de planificación consumieron del orden de 1,400 millones de tokens de entrada. Es un marcador de escala útil: no es una sesión de chatbot, es un presupuesto de cómputo.

Cibercrimen: el ex pentester y Storm-3358

La misma herramienta abarca ahora espionaje estatal y fraude ordinario. El 26 de octubre, BleepingComputer informó de que la policía de Seúl había identificado a siete sospechosos en una operación que comprometió más de 90 organizaciones en Corea del Sur. El líder era un hacker autodidacta de 32 años que había trabajado en una empresa de ciberseguridad entre 2019 y 2022; empezó a atacar en septiembre de 2025 y adoptó herramientas de IA a finales de agosto de 2026. En 38 incidentes, el grupo exigió 360 millones de wones (unos 270,000 dólares) para no difundir los datos robados. La policía lo describió como la primera detención coreana en un caso de piratería y robo de datos personales a gran escala que explotaba IA generativa (BleepingComputer).

El informe de Microsoft del 6 de noviembre añade la capa criminal profesional. Storm-3358 es un grupo de intrusión con base en Camboya que ataca principalmente entidades financieras del sudeste asiático, además de un número menor de grandes entidades financieras globales. En octubre de 2026 usó ARTEX junto a automatización convencional para escanear sistemas conectados a Internet, explotar la carga de archivos anónima y SSRF, e instalar los troyanos de acceso remoto WISP, vshell y AdaptixC2, con agentes que usaban netcat y curl para descargarlos (Microsoft).

La cola larga: WorkOS y AntiFox

No todos los incidentes necesitan un Estado-nación. WorkOS reveló el 30 de octubre que un atacante accedió a una aplicación interna de ventas y se llevó datos de contacto profesionales, historiales de cuentas de clientes y resúmenes de conversaciones comerciales y de soporte. El fundador de la empresa atribuyó la intrusión a ARTEX y dijo que los investigadores vieron los user-agents artex-enrich/1.0 y norma/0.4 en las peticiones web (BleepingComputer, 3 de noviembre de 2026).

AntiFox muestra hacia dónde van los forks. Arctic Wolf observó hosts de Alibaba Cloud ejecutando interfaces AntiFox y usando identidades de AWS válidas, incluidos usuarios IAM y roles EC2 asumidos, para hacer llamadas autenticadas a la API. En un caso, el operador desplegó un webshell ASPX en un servidor IIS expuesto a Internet, leyó la configuración de la aplicación y las cadenas de conexión a la base de datos, y copió archivos de configuración y logs a un directorio accesible por web. En otro, rotó identidades e hizo cientos de peticiones a la API de AWS en unos 30 minutos; la mayoría se bloquearon, pero algunas obtuvieron secretos de producción, y un incidente separado usó una identidad válida para leer, copiar y borrar objetos S3 (BleepingComputer).

¿Qué hacen realmente los agentes?

El análisis de logs de Wiz es la descripción pública más clara del bucle. En varias víctimas, el primer movimiento del agente fue leer la aplicación: descargar source maps de JavaScript, config.json, env.js y el documento OpenAPI, y luego llamar a rutas de API internas cuyos nombres solo aparecen en esos archivos (Wiz). Esa secuencia es una huella. Un navegador carga un bundle; no descarga main-3a9f.js.map y luego adivina GeneratePasswordResetToken dos minutos después.

El playbook se repite:

1. Mapear la aplicación. Los source maps, la configuración de ejecución y los documentos Swagger/OpenAPI revelan rutas, parámetros y funcionalidad oculta.
2. Sondear la autenticación. El agente inicia flujos de inicio de sesión, muta callbacks OAuth y parámetros state, envía JWT sin firmar y varía rutas SSO. Wiz registró más de 60 variantes de rutas SSO con un token alg:none en dos minutos.
3. Abusar de la recuperación de cuenta. Comprueba si existe un nombre de usuario y luego llama a endpoints de restablecimiento de contraseña, recuperación de nombre y activación. Un 204 de un endpoint de token de restablecimiento es una señal útil aunque no llegue ningún correo.
4. Registrarse y probar el aislamiento de tenants. Donde el registro está abierto, usa un buzón desechable, confirma la cuenta y pide inmediatamente datos de otra empresa manipulando identificadores predecibles.
5. Establecer una línea base. Antes de hacer fuzzing, pide una ruta inexistente como /zzz-nonexistent-xyz123 para aprender cómo es un 404 real.
6. Pulverizar y adaptarse. Las pulverizaciones corren con una separación mediana de un segundo, en ráfagas de 20 a 60 minutos, con un user-agent distinto por ráfaga y foco en cuentas de ingenieros de software. Cuando se bloquea una IP, aparece otra en minutos; cuando se limita un endpoint, el agente cambia a otro endpoint del mismo host.

La tabla relaciona esos comportamientos con lo que un defensor puede recoger realmente.

Otros dos comportamientos son fáciles de pasar por alto. El agente usa clientes programáticos corrientes (python-urllib/3.12, python-requests/2.31.0, curl/7.88.1, norma/0.4, artex-enrich/1.0) y cadenas de Chrome trivialmente falsificables. Los user-agents por sí solos hacen ruido. La secuencia es la señal: una descarga de source map, una ruta interna, un token alg:none, una llamada de restablecimiento y una pulverización, todo desde el mismo ASN en una hora, no es un navegador.

¿Por qué funciona?

Cuatro propiedades explican la adopción.

No necesita una vulnerabilidad para llegar a la nube. Los responsables de Unit 42 describen las páginas de restablecimiento de contraseña y las API expuestas como el camino al acceso a la nube, sin explotar ninguna vulnerabilidad de software. Los flujos de identidad están diseñados para ser accesibles desde Internet; eso es lo que los hace útiles y lo que los hace atacables.

El coste marginal es bajo. Check Point Research analizó a un operador que ejecutó dos consolas ARTEX durante unas dos semanas contra diez tiendas de firmas de código iOS del mercado gris, con DeepSeek v4.1 Flash y Kimi K3.1 Pro. El operador consumió 36,000 millones de tokens; a los precios oficiales de la API de DeepSeek, Check Point estima el coste de cómputo entre 700 y 1,500 dólares (Check Point Research, 5 de noviembre de 2026). Los certificados .p12 robados y sus contraseñas en texto claro son el inventario de las tiendas de firma que el operador estaba saqueando. La herramienta es gratuita; los modelos son una commodity; la lista de objetivos es pública.

Las barreras forman parte del enrutamiento. Check Point encontró modelos chinos dominando las configuraciones de los operadores, con DeepSeek Flash como el más frecuente. En las tres instancias con modelos estadounidenses configurados, los únicos rechazos observados vinieron de Opus 5.5 de Anthropic, y el operador cambió a modelos chinos más permisivos. La elección de modelo no es una declaración ideológica; es un parámetro operativo, y el agente rodeará un rechazo igual que rodea una IP bloqueada.

La identidad es el plano de control. Cada campaña descrita en este artículo dependió en algún momento de credenciales, tokens o roles: una aplicación OAuth, una aserción SAML, un rol IMDS, una contraseña LAPS, una configuración VPN, un secreto de Key Vault, un usuario IAM. El agente no necesita romper la criptografía. Necesita una relación de confianza válida y suficientes intentos para encontrarla.

La población de consolas expuestas es la otra mitad de la historia. Los escaneos independientes de principios de noviembre discrepan porque cuentan cosas distintas: Censys contó más de 800 despliegues accesibles sin inicio de sesión (TechCrunch, 6 de noviembre de 2026); Check Point contó 2,557 sistemas que alojaban o habían alojado un panel, con 1,608 en vivo y públicos en el momento de su investigación; BadByte contó 1,645 hosts sirviendo la consola ARTEX el 4 de noviembre; Hunt.io contó unos 1,300 hosts haciendo coincidir el título de la página de la consola, según Security Affairs. Una consola expuesta no es solo una víctima. Guarda listas de objetivos, credenciales, tráfico capturado y una clave de CA de proxy, y es un servidor de salto listo para usar.

¿Qué temer durante el próximo año?

La trayectoria más probable no es una única campaña ARTEX catastrófica. Es la mercantilización.

• Más frameworks, no uno. Unit 42 contó 1,323 hosts expuestos a Internet ejecutando CyberStrikeAI y 609 ejecutando ARTEX en octubre de 2026, con 21 hosts ejecutando ambos, y analizó 14 herramientas del ecosistema (Unit 42). Check Point cita CyberStrike, Cairn y PentAGI junto a ARTEX. Cerrar un proyecto no cierra la categoría.
• Forks baratos con nuevos objetivos. AntiFox tomó ARTEX 0.1.1 y lo apuntó a identidades de AWS. El siguiente fork apuntará a lo que sepa su autor: Kubernetes, API de administración SaaS, CI/CD, OSS de telecomunicaciones. El framework es una cáscara; los skills y los prompts son la carga útil.
• El acceso a la cadena de suministro como multiplicador. ConnectWise es la plantilla. Un proveedor comprometido o una credencial de aplicación multi-tenant robada dan a un agente una ruta de confianza hacia todos los tenants aguas abajo a la vez. La mayoría de las organizaciones no ve esa ruta porque se parece al proveedor.
• Actores estatales y criminales en la misma herramienta. Storm-0940, VAPOR PANDA, Storm-3358 y el grupo del ex pentester usaron el mismo framework con fines distintos. Esa convergencia comprime el tiempo entre la aparición de una técnica en el espionaje y su uso en el fraude.
• La ventana de alerta del defensor se encoge. Microsoft señala que la automatización genera más tráfico y más alertas, pero la velocidad deja poco tiempo para responder antes de que el actor tenga persistencia. Un agente que alcanza acceso privilegiado en tres horas superará una cola de triaje medida en días.
• Las consolas expuestas siguen siendo un suministro de infraestructura de ataque. Una consola sin autenticación es un punto de salto, un almacén de credenciales y una fuente de datos de objetivos ajenos. La población es lo bastante grande como para que escanear consolas sea en sí mismo un negocio.

El contrapeso es que los agentes actuales hacen ruido y a menudo fallan. Microsoft dice que la mayoría del ataque de Storm-0940 no tuvo éxito. Unit 42 vio a Cairn generar cientos de miles de peticiones de alta frecuencia desde una sola IP de origen. La velocidad crea oportunidades de detección a la vez que presión.

¿Cómo deben prepararse los defensores?

El orden importa. Empiece por las consolas, luego la identidad y después la materia prima que consumen los agentes.

1. Encuentre y cierre las consolas ARTEX y similares. Busque en su inventario de activos y en los logs de salida el título de la consola, el puerto por defecto 8787 y los build IDs. Si una consola está expuesta, trátela como comprometida: guarda listas de objetivos, credenciales, tráfico capturado y una clave privada de CA de proxy. Retire el acceso público, ponga la administración detrás de una VPN o una lista de permitidos, rote la contraseña de PostgreSQL, las claves de LLM, las claves de API de búsqueda, los webhooks de notificación y las credenciales de proxy, y sustituya jwt.key, que puede falsificar tokens de administrador.

2. Trate la identidad como el perímetro. Imponga MFA resistente al phishing, bloquee la autenticación heredada y revise las políticas de acceso condicional. Audite los registros de aplicaciones y las aplicaciones empresariales: quién dio consentimiento, qué permisos se concedieron, qué credenciales se añadieron y qué service principals se asignaron un rol. La guía de Microsoft sobre ConnectWise es precisa: preserve la configuración y las evidencias antes de borrar una aplicación, inventaríe los ID de aplicación afectados y revise los inicios de sesión de service principals desde al menos el 15 de octubre, ampliando al 1 de octubre cuando los registros lo permitan.

3. Cace la secuencia agéntica, no el user-agent. Cree detecciones para una descarga de source map o config.json seguida de llamadas a rutas internas; JWT alg:none y state OAuth malformados; enumeración de usuarios seguida de llamadas de restablecimiento; registros con correo desechable seguidos de sondeo de ID de objetos; una sonda 404 de línea base antes de una ráfaga de fuzzing; e inicios de sesión fallidos a alrededor de uno por segundo en muchas cuentas. Mantenga juntos las tasas por IP y por cuenta, el ASN, el timing y la ruta.

4. Retire la materia prima. No sirva source maps, env.js, config.json ni documentos Swagger desde producción salvo que lo pretenda. Saque los secretos de los bundles de cliente y de los repositorios; rote todo lo que se haya commiteado. Exija IMDSv2, mantenga las claves de acceso de larga duración fuera de la configuración de la aplicación y limite los roles de instancia al mínimo. Son los mismos arreglos que derrotaban la versión manual de estos ataques; siguen funcionando.

5. Detecte la post-explotación. Vigile las adiciones de credenciales de aplicación, los nuevos service principals o propietarios, las asignaciones de roles, la autoasignación de Global Administrator y las llamadas SecretGet masivas en varios Key Vaults en poco tiempo. Vigile webshells, descargas con netcat/curl hacia raíces web, nuevas tareas cron, tráfico LDAP/JNDI, callbacks DNS y accesos inusuales a correo o archivos. Los marcadores de caza de CrowdStrike para una campaña incluían líneas de comando con artx, roles cloud con prefijo artx-, comentarios de comandos de administración con art18- y el directorio C:\ProgramData\artx5v\.

6. Ralentice al agente. Las pruebas de Microsoft mostraron que honeypots, señuelos, tarpits y falsas victorias reducían el tráfico de ataque que llegaba a los activos reales y producían una señal de atribución de alta confianza. Un tarpit consume el tiempo y el presupuesto del agente; una falsa victoria puede hacerle parar en un falso éxito. No sustituye al parcheo, pero cambia la economía de una campaña desatendida.

7. Ensaye la respuesta. Decida de antemano quién puede desactivar una aplicación de proveedor, revocar sesiones y rotar claves, y en qué orden. Preserve los logs antes de la contención. Asuma que los datos accesibles por la identidad comprometida fueron leídos y notifique sobre esa base en lugar de esperar una prueba de exfiltración.

¿Qué no significa esto?

• No todas las consolas expuestas son maliciosas. Muchas son de testers autorizados que dejaron un laboratorio en Internet. Silas Cutler, de Censys, lo dice explícitamente. El problema es la exposición, no la intención de cada operador.
• La mayoría de los intentos fallan. Microsoft no observó ninguna autenticación correcta en la pulverización de 151,000 eventos y dice que la mayoría del ataque de Storm-0940 no tuvo éxito. Los agentes son persistentes, no omnipotentes.
• Una herramienta no es una campaña. ARTEX ha sido usado por un actor estatal, un grupo de espionaje distinto, un grupo criminal y un ex pentester individual. La atribución pertenece al operador, no al framework.
• Las técnicas no son nuevas. Wiz señala que ninguna de las técnicas individuales observadas era nueva. Lo nuevo es el encadenamiento, el ritmo y la resistencia.
• Los recuentos no son comparables. Censys, Check Point, BadByte y Hunt.io midieron poblaciones distintas en días distintos. No los promedie ni trate uno como el total verdadero.

¿Qué no se pudo verificar?

• Los recuentos exactos de estrellas y forks originales. Wiz informa de más de 12,000 forks en el cierre; la página de GitHub del repositorio desapareció y no se pudo recuperar una instantánea archivada durante esta investigación.
• La victoria en el reto «Agent+» de Baidu la informa Wiz Research; no encontramos un anuncio primario de Baidu o ARTEX.
• El número de registros robados en el caso de la policía de Seúl. El cuerpo del artículo de BleepingComputer dice 8.2 millones; su titular dice 82 millones. No usamos ninguna de las dos cifras en este artículo.
• Si Storm-3358 y Storm-0940 se solapan, o si el actor de los bancos coreanos está relacionado con alguno. Microsoft y CrowdStrike describen grupos distintos.
• La población exacta de consolas expuestas. Los recuentos publicados van de más de 800 a 1,645, y cada uno usa una definición distinta.
• El linaje de AntiFox más allá del fork reportado de ARTEX 0.1.1, y quién opera la infraestructura de Alibaba Cloud.
• Si el cierre del código redujo el mal uso. Los forks, espejos e imágenes Docker ya eran públicos.

Cronología

• Julio de 2026: ARTEX se publica en GitHub como framework de código abierto.
• Septiembre de 2026: Wiz informa de su victoria en el reto de red team «Agent+» de Baidu; entidades financieras surcoreanas empiezan a denunciar intrusiones.
• 7 de octubre de 2026: CrowdStrike publica su análisis de la campaña coreana.
• 8 de octubre de 2026: el autor anuncia el paso a código cerrado; el proyecto pasa a privado.
• 16 de octubre de 2026: ConnectWise publica su aviso inicial sobre Cloud Backup.
• 17-28 de octubre de 2026: VAPOR PANDA usa ARTEX contra más de 200 organizaciones en 14 países.
• 26 de octubre de 2026: la policía de Seúl anuncia siete sospechosos y más de 90 organizaciones comprometidas.
• 4 de noviembre de 2026: BadByte publica el análisis de la imagen Docker con backdoor; se cuentan 1,645 consolas ARTEX en línea.
• 6 de noviembre de 2026: Microsoft informa de que Storm-3358, un grupo con motivación económica, usa ARTEX contra entidades financieras.
• 11 de noviembre de 2026: Arctic Wolf y BleepingComputer describen AntiFox, un fork, usado en el robo de credenciales de AWS.

Preguntas frecuentes

¿ARTEX es una vulnerabilidad o una CVE?

Ninguna de las dos. Es un framework de pruebas de penetración de doble uso. Una búsqueda por palabra clave en el NVD de artex no devolvió registros el 13 de noviembre de 2026 (NVD), y las intrusiones descritas aquí explotaron clases conocidas de debilidad: API expuestas, MFA débil o ausente, flujos de restablecimiento de contraseña, SSRF, aserciones SAML sin firmar, JWT alg:none, IDOR y credenciales filtradas.

¿ARTEX ataca aplicaciones móviles?

La información pública describe aplicaciones web, proveedores de identidad, API en la nube y hosts Windows y Linux locales. Hunt.io recuperó código fuente de sonda para iOS, utilidades de kernel y firmware de Android y una herramienta para un exchange de criptomonedas en el directorio de un operador, pero su relación con las brechas confirmadas no está establecida. Es más probable que los parques móviles se alcancen a través de las API de backend y los flujos de identidad que atacan los mismos agentes.

¿Se puede detectar bloqueando user-agents?

No de forma fiable. Los operadores rotan los user-agents, y Wiz registró 15 cadenas distintas en las víctimas, incluidas cadenas de Chrome ordinarias y python-urllib. Use los user-agents como una señal débil y correlaciónelos con la secuencia de peticiones, el ritmo y la ruta.

¿Es seguro ejecutar ARTEX para pruebas autorizadas?

Solo si lo trata como un servicio de alto riesgo. La consola no tiene autenticación más allá de su formulario de inicio de sesión (BadByte), el contenedor corre como root, el archivo compose publica el puerto 8787 en todas las interfaces y los secretos se guardan en texto claro. Póngala detrás de una VPN, restrinja la salida, use un host dedicado, rote sus claves y nunca la instale desde una imagen no verificada.

¿Cuál es el control más útil?

Cerrar las superficies de administración e identidad expuestas a Internet. El punto de Unit 42 es que estos agentes no pueden atacar lo que no encuentran. Cada consola que retire, cada source map que deje de servir y cada flujo de restablecimiento que limite reduce el conjunto de caminos que un agente puede probar a velocidad de máquina. Si solo va a hacer una cosa, empiece por la lista de búsqueda de consolas de «¿Cómo deben prepararse los defensores?»; la imagen troyanizada se trata en el artículo separado sobre el backdoor de ARTEX.

Referencias

• Microsoft Threat Intelligence, «AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise», 21 de octubre de 2026: https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/ (verificado el 2026-11-13)
• Microsoft Threat Intelligence, «ARTEX abuse expands as cybercriminals target financial sector», 6 de noviembre de 2026: https://www.microsoft.com/en-us/security/blog/2026/11/06/artex-abuse-expands-as-cybercriminals-target-financial-sector/ (verificado el 2026-11-13)
• Wiz Research, «ARTEX in the Wild: Storm-0940 Expands Targeting of IT and Software Vendors», 22 de octubre de 2026: https://www.wiz.io/blog/artex-in-the-wild-storm-0940-expands-targeting-of-it-and-software-vendors (verificado el 2026-11-13)
• CrowdStrike, «Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance», 7 de octubre de 2026: https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/ (verificado el 2026-11-13)
• CrowdStrike, «VAPOR PANDA Uses AI-Driven ARTEX to Grow Global Espionage Campaign», 29 de octubre de 2026: https://www.crowdstrike.com/en-us/blog/vapor-panda-uses-artex-to-scale-global-campaign/ (verificado el 2026-11-13)
• Check Point Research, «Hacking on Autopilot: Inside ARTEX Cybercrime Campaigns», 5 de noviembre de 2026: https://research.checkpoint.com/2026/hacking-on-autopilot-inside-artex-cybercrime-campaigns/ (verificado el 2026-11-13)
• Unit 42, «ARTEX and AI-Powered Red Teaming Tools: What Defenders Need to Know», 11 de noviembre de 2026: https://unit42.paloaltonetworks.com/artex-and-ai-powered-red-teaming-tools/ (verificado el 2026-11-13)
• Zscaler ThreatLabz, «Inside the Global AI-Assisted Hacking Campaign»: https://www.zscaler.com/blogs/security-research/inside-global-ai-assisted-hacking-campaign (verificado el 2026-11-13)
• Security Affairs, «Inside ARTEX: AI Hacking Tools, Exposed Servers and South Korean Bank Breaches», 7 de noviembre de 2026: https://securityaffairs.com/184100/cyber-crime/inside-artex-ai-hacking-tools-exposed-servers-and-south-korean-bank-breaches.html (verificado el 2026-11-13)
• BleepingComputer, «Hacker used ARTEX AI and Claude agents to target South Korean banks», 10 de octubre de 2026: https://www.bleepingcomputer.com/news/security/hacker-used-artex-ai-and-claude-agents-to-target-south-korean-banks/ (verificado el 2026-11-13)
• BleepingComputer, «Former pentester used ARTEX AI to steal 8.2 million data records», 26 de octubre de 2026: https://www.bleepingcomputer.com/news/security/former-pentester-used-artex-ai-to-steal-82-million-data-records/ (verificado el 2026-11-13)
• BleepingComputer, «WorkOS says attacker used ARTEX AI to breach internal sales app», 3 de noviembre de 2026: https://www.bleepingcomputer.com/news/security/workos-says-attacker-used-artex-ai-to-breach-internal-sales-app/ (verificado el 2026-11-13)
• BleepingComputer, «Hackers use AntiFox AI agents in AWS credential-theft attacks», 11 de noviembre de 2026: https://www.bleepingcomputer.com/news/security/hackers-use-antifox-ai-agents-in-aws-credential-theft-attacks/ (verificado el 2026-11-13)
• BadByte, «ARTEX Backdoor: 7,946 Pulls of a Trojanized Docker Image Handing Out Root Shells», 4 de noviembre de 2026, actualizado el 5 de noviembre de 2026: https://badbyte.io/artex-backdoor-docker-image/ (verificado el 2026-11-13)
• TechCrunch, «Hundreds of Artex AI hacking tools found publicly exposed to the web», 6 de noviembre de 2026: https://techcrunch.com/2026/11/06/hundreds-of-artex-ai-hacking-tools-found-publicly-exposed-to-the-web/ (verificado el 2026-11-13)
• README de ARTEX, fork público del proyecto original: https://github.com/horizonl/ARTEX (verificado el 2026-11-13)
• Búsqueda por palabra clave en el NVD de artex, cero registros el 2026-11-13: https://nvd.nist.gov/vuln/search/results?query=artex&search_type=all (verificado el 2026-11-13)