Malware polimórfico y metamórfico: qué son, cómo han evolucionado y cómo detectarlos

El malware polimórfico cambia de aspecto en cada copia, normalmente cifrando el cuerpo de otra manera y generando un descifrador diferente, mientras el código que se ejecuta sigue siendo el mismo. El metamórfico reescribe las instrucciones del cuerpo en cada generación, de modo que no queda un núcleo constante. Los dos buscan que no exista una huella fija que un antivirus pueda reconocer.

La idea tiene más de 35 años y ha vuelto a los informes de amenazas con la IA generativa. En noviembre de 2025, Google Threat Intelligence Group describió PROMPTFLUX, un dropper en VBScript que pedía a la API de Gemini nuevas técnicas de ofuscación para modificarse "justo a tiempo" y esquivar las firmas estáticas. Google lo calificó de experimental y su función de autoactualización estaba desactivada.

¿Qué es el malware polimórfico?

MITRE ATT&CK lo recoge desde octubre de 2024 como la subtécnica T1027.014, Polymorphic Code, dentro de la ofuscación de ficheros e información (T1027). La define como código que cambia su huella durante la ejecución y que, en cada ejecución, se convierte en una versión distinta con el mismo objetivo. Desde la versión 19, de abril de 2026, T1027 figura bajo la táctica Stealth.

El mecanismo clásico lo describía Carey Nachenberg, de Symantec, en un documento de 1996. Los virus cifrados mantenían el mismo descifrador de una generación a otra y los antivirus aprendieron pronto a buscarlo. El polimórfico añade un motor de mutación que genera una rutina de descifrado distinta en cada infección. Esa rutina se ejecuta primero, descifra el cuerpo en memoria y le cede el control, de modo que, como resumía la guía NIST SP 800-83 de 2005, el cifrado solo altera la apariencia del código.

Los empaquetadores y crypters (T1027.002, Software Packing) consiguen un efecto parecido desde fuera del código. Comprimen o cifran el ejecutable, cambian su hash y sus patrones de bytes, y reconstruyen el programa en memoria al arrancar. Los protectores con máquina virtual, como VMProtect o Themida, van más lejos y traducen el código a un formato que solo ejecuta un intérprete incluido en el binario, según MITRE. También los usa software legítimo, así que detectar el protector o una sección de alta entropía da falsos positivos si no se cruza con la prevalencia y el comportamiento.

¿En qué se diferencia el malware metamórfico del polimórfico?

El malware metamórfico no esconde el cuerpo tras un cifrado, sino que lo reescribe. Peter Ször y Peter Ferrie, investigadores de Symantec, escribían en "Hunting for Metamorphic" que los virus metamórficos no tienen descifrador ni un cuerpo constante, aunque algunos de los más conocidos, como Zmist y Simile, combinaban el cuerpo metamórfico con un descifrador polimórfico.

Para conseguirlo, el motor desensambla el código, lo pasa a una representación intermedia y lo vuelve a ensamblar con instrucciones equivalentes, registros intercambiados, bloques reordenados y código basura que no altera el resultado. Algunos motores también encogen el código para que no crezca sin límite.

La terminología no es uniforme. MITRE trata "metamórfico" como sinónimo de polimórfico en T1027.014, mientras que el NIST de 2005 y la literatura de los fabricantes de antivirus los separan. Para la detección, la diferencia importa, porque el polimórfico acaba mostrando un cuerpo constante al descifrarse y el metamórfico no lo tiene.

La tabla ordena las variantes de esta familia de técnicas, de la más simple a la más reciente.

¿Cómo se detecta el malware polimórfico?

Una firma clásica busca un hash o un patrón de bytes, con comodines, y el malware polimórfico cambia ambos en cada copia. La respuesta de los antivirus en los años noventa fue la emulación, que Symantec llamaba descifrado genérico. El escáner ejecuta el fichero en un ordenador virtual aislado hasta que el descifrador expone el cuerpo, y entonces busca la firma.

La emulación sigue dentro de los motores actuales. Alexei Bulazel presentó en Black Hat USA 2018 la ingeniería inversa del emulador de Windows Defender, incluido en mpengine.dll. Microsoft combina ese análisis local con modelos de aprendizaje automático en la nube que, según su documentación, identifican amenazas nuevas a veces antes de que infecten un solo equipo.

El metamórfico complica la emulación porque no hay cuerpo constante que exponer, y los autores de virus añadieron trucos contra los emuladores, como las comprobaciones de tiempo con RDTSC de Simile o las llamadas a GetTickCount de Virut. Por eso las defensas actuales observan lo que el código hace al ejecutarse. Microsoft reconoce que las amenazas muy polimórficas mutan más rápido de lo que las soluciones tradicionales pueden seguir, y apoya el bloqueo por comportamiento en aprendizaje automático.

En los scripts, AMSI (Antimalware Scan Interface) entrega el código a los motores cuando llega desofuscado al intérprete, aunque se haya generado durante la ejecución. PowerShell, Windows Script Host y las macros de Office integran esta interfaz. AMSI funciona dentro del proceso que analiza y el malware puede anularlo en memoria, como documenta MITRE en familias como Lumma Stealer, Donut o Brute Ratel C4.

