ARTEX y el salto de los agentes ofensivos: cuando el harness importa mas que el modelo

Durante años, la conversación sobre IA ofensiva se concentró en una pregunta casi infantil: "qué modelo sabe más hacking". La campaña observada contra entidades financieras de Corea del Sur a finales de septiembre y comienzos de octubre de 2026 obliga a cambiar esa pregunta. El punto central ya no es si un LLM puede sugerir un payload, reconocer un stack o improvisar una cadena de ataque. El punto central es que ahora existen harnesses capaces de convertir esa capacidad parcial en una operación continua, persistente y distribuida.

ARTEX es un buen ejemplo de ese salto. No es simplemente un chatbot con acceso a Bash. Es una plataforma de ejecución para agentes ofensivos: backend en Go, frontend Next.js, PostgreSQL, proxy de tráfico, transcripts persistentes, workers concurrentes, graph storage, MCPs, skills y un SDK de agentes llamado norma que resuelve el bucle completo de reasoning, tool use, control de contexto y continuidad.

La campaña contra bancos coreanos es importante precisamente porque muestra que el riesgo no vive solo en el modelo, sino en la infraestructura que lo rodea. CrowdStrike describió una actividad activa entre finales de septiembre y principios de octubre de 2026 contra organizaciones financieras surcoreanas, con exfiltración de datos y uso de ARTEX junto a LLMs. El actor dejó expuestos directorios con historiales de Claude Code, ficheros de configuración de ARTEX y memoria de Claude, lo que permitió reconstruir buena parte de su operativa. La investigación apunta a una arquitectura de dos servidores: uno principal controlado por el actor y otro que alojaba la instancia de ARTEX, con DeepSeek v4.1-flash como backend principal y GLM-5.3 y Grok 4.6 como modelos auxiliares. CrowdStrike no atribuye la operacion a un actor concreto, aunque la considera compatible con un actor de habla china y motivacion financiera.

Lo relevante es que ARTEX no se limita a "preguntar cosas" a un modelo. En el código, el agente se construye sobre norma, un harness genérico que expone una sesión stateful. Esa sesion recibe provider, system prompt, tools, permisos, hooks, transcript y compaction, y después entrega la ejecución a un loop de harness.Query. El loop normaliza eventos, mantiene la conversación, ejecuta herramientas, devuelve tool_result, recupera de errores de contexto, reintenta, comprime, reanuda sesiones y decide cuando el agente ha terminado.

Ese detalle es esencial. En una arquitectura tradicional, un LLM solo produce texto. En ARTEX, el LLM está enchufado a una máquina de estados operativa. Puede leer assets, reclamar intents, ejecutar herramientas, registrar facts, guardar findings, consultar trafico capturado, abrir shells, usar MCPs, reanudar transcripts y colaborar con otros agentes. El modelo ya no es una interfaz de consulta; es un componente dentro de un sistema de ejecución persistente.

La arquitectura multiagente de ARTEX tampoco es decorativa. Cada tarea arranca un planner y varios workers. El planner no ejecuta directamente la explotación; observa el estado global, decide si el objetivo está cumplido y genera nuevas intenciones de trabajo. Los workers reclaman una sola intención cada uno, la ejecutan y escriben de vuelta en dos grafos: un asset graph global y un exploration graph por tarea. Ese esquema convierte la exploración ofensiva en una cola de trabajo con memoria estructurada.

El planner dispone de una vista resumida del mundo: goals, facts, findings, coverage, intents abiertos, intents agotados y assets. Los workers, por su parte, operan sobre una única intención y devuelven hechos concretos. Cuando un worker descubre algo, ese hallazgo despierta al planner, que puede abrir nuevas líneas de trabajo o cerrar objetivos. Es, en esencia, una mini-organización ofensiva automatizada.

La peligrosidad no está solo en la concurrencia, sino en la persistencia. ARTEX conserva transcripts por agente e intent. Un worker que se pausa o se bloquea puede reanudarse más tarde en el mismo punto. El planner puede conservar todolists entre "despertares" o reanudaciones. El sistema también implementa compactación de contexto y digests del grafo para no perder continuidad cuando la ventana del modelo se agota. Eso significa que una operacion de larga duración no depende de una sola llamada al modelo: puede sobrevivir horas, días y reinicios.

