Por Canuto  

Un atacante robó una clave API de METR, consumió cerca de USD $600.000 en créditos gratuitos durante tres semanas y pasó inadvertido entre las alertas habituales de la organización. El grupo también reveló un segundo incidente, en el que intrusos sondearon su infraestructura y buscaron acceder a datos de evaluaciones no publicados.
***

  • Una falla de autenticación expuso durante varios días una instancia EC2 personal con una clave API de METR.
  • El atacante mantuvo acceso persistente y utilizó modelos públicos por un valor aproximado de USD $600.000.
  • METR detectó un segundo ataque con escaneo automatizado, phishing y un endpoint que podía mostrar datos no publicados.

 

Una clave expuesta y tres semanas de consumo

La organización Model Evaluation and Threat Research, conocida como METR, reveló dos incidentes de seguridad ocurridos durante 2026, incluido el robo de una clave API utilizada para inferencia en modelos públicos. En una actualización publicada el 31 de agosto, la organización explicó que el primer episodio comenzó en marzo, cuando un atacante obtuvo acceso a una instancia EC2 personal empleada por uno de los investigadores y utilizó las credenciales durante aproximadamente tres semanas. METR indicó que no encontró evidencia de acceso a información sensible en ninguno de los incidentes.

Según el relato divulgado por la organización y recogido por The Register, la clave permitió consumir créditos de modelos públicos por un valor aproximado de USD $600.000. El proveedor de los modelos había entregado esos créditos gratuitamente a METR, por lo que el ataque no produjo una factura equivalente para la entidad sin ánimo de lucro. La circunstancia redujo el impacto financiero directo, aunque expuso una debilidad importante en la administración de credenciales y en la vigilancia del uso de modelos.

La instancia pertenecía a un investigador que no manejaba datos de modelos, credenciales ni información sobre arquitecturas, entrenamiento o fechas de lanzamiento. METR explicó que el equipo utilizaba agentes de IA dentro de ese entorno y que la máquina estaba intencionalmente accesible desde internet, detrás de la autenticación de Google. El problema apareció cuando una aplicación creada rápidamente incorporó una falla de tipo fail-open, capaz de desactivar la autenticación en lugar de bloquear el acceso ante un error.

Como consecuencia, el sistema quedó expuesto públicamente durante varios días. METR sospecha que el atacante pudo localizarlo mediante sitios registrados recientemente, incluidos listados de transparencia de certificados, y utilizando palabras clave relacionadas con modelos de lenguaje y agentes. La hipótesis apunta a una búsqueda automatizada de aplicaciones que pudieran contener claves API de proveedores de modelos, una práctica que convierte los entornos experimentales en objetivos atractivos para intrusos con motivaciones financieras.

El acceso persistente pasó inadvertido

Una vez dentro de la aplicación, el atacante indujo a un agente a revelar la clave API asociada con la cuenta de modelos públicos de METR. Después añadió una clave SSH para conservar el acceso, una maniobra que le permitió regresar al sistema sin repetir necesariamente el mismo procedimiento de autenticación. Durante las tres semanas siguientes, las credenciales robadas sirvieron para ejecutar solicitudes y agotar una cantidad sustancial de créditos en modelos públicos.

El caso plantea una pregunta central: cómo un consumo extraordinario no activó una respuesta temprana. METR señaló que sus evaluaciones habituales utilizan grandes volúmenes de tokens y generan con frecuencia alertas de límites de tasa, errores de API y comportamientos inusuales. Dentro de ese contexto operativo, el tráfico adicional no parecía suficientemente diferente de las pruebas legítimas que la organización realiza de manera regular.

La ausencia de un costo visible también contribuyó a retrasar la detección. Como los créditos habían sido otorgados sin cargo, METR no recibió una factura elevada que obligara a revisar de inmediato el comportamiento de la cuenta, y en aquel momento tampoco contaba con una herramienta para establecer un límite de gasto sobre esa clase de clave. La combinación de tokens gratuitos, alertas frecuentes y controles financieros limitados creó un entorno en el que el abuso pudo mezclarse con la actividad normal.

El incidente muestra por qué una clave API no debe tratarse como un dato menor, incluso cuando el servicio asociado no cobra directamente por cada solicitud. Una credencial comprometida puede permitir consumo no autorizado, elevar costos futuros, afectar límites de uso o servir como punto de partida para movimientos posteriores dentro de una infraestructura. En sistemas que coordinan agentes, además, la capacidad de inducir al software a revelar secretos amplía el riesgo más allá del simple robo de una contraseña.

Un segundo ataque contra la infraestructura pública

El segundo incidente ocurrió a comienzos de mayo, cuando METR observó una campaña externa sostenida contra su infraestructura accesible públicamente. La organización había recibido una advertencia sobre posibles atacantes motivados financieramente que buscaban obtener acceso ilícito a modelos frontera, y posteriormente identificó actividades de reconocimiento dirigidas a encontrar una vía de entrada. No obstante, METR dijo que no halló pruebas de que los intrusos hubieran accedido a datos internos.

Los atacantes emplearon agentes para explorar distintas rutas de compromiso, entre ellas el descubrimiento automatizado de vulnerabilidades y el escaneo de servicios recién desplegados. También intentaron realizar credential stuffing contra proveedores de autenticación, obtener tokens OAuth y ejecutar campañas de phishing. La variedad de técnicas sugiere una operación que combinaba automatización con métodos tradicionales, en lugar de depender de una sola vulnerabilidad conocida.

Mientras ocurría ese sondeo, METR había expuesto de forma accidental un mecanismo de consultas SQL de solo lectura a través de su visor público de transcripciones. Las consultas estaban limitadas por defecto a información pública, pero un error permitía consultar datos de evaluación que todavía no habían sido publicados. La organización reconoció además que algunos datos sensibles sobre modelos habían sido incluidos accidentalmente en esa base de datos, aunque no afirmó que fueran extraídos.

Un investigador independiente dedicado a encontrar fallas descubrió el problema y lo reportó a METR. La organización pagó una recompensa por el hallazgo y desconectó la API, mientras que su investigación no encontró evidencia de que los atacantes hubieran localizado el exploit o consultado información no pública. El episodio ilustra cómo un componente creado para ofrecer transparencia sobre evaluaciones puede terminar ampliando la superficie de ataque si no se separan estrictamente los datos públicos de los internos.

Respuesta y cambios de seguridad

Tras el incidente de marzo, METR informó que reforzó su infraestructura, actualizó sus protocolos y modificó sus procesos de revisión. La organización también contrató a un responsable de seguridad y planea sumar más personal especializado, una decisión que refleja el aumento de las exigencias operativas para grupos que prueban modelos y agentes avanzados. En este tipo de entornos, la seguridad ya no depende únicamente de proteger servidores tradicionales, sino también de controlar qué información pueden revelar los agentes.

La organización indicó que ahora utiliza un entorno de producción aislado para las aplicaciones orientadas al público. Ese espacio queda separado de su infraestructura interna, con el objetivo de limitar el impacto de una vulnerabilidad en un visor, una API o cualquier otro servicio expuesto. La segmentación no elimina por sí sola el riesgo, pero reduce la posibilidad de que un fallo público se convierta en una puerta directa hacia sistemas y datos reservados.

El caso también coloca bajo escrutinio las aplicaciones desarrolladas con rapidez mediante herramientas de inteligencia artificial o prototipado acelerado. METR describió la aplicación involucrada como una solución creada de manera informal y señaló que su falla de autenticación operaba en modo fail-open, una condición especialmente peligrosa para servicios que contienen secretos. La velocidad de despliegue puede facilitar la experimentación, pero exige revisiones independientes, gestión estricta de credenciales y monitoreo capaz de distinguir pruebas legítimas de abuso.

Para METR, los dos episodios no produjeron evidencia de que se hubieran comprometido datos sensibles, pero sí demostraron que una organización dedicada a evaluar sistemas avanzados también puede quedar expuesta por controles básicos. El robo de una sola clave permitió un consumo masivo que permaneció oculto durante semanas, mientras una API pública casi abrió acceso a resultados no publicados. La respuesta anunciada busca cerrar esas brechas antes de que una próxima intrusión encuentre una recompensa más valiosa.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados