Ataques de « malware » basados en IA: cómo la IA transforma el software malicioso y cómo defenderse de él

En septiembre de 2026, el Grupo de Inteligencia sobre Amenazas de Google informó de un caso en el que un atacante utilizó un flujo de trabajo basado en IA para planificar, desarrollar y llevar a cabo una recopilación masiva de credenciales en menos de seis horas tras obtener acceso de tipo « cloud ». Se trataba de una campaña concreta observada, no de la duración típica de un ataque. Esto ilustra la preocupación operativa que suscitan los ataques de « malware » basados en IA: la IA puede acortar algunas fases del ciclo de ataque, incluso cuando la vulnerabilizació a sigue dependiendo de puntos débiles ya conocidos.

Los ataques de « malware » basados en IA son intrusiones en las que un atacante utiliza la IA para diseñar, modificar, distribuir o ejecutar software malicioso. El término abarca distintos niveles de participación de la IA. Un desarrollador puede utilizar un modelo para escribir código, mientras que un implante más inusual puede consultar un modelo durante la ejecución para decidir qué hacer a continuación. Se trata de amenazas distintas, con pruebas y defensas diferentes. Esta guía las distingue, analiza casos documentados y ofrece a los equipos de seguridad una forma práctica de detectarlas y responder a ellas.

¿Qué se considera un ataque de « malware » de IA?

La pregunta relevante es en qué punto de la cadena de ataque interviene la IA. Malware no se convierte en una nueva «especie» técnica por el mero hecho de que un modelo haya ayudado a escribirlo. El impacto en la seguridad depende de lo que haga el código, de lo que controle el atacante y de si el modelo sigue interviniendo tras la implementación.

Estas categorías pueden solaparse. Tampoco deben confundirse con la detección de amenazas mediante IA, que es el uso defensivo de la IA, ni con los ataques contra una aplicación de IA, como prompt injection. Para obtener una definición general y una taxonomía, consulta la guía «malware ».

«Asistido por IA» no es lo mismo que «autónomo»

«Generado por IA» da una idea del origen del desarrollo. «Autónomo» da una idea del control operativo. Ninguno de estos términos por sí solo indica si un ataque ha tenido éxito. Un programa de robo de datos escrito mediante un modelo puede ejecutarse íntegramente a partir de instrucciones fijas. Por el contrario, un programa relativamente pequeño puede delegar una tarea concreta, como la navegación por una interfaz, a un modelo en tiempo de ejecución.

El « malware » polimórfico es anterior a la IA generativa

MITRE ATT&CK describe el código polimórfico como un software que modifica su huella en tiempo de ejecución sin dejar de cumplir su objetivo. Los motores de mutación ya existían antes de los grandes modelos de lenguaje. La IA puede acelerar la variación del código o seleccionar variantes, pero un hash cambiante no es prueba de que la IA haya generado la muestra.

Cómo utilizan los atacantes la inteligencia artificial para crear y llevar a cabo sus operaciones malware

El modelo de amenazas más fundamentado parte de pasos concretos, en lugar de basarse en la afirmación de que todos los ataques están totalmente automatizados. Las investigaciones actuales documentan el uso de la inteligencia artificial en el desarrollo, la ofuscación y las decisiones operativas, con distintos niveles de madurez y visibilidad.

Desarrollo e iteración

Un atacante puede utilizar un modelo de programación para esbozar componentes, explicar errores, portar código entre lenguajes, escribir lógica de señuelo o automatizar pruebas. En su análisis de mayo de 2026, el Grupo de Inteligencia sobre Amenazas de Google describió CANFAIL y LONGSTREAM, dos familias de « malware » utilizadas en actividades dirigidas contra organizaciones ucranianas. Los investigadores encontraron código que evaluaron como relleno generado por un modelo, diseñado para ocultar funciones maliciosas. En LONGSTREAM, identificaron 32 consultas inactivas sobre el estado del horario de verano, un ejemplo de volumen de código de apariencia inofensiva más que de un nuevo objetivo de ataque. Las 32 instancias describen una familia de código analizada, no una medida de prevalencia.

Para los defensores, la pregunta inmediata sigue siendo si un archivo binario o un script malicioso puede ejecutarse, lograr persistencia, robar credenciales o comunicarse con el exterior. La autoría de la IA puede complicar la atribución, pero no elimina esos comportamientos.

Ofuscación y variación del código

La IA puede ayudar a reescribir código, añadir ramas inactivas y variar el empaquetado para frustrar la comparación estática. El Grupo de Inteligencia sobre Amenazas de Google describió PROMPTFLUX, un dropper experimental en VBScript diseñado para consultar a un modelo con el fin de que se modifique a sí mismo. El análisis de Google indicaba explícitamente que la versión observada se encontraba en fase de desarrollo o prueba y no demostraba la capacidad de comprometer un dispositivo o una red. Se trata de una prueba de un método en fase de prueba, no de un uso generalizado y exitoso.

Los hash y las firmas de archivos estáticos siguen siendo útiles para las muestras conocidas. Combínalos con datos de telemetría de procesos, memoria, identidad y red, para que los cambios en la apariencia de un archivo no se conviertan en un punto ciego.