Otro aspecto delicado es la superficie de herramientas. El harness de norma expone Bash, lectura y escritura de ficheros, tareas de background, web fetch, web search, tools diferidas, memory, skills y MCPs. ARTEX añade encima sus propias tools de dominio: add_intent, record_fact, report_finding, list_assets, graph_overview, traffic_search, traffic_get, traffic_blob, kill_work, steer_work y muchas más. En la práctica, el modelo no solo razona: también opera, consulta, persiste y coordina.

Hay un detalle especialmente inquietante en el código: planner y worker se lanzan con permission ModeBypass. Es decir, el harness dispone de una capa de permisos, pero ARTEX configura sus agentes principales para saltarsela y delega el control real en reglas de interceptación, constraints y el entorno de despliegue. En un laboratorio eso puede ser razonable. En manos ofensivas, reduce mucho la friccion entre decision y accion.

La lección de la campana coreana es que estos harnesses no convierten un modelo mediocre en un mago, pero si convierten pequeñas capacidades en una cadena operativa coherente. Un LLM que por separado solo sugeriría comandos pasa a formar parte de un sistema que:

  • divide objetivos
  • distribuye trabajo
  • conserva memoria
  • reanuda sesiones
  • ejecuta tools
  • registra evidencia
  • correlaciona trafico
  • cambia de modelo si uno falla
  • y mantiene una operacion viva aunque ningún turno individual sea brillante

Por eso el riesgo real de los harnesses de IA no es que "la IA hackee sola". Es algo más mundano y mas preocupante: reducen el coste de coordinación. Automatizan las partes aburridas que antes frenaban a operadores poco disciplinados: seguimiento de estado, repetición de intentos, gestion de contexto, correlacion de evidencias, ejecución paralela y persistencia de notas. Lo que antes exigía un equipo humano coordinado puede empezar a parecerse a una cola de jobs con agentes especializados.

También introducen nuevos problemas defensivos. Un entorno así genera trazas distintas de las de un operador manual: patrones de consulta repetitiva, ejecución iterativa contra el mismo objetivo, llamadas a APIs LLM, tráfico a proxies, transcripts, uso de MCPs y una mezcla de automatización y actividad manual dificil de separar. Para un blue team, detectar un harness agéntico requiere mirar no solo IOC clasicos, sino tambien ritmos operativos, secuencias de herramientas, patrones de prompts, persistencia de sesiones y artefactos como memory files o logs de agentes.

ARTEX no es peligroso porque tenga un modelo concreto. De hecho, soporta Anthropic, OpenAI Chat Completions, OpenAI Responses y endpoints compatibles. Es peligroso porque abstrae el modelo y convierte la inteligencia en una pieza intercambiable dentro de una plataforma. Si mañana cambia DeepSeek por GPT, Claude, Grok o un endpoint privado, la arquitectura sigue funcionando igual.

Ese es el verdadero cambio de paradigma. Los modelos van y vienen; los harnesses permanecen. Y cuando un harness incorpora herramientas, memoria, concurrencia, grafo, proxies, transcripts, skills y reanudación, deja de ser una demo de IA y se convierte en infraestructura operativa.

La campaña contra bancos coreanos no debería leerse sólo como "un actor uso ARTEX". Debería leerse como una advertencia más amplia: el futuro de la ofensiva asistida por IA no sera un único modelo supercapaz, sino sistemas modulares que conectan modelos normales con buenas herramientas, buen estado y buena orquestación. Y eso, para defensa, es bastante más difícil de frenar.

Referencias

  • [^1]: CrowdStrike Intelligence, "Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance", 7 de octubre de 2026. Fuente
  • [^2]: Yonhap News Agency, "Chinese-speaking hacker possibly linked to AI-driven attacks on S. Korean banks: report", 8 de octubre de 2026. Fuente
  • [^3]: Fork analizado: Hinln/ARTEX, repositorio público basado en Autumn-27/ARTEX v0.3.15. Código fuente

Comentarios