Los desarrolladores de malware siempre han adaptado su código y sus tácticas a las defensas y al escrutinio que probablemente encuentren. Utilizando diversos métodos de evasión y anti-análisis, intentan habitualmente dificultar el análisis del código o impedir que su malware revele su verdadero comportamiento mientras es inspeccionado. Sin embargo, a medida que las herramientas basadas en Grandes Modelos de Lenguaje (LLM) se integran cada vez más en tareas de seguridad, como el triaje y análisis de código, era solo cuestión de tiempo que los actores de amenazas comenzaran a buscar formas prácticas de subvertirlas también. Una nueva técnica, bautizada como GuardBreaker por los investigadores de ESET, representa un giro particularmente astuto: en lugar de ocultar el código malicioso, el atacante inserta un comentario diseñado explícitamente para que un escáner de código impulsado por IA se niegue a seguir analizando el archivo, justo antes de la parte dañina.
GuardBreaker: Una Técnica de Evasión que Apunta a la Seguridad de los LLM
Los investigadores de ESET detectaron recientemente este intento en un script VBScript utilizado por el grupo alineado con Rusia conocido como UAC-0099. El grupo empleó este script en las primeras etapas de un ataque contra un objetivo en Ucrania. La técnica es sorprendentemente simple: los atacantes insertaron una solicitud señuelo en los comentarios del script, pidiendo orientación para construir un arma nuclear. El objetivo era activar los mecanismos de seguridad de un escáner de código basado en un LLM, provocando que se negara a procesar el resto del archivo. De esta forma, el escáner nunca llegaba a examinar el código malicioso real, cuya función era descargar e instalar MATCHBOIL, un cargador (loader) utilizado exclusivamente por este grupo para distribuir cargas útiles adicionales.
Este método, denominado GuardBreaker por ESET, explota una característica fundamental de los LLM: su tendencia a rechazar solicitudes peligrosas o no éticas. Al incluir un comentario que simula una petición de este tipo, el atacante introduce una «orden» adversaria que, si el sistema de análisis no está adecuadamente protegido, puede interrumpir la inspección. A diferencia de muchas otras técnicas de evasión que operan en la sombra, este comentario señuelo está a la vista de todos, especialmente de los modelos que analizan el código. No tiene ningún efecto en el comportamiento del script durante la ejecución, pero su presencia indica que UAC-0099 ya está considerando la posibilidad de que un sistema de IA forme parte de las defensas del objetivo.
¿Cómo Funciona el Ataque de Inyección de Prompts en el Análisis de Código?
GuardBreaker es, en esencia, un intento muy simple de inyección de prompts. En este caso, la entrada del atacante llega al LLM en el momento de la inferencia a través del archivo que está siendo analizado. La técnica explota una debilidad arquitectónica común en los LLM actuales: estos modelos procesan contenido no confiable (como el código de un archivo) e instrucciones confiables (las del sistema de análisis) sin límites suficientemente sólidos entre ambos. El atacante aprovecha esta falta de separación para introducir un prompt que el modelo interpreta como una instrucción genuina del sistema.
Este no es un caso aislado. Se han observado intentos similares de interferir con escáneres impulsados por LLM, especialmente en ataques a la cadena de suministro de software. Por ejemplo, la empresa Socket encontró instrucciones falsas del sistema y contenido diseñado para activar políticas de seguridad colocados antes de una carga útil de JavaScript en paquetes maliciosos de PyPI. De manera similar, StepSecurity informó sobre un prompt que instruía directamente a cualquier modelo de análisis que procesara el archivo a ignorar el código malicioso y reportar el paquete como limpio. En otro incidente, se detectó un paquete npm cuyo archivo JavaScript principal repetía la frase «You’re absolutely right!» decenas de miles de veces. El objetivo era agotar la ventana de contexto del modelo, dejando el script malicioso, que aparecía después, fuera del alcance práctico del análisis.
Otras Formas de Cegar a los Escáneres de Código con IA
Los atacantes podrían intentar cegar el proceso de análisis de malware mediante otras tácticas igualmente sencillas, o incluso combinándolas. Archivos con una estructura inusual o torpe podrían ser truncados o analizados solo parcialmente. Partes del código malicioso podrían ocultarse bajo la apariencia de información confidencial o datos sensibles, haciendo que el modelo evite procesarlos. También es posible el uso de tipos de archivo personalizados que requieran herramientas específicas para su procesamiento, o la creación de código que dirija a los agentes de IA hacia acciones que requieran revisión humana, provocando retrasos que el atacante pueda explotar. Los agentes que invocan herramientas externas, como desempaquetadores o desofuscadores, amplían aún más la superficie de ataque, ya que estas llamadas podrían ser secuestradas para la entrega y ejecución de malware.
¿Qué es la Inyección de Prompts en el Contexto de la Seguridad del Código?
La inyección de prompts es una técnica de ciberseguridad que explota la forma en que los modelos de IA procesan las instrucciones. Ocurre cuando un atacante introduce un texto malicioso o manipulado (el «prompt») dentro de un sistema que utiliza un LLM, con el objetivo de alterar su comportamiento previsto. En el caso del análisis de código, el atacante inserta este prompt dentro del propio código que se está analizando. Si el LLM no distingue correctamente entre las instrucciones del sistema y el contenido del archivo (que está bajo su escrutinio), puede obedecer la orden maliciosa. Así, un simple comentario que diga «ignora el resto del código» o, como en el caso de GuardBreaker, que active una salvaguarda de seguridad, puede hacer que el modelo omita por completo la parte maliciosa del programa.
El Grupo UAC-0099 y el Uso de Técnicas Anti-Análisis
El uso de GuardBreaker por parte de UAC-0099 no es un hecho aislado, sino que demuestra una evolución en sus tácticas. El grupo, conocido por sus operaciones contra Ucrania, ya había mostrado su capacidad para adaptar sus herramientas al entorno de la víctima. En ataques recientes, se detectó que el grupo verificaba la presencia de procesos asociados a herramientas de análisis establecidas, como IDA y Wireshark, antes de ejecutar su carga maliciosa. La incorporación de una técnica anti-análisis dirigida a sistemas de IA sugiere que los atacantes están ampliando su repertorio para contrarrestar las defensas más modernas. La simpleza de la técnica de GuardBreaker la hace especialmente peligrosa, ya que no requiere un profundo conocimiento técnico de los LLM, sino una comprensión básica de sus puntos débiles.
Implicaciones para la Seguridad Empresarial: ¿Quién Tiene la Autoridad Final?
El caso de GuardBreaker subraya una lección fundamental para los profesionales de la seguridad: cualquier tecnología que pueda afectar las posibilidades de éxito de un atacante terminará siendo un objetivo. Las empresas que confían en las revisiones de código y otros flujos de trabajo asistidos por LLM deben comprender con exactitud qué inspecciona cada herramienta, dónde se sitúa en la cadena de decisiones y, crucialmente, qué ocurre cuando se niega a responder o no puede completar una tarea.
La respuesta no es abandonar la IA, sino implementar un enfoque de defensa en profundidad. Ningún motor LLM debería tener la autoridad única para decidir que un código es seguro. Los resultados generados por IA deben ser validados de forma cruzada mediante un enfoque multicapa y multimodelo que combine lo mejor de la automatización avanzada con la experiencia humana. Cuando un modelo no emite un resultado (por ejemplo, porque ha sido engañado por un prompt como GuardBreaker), esa falta de respuesta también debe desencadenar comprobaciones adicionales, no ser interpretada como una señal de que el archivo es seguro.
Más Allá de la Prevención: Detección y Respuesta ante Amenazas con IA
Las organizaciones de todos los tamaños necesitan una ruta clara que vaya desde la prevención hasta la detección y la respuesta. Para aquellas que no cuentan con equipos de seguridad las 24 horas del día, los servicios de Detección y Respuesta Gestionada (MDR, por sus siglas en inglés) pueden proporcionar el seguimiento necesario. Un experto en seguridad, combinando el análisis de la telemetría global con la inteligencia de amenazas, puede investigar cualquier incidente sospechoso en el contexto de la actividad general de la red y determinar los pasos a seguir. Este enfoque se construye sobre décadas de uso de tecnologías fundacionales de IA, métodos de análisis probados y juicio humano experto. De esta manera, cualquier negocio puede asegurarse de que una acción de un solo modelo LLM no se convierta en un punto ciego en sus defensas cibernéticas.
La estrategia de defensa más efectiva contra estas nuevas formas de evasión no es técnica, sino operativa. Implica asumir que los LLM pueden ser engañados y construir procesos de verificación que lo tengan en cuenta. La combinación de automatización para la velocidad y análisis humano para el contexto y la validación sigue siendo la mejor barrera contra atacantes que, como UAC-0099, ya están aprendiendo a explotar las vulnerabilidades de la inteligencia artificial generativa.
