Agentes de IA de bajo coste convierten intrusiones en comercios minoristas en una cadena de robo de tarjetas
Actor chino usa agentes IA Strix, Cairn y Hermes para vulnerar tiendas online y robar más de 600.000 tarjetas de pago en campaña barata y rápida.
Imagen ilustrativa generada con IA
Decenas de empresas, comprometidas en una campaña que se expandió rápidamente
Un actor de amenazas de habla china motivado por el lucro utiliza herramientas autónomas de IA para detectar vulnerabilidades, lanzar ataques y mantener el acceso a comercios en línea y otras organizaciones.
La campaña comenzó en julio de 2026 y desde entonces ha afectado a decenas de empresas, según la información sobre la investigación de Gambit. Entre el 10 y el 15 de septiembre, el actor puso en marcha 105 proyectos de ataque. Al menos 27 empresas resultaron comprometidas en distintos grados.
Por lo general, las intrusiones exitosas duraron menos de un día. En algunos casos, el actor consiguió acceder a los sistemas en cuestión de horas.
La operación ya ha tenido importantes consecuencias económicas y operativas. Gambit atribuyó el robo de más de 600.000 registros de tarjetas de pago vigentes a brechas en dos empresas. Más de 488.000 de esas tarjetas eran de Estados Unidos.
El atacante también instaló skimmers en tiendas en línea y obtuvo cierto nivel de acceso a una empresa hotelera incluida en Fortune 500. Entre las demás víctimas identificadas había una aerolínea estadounidense, un distribuidor de suministros industriales y una tienda de moda en línea.
El sistema no funcionaba de forma totalmente autónoma. El operador daba instrucciones breves, seleccionaba objetivos y redirigía a los agentes una vez obtenido el acceso. Sin embargo, delegó buena parte del reconocimiento, la explotación y la planificación de los ataques en tres herramientas de código abierto: Strix, Cairn y Hermes.
Strix y Cairn automatizaron el reconocimiento y la explotación
La primera fase se apoyó en Strix, una herramienta de pruebas de penetración de código abierto que busca vulnerabilidades. Del 23 al 31 de agosto, el actor ejecutó Strix 146 veces en su «modo profundo» contra 138 hosts.
El atacante accedió a la herramienta mediante OpenRouter y utilizó los modelos GLM 5.2 y DeepSeek v4 Pro. Después, los informes generados por Strix se transfirieron a Cairn, un motor autónomo de pruebas de penetración.
Cairn, configurado con DeepSeek v4.1 Flash, puso en marcha los 105 proyectos de ataque detectados entre el 10 y el 15 de septiembre. Gambit recuperó 48 informes de Cairn; los demás habían sido borrados.
En lugar de aplicar una misma cadena de explotación a todos los objetivos, Cairn seleccionaba dinámicamente las rutas de ataque mediante sondeos e intentos de explotación. Por ello, las tácticas, técnicas y procedimientos variaron en la mayoría de las víctimas.
La información disponible no identifica las vulnerabilidades concretas que se explotaron, su nivel de gravedad ni los identificadores CVE correspondientes. Tampoco se han revelado las versiones exactas del software afectado. Por tanto, los defensores no pueden asociar ninguna vulnerabilidad específica de esta campaña con el catálogo de vulnerabilidades explotadas conocidas de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos, y no consta ningún plazo federal de mitigación asociado.
La falta de CVE divulgados también significa que las organizaciones no pueden hacer frente a esta campaña instalando un único parche específico. La detección debe centrarse en cambios no autorizados, credenciales robadas, aplicaciones comprometidas y mecanismos de persistencia observados en cada víctima.
Hermes proporcionó al operador una infraestructura de ataque persistente
Para coordinar los ataques y llevar a cabo operaciones interactivas, el actor de amenazas utilizó Hermes, un agente autónomo de código abierto con memoria persistente, historial de sesiones con función de búsqueda, consola web, tareas programadas y capacidad para crear sus propias habilidades.
El atacante configuró Hermes con una personalidad de sistema en chino y 121 habilidades, 78 de ellas diseñadas para actividades ofensivas. El agente funcionaba con el modelo opus-4.6 de Anthropic.
Gambit identificó 1.951 instrucciones introducidas por un operador humano a lo largo de 260 sesiones. Por lo general, eran órdenes breves en chino que indicaban a Hermes que iniciara un ataque, eligiera el siguiente paso general o realizara una acción después de obtener acceso.
Esta división del trabajo es importante. El operador no tenía que especificar cada comando ni establecer de antemano toda la ruta de intrusión. En su lugar, la persona indicaba los objetivos y el agente conservaba el contexto, recurría a habilidades especializadas y colaboraba en las distintas fases del ataque.
Daniel Wilcock, analista de inteligencia de amenazas de Talion Cyber Security, señaló que esta actividad se diferenciaba de las demostraciones controladas de pruebas de penetración con IA. En este caso, los agentes recibían instrucciones para atacar organizaciones, seguir buscando vulnerabilidades y eliminar pruebas.
La operación también resultaba barata, ya que sus principales herramientas eran de código abierto. A partir de los registros recuperados, Gambit calculó un coste medio de 25,46 dólares en 101 análisis completados.
El robo de tarjetas abarcó desde las bases de datos hasta las páginas de pago
Los ataques buscaban obtener datos de pago por distintas vías.
En dos empresas afectadas, el actor de amenazas robó al menos 600.000 registros de tarjetas vigentes. Los investigadores encontraron una habilidad de Hermes diseñada para extraer información de tarjetas robadas de la base de datos Magento de una víctima. Se desconocen tanto las versiones exactas de Magento como el método de acceso inicial.
La manipulación de bases de datos también podía provocar daños destructivos. En otro incidente, relacionado con un comercio de bicicletas, se indicó al agente que borrara unas tablas de prueba que había creado. Sin embargo, eliminó las tablas de respaldo del comercio.
Otras víctimas fueron infectadas con skimmers que capturaban datos en las páginas de pago. Gambit confirmó inicialmente 19 organizaciones afectadas. Más adelante, en colaboración con el investigador de seguridad Varys, identificó más de 100 sitios web infectados adicionales.
Lo más habitual era que el atacante insertara el código del skimmer en un archivo JavaScript existente, aunque los métodos de instalación variaban considerablemente. También se introdujo código malicioso mediante:
- Etiquetas de script añadidas a los sitios web.
- El bloque de etiquetas de Google de un sitio.
- Contenido alojado en un bucket de AWS S3.
- Campos de contenido de bases de datos.
- Un Kubernetes initContainer.
- El modelo de página en caché de la página de pago.
Esta variedad hace que el análisis de archivos por sí solo no sea suficiente. Un paquete de scripts de pago puede parecer limpio aunque se esté inyectando contenido malicioso desde una base de datos, un objeto alojado en la nube, un contenedor de inicialización o la configuración de un sistema de gestión de etiquetas.
La persistencia sobrevivió a la reinstalación limpia de la aplicación
Una intrusión en un comercio de vinos estadounidense muestra cómo se adaptó el actor cuando las tareas habituales de recuperación eliminaron el skimmer.
La reinstalación de la aplicación del comercio restauró un paquete limpio para la página de pago y eliminó temporalmente la modificación maliciosa. En respuesta, el operador creó una tarea cron en el directorio de registros de JBoss.
La tarea comprobaba cada dos minutos el tamaño del archivo en cuestión. Si el despliegue restauraba el archivo legítimo, volvía a insertar el skimmer.
Este mecanismo podía dar la impresión de que la infección reaparecía por sí sola tras la remediación. También demuestra que sustituir los archivos modificados de la interfaz no siempre elimina el punto de apoyo subyacente.
El uso de un directorio de registros para alojar un componente de persistencia programado puede dificultar aún más la investigación si los defensores se centran exclusivamente en los directorios del código de la aplicación. Es necesario revisar por separado las tareas programadas, las rutas de servicio con permisos de escritura y los archivos inusuales en los directorios de JBoss.
Preservar las pruebas es especialmente importante. El actor borró algunos informes de ataque, y sus herramientas también eliminaron datos de las víctimas o destruyeron copias de respaldo por error. Reconstruir los sistemas antes de recopilar registros y pruebas volátiles puede hacer desaparecer información necesaria para reconstruir la intrusión.
Se dio prioridad a los comercios con código propio
El actor seleccionaba los objetivos mediante un servicio de clasificación del tráfico web y daba prioridad a los comercios que utilizaban código propio. El operador introdujo 301 resultados en la consola de ataque.
Al menos dos objetivos se seleccionaron manualmente porque el atacante ya tenía sus contraseñas de administrador. Se desconoce cómo obtuvo esas credenciales.
Las aplicaciones de comercio minorista con código propio presentan una superficie de ataque amplia y heterogénea. En esta campaña, las herramientas automatizadas podían sondear cada entorno y adaptar la ruta de ataque, en lugar de depender de una única vulnerabilidad presente en todas las víctimas.
Esa flexibilidad ayuda a explicar por qué entre las víctimas también había organizaciones ajenas al comercio minorista en línea. La operación alcanzó empresas de hostelería, aviación, distribución industrial y moda, aunque no se ha revelado el nivel exacto de acceso obtenido en cada organización.
Los defensores deben revisar todas las dependencias de las páginas de pago
No se ha publicado ningún parche de proveedor, medida de mitigación validada ni procedimiento de remediación confirmado para esta campaña. Por tanto, las organizaciones que gestionan páginas de pago deben investigar tanto el acceso inicial como los distintos puntos desde los que se reinstalaron los skimmers.
Entre las medidas prioritarias se encuentran:
- Revisar el JavaScript y las etiquetas de script de las páginas de pago para detectar adiciones no autorizadas, incluidos cambios en archivos que por lo demás sean legítimos.
- Auditar las configuraciones de Google Tag e identificar el código añadido o modificado recientemente.
- Inspeccionar los recursos alojados en S3 que cargan las páginas de pago, incluido el historial de objetos y los registros de acceso disponibles.
- Buscar scripts inyectados o referencias desconocidas en los campos de contenido de las bases de datos y en los modelos de página en caché.
- Revisar los Kubernetes initContainers para detectar comandos, imágenes, montajes o modificaciones de archivos no autorizados.
- Examinar las tareas programadas y los directorios de registros de JBoss, especialmente las que supervisan el tamaño de los archivos o reescriben repetidamente los recursos de la aplicación.
- Investigar las bases de datos de Magento para detectar accesos a datos de tarjetas, consultas sospechosas, preparación de datos para su extracción, actividad de borrado y copias de respaldo modificadas.
- Preservar las pruebas forenses antes de reconstruir los sistemas afectados, incluidos los registros de los agentes, los registros de autenticación, la actividad de las bases de datos, los registros de auditoría en la nube y el historial de despliegues.
- Cambiar las credenciales de administrador expuestas y determinar si se utilizaron contraseñas existentes para seleccionar objetivos concretos o acceder a ellos.
Las organizaciones que descubran un skimmer deben considerarlo una señal de que el servidor puede estar comprometido en mayor profundidad, no solo de que hay un recurso web dañado. Los mecanismos de persistencia observados demuestran que restaurar una página de pago limpia puede eliminar la carga maliciosa visible y dejar intacta la vía que permite al atacante volver a infectarla.
Fuentes
Este artículo es una reelaboración original basada en las siguientes fuentes.