El registro de bloques de script de PowerShell (evento 4104) conserva el contenido de cada bloque procesado, incluido el intento de anular AMSI, y Microsoft recomienda protegerlo con Protected Event Logging. YARA puede analizar procesos en ejecución además de ficheros, y cuando una muestra llega al laboratorio, el análisis de malware dinámico y en memoria recupera el código descifrado.

¿Qué controles y búsquedas protegen a una empresa del malware polimórfico?

Microsoft Defender for Endpoint incluye reglas de reducción de la superficie de ataque (ASR) que actúan sobre el comportamiento y la reputación, según su referencia de reglas actualizada en septiembre de 2026. Junto con el antivirus y un EDR, son las capas que cubren el código cambiante.

• La regla "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" frena los ejecutables únicos o recién creados (.exe, .dll y .scr), el resultado típico del reempaquetado por entrega. Necesita la protección en la nube y no cubre scripts ni accesos directos.
• La regla "Block execution of potentially obfuscated scripts" está documentada para PowerShell, y el bloqueo a primera vista (block at first sight) envía a la nube las muestras desconocidas y puede bloquearlas en segundos.
• El control de aplicaciones con App Control for Business en modo de cumplimiento bloquea los scripts de wscript.exe y cscript.exe que la política no autoriza, deja PowerShell en Constrained Language Mode y bloquea mshta.exe. Los intérpretes no integrados, como muchos de Python, quedan fuera, y las reglas por editor no frenan el malware firmado con certificados robados.
• VBScript, el lenguaje de PROMPTFLUX, está obsoleto desde octubre de 2023 y se distribuye como característica a petición, así que puede retirarse de los equipos que no lo usen.
• El EDR detecta lo que se repite entre copias porque el objetivo no cambia, como la persistencia, la inyección en otros procesos o el tráfico de salida, y no la secuencia exacta de instrucciones.

En Defender XDR, la búsqueda avanzada permite convertir esas ideas en consultas periódicas. Los umbrales son orientativos y se ajustan a cada entorno.

