La idea de que la IA y malware vuelven a los ataques “más difíciles” de detener es tentadora, pero el análisis de Unit 42 cuenta otra historia. En un estudio con 405 muestras relacionadas con IA de alguna forma, los investigadores observaron que la mayoría no llegaba a entornos reales. En cambio, la contribución principal parece estar en acelerar la creación y la variación de herramientas maliciosas, sin cambiar de forma radical su detectabilidad.
El resultado es relevante para equipos de seguridad: las defensas existentes—como análisis en sandbox, detección por comportamiento y señales en firmas digitales—parecen seguir funcionando. A continuación, se explica qué encontraron, cómo midieron el impacto y qué tipos de muestras dominaron el conjunto analizado.
Qué analizó Unit 42 y cómo midieron la “vida real” del malware
Unit 42 revisó 405 muestras vinculadas a IA de manera directa o indirecta. El estudio abarcaba desde ransomware con asistencia potencial de modelos de lenguaje, hasta instaladores que, en la práctica, solo tomaban el nombre o el aspecto de una app conocida de IA.
Para evaluar si el malware alcanzaba un objetivo real, los investigadores cruzaron distintos datos: hashes de los archivos contra telemetría de endpoints, sesiones de red enviadas a análisis en sandbox y registros de alertas internos cuando el archivo efectivamente se ejecutaba.
El contraste fue contundente. Aproximadamente 97% de las muestras no “salieron” de entornos controlados como repositorios de investigación, un sandbox o pruebas internas. Solo una fracción pequeña terminó en endpoints protegidos, y un grupo algo mayor apareció en el tráfico observado hacia sandboxes de red.
Solo 12 muestras llegaron a endpoints protegidos
En los datos en vivo, solo 12 hashes aparecieron en endpoints. Es decir, esas muestras lograron ejecutar realmente en sistemas protegidos, no únicamente circular por repositorios o entornos de laboratorio.
Además, los investigadores reportaron que entre 15 y 20 hashes se observaron en tráfico de sandboxes de red. Esto sugiere que algunas muestras sí pasaron por fases de distribución o interacción inicial, pero no necesariamente alcanzaron el mismo nivel de ejecución efectiva en sistemas reales.
Lo más importante para el enfoque defensivo es que cada una de las 12 muestras detectadas en endpoints protegidos disparó alertas. En otras palabras: cuando el malware sí se ejecuta, el ecosistema de detección existente reacciona.
Las 3 categorías principales de muestras que no pasaron a producción
El conjunto de muestras que no llegó a objetivos reales se agrupó en tres patrones. Esta clasificación ayuda a entender por qué, pese a la presencia de señales vinculadas a IA, la efectividad final fue limitada.
1) Códigos de prueba para demostrar técnicas
La categoría más grande correspondió a material tipo proof-of-concept: implementaciones diseñadas para mostrar una técnica. Muchas de estas muestras estaban preparadas para actuar únicamente contra redes locales o privadas, incorporaban salida de depuración poco compatible con operaciones de un atacante real y, según el análisis, fueron subidas una sola vez por un laboratorio o una universidad.
Esto no implica que el contenido sea “inofensivo”, sino que su trayectoria no se parece a la de campañas sostenidas. Más bien, parecen piezas creadas para evaluación o demostración técnica.
2) Muestras repetidas por pruebas de defensas
Otro grupo se asoció a organizaciones que estaban probando sus defensas usando muestras previamente reportadas. El rasgo distintivo fue la repetición: cargas del mismo archivo desde la misma fuente en una ventana de tiempo corta.
En estos casos, la actividad observable no refleja necesariamente intención maliciosa en el mundo real, sino el uso de “material de prueba” para validar la respuesta del sistema de seguridad.
3) IA como “marca” para atraer víctimas
La tercera categoría se relacionó con campañas que usaban IA como cebo. Los instaladores se presentaban como si fueran componentes de productos de IA conocidos, pero el contenido real no ofrecía funcionalidades de IA.
Este enfoque de branding puede aumentar la tasa de curiosidad o de clic, pero no necesariamente aumenta la sofisticación técnica desde el punto de vista de la detección. En el análisis, justamente eso parece dominar: el gancho está en la apariencia, no en una nueva lógica difícil de identificar.
Cuando sí alcanzan endpoints: cinco familias y distribución global
Las 12 muestras que llegaron a endpoints protegidos abarcaban cinco familias de malware y se observaron en tres países. No hubo una concentración clara por industria o región.
Este punto es relevante porque desactiva la idea de que “todo ocurre en un único sector” o que es un problema localizado. En la muestra analizada, los patrones se reparten de forma relativamente amplia.
FunkSec: ransomware con señales de asistencia mediante IA
La familia más frecuente fue FunkSec. Varios investigadores la han vinculado a asistencia de modelos de lenguaje para acelerar el proceso de desarrollo o variación.
Un detalle que llamó la atención fue la presencia de nombres de archivos de proyecto dentro de las muestras analizadas. Unit 42 indicó que el mismo ransomware era etiquetado con distintos nombres durante el análisis, y que el ritmo de esos cambios se ajusta más—según los investigadores—a un patrón impulsado por prompts que al ciclo tradicional de desarrollo.
En términos simples: la IA puede ayudar a iterar más rápido, generando variaciones que mantienen la esencia del ataque, aunque no cambie necesariamente las técnicas de detección que ya funcionan.
Recipe Lister: un instalador que abre una puerta trasera
El ejemplo más extendido fue un instalador que simulaba ser una app para encontrar recetas llamada Recipe Lister. El archivo incluía una firma digital y, tras la instalación, ejecutaba silenciosamente una puerta trasera.
De acuerdo con el análisis, el archivo se distribuyó a más de 50 organizaciones. Esto produjo cerca de 6.500 registros en endpoints y alrededor de 9.600 alertas.
Al principio, su firma parecía evitar la sospecha, pero el análisis detectó señales como la combinación de un firmante inusual y contenidos del archivo altamente empaquetados, lo que terminó elevando el riesgo y facilitando la detección.
Oyster: un backdoor que se disfraza de instalador de Dropbox
Otra variante reportada fue el backdoor Oyster. En este caso, el malware se presentaba como un instalador de Dropbox, con una firma que listaba a Dropbox como publicador.
Unit 42 señaló que cada vez más los atacantes recurren a herramientas de IA para generar el código de entrega, lo que puede volver el proceso de establecer un primer acceso más rápido y barato.
Sin embargo, de nuevo aparece el matiz clave: en el conjunto analizado, esa aceleración no significó que las defensas tradicionales dejaran de ser efectivas.
Otras piezas: stealer con C2 y un caso con COM hijacking
El estudio también incluyó un ejecutable de Windows que entregó el information stealer Rhadamanthys con comunicación activa de command-and-control, algo que reportes previos habían relacionado con una cadena de infección asistida por IA.
Además, se encontró una muestra que imitaba un componente del producto de seguridad 360 Total Security e implementaba persistencia mediante COM hijacking. Unit 42 la incluyó porque apareció en campañas acompañadas de cebos con marca de IA, aunque su funcionamiento no dependía de IA por sí mismo.
Por qué las defensas actuales sí bloquean las muestras vinculadas a IA
Una conclusión central del análisis es que las defensas existentes cubren el problema. Unit 42 indicó que los controles que ya se usan para malware convencional funcionaron también contra estas muestras relacionadas con IA.
Entre los mecanismos que lograron identificar y bloquear el contenido estaban: detonación en sandbox, detección basada en comportamiento, anomalías en firmas digitales y mediciones de qué tan empaquetado o cifrado está un archivo.
El estudio recalca que ninguna de las muestras asociadas a IA requirió la creación de un método de detección completamente nuevo. Esto no elimina la necesidad de seguimiento, pero sí sugiere que el foco debe estar en aplicar bien lo que ya existe.
Qué significa esto para equipos de seguridad: más velocidad, no más impunidad
En conjunto, los hallazgos apuntan a un papel actual de la IA en el malware: como forma de acelerar el desarrollo y la variación de herramientas. La IA puede reducir fricción en tareas como generar componentes, ajustar presentaciones de entrega o cambiar nombres y variaciones.
Pero esa rapidez—al menos en los casos observados por Unit 42—no se tradujo en una tasa de éxito mayor. La mayoría de las muestras analizadas no llegó a producción, y las pocas que sí alcanzaron endpoints generaron alertas bajo los mecanismos habituales.
Conclusión
El análisis de Unit 42 sobre AI y malware ofrece una visión práctica y menos sensacionalista: la IA puede ayudar a los atacantes a producir y adaptar herramientas más rápido, pero no necesariamente hace que el malware sea invulnerable ante la detección.
Mientras las organizaciones mantengan una postura activa—ejecución segura en sandboxes, detección por comportamiento, análisis de firmas y revisión de empaquetado/cifrado—las defensas tradicionales siguen mostrando capacidad para identificar y bloquear este tipo de amenazas cuando intentan operar en el mundo real.
Fuente: https://www.securityweek.com/ai-speeds-up-malware-development-not-its-success-rate-analysis/