Llamadas al modelo durante la ejecución

Un « malware » integra un servicio de IA en su flujo de trabajo de ejecución. Google informó de que PROMPTSTEAL, utilizado contra Ucrania, consultó un modelo a través de una API para generar comandos destinados a recopilar información del sistema y documentos. El « malware » ejecutó dichos comandos y envió los datos recopilados a la infraestructura del atacante. Google señaló que se trataba de la primera vez que observaba que un « malware » consultaba un modelo en operaciones en vivo. Se trata de una prueba operativa más sólida que la muestra experimental de PROMPTFLUX, pero aún así no demuestra que este tipo de « malware » sea habitual.

En su análisis de mayo de 2026, Google describió PROMPTSPY, una puerta trasera para Android que utilizaba un modelo para interpretar el estado de la interfaz y devolver acciones para la navegación por el dispositivo. Se trata de un ejemplo específico de un dispositivo. Sus mecanismos de accesibilidad y persistencia de aplicaciones de Android no deben generalizarse a entornos empresariales de Windows o Linux malware.

Flujos de trabajo más rápidos para los operadores

La IA también puede situarse fuera de la « malware ». Un operador humano puede utilizar agentes para priorizar objetivos, depurar herramientas o gestionar los escaneos y la recopilación de credenciales. El caso de Google de septiembre de 2026 se refería a una campaña basada en agentes que se completó en menos de seis horas. Su rapidez es importante porque permite reducir el tiempo de espera para las decisiones manuales de los operadores. El caso no demuestra que todas las intrusiones asistidas por IA sean más rápidas, ni que el propio « malware » tomara todas las decisiones.

Lo que demuestran las pruebas y lo que no demuestran

La progresión desde la asistencia en la escritura de código hasta el uso de modelos en tiempo de ejecución es una realidad en los casos documentados, pero los ejemplos no deben confundirse con la prevalencia. Las pruebas son más sólidas cuando los investigadores pueden examinar muestras, artefactos de desarrollo o datos de telemetría de incidentes y describir lo que se observó realmente.

La tendencia actual apunta a una mayor implicación de la IA, desde la asistencia al desarrollo hasta las llamadas a modelos durante la ejecución. Esto facilita la detección de código alterado y agiliza los flujos de trabajo. Sin embargo, no respalda la afirmación generalizada de que el « malware » sea ya autónomo, de que las firmas sean inútiles o de que la mayoría de las infecciones sean generadas por la IA. El resumen de M-Trends 2026 de Google advertía, de forma similar, que la gran mayoría de las intrusiones exitosas que observó seguían debiéndose a fallos humanos y sistémicos ya conocidos.

Cómo avanzan los ataques de « malware » basados en IA por todo un entorno

Incluso un implante novedoso debe conseguir acceso, ejecutarse y producir efectos. Los defensores pueden organizar la investigación en torno a estas etapas observables sin depender de un único nombre de familia malware.

1. Acceso y ejecución. Un archivo adjunto malicioso, un paquete comprometido, un servicio expuesto o unas credenciales robadas proporcionan al atacante una vía de acceso. Determina qué se ejecutó, con qué identidad y en qué recurso.

2. Detección y adaptación. El código u operador realiza un inventario del software, los controles de seguridad, los archivos o los servicios cloud . La IA puede ayudar a interpretar esas observaciones, pero la detección de anomalías sigue siendo observable.

3. Persistencia y privilegios. Las tareas programadas, los cambios en los servicios, el uso de tokens o las concesiones no autorizadas amplían el acceso. Comprueba si un cambio está autorizado antes de considerarlo malicioso.

4. Movimiento y control. Esté atento a nuevas sesiones remotas, rutas de acceso inusuales, llamadas salientes a modelos o API y tráfico de comando y control. Una simple solicitud a la API de un modelo no es prueba de que se haya producido una intrusión; hay que relacionarla con el proceso y las acciones posteriores.

5. Recopilación e impacto. El acceso a archivos, la recopilación de credenciales, la preparación de datos, la exfiltración, el cifrado o la interrupción del servicio revelan el objetivo. Conserva las marcas de tiempo y las relaciones entre entidades para que se pueda reconstruir la secuencia.

Esta visión por fases resulta especialmente útil cuando la carga útil cambia de forma. Además, permite que el equipo se centre en el impacto si la afirmación sobre el origen de la IA sigue siendo incierta.

Cómo detectar e investigar posibles casos de uso de IA malware

La detección debe combinar controles basados en el «malware » con el análisis del comportamiento en todos los dispositivos, identidades, redes y servicios cloud . El objetivo es confirmar una cadena de ataque, no etiquetar cada proceso desconocido como « malware de IA».

Mantener los controles convencionales de « malware »

Mantén la protección de los terminales, la aplicación de parches, las comprobaciones de procedencia del software y la comparación con indicadores conocidos. Las muestras y variantes conocidas aún pueden bloquearse. Añade el historial de procesos, la telemetría de scripts y memoria, y los controles de políticas de ejecución para las técnicas que eluden la simple comparación de archivos. La entrada sobre código polimórfico de MITRE recomienda explícitamente métodos basados en el comportamiento junto con los controles antimalware.

