La IA que escribe el exploit y la que filtra tus datos: la semana del 18 al 24 de agosto

Un brazo robótico de precisión sosteniendo una ganzúa metálica frente a una cerradura industrial abierta, en paleta verde azulada con acento ámbar
0 0 votos
Valora la Publicación

La semana del 18 al 24 de agosto dejó cinco casos que cuentan la misma historia desde ángulos distintos: la inteligencia artificial acortó el camino entre «hay una falla» y «hay un exploit funcionando», y lo hizo de los dos lados del mostrador.

Cinco agencias del gobierno de EE.UU. alertaron sobre scripts de ataque generados con IA contra PLCs de Siemens, Microsoft parcheó un fallo que convertía a Copilot en un canal de exfiltración con un solo clic, y un investigador demostró que a Grok se le pueden meter instrucciones cifradas que sus filtros no pueden leer.

Del lado ofensivo: exploits escritos con ayuda de IA contra PLCs de Siemens

El 19 de agosto la NSA, CISA, el FBI, el Departamento de Energía y la EPA publicaron el aviso conjunto AA26-231A sobre una amenaza activa contra controladores lógicos programables (PLC) de la serie S7 de Siemens expuestos a internet.

El dato que hace ruido no es la falla, sino el método: las agencias documentaron que los atacantes usaron asistencia de IA para generar los scripts de explotación a partir de información pública, con objetivos de acceso inicial, robo de credenciales y denegación de servicio.

Las herramientas son scripts de Python que integran librerías legítimas de automatización industrial (snap7 y python-snap7) para pasar por utilidades de monitoreo. Vía el protocolo S7comm permiten leer y escribir memoria del PLC, datos de configuración y lógica ladder.

El alcance cubre toda la línea S7, del S7-200 al S7-1500 incluidos los controladores de seguridad, y los sectores señalados son manufactura crítica, energía, agua y saneamiento, química y alimentos. Para el reconocimiento los atacantes usaron servicios de escaneo público como Censys y ZoomEye.

Las mitigaciones son las de siempre, y ese es el punto: inventariar los S7, sacarlos de internet, bloquear el puerto TCP 102 en el perímetro, activar la protección por contraseña del PLC y monitorear tráfico S7comm fuera de las ventanas de mantenimiento.

Del lado defensor: los asistentes que filtran

CoSnitch: el parámetro no documentado que el propio Copilot reveló

Varonis Threat Labs publicó CoSnitch (CVE-2026-24301), un conjunto de tres fallas en Copilot Personal (copilot.microsoft.com) que permitían robar datos con un solo clic. Microsoft las parcheó el 18 de agosto.

La forma en que se encontró la primera es notable: los investigadores insistieron con preguntas al propio asistente sobre sus barreras de confirmación, hasta que Copilot les reveló un parámetro de URL no documentado, autorun=1. Es decir, el modelo entregó el secreto que lo abría.

Combinado con el parámetro conocido q=, ese flag hacía que el prompt del atacante se ejecutara solo en la sesión autenticada de la víctima, sin confirmación y aunque cerrara la pestaña enseguida. Lo alcanzable incluía:

  • Cuerpo, asunto y metadatos de remitente y destinatario de los correos.
  • Títulos, asistentes, horarios y lugares de las reuniones del calendario.
  • Nombres y metadatos de archivos de Google Drive.
  • Conversaciones previas, instrucciones guardadas y reglas de memoria del usuario.

Las otras dos fallas completaban la cadena: exfiltración hacia un webhook con codificación base64 y escritura persistente en la memoria del asistente a partir de páginas web resumidas.

Varonis reportó el problema en diciembre de 2025 y el parche llegó ocho meses después. No hay evidencia de explotación real.

Grok y las instrucciones cifradas que el filtro no puede leer

Rony Utevsky, de Adversa AI, publicó el 20 de agosto una técnica que bautizó Cryptographic Context Injection (inyección de contexto criptográfico) y que probó contra Grok de xAI y contra Gemini 3 Flash de Google.

La idea explota una grieta estructural. El atacante deja en una página web las instrucciones maliciosas cifradas con AES-256-GCM junto a la clave de descifrado, el filtro de entrada del modelo no puede leer ese texto cifrado y lo deja pasar, y el modelo lo descifra dentro de su propio intérprete de código.

