Ransomware PAYLOAD: tomaron el Active Directory y dejaron el rescate en cada PC por GPO

El equipo de respuesta a emergencias de Kaspersky (GERT) publicó el 21 de septiembre de 2026 la reconstrucción de un ataque de ransomware en el que el rescate no llegó a las PCs dentro de un programa: llegó por una directiva de grupo (GPO), la herramienta con la que una empresa configura de una sola vez todas las computadoras de su dominio —el Active Directory, el directorio de usuarios y equipos que se administra desde un servidor Windows—.

El atacante entró por la VPN con una credencial válida comprometida y, con permisos de administrador de dominio o equivalentes, creó una GPO llamada PAYLOAD en la raíz del dominio: con esa sola pieza de configuración dejó el rescate en todas las PCs con Windows unidas al dominio.

En esas PCs no se cifró ni un archivo. Según Kaspersky, al momento del análisis no había en ellas ejecutables maliciosos residentes, persistencia ni procesos maliciosos: del lado de las PCs, todo el ataque vivió adentro del Active Directory. Eso no lo volvió inofensivo. Antes del rescate hubo robo de datos desde los servidores de archivos y otros sistemas, que terminaron publicados en la dark web, y en servidores Linux de la organización apareció una variante de PAYLOAD para servidores de virtualización ESXi. La víctima fue una empresa manufacturera de Medio Oriente; el informe no documenta casos en América Latina.

Si tu empresa tiene un servidor con Windows y las PCs unidas a un dominio, la frase que importa del informe es esta: una organización que dependa de detectar el ejecutable del ransomware «no habría visto nada» hasta que la primera PC reinició y apareció el fondo del rescate. El rastro más temprano y más útil quedó en el controlador de dominio, y casi todo lo que conviene revisar ya viene con Windows Server.

Si en cambio trabajás con PCs sueltas, sin servidor ni dominio, este ataque en particular no te alcanza, pero la puerta de entrada sí (la medida 2). Y si sos empleado y un día al prender la PC aparece un cartel así, avisá a quien administra los sistemas: el problema no está en tu computadora sino en el servidor, y formatearla no lo arregla.

Qué revisar hoy si tu empresa tiene dominio

Salen de las recomendaciones del propio informe, ordenadas de la más urgente a la más estructural; la primera es una adaptación nuestra de las alertas que propone, para quien no tiene un sistema que las dispare. Si el dominio lo administra un proveedor externo, esta lista es para mandársela.

1. Mirá qué directivas cuelgan de la raíz del dominio

En la consola de Administración de directivas de grupo (GPMC), fijate qué GPO están vinculadas directamente al dominio: son las que se aplican a todas las computadoras y usuarios que dependen de él. Si aparece una que nadie en la empresa reconoce —en este caso se llamaban «PAYLOAD» y «win Firewall Off»—, tratala como un incidente. Kaspersky señala que un cambio en los vínculos de la raíz del dominio hecho por una cuenta fuera de lo habitual es uno de los indicadores más reveladores de este tipo de ataque.

2. Doble factor resistente al phishing en la VPN

La puerta de entrada fue una cuenta válida usada contra la VPN SSL de un equipo FortiGate. El informe no dice si esa VPN pedía un segundo factor; sí recomienda autenticación multifactor resistente al phishing en todas las entradas de VPN y de acceso remoto, que no es lo mismo que un código por SMS. Si la tuya se abre solo con usuario y contraseña, una credencial comprometida alcanza para entrar. Esta es la única medida de la lista que, según cómo esté armada tu VPN, puede pedir comprar algo, como llaves de seguridad o un servicio de identidad.

3. Prendé la auditoría de cambios en el directorio

En los controladores de dominio, la directiva de auditoría avanzada tiene una subcategoría llamada «Auditar cambios de servicio de directorio» (Audit Directory Service Changes, dentro de Acceso DS). Kaspersky pide activarla en todos los controladores y vigilar tres eventos:

• 5137: se creó un objeto en el directorio, como una GPO nueva. La cuenta que la creó tiene que ser un administrador de directivas autorizado.
• 5136: se modificó un objeto, como el vínculo de una GPO en la raíz del dominio.
• 5141: se borró un objeto, lo que sirve para detectar manipulaciones y para evaluar una limpieza.

Un detalle de la documentación de Microsoft que conviene no pasar por alto: esta auditoría solo genera eventos sobre los objetos que tienen configurada su lista de auditoría (SACL). Activarla no alcanza si nadie comprobó que el evento aparece, y el propio informe advierte que la falta de un evento esperado puede deberse a una auditoría mal configurada.

4. Separá quién crea directivas de quién las vincula

