El 21 de octubre de 2026, CrowdStrike publicó una investigación sobre cuatro operadores que utilizaron agentes de IA para ejecutar intrusiones. Uno comprometió al menos 15 entidades de salud de Argentina. El informe documenta robo de credenciales e historias clínicas de al menos una víctima; no establece que se hayan extraído registros de las 15.
Para prestadores de salud, proveedores tecnológicos y equipos de seguridad de Latinoamérica, la pregunta útil es qué caminos podría recorrer un intruso después de obtener un acceso inicial. Las sesiones documentadas muestran agentes que continúan ante obstáculos, buscan credenciales y encuentran rutas entre entornos.
Este artículo se basa en el informe completo de CrowdStrike y su resumen público. Los diagramas son reconstrucciones explicativas de Oktsec. No investigamos de forma independiente los sistemas de las víctimas.
Qué ocurrió en Argentina
CrowdStrike describe al Actor 1 por los idiomas utilizados: español e inglés. Eso no verifica su nacionalidad ni su ubicación. El operador reconstruyó PentestGPT, un framework de pruebas de penetración de código abierto, alrededor de dos agentes de Claude Code. Uno seleccionaba las tareas y el otro las ejecutaba con herramientas conectadas.
Los investigadores reconstruyeron la actividad a partir de herramientas, instrucciones y resultados que quedaron en directorios accesibles desde internet en la infraestructura de los atacantes. Esa evidencia permite entender su operación, pero no constituye un registro completo de la respuesta de cada víctima ni del impacto final sobre los pacientes.
La campaña se observó entre mayo y agosto de 2026. El 21 de octubre es la fecha de publicación, no el día en que comenzaron todas las intrusiones. La diferencia importa para buscar evidencia histórica y comunicar lo ocurrido a la dirección.
Dos episodios que permiten entender el riesgo
En la primera sesión, el operador partió de un acceso existente y pidió al agente que se desplazara por la red y obtuviera credenciales. La primera ruta quedó bloqueada. El agente encontró otra y obtuvo credenciales de un controlador de dominio, la infraestructura que gestiona la autenticación en un dominio Windows. CrowdStrike describe una duración aproximada de 20 minutos, sin nuevas indicaciones humanas.
La segunda sesión involucró dos organizaciones de salud que ya estaban comprometidas. El agente utilizó el acceso a una para alcanzar un servidor interno de la otra, sin una instrucción explícita de realizar ese salto. La sesión reportada duró aproximadamente 12,5 minutos. No demuestra que haya comprometido desde cero dos organizaciones previamente seguras en ese tiempo.
Dos episodios, medidos en minutos
Ambos partieron de accesos ya comprometidos. No miden el tiempo necesario para ingresar desde cero.
Dentro de una entidad
≈ 20 minutos- Acceso previoEl atacante ya había ingresado.
- Primer intento bloqueadoFirewall o controles de acceso.
- Ruta alternativaEl agente continúa sin nuevas instrucciones.
- Credenciales obtenidasDel controlador de dominio.
Entre dos entidades
≈ 12,5 minutos- Entidad A comprometidaEl atacante ya tenía acceso a ambas.
- A como puenteEl agente elige el recorrido.
- Explora la entidad BEncuentra una ruta interna.
- Servidor interno alcanzadoPrepara el siguiente paso.
El informe completo documenta los dos episodios en las páginas 13–14. Cada uno muestra un recorrido concreto desde un acceso existente hasta un sistema más sensible.
Cómo operaba el flujo de agentes
El Supervisor seleccionaba la siguiente tarea a partir de una máquina de estados: un flujo predefinido de etapas del ataque. El Ejecutor realizaba esa tarea. El operador incorporó servidores MCP, scripts de Python y skills al framework derivado de PentestGPT. Una persona seguía definiendo el objetivo y podía intervenir.
Cómo se coordinaron los dos agentes
Esquema conceptual del framework derivado de PentestGPT. La autonomía seguía un objetivo definido por una persona.
Tarea → ejecución → resultado → siguiente tarea
Esta arquitectura permite que el software evalúe un resultado y elija la siguiente acción sin esperar que una persona emita cada comando. Por eso, bloquear un intento no demuestra que la operación haya terminado. El equipo defensor necesita entender qué otras credenciales, rutas de red y herramientas siguen disponibles.
La presencia de MCP o de un framework abierto de pruebas no indica por sí sola actividad maliciosa. Ambos tienen usos legítimos. En este caso, la diferencia está en el acceso no autorizado y las acciones realizadas sobre los sistemas de las víctimas.
CrowdStrike informa que los cuatro operadores superaron controles de seguridad comerciales de IA. Es evidencia sobre estas campañas observadas, no una prueba de que esos controles nunca funcionen. Para una organización que despliega sus propios agentes, es una razón para exigir permisos en los sistemas y herramientas utilizados, en lugar de tratar la aceptación de una solicitud por el modelo como autorización.
Separar evidencia y atribución
Qué sabemos y con qué alcance
Una observación, una proyección y una incógnita requieren tratamientos distintos.
- Documentado
- Al menos 15 entidades comprometidas; robo de credenciales e historias clínicas en al menos una. Los dos episodios aparecen en el PDF.
- Evaluación del proveedor
- Confianza moderada en la generalización de capacidades ofensivas; alta en el crecimiento de estas intrusiones durante los próximos 12 meses.
- Atribución separada
- Brasil y Colombia figuran en el informe, pero bajo el Actor 2. No deben sumarse a la campaña argentina del Actor 1.
- No establecido
- Identidad pública de las víctimas, cantidad de pacientes, notificaciones realizadas o nacionalidad real del operador.
El PDF completo menciona a Brasil y Colombia en el apartado del Actor 2. Esos países no deben atribuirse al operador que atacó la salud argentina por aparecer en el mismo informe. Del mismo modo, el idioma, la ubicación de una infraestructura y la nacionalidad de una persona son datos diferentes.
Los niveles de confianza de CrowdStrike corresponden a evaluaciones analíticas sobre adopción futura y capacidades ofensivas. Cuatro operadores investigados ofrecen ejemplos concretos; no permiten medir qué proporción de todos los ataques utiliza IA.
El informe deja preguntas importantes sin resolver públicamente: qué entidades resultaron afectadas, cuántos pacientes estuvieron involucrados y si hubo notificaciones. La ausencia de una notificación pública en el material consultado no demuestra que nunca se haya informado a las víctimas o a las autoridades.
Qué deberían revisar los equipos de salud e infraestructura
Las siguientes verificaciones son recomendaciones de Oktsec derivadas del comportamiento observado. No establecen la causa de cada compromiso del informe. El punto de partida son las rutas de acceso, el inventario y los procedimientos de respuesta de la propia organización.
Del episodio a una verificación concreta
Recomendaciones de Oktsec para priorizar una revisión. No son un diagnóstico de todas las organizaciones afectadas.
Parte de un acceso existente
Inventario, parches y eliminación de accesos innecesarios.
Continúa cuando una ruta falla
Segmentación, permisos y conexiones de salida.
Obtiene credenciales de identidad
Cuentas administrativas, controladores de dominio y alertas.
Usa una entidad como puente
Acceso de proveedores, límites de confianza y registros centralizados.
Infraestructura de identidad y cuentas privilegiadas
Revisar quién y qué puede acceder a los controladores de dominio y otros servicios de autenticación. Separar las identidades administrativas de las cuentas de uso cotidiano, eliminar privilegios innecesarios y validar alertas de acceso inusual a credenciales. Confirmar que las cuentas de servicio tengan solo los permisos que necesita cada carga de trabajo.
Ante una sospecha de compromiso, coordinar la rotación de credenciales, la revocación de sesiones y la contención con respuesta a incidentes. Cambiar una contraseña no demuestra que se haya eliminado el acceso del atacante. Preservar la evidencia relevante y considerar las dependencias de los servicios antes de realizar cambios que puedan interrumpirlos.
Accesos de red y de proveedores
Comprobar si una aplicación comprometida, una conexión de un proveedor o una cuenta de acceso remoto puede alcanzar sistemas fuera de su alcance previsto. Revisar las rutas entre unidades de negocio y organizaciones, incluidas las conexiones de salida. Una regla que bloquea una técnica no demuestra que todas las rutas alternativas estén controladas.
Pedir a los proveedores que identifiquen los sistemas y credenciales que administran, cómo limitan el acceso y cómo colaborarían en una investigación. Registrar un responsable de escalamiento. El episodio entre víctimas no demuestra por sí solo que un proveedor compartido haya sido la causa; esa relación no está establecida aquí.
Detección, evidencia y responsables de respuesta
Confirmar que los eventos de autenticación, las acciones privilegiadas y la actividad de red relevante lleguen a un sistema central que un intruso en un equipo no pueda borrar fácilmente. Verificar quién recibe las alertas, quién puede revocar accesos y cómo se inicia una investigación fuera del horario habitual. Probar el circuito con el equipo o proveedor que ya realiza el monitoreo.
Cada revisión debe dejar un responsable, una referencia a la evidencia y una acción pendiente. Completar una lista sin comprobar el control aporta poca certeza. Los equipos de SOC y respuesta existentes deben recibir los hallazgos por sus procesos habituales.
Datos de pacientes y decisiones de notificación
Las historias clínicas pueden generar consecuencias más allá de una interrupción del servicio. Una organización de salud necesita determinar qué información fue consultada o extraída, preservar el registro de la investigación y preparar comunicaciones que distingan el impacto confirmado de lo que sigue sin conocerse.
Definir antes de un incidente quién decide: operaciones clínicas, seguridad, asesoría legal, privacidad y comunicaciones. El equipo legal debe determinar las obligaciones aplicables a la entidad, el sector, la jurisdicción y los contratos. Registrar en el plan de respuesta los criterios, destinatarios y plazos de notificación aplicables.
La falta de nombres de víctimas o cifras de pacientes en el informe público no debe completarse con estimaciones. Las comunicaciones a pacientes, autoridades y socios deben basarse en hallazgos verificados y requisitos aplicables.
Qué implica para quienes despliegan sus propios agentes de IA
Un entorno de agentes puede concentrar credenciales cloud, tokens de repositorios, claves de proveedores de modelos y acceso a herramientas. Inventariar esas identidades, separar los permisos de desarrollo y producción y revisar qué podría alcanzar un host de agentes comprometido. Es una implicación defensiva del caso, no una afirmación de que las víctimas argentinas hayan sido atacadas a través de sus propios despliegues de IA.
Probar las solicitudes contra límites explícitos: herramienta, cuenta, destino, recurso y acción permitidos. Evitar que documentos no confiables, archivos de repositorios o respuestas de herramientas sustituyan la autorización. Revisar también los caminos alternativos a la integración prevista.
Oktsec puede ayudar a definir una evaluación de seguridad de esas rutas y revisar los controles junto con el equipo. Oktsec Control aplica políticas configuradas al tráfico de agentes que pasa por él. No intercepta los agentes de un atacante externo ni protege rutas que lo eviten. Los hallazgos deben incorporarse a los procesos de seguridad y respuesta que ya tenga la organización.
Fuentes y alcance editorial
- CrowdStrike: Uncovers New Agentic AI Campaigns, 21 de octubre de 2026. Resumen público de los cuatro operadores.
- CrowdStrike: informe completo Agentic AI Campaigns. Páginas 5–6: alcance y arquitectura; páginas 13–14: los dos episodios argentinos; páginas 17–18: evaluaciones con niveles de confianza.
Revisión de fuentes: 25 de octubre de 2026. Los diagramas simplifican los flujos reportados para su análisis defensivo y omiten instrucciones operativas de explotación. Las recomendaciones y el alcance del producto son análisis de Oktsec. Este artículo analiza una investigación publicada; no es una investigación independiente del incidente.