Así, las instrucciones del atacante le llegan al modelo como salida confiable de su propio runtime y no como contenido externo sospechoso. A diferencia de trucos anteriores con base64 o sustitución, AES no se puede «leer de memoria»: obliga a ejecutar.

En la demostración alcanza con pedirle a Grok que resuma la página. El asistente termina armando una URL hacia el servidor del atacante que lleva adentro el nombre del usuario, su ubicación aproximada, su plan de suscripción y el historial completo de la conversación.

Utevsky reportó el hallazgo a xAI el 3 de junio y volvió a insistir el 4 y el 10 de agosto. Según su publicación, el ataque seguía funcionando contra Grok el 19 de agosto; en Gemini la tasa de éxito bajó mucho, aunque el investigador aclara que tampoco está cerrado del todo.

Snowflake: cuando la IA revisa el código y no ve nada

El caso más comentado de la semana fue el que publicó Wiz sobre el repositorio público snowflakedb/snowflake-connector-net, y conviene contarlo con precisión porque circuló distorsionado.

El workflow jira_issue.yml de GitHub Actions interpolaba el título de un issue directamente dentro de un bloque run:. Con una comilla simple bien puesta en el título, cualquiera sin autenticar podía ejecutar comandos en el runner.

El Red Agent de Wiz, su herramienta autónoma de investigación de seguridad, encontró y explotó la falla el 23 de junio y se llevó el token de la API de Jira de la cuenta qa@snowflake.net, con acceso de lectura a proyectos de ingeniería, cumplimiento y bug bounty. Snowflake parcheó ese mismo día, rotó el token el 24 y dice que sus registros de auditoría no muestran accesos de terceros en la ventana de cinco días.

El punto delicado es la autoría. El pull request #1218 lleva a GitHub Copilot Autofix como coautor, pero el historial del repositorio no permite establecer que Copilot escribiera las líneas vulnerables, y hay reportes que las ubican en un commit humano anterior.

Wiz terminó actualizando su publicación para aclararlo: Copilot fue coautor, revisó el PR fusionado y lo dio por bueno sin notar la vulnerabilidad. El escaneo de GitHub Advanced Security tampoco la marcó, pese a que GitHub había documentado esta clase de inyección en julio de 2025.

Dicho de otro modo: acá no hubo una IA sembrando una puerta trasera. Hubo una IA revisora que no vio nada, un escáner que tampoco, y una IA atacante que sí.

9.300 llaves de AWS abiertas, y la principal fuente es una plataforma de IA

Truffle Security cerró la semana con un informe incómodo: de las claves de acceso de AWS filtradas públicamente entre agosto de 2022 y agosto de 2026, más de 9.300 siguen activas y autenticando.

Sus escáneres recolectaron 431.875 hallazgos en historial de Git, datasets, imágenes de Docker, registros de paquetes y logs de CI, de los que salieron 64.024 pares de claves únicos. Al revalidar los 10.616 pares completos, el 88% seguía funcionando.

Peor todavía, 768 de esas claves dan control total de la cuenta: 526 son claves de usuario root y 242 pertenecen a usuarios IAM con la política AdministratorAccess. La antigüedad mediana ronda los cinco años y la enorme mayoría nunca se rotó.

El detalle que ata este caso con los anteriores es de dónde salen: la mayor fuente individual de claves vivas fue Hugging Face, con 8.482 claves únicas repartidas en 3.394 datasets. La fiebre por publicar datos y modelos se llevó puesta la higiene de secretos.

Truffle validó todo con llamadas de solo lectura a metadatos y notificó a los dueños que pudo identificar. Su recomendación práctica: borrar toda clave de acceso de root, auditar las claves IAM por antigüedad, poner alarmas de presupuesto y tratar como comprometida para siempre cualquier credencial que haya tocado un commit.

¿Cuánto tarda tu organización desde que se publica una falla hasta que la tapa?

Los cinco casos miden distintos tramos de la misma ventana. De un lado, la IA comprimió el tiempo de armar un exploit contra un PLC de veinte años o de encontrar una inyección en un workflow de CI.

Del otro, la respuesta sigue midiéndose en meses (ocho para el parche de Copilot, dos y medio sin respuesta efectiva en Grok) y las claves filtradas, en años sin rotar.

¿Tenés inventariados los asistentes de IA con acceso a tus datos corporativos y las claves que alguna vez pasaron por un repositorio público? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x