Para crear una GPO y vincularla a la raíz del dominio, la cuenta con la que se hizo tenía que ser administradora de dominio o tener un poder equivalente delegado; el informe da como ejemplo pertenecer al grupo Group Policy Creator Owners y tener permiso para vincular en el dominio. Kaspersky recomienda separar el permiso de crear GPO del de vincularlas, darlos solo a un rol de administrador dedicado y auditado, y que los administradores de dominio no inicien sesión en PCs ni en servidores comunes.

En una PyME, el primer paso suele ser más básico: saber cuántas cuentas son administradoras de dominio hoy y que ninguna sea la que alguien usa para leer el correo.

5. Windows LAPS, sin costo de licencia

La última de la lista es Windows LAPS, la función de Windows que le pone a cada equipo una contraseña de administrador local distinta, la rota sola y la guarda de forma segura. Microsoft explica por qué importa: las cuentas de administrador local suelen compartir la misma contraseña en muchos equipos, y un atacante lo aprovecha para moverse de uno a otro. Si las contraseñas se guardan en Active Directory, no pide licencias adicionales.

Viene de fábrica en Windows Server 2025 y en Windows 11 23H2 en adelante, y llega con la actualización del 11 de abril de 2023 o posterior a Windows Server 2019 y 2022, a Windows 11 21H2 y 22H2 y a Windows 10 (en este caso, solo mientras siga recibiendo actualizaciones, por ejemplo con ESU). Para versiones anteriores queda el LAPS clásico, ya obsoleto, con soporte hasta que termine el de cada una.

Cómo fue, día por día

Kaspersky reconstruyó la secuencia con el análisis forense de las PCs y del controlador de dominio. Todas las fechas son de 2026:

Lo que cambió en cada PC

Kaspersky listó los cambios con un análisis del conjunto resultante de directivas (RSoP) en las PCs afectadas. La GPO «PAYLOAD» hizo cuatro cosas, todas con mecanismos normales de las directivas de grupo:

• La nota de rescate, por todos lados. Copió un archivo de texto desde SYSVOL al escritorio y a la raíz de los discos C: y D:, como README-payload.txt de solo lectura.
• Un cartel antes de entrar. Usó el aviso legal de inicio de sesión de Windows —el mismo que muchas empresas usan para recordar que el equipo es corporativo— con el título «Welcome to Payload!» y el pedido de rescate como texto.
• El fondo y la pantalla de bloqueo. Los dos pasaron a mostrar una imagen alojada en el propio controlador de dominio.
• El administrador local, afuera. Dejó deshabilitada la cuenta de administrador local de cada equipo.

La segunda GPO, «win Firewall Off», apagó el firewall de Windows en los perfiles de dominio, privado y público de todos los equipos. Según Kaspersky, se desplegó aparte de «PAYLOAD», debilitaba las defensas de cada PC y le garantizaba al atacante acceso por red a los equipos para lo que viniera después.

El día que la directiva esperó

Es, según el propio informe, el detalle más instructivo del caso desde lo forense. La GPO se escribió el 13 de abril y ese mismo día quedó guardada en las PCs. Kaspersky explica que la parte que cambia la configuración del equipo —fondo y pantalla de bloqueo, opciones de seguridad, firewall— se aplica al reiniciar o en una actualización de directivas, y que ninguna PC había reiniciado; el informe no aclara por qué la actualización periódica tampoco la aplicó antes.

El ataque quedó un día dormido, hasta que las máquinas se reiniciaron según los procedimientos habituales y el rescate apareció de golpe en la mayoría de las PCs.

Kaspersky le ve dos consecuencias posibles: puede darle al atacante una ventana tranquila para llevarse datos o preparar lo siguiente, y puede separar en el tiempo la causa (la creación de la GPO, que queda en el registro del directorio) del efecto (las pantallas del rescate), lo que complica reconstruir qué pasó si no había auditoría del directorio.

Leído al revés, que es como le sirve a una PyME: con la auditoría del punto 3 prendida, el evento de una GPO nueva que nadie pidió se registra cuando se crea; en este caso, eso fue un día antes de que apareciera el rescate.

Por qué el antivirus no tenía nada que oler

Contra las PCs, el atacante no llevó nada que un escáner pudiera revisar: usó las herramientas de la casa. Las directivas de grupo son, en palabras de Kaspersky, un canal de distribución firmado, permitido y con privilegios de SYSTEM que la mayoría de las herramientas de detección y respuesta de los equipos están diseñadas para no inspeccionar. Como todo se hizo con un mecanismo legítimo, «no hay código malicioso que las soluciones de seguridad puedan buscar»: la lógica maliciosa está en la configuración de la directiva.

Y la persistencia tampoco está en las PCs, sino en el vínculo de la GPO en el controlador de dominio: mientras siga ahí, cada actualización de directivas le vuelve a aplicar el rescate a una PC recién limpiada. Por eso la limpieza empieza por el servidor (el orden completo va más abajo). Kaspersky aclara, además, que PAYLOAD sí tiene una variante para Windows que cifra; en este caso no apareció en las PCs.