Correlacionar el comportamiento más allá del archivo

Analiza combinaciones como un proceso de reciente lanzamiento que lee almacenes de credenciales, se pone en contacto con un servicio externo desconocido, inicia un acceso remoto y prepara datos. Relaciona el host con la cuenta que utilizó y con las acciones de « cloud » o SaaS que se produjeron a continuación. El contexto de red e identidad puede revelar la progresión cuando cambia el hash de un archivo o cuando un agente de punto final carece de visibilidad. El caso de uso de detección de brechas de EDR de Vectra AI describe esta visibilidad complementaria; los equipos deben validar la cobertura real en su entorno.

Considera el tráfico del modelo como un contexto, no como un veredicto

Siempre que la política lo permita, registra el proceso de llamada, el destino, la cuenta, la hora, el volumen de solicitudes y los comandos posteriores para los servicios de IA empresariales. Una herramienta legítima para desarrolladores puede generar un tráfico similar. Notifica a tus superiores cuando un proceso sospechoso realice llamadas al modelo y, a continuación, ejecute comandos generados, modifique la persistencia o acceda a datos confidenciales. Evita recopilar indicaciones o cargas útiles que excedan las políticas aprobadas de privacidad y retención.

Utiliza una breve lista de comprobación para la investigación

Si no se dispone de registros de uso del modelo, indique que no se ha confirmado la participación de la IA. No obstante, se puede seguir adelante con la respuesta basándose en el comportamiento malicioso observado.

Cómo reducir el riesgo y actuar ante él

Los controles más útiles limitan lo que puede hacer un « malware » o un operador asistido por IA tras el acceso. Hay que dar prioridad al control de acceso basado en la identidad, las rutas de ejecución, la salida de datos y la velocidad de respuesta, junto con la prevención.

1. Reducir la exposición. Aplique parches a los servicios vulnerables, restrinja los paquetes y scripts no fiables, revise los permisos de las herramientas de desarrollo y proteja las claves de API y las credenciales de los agentes. Aplique el principio del privilegio mínimo a las identidades de « cloud » y SaaS.

2. Implementa la ruta de ataque. Mantén los registros de los terminales, la red, la identidad, cloud y los servicios de IA pertinentes con la hora sincronizada. Define quién puede revisar las pruebas de uso de los modelos y durante cuánto tiempo se conservan.

3. Probar las detecciones basadas en el comportamiento. Simular el descubrimiento autorizado, el acceso mediante credenciales, la ejecución remota y la preparación de datos. Evaluar si el equipo es capaz de vincular los eventos en un único incidente sin recurrir a un hash conocido.

4. Contener la cadena de infección observada. Aislar los hosts afectados cuando sea necesario, revocar las sesiones activas y los tokens expuestos, bloquear los destinos maliciosos confirmados y conservar las pruebas forenses antes de proceder a una limpieza general.

5. Recuperarse y aprender. Restablecer el sistema a partir de fuentes fiables, comprobar que se ha eliminado cualquier rastro persistente, rotar las credenciales afectadas y comparar la cronología con las marcas de tiempo de detección y contención. Actualizar los manuales de actuación para cualquier paso omitido relacionado con la identidad, la red o el « cloud ».

Una evaluación útil plantea la siguiente pregunta: ¿podría el equipo identificar la identidad comprometida, los activos afectados y la siguiente acción del atacante con la rapidez suficiente para intervenir? Registra por separado el tiempo de detección, el tiempo de investigación y el tiempo de contención. Un ejercicio controlado permite poner a prueba esa cuestión sin dar por sentada la eficacia de un proveedor concreto.

Dónde Vectra AI

Vectra AISu posicionamiento en materia de seguridad y observabilidad nativas de la IA resulta relevante cuando un ataque se desplaza entre identidades, redes, servicios de « cloud » y terminales. Su caso de uso de detección de brechas mediante EDR describe una visibilidad del comportamiento que va más allá de los terminales gestionados. En el caso de las investigaciones basadas en IA « malware », lo que hay que evaluar es si las señales disponibles ayudan a los analistas a relacionar el uso indebido de credenciales, el movimiento lateral y la exfiltración con una intrusión activa. La adecuación del producto y las acciones de respuesta dependen de la implementación, las integraciones y los permisos, por lo que conviene verificarlos en una prueba de valor.

Si estás configurando tus controles, empieza por los conceptos básicos de «malware » y la guía de detección de amenazas de IA. Los equipos que evalúen las deficiencias más allá de la telemetría de los puntos finales pueden consultar el caso de uso de detección de deficiencias de EDR. Para obtener asesoramiento específico sobre la implementación tras dicha evaluación, solicita una demostración de « Vectra AI ».

Nota sobre la fuente y el método: Esta guía de investigación se contrastó el 22 de octubre de 2026 con los informes originales de los investigadores y con MITRE ATT&CK. Los casos no constituyen un estudio de incidencia ni una prueba independiente del producto.

‍