Reconocimiento con IA sobre infraestructura de IA: qué buscan los atacantes

Cuando tu infraestructura de IA es solo un notebook de Jupyter en un portátil, la superficie de amenaza es manejable. Cuando son endpoints de LLM en producción que sirven a miles de usuarios, una base de datos vectorial con embeddings sensibles y un pipeline de entrenamiento con acceso a tus datos más limpios, la historia es otra. Los atacantes se han dado cuenta.

La superficie de ataque de la IA ha cambiado

Los objetivos tradicionales del reconocimiento se conocen bien: puertos abiertos, servicios expuestos, buckets de S3 mal configurados, credenciales filtradas. La infraestructura de IA añade una nueva capa encima de todo eso:

• Endpoints de modelos: APIs de inferencia, a menudo con un acceso de red amplio y una autenticación mínima más allá de una clave de API
• Bases de datos vectoriales: almacenes de embeddings que pueden contener representaciones de documentos sensibles, a menudo con controles de acceso más débiles que los de los documentos de origen
• Pipelines de entrenamiento: trabajos con acceso de escritura a los pesos del modelo, que a menudo se ejecutan con roles de IAM elevados
• Ventanas de contexto: los LLM a los que se ha dado acceso privilegiado a herramientas (lectura de archivos, ejecución de código, llamadas a APIs) pueden sondearse para que filtren lo que hay en su contexto
• Los propios pesos del modelo: los modelos ajustados pueden codificar datos de entrenamiento sensibles que se pueden extraer en parte mediante ataques de inversión

Cómo es el reconocimiento de IA

El reconocimiento sobre infraestructura de IA sigue las mismas fases que el reconocimiento tradicional (descubrimiento pasivo, enumeración activa, identificación de servicios), pero con técnicas específicas de IA superpuestas.

Descubrimiento pasivo

Los atacantes empiezan por lo que es visible públicamente:

• Búsquedas en Shodan y Censys de puertos expuestos de servicio de modelos (Triton Inference Server, vLLM, Ollama, BentoML)
• Búsquedas en GitHub de claves de API incrustadas en el código para Anthropic, OpenAI, Cohere, Hugging Face o Replicate
• Model cards públicas y páginas de modelos de HuggingFace que revelan la composición de los datos de entrenamiento
• LinkedIn y ofertas de empleo que desvelan el stack de IA (por ejemplo, «se requiere experiencia con Weaviate y LangChain»)

Enumeración activa

Una vez identificado un servicio de IA objetivo:

• Sondear los endpoints de metadatos del modelo (/v1/models, /info, /health) para identificar la familia, la versión y las capacidades del modelo
• Probar si hay inferencia sin autenticación: muchos servidores de modelos internos confían en la posición en la red en lugar de en la autenticación
• Sondear los sistemas RAG con consultas diseñadas para sacar a la luz lo que hay en el almacén vectorial
• Enviar prompts manipulados para comprobar si se filtra el prompt del sistema y si hay acceso a herramientas

Técnicas específicas de LLM

Esta es la nueva frontera. Los atacantes usan el propio modelo como objetivo de reconocimiento:

• Extracción del prompt del sistema: prompts diseñados para que el modelo repita o describa su prompt del sistema
• Enumeración de herramientas: pedir al modelo que describa a qué herramientas tiene acceso
• Extracción de datos mediante inferencia de pertenencia: sondear si documentos concretos estaban en el conjunto de entrenamiento
• Inyección indirecta de prompts: incrustar instrucciones en documentos que el modelo recuperará más tarde, para secuestrar su comportamiento cuando procese ese contenido

El modelo de amenazas del CISO para la infraestructura de IA

Si ejecutas IA en producción, tu modelo de amenazas debería incluir:

1. Inventaría tus endpoints de IA: cada API de inferencia, cada servidor de modelos, cada base de datos vectorial. Si no sabes qué está expuesto, no puedes defenderlo.
2. La autenticación no es opcional: la autenticación con clave de API es el mínimo; para los modelos sensibles, considera mTLS y listas de IP permitidas como controles adicionales.
3. Trata las bases de datos vectoriales como bases de datos de producción: los embeddings pueden filtrar contenido sensible mediante la búsqueda por similitud. Aplica los mismos controles de acceso que aplicarías a los documentos de origen.
4. Audita el acceso del modelo a herramientas: si tu LLM tiene herramientas (lectura de archivos, búsqueda web, ejecución de código), documenta exactamente a qué puede acceder. Un modelo que puede leer archivos debe limitarse al conjunto mínimo necesario.
5. Registra las peticiones de inferencia: los logs de inferencia del modelo son tu equivalente a los logs del servidor web. Son esenciales para detectar patrones de sondeo anómalos e intentos de inyección de prompts.

Cómo se ve esto en una Cyber War Room

En PlayCISO estamos incorporando escenarios de incidentes específicos de IA a nuestra Cyber War Room, entre ellos un escenario de «servidor de modelos comprometido» en el que la primera señal son unos logs de inferencia anómalos, y otro de «exfiltración de datos de RAG» en el que un atacante usa la búsqueda por similitud para extraer documentos sensibles incrustados.

No se trata solo de saber que estas amenazas existen, sino de practicar la toma de decisiones bajo presión: ¿qué aíslas primero? ¿Qué le dices al consejo? ¿Cómo evalúas si se exfiltraron datos de entrenamiento?

Si quieres poner a prueba tu toma de decisiones de seguridad en IA: ejecuta tu primera Cyber War Room gratis →

Para saber más: AI Reconnaissance on AI Infrastructure — Hackers Arise