Tampoco es una técnica nueva, y el informe lo dice de entrada: los ataques por directivas de grupo «no son nada nuevo», y recuerda que ya los usaron operadores de Ryuk, LockBit y BlackCat/ALPHV para desplegar ransomware. La diferencia de este caso es que la GPO no fue el lanzador de un cifrador: fue el arma del impacto sobre las PCs.

Una aclaración que corresponde porque el autor vende la defensa: Kaspersky cierra afirmando que sus soluciones detectan esta actividad. Para su SIEM —el sistema que junta y cruza los registros de la red— publicó un paquete de reglas, que necesita recibir varios eventos de Windows (de Sysmon, de auditoría de archivos y del registro, y el 5136 del punto 3).

De su EDR dice que, con la auditoría bien configurada, puede alertar por los rastros que deja tocar una GPO, y que un tipo de evento específico para seguirlas recién llega en su próxima versión mayor; es el mismo informe que dice que la mayoría de las herramientas de ese rubro no están hechas para inspeccionar directivas.

No dice si la víctima usaba algún producto suyo. Y ya que estamos: en TCD vendemos licencias de consumo de Kaspersky, y ninguna cubre lo que recomienda este informe.

Y si te preguntás cómo llega alguien hasta el controlador de dominio de una empresa, el 3 de septiembre contamos cómo Microsoft siguió a un falso soporte técnico de Teams hasta el controlador de dominio. Acá la entrada fue otra —la VPN—, pero el destino es el mismo, y este caso muestra lo que puede hacer quien llega ahí.

Si ya apareció el cartel del rescate

Se empieza por el controlador de dominio, no por las PCs. El orden que propone Kaspersky:

• Borrar las GPO maliciosas desde la consola de administración y limpiar los archivos que dejaron en SYSVOL.
• Restablecer la contraseña de la cuenta comprometida y revisar todas las cuentas y grupos con privilegios, por si hubo cambios no autorizados.
• Rotar dos veces la contraseña de la cuenta krbtgt si se confirma que comprometieron un administrador de dominio.
• Recién entonces, forzar la actualización de directivas en las PCs (gpupdate /force) para rehabilitar el administrador local y el firewall con una directiva limpia.

Como en el caso documentado también hubo robo de datos, conviene que lo encare alguien con experiencia en respuesta a incidentes.

Lo que el informe no dice

• Cómo se comprometió la credencial. Los registros del FortiGate no alcanzaron para saberlo. Kaspersky deja tres hipótesis, sin orden de preferencia: pruebas masivas de contraseñas contra el portal de la VPN (password spraying o credential stuffing), robo por phishing o compra a un intermediario que vende accesos iniciales.
• Cómo se llegó del acceso por VPN al permiso de escribir directivas. Tampoco se pudo reconstruir: los registros de la VPN y de la plataforma de virtualización no alcanzaron. Las rutas más habituales para llegar a ese nivel de permisos —DCSync, Kerberoasting, pass-the-hash o pass-the-ticket, todas técnicas de abuso de credenciales del dominio— no se confirmaron ni se descartaron.
• Por qué no cifró. Kaspersky evalúa con confianza moderada dos escenarios: que haya sido una decisión deliberada para quedarse por debajo del daño irreversible y guardarse la opción de cifrar después, o que la operación se haya interrumpido antes de terminar.
• Quién fue. Más allá de hablar de los «operadores de PAYLOAD», no identifica al actor ni lo vincula con un grupo conocido.
• Qué más pasó fuera de las PCs. No cuenta si la variante para ESXi llegó a cifrar algo, solo que la evidencia no indica que se usaran las acciones para debilitar ESXi que describe. Su lista de indicadores incluye dos herramientas para matar procesos sin decir dónde aparecieron, aunque el mismo informe afirma que el impacto se logró sin un solo binario malicioso en ningún equipo.
• Lo que hace la familia. Las capacidades de PAYLOAD que describe —borrar registros de eventos, detener procesos de seguridad, borrar las instantáneas de volumen— salen de análisis públicos de otras muestras, y aclara que no se confirmaron en este incidente.

Fuentes

• Kaspersky GERT, «Group Policy hijacked: PAYLOAD ransomware weaponizes Active Directory GPO», Securelist, 21 de septiembre de 2026 (en inglés). Fuente primaria de todos los datos del caso.
• Microsoft Learn, «What is Windows LAPS?» (en inglés). Plataformas compatibles, licencias y para qué sirve.
• Microsoft Learn, «Audit Directory Service Changes» (en inglés). Qué registra esa subcategoría de auditoría y el requisito de SACL.

Las traducciones de las citas son propias; cada enlace lleva al original.