Introducción

Fecha de publicación: 10 de septiembre de 2026
Categoría: Ataques de IA (LLM/LocalAI)

A medida que las organizaciones integran herramientas basadas en Modelos de Lenguaje Grande (LLM) para automatizar el triaje y análisis de código sospechoso, los actores maliciosos adaptan sus tácticas para subvertir estas defensas algorítmicas. Investigadores de ESET han documentado una nueva técnica denominada GuardBreaker, empleada por el grupo de amenazas alineado con Rusia UAC-0099 en las fases iniciales de una campaña contra objetivos en Ucrania. La técnica consiste en insertar una solicitud simulada y prohibida dentro de los comentarios de un script en VBScript, diseñada para activar los filtros de seguridad de los escáneres impulsados por IA y forzar su interrupción antes de que el motor logre inspeccionar el código malicioso subyacente, cuyo objetivo final era desplegar el cargador MATCHBOIL.

¿Qué es GuardBreaker? (Análisis General)

GuardBreaker se clasifica conceptualmente como una forma de inyección de prompts a tiempo de inferencia (inference-time prompt injection). No explota una vulnerabilidad tradicional de software (como un desbordamiento de búfer o una ejecución remota de código en el motor del LLM), sino que aprovecha una debilidad arquitectónica fundamental en los sistemas actuales de análisis basados en IA: la incapacidad de separar de forma fiable las instrucciones de control confiables de los contenidos no confiables procesados dentro de un mismo flujo de entrada.

Aunque no se ha asignado un CVE específico para este comportamiento a nivel de aplicación (N/A para este incidente al tratarse de una explotación lógica de salvaguardas algorítmicas), se puede estimar analíticamente bajo la taxonomía común de fallos en sistemas de inteligencia artificial:

  • Vector CVSS estimado: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L (Puntuación estimada: 5.1 Media). Nota: Estimación razonada basada en el impacto operativo sobre la integridad y disponibilidad del pipeline de análisis automatizado.
  • Clasificación CWE estimada: CWE-20 (Improper Input Validation) combinada con debilidades en el manejo de contexto de modelos generativos.

El componente afectado es el flujo de trabajo de seguridad automatizado que depende de LLMs para realizar revisiones estáticas de código. Al comprometer la respuesta del modelo, los atacantes logran cegar los sistemas de detección temprana.

¿Cómo funciona? (Análisis Técnico)

El mecanismo técnico detrás de GuardBreaker es directo pero altamente efectivo en entornos donde los analistas automatizados carecen de supervisión multicapa:

  • Flujo de entrada del señuelo: El actor de amenaza inserta un comentario sintácticamente válido en VBScript que incluye una solicitud explícita para la fabricación de armas nucleares o contenido altamente restringido por las políticas de seguridad del modelo de IA.
  • Interrupción de la inferencia (Mecanismo de evasión): Cuando el escáner basado en LLM procesa el archivo durante la fase de triaje estático, el modelo interpreta el texto dentro del comentario como una directiva o contenido que viola sus políticas éticas internas. Como respuesta programada de seguridad, el LLM trunca la salida o aborta la ejecución de la tarea de escaneo.
  • Despliegue del payload real: Al abortar el análisis de forma prematura debido a la falsa alarma provocada por el comentario, el script malicioso real —encargado de descargar y ejecutar el cargador MATCHBOIL— pasa desapercibido ante la herramienta de IA, permitiendo que la fase inicial del ataque avance en el sistema objetivo.
text 
[ Archivo VBScript Malicioso ]
       │
       ├──> [ Comentario con Señuelo (GuardBreaker) ] ──> [ Activa Filtros de Seguridad del LLM ] ──> [ Escaneo Abortado ]
       │
       └──> [ Carga Útil (MATCHBOIL Loader) ] ──────────> [ Oculto a la Inspección ] ──────────────> [ Ejecución Exitosa ]

Sistemas / Entornos Afectados

La técnica no impacta a un software o sistema operativo específico mediante un fallo de memoria, sino a una clase entera de arquitecturas de defensa:

  • Sistemas de revisión de código automatizados basados en LLM (tanto soluciones comerciales integradas en canalizaciones CI/CD como herramientas locales de análisis estático asistidas por IA).
  • Equipos de seguridad que dependen exclusivamente de la automatización de modelos generativos para el triaje rápido de scripts (scripts de PowerShell, VBScript, JavaScript, etc.).
  • Cadenas de suministro de software donde paquetes maliciosos en repositorios públicos (PyPI, npm) utilizan técnicas similares (instrucciones de sistema falsas o saturación de contexto con cadenas repetitivas como “You’re absolutely right!”).

Mitigación y Detección

Remediación

  • Enfoque Multi-modelo y Multicapa: Ningún motor de LLM debe poseer la autoridad exclusiva para determinar si un fragmento de código es seguro o malicioso. Se debe implementar una validación cruzada combinando análisis heurístico tradicional, motores estáticos basados en reglas (YARA/SIGMA) y supervisión humana.
  • Aislamiento del Contexto: Configurar los analizadores basados en IA para tratar de forma estricta el código analizado como datos puros y no como instrucciones ejecutables o directivas de control, mitigando el impacto de la inyección de prompts.
  • Políticas de Fallo Seguro (Fail-Safe): Asegurar que cuando un LLM se niegue a responder o interrumpa su análisis por una alerta de seguridad, el sistema no descarte el archivo como “limpio”, sino que lo derive automáticamente a una revisión manual o a un pipeline de análisis dinámico.

Detección

  • Monitoreo de Anomalías en el Pipeline: Registrar y alertar sobre interrupciones abruptas, errores de rechazo de políticas o truncamientos inesperados en las herramientas de análisis asistidas por IA.
  • Búsqueda de IoCs (Threat Hunting): Auditar repositorios de scripts y archivos adjuntos en busca de comentarios inusuales que contengan solicitudes hiperbólicas, temas prohibidos (armamento, contenido ilegal) o patrones repetitivos destinados a saturar la ventana de contexto.

“Ningún motor de LLM debe tener la autoridad única para decidir que una pieza de código es segura; la automatización debe complementarse siempre con validación humana y heurísticas tradicionales para evitar puntos ciegos en la defensa.”

Recapitulando

La aparición de la técnica GuardBreaker por parte del grupo UAC-0099 evidencia que los atacantes adaptan activamente sus métodos para explotar las limitaciones de las tecnologías de inteligencia artificial integradas en la defensa corporativa. El uso de simples comentarios señuelo para desactivar escáneres basados en LLM demuestra que los vectores de inyección de prompts ya no son solo un riesgo teórico para aplicaciones web, sino una herramienta de evasión operativa en ciberespionaje y distribución de malware. Las organizaciones deben adoptar arquitecturas de defensa en profundidad, donde la IA actúe como un asistente de apoyo y nunca como el único juez en la toma de decisiones críticas de seguridad.

Referencias