• Binarios de baja prevalencia sin firma válida: DeviceProcessEvents | where Timestamp > ago(7d) | summarize Equipos = dcount(DeviceId) by SHA1, FileName, FolderPath | invoke FileProfile("SHA1", 1000) | where GlobalPrevalence < 50 or isnull(GlobalPrevalence) | where SignatureState != "SignedValid"
• Intérpretes de scripts que contactan con APIs de modelos de lenguaje, empezando por la de Gemini y ampliando la lista con los servicios de IA de la organización: DeviceNetworkEvents | where RemoteUrl has "generativelanguage.googleapis.com" | where InitiatingProcessFileName in~ ("wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "rundll32.exe")
• Scripts que escriben en la carpeta de Inicio, la persistencia de PROMPTFLUX: DeviceFileEvents | where FolderPath has @"\Start Menu\Programs\Startup\" | where InitiatingProcessFileName in~ ("wscript.exe", "cscript.exe", "powershell.exe", "pwsh.exe", "mshta.exe")
• Intentos de anular AMSI en el evento 4104, buscando cadenas como AmsiScanBuffer o amsi.dll en el texto del bloque, e hilos que arrancan fuera de los módulos cargados (evento 8 de Sysmon con StartModule vacío).

Esas búsquedas exigen reglas mantenidas y probadas contra técnicas de ATT&CK, el trabajo que describimos en ingeniería de detección, y un equipo que revise las alertas a todas horas, como un SOC gestionado. Una búsqueda de amenazas periódica cubre lo que las reglas no ven, y el bastionado de sistemas reduce lo que un código nuevo puede hacer al ejecutarse.

¿Sigue siendo una amenaza el malware polimórfico en 2026?

La enciclopedia de Kaspersky considera hoy poco habitual el polimorfismo clásico, porque los atacantes han pasado al cifrado y la ofuscación del código. El objetivo de entregar una muestra distinta a cada víctima sigue vigente con otros medios. Ya en 2010, Kaspersky señalaba el polimorfismo en servidor como la vía principal de propagación de ficheros maliciosos. En ese modelo, el motor de mutación se queda en la infraestructura del atacante y cada descarga recibe un fichero distinto.

La CISA describía en 2018 a Emotet como un troyano bancario polimórfico capaz de esquivar la detección basada en firmas. Webroot situó en más del 94 % la proporción de ejecutables maliciosos polimórficos que encontró en 2017, y en el 93 % la de muestras vistas en un solo equipo. Son datos de un fabricante y de hace casi una década, aunque explican por qué un hash aislado sirve de poco como indicador.

¿Cómo usa la IA generativa el código que se reescribe?

CyberArk publicó en enero de 2023 un diseño de investigación de malware polimórfico que pedía a la API de ChatGPT módulos de código nuevos de forma periódica. En marzo de ese año, HYAS presentó BlackMamba, una prueba de concepto de keylogger que generaba su funcionalidad durante la ejecución.

En noviembre de 2025, GTIG informó de que había identificado por primera vez familias de malware que consultan modelos de lenguaje durante la ejecución. PROMPTFLUX, detectado en junio de 2025, pedía a Gemini técnicas de ofuscación en VBScript para modificarse, y una variante solicitaba reescribir todo su código fuente cada hora. Google lo situó en fase de desarrollo o pruebas, sin capacidad demostrada de comprometer una red, aunque el código dejaba clara la intención de crear un script metamórfico.

En febrero de 2026, el mismo equipo describió HONESTCUE, que recibe de Gemini código C# y lo compila en memoria sin dejar la carga en disco, probablemente como prueba de concepto. Su informe de mayo de 2026 asocia PROMPTFLUX a T1027.014 y describe CANFAIL y LONGSTREAM, usados por actores vinculados a Rusia contra organizaciones ucranianas, que rellenan su código con lógica señuelo generada por modelos de lenguaje (T1027.016, Junk Code Insertion).

Tampoco todo el malware con IA muta. LAMEHUG, que el CERT-UA atribuyó con confianza moderada a APT28 en julio de 2025, usa un modelo alojado en Hugging Face para generar comandos y no para reescribirse. PromptLock, presentado en agosto de 2025 como el primer ransomware con IA, resultó ser un prototipo académico de la Universidad de Nueva York, como explicamos al hablar de la IA en la investigación ofensiva.

Cuando el malware consulta un modelo durante la ejecución, arrastra elementos fijos. Según GTIG, PROMPTFLUX llevaba en el código una credencial de la API de Gemini, pedía el modelo gemini-1.5-flash-latest, registraba su actividad en %TEMP%\thinking_robot_log.txt y guardaba cada versión en la carpeta de Inicio. Esos elementos sirven para firmas y búsquedas, y la dependencia del proveedor permite cortar el servicio, como hizo Google al desactivar los recursos asociados.

A octubre de 2026, ATT&CK no tiene una técnica específica para el malware que consulta un modelo durante la ejecución. La T1682 (Query Public AI Services), añadida en abril, cubre el uso de servicios de IA en la fase de reconocimiento.

¿Cuándo apareció el primer virus polimórfico?

Según la enciclopedia de Kaspersky, los primeros virus polimórficos aparecieron en 1990 con la familia Chameleon (1260, V2P1, V2P2 y V2P6), escrita por Mark Washburn. En 1992, Dark Avenger distribuyó el Mutation Engine (MtE), un generador que otros autores podían enlazar a sus virus para hacerlos polimórficos.

El metamorfismo se extendió con Windows de 32 bits. Virus Bulletin analizó en 2001 W95/Zmist, del autor ruso Zombie, y en 2002 W32/Simile, cuyo motor MetaPHOR ocupaba alrededor del 90 % del código y del que llegaron muestras de grandes empresas de España.

Sality, un infector polimórfico observado desde 2003, mantuvo su red de pares hasta que el 31 de agosto de 2026 CrowdStrike y sus socios, entre ellos el Departamento de Justicia y el FBI de Estados Unidos, la desarticularon. Las más de 33.000 infecciones existentes siguen activas y deben limpiarse.

¿Qué exigen el ENS, NIS2 e ISO 27001 frente al código dañino?

El Esquema Nacional de Seguridad (Real Decreto 311/2022) dedica la medida op.exp.6 a la protección frente a código dañino. Exige software de protección en puestos, servidores y elementos perimetrales, y el análisis de todo fichero procedente de fuentes externas. En categoría ALTA añade el refuerzo R3, que solo permite ejecutar aplicaciones autorizadas, y el R4, que pide herramientas EDR, según el texto del BOE.

El artículo 21.2 de la Directiva NIS2 no menciona el malware de forma expresa. El Reglamento de Ejecución (UE) 2024/2690, aplicable a proveedores de nube, centros de datos y proveedores de servicios gestionados, entre otros, lo hace en su punto 6.9. Obliga a detectar o impedir el software malicioso o no autorizado y, cuando proceda, a contar con software de detección y respuesta. La guía técnica de ENISA de junio de 2025 recomienda además la lista de aplicaciones permitidas y la vigilancia del comportamiento del sistema.

La norma ISO/IEC 27001:2022 recoge la protección frente al malware en el control 8.7 del anexo A, apoyada en la concienciación de los usuarios. Las tres normas apuntan a los dos controles que no dependen de reconocer la forma del código, la lista de aplicaciones permitidas y la detección por comportamiento.

Fuentes y metodología: este artículo se basa en NIST SP 800-83, MITRE ATT&CK y los análisis de Virus Bulletin, Symantec y Kaspersky. También usa los informes de Google Threat Intelligence Group, CyberArk, CERT-UA y CrowdStrike, la documentación de Microsoft y los textos del ENS y de NIS2, consultados a 20 de octubre de 2026. Las cifras de fabricantes se citan con su fecha y son ilustrativas.

Aviso: los nombres de reglas, tablas y productos corresponden a Microsoft Defender y Windows, y otras plataformas ofrecen controles equivalentes. Las consultas, las reglas ASR y el control de aplicaciones deben probarse en modo auditoría y adaptarse a cada entorno antes de pasar a bloqueo.