cómo un simple comentario de código puede confundir a la IA en el análisis de malware

Los escáneres de malware basados en modelos de lenguaje grande (LLM) no ayudarán a los atacantes a fabricar un arma nuclear, pero esa negativa podría jugar a su favor.

10 Sep 2026
 • 
,
5 min. read

Los desarrolladores de malware llevan años adaptando su código y sus tácticas a las defensas y mecanismos de análisis que podrían interponerse en su camino. Mediante diversos métodos de evasión y antianálisis, intentan dificultar el análisis del código o impedir que su malware revele su verdadero comportamiento mientras está siendo inspeccionado. Otras herramientas, especialmente los EDR killers, ampliamente documentados por investigadores de ESET, apuntan directamente a las propias soluciones de seguridad.

A medida que las herramientas basadas en modelos de lenguaje de gran tamaño (LLM, por sus siglas en inglés) se utilizan cada vez más para asistir en diversas tareas de seguridad, incluido el análisis y la clasificación de código, era solo cuestión de tiempo para que los actores de amenazas comenzaran a buscar formas prácticas de subvertirlas también. Junto con las técnicas de evasión convencionales, algunos están adoptando un enfoque diferente: la entrada adversarial diseñada para frustrar el análisis se deja a la vista de todos.

Recientemente, investigadores de ESET detectaron uno de estos intentos en un script VBScript que el grupo UAC-0099, alineado con Rusia, utilizó en las primeras etapas de un ataque contra un objetivo en Ucrania. Al insertar en un comentario del script una solicitud señuelo para obtener instrucciones sobre cómo construir un arma nuclear, el actor malicioso buscaba activar las barreras de seguridad de un escáner de código impulsado por LLM y hacer que dejara de inspeccionar el resto del archivo antes de llegar al código malicioso. El propósito del script era descargar e instalar MATCHBOIL, un loader utilizado exclusivamente por este grupo para distribuir cargas maliciosas adicionales.

Esta sencilla técnica, que ESET ha denominado GuardBreaker, se basa precisamente en el tipo de “solicitud” que los modelos LLM suelen rechazar:

A diferencia de muchos otros trucos del repertorio de evasión de los atacantes, este comentario señuelo está ahí para que lo vea todo el mundo, especialmente los modelos encargados de analizar el código. Además, por supuesto, no tiene ningún efecto sobre el comportamiento del script durante su ejecución. Sin embargo, su presencia sugiere que UAC-0099 estaba considerando la existencia de un sistema de IA dentro de las defensas del objetivo. De hecho, en otros ataques recientes, el grupo también buscó procesos asociados con herramientas de análisis consolidadas, como IDA y Wireshark.

El antianálisis apuntan a otro objetivo

GuardBreaker puede entenderse mejor como un intento muy simple de inyección de prompts (prompt injection): la entrada del atacante llega al LLM durante el proceso de inferencia a través de un archivo que está siendo analizado. De esta manera, busca explotar una debilidad arquitectónica de los LLM actuales, que procesan contenido no confiable e instrucciones confiables sin límites suficientemente sólidos entre ambos.

Intentos similares de interferir con escáneres impulsados por LLM han surgido especialmente en ataques a la cadena de suministro de software. Por ejemplo, Socket encontró instrucciones de sistema falsas y contenido diseñado para activar políticas de seguridad colocados antes de una carga útil JavaScript en paquetes maliciosos de PyPI. Al informar sobre la misma campaña, StepSecurity identificó un prompt que indicaba explícitamente a cualquier modelo que analizara el archivo que ignorara el código malicioso y reportara el paquete como seguro. En otro incidente, investigadores detectaron un paquete npm cuyo archivo JavaScript principal repetía la frase “You’re absolutely right!” decenas de miles de veces con la intención de agotar la ventana de contexto del modelo y dejar el script malicioso posterior fuera de un análisis práctico.

Los atacantes también podrían intentar cegar los procesos de análisis de malware mediante otros trucos simples, o combinando varios de ellos. Archivos inusuales o estructurados de forma poco convencional podrían acabar siendo truncados o analizados solo parcialmente. Algunas secciones del código malicioso podrían ocultarse bajo el pretexto de contener información confidencial u otros datos sensibles.

Otros ataques podrían emplear tipos de archivos personalizados que requerirían herramientas específicas para procesarlos. Asimismo, podrían dirigir a los agentes de IA hacia acciones que requieran revisión humana, provocando retrasos y aprovechando los tiempos de respuesta. Los agentes que invocan herramientas externas, como desempaquetadores u ofuscadores inversos, amplían aún más la superficie de ataque, ya que en algunos casos esas llamadas podrían ser secuestradas para distribuir y ejecutar malware.

¿Quién tiene el control?

GuardBreaker refuerza una lección que los profesionales de seguridad ya conocen: cualquier tecnología que pueda afectar las posibilidades de éxito de un atacante terminará convirtiéndose en un objetivo. Las organizaciones que dependen de revisiones de código impulsadas por LLM y otros flujos de trabajo asistidos por IA deben comprender exactamente qué inspecciona cada herramienta, dónde se encuentra dentro de la cadena de decisiones y qué ocurre cuando se niega a responder o no puede completar una tarea.

Sin embargo, es fundamental que ningún motor LLM tenga la autoridad exclusiva para decidir si una pieza de código es segura. Los resultados asistidos por IA deben validarse mediante un enfoque multicapa y multimodelo que combine de la mejor manera posible la automatización avanzada con la experiencia humana. Del mismo modo, la ausencia de resultados también debe desencadenar verificaciones adicionales.

Las organizaciones de todos los tamaños necesitan además una estrategia clara que abarque prevención, detección y respuesta. Para aquellas que no cuentan con equipos de seguridad operando las 24 horas, los servicios de detección y respuesta gestionadas (MDR) pueden proporcionar el seguimiento necesario, permitiendo que especialistas investiguen cualquier incidente sospechoso dentro del contexto de otras actividades observadas en el entorno y determinen los pasos a seguir.

Este enfoque se sustenta en décadas de experiencia con las tecnologías fundamentales de IA, métodos de análisis probados, criterio experto, investigación de amenazas y telemetría global. De esta manera, cualquier organización puede evitar que la acción de un único modelo LLM se convierta en un punto ciego dentro de sus defensas de ciberseguridad.

¡Para todos nuestros lectores!

Aprovechen esta oportunidad de obtener un trial gratuito de 30 días para Google Workspace, la mejor solución para tu empresa. Disfruta de todas sus funcionalidades, como correo electrónico personalizado, almacenamiento en la nube y herramientas de colaboración.

Comienza tu prueba gratuita