Qué afirma la investigación sobre CARLIY0S
Straiker publicó el 21 de octubre de 2026 una investigación sobre CARLIY0S, un sistema que, según la firma, fue utilizado por operadores asociados a CyberCartel para coordinar actividad contra más de 400 objetivos financieros de Latinoamérica. La investigación describe bancos y proveedores de pagos entre los tipos de organizaciones buscadas. Esa cifra se refiere a objetivos, no demuestra que más de 400 instituciones fueran vulneradas con éxito.
La base de la investigación, según Straiker, fue el acceso a una instantánea de sistemas y materiales de trabajo atribuidos al grupo, incluidos archivos de configuración, scripts, infraestructura y una base llamada FinancialSoft. Es evidencia directa de lo que había en ese entorno, pero el informe no publica una verificación independiente de cada ataque, ni identifica a las organizaciones afectadas. Por eso, las atribuciones y el alcance deben leerse como hallazgos de la firma, no como confirmación pública de responsabilidad o daños en cada entidad.
La cobertura del caso también recoge esa limitación: no se divulgaron los nombres de los bancos y no puede establecerse públicamente qué instituciones de la región habrían sufrido una intrusión. Tampoco hay en las fuentes aportadas una lista verificable que conecte cada uno de los más de 400 objetivos con un acceso exitoso, extracción de datos o pérdidas financieras.
Una cadena de herramientas, no un agente autónomo único
Straiker presenta CARLIY0S como una estructura distribuida que combinaba operadores humanos, scripts, herramientas de seguridad y modelos comerciales. El sistema se habría apoyado en PentAGI, un marco de pruebas de seguridad automatizadas, y en componentes que permitían compartir información y delegar tareas. Es más preciso describirlo como una operación asistida y coordinada mediante IA que como un agente que actuó por sí solo.
El informe atribuye funciones distintas a varios modelos. Claude aparece en una configuración de agentes con tareas de análisis, generación de código o evaluación de alternativas; un modelo se usaría como coordinador desde Cursor. Grok figura asociado a tareas de recopilación y clasificación de información, mientras que Kimi aparece en configuraciones de respaldo. La documentación de configuración no prueba por sí sola que cada modelo se ejecutara con éxito en todos los pasos o contra todos los objetivos.
También se describen herramientas convencionales para automatizar interacciones web, analizar tráfico y sincronizar datos entre equipos. Los modelos podían aportar análisis o propuestas, pero el acceso a sistemas y la ejecución dependían de herramientas, credenciales, scripts e infraestructura. La capacidad efectiva de cada etapa, por tanto, no puede inferirse solo de la presencia de una configuración de IA.
Qué papel se atribuye a cada componente
La tabla resume lo que Straiker dice haber observado en los materiales atribuidos al sistema; no demuestra que cada función se completara en todos los ataques.
| Componente | Función descrita | Límite de la evidencia |
|---|---|---|
| Claude | Análisis, debate de opciones y coordinación de tareas en configuraciones de varios agentes. | Los archivos de configuración no demuestran invocación exitosa para cada operación. |
| Grok | Minería o recopilación de datos que alimentaban FinancialSoft. | La existencia de cinco “Grok miners” no prueba el origen o uso de cada registro. |
| Kimi | Modelo alternativo o de respaldo en determinados flujos. | Una configuración de respaldo no demuestra que se activara en cada caso. |
| Scripts y herramientas | Automatización de navegación, tratamiento de datos y conexión con otros sistemas. | Son componentes de software; su presencia no confirma por sí sola el éxito de una intrusión. |
| Operadores humanos | Definición de objetivos y supervisión de la operación descrita. | La investigación no cuantifica con precisión la intervención humana en cada etapa. |
Qué muestran los registros y qué no permiten concluir
En la instantánea que Straiker dice haber revisado, FinancialSoft contenía 4.493 registros. La descripción incluye datos de cuentas financieras, direcciones de correo, contraseñas, claves de API y otros materiales sensibles. Entre los recuentos publicados figuran 2.911 direcciones de correo y 903 números de cuenta. Son cantidades atribuidas al inventario observado, no una medida de personas afectadas ni una confirmación de que todos los datos fueran válidos o se utilizaran.
El informe también menciona credenciales asociadas a infraestructura de pagos, incluida información que podría relacionarse con SPEI, el sistema mexicano de pagos interbancarios. La exposición de credenciales puede elevar el riesgo de accesos no autorizados o fraude, pero no basta para demostrar que se ejecutaron transferencias, que se accedió a cuentas de clientes o que las credenciales seguían activas.
La firma afirma haber anonimizado a las organizaciones y sanitizado material sensible de la publicación. En consecuencia, el lector no puede comprobar la identidad de las entidades ni contrastar públicamente el estado de cada cuenta o clave mencionada. La cantidad y la naturaleza de los registros justifican atención defensiva, pero no deben transformarse en una afirmación de pérdidas concretas.
Respuesta de proveedores y alcance de las medidas
Straiker afirma que compartió indicadores relevantes con proveedores de modelos. Según la firma, Anthropic revocó una credencial comprometida utilizada para acceder a Claude. También señaló que xAI había sido notificada y examinaba la actividad asociada a cinco “Grok miners”. Esas medidas se refieren al acceso a servicios concretos; no prueban que toda la infraestructura atribuida al grupo quedara desactivada.
El material aportado no documenta medidas concretas adoptadas por bancos latinoamericanos para bloquear agentes de IA, ni identifica qué entidades estarían implementando controles específicos. Por ello, no se puede afirmar que bancos de la región hayan desplegado un bloqueo general de agentes de terceros a raíz de este caso. Conviene distinguir esa cuestión de las restricciones preventivas que se han descrito en otros mercados y que no acreditan una respuesta de las instituciones latinoamericanas.
Desde el punto de vista defensivo, el caso señala áreas que las entidades pueden revisar: credenciales expuestas, permisos de API, accesos a portales administrativos, actividad inusual y conexiones con servicios externos. Son líneas de defensa pertinentes frente a riesgos de acceso y automatización, no una garantía de detección ni una lista de medidas cuya implantación haya sido confirmada en los bancos involucrados.
Qué revisar ante una posible exposición de credenciales
Estos pasos son criterios generales de respuesta; las fuentes disponibles no confirman que una entidad concreta los haya aplicado en este caso.
- 01Identificar qué credenciales o claves se consideran expuestas y a qué sistemas conceden acceso.
- 02Revocar o rotar las credenciales afectadas y revisar si existen accesos o usos no habituales.
- 03Examinar registros de autenticación, actividad de API y cambios en sistemas conectados.
- 04Limitar permisos a lo necesario y separar las funciones de consulta de las que permiten ejecutar operaciones.
- 05Mantener seguimiento de proveedores y servicios externos vinculados a la respuesta.
Qué cambia —y qué no— para la seguridad de la IA
El interés del caso no depende de que un modelo haya actuado con autonomía general. La investigación describe una combinación de modelos comerciales, herramientas automáticas, scripts, infraestructura compartida y operadores. Ese ensamblaje puede ayudar a organizar tareas y ampliar el alcance de una operación, pero el informe no permite concluir que la IA sustituyera a los atacantes ni que eligiera y ejecutara por sí sola cada acción.
La evidencia presentada por Straiker es un estudio de caso basado en materiales que la firma atribuye al entorno de trabajo de los operadores. No es, por sí misma, una medición independiente de la frecuencia de ataques con agentes, ni prueba que la misma arquitectura produzca resultados equivalentes en otros grupos o sectores. Tampoco convierte una configuración de modelo en evidencia de que el modelo haya generado una intrusión exitosa.
El resultado práctico es más acotado: las entidades financieras deben considerar que herramientas de IA pueden formar parte de flujos de trabajo ofensivos ya apoyados por software e infraestructura tradicionales. La respuesta no se reduce a bloquear un modelo: también requiere proteger credenciales, limitar permisos, observar el comportamiento de cuentas y APIs y verificar incidentes con registros técnicos. Las fuentes aportadas no permiten atribuir una medida regulatoria nueva ni describir una política común de los bancos latinoamericanos.
Qué sigue abierto
- Las organizaciones objetivo no se identifican públicamente, por lo que no es posible verificar cuáles sufrieron accesos exitosos.
- No se publica una correspondencia verificable entre los más de 400 objetivos y el número de entidades vulneradas, los datos extraídos o las pérdidas.
- La presencia de configuraciones de modelos en los materiales atribuidos al grupo no demuestra que cada modelo se ejecutara con éxito en cada etapa.
- Las fuentes aportadas no confirman qué medidas concretas implementaron bancos latinoamericanos para detectar o bloquear agentes de IA.
Continúa explorando
Fuentes consultadas
Correcciones y transparencia
Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.
Proponer una corrección