/
← Voltar ao feed
high manufacturing

PAYLOAD extortion group abuses domain-root GPO to disrupt a Middle East manufacturer without deploying a Windows encryptor

1 fonte(s) · 1 atualização(ões) · publicado 21/09/2026 07:00 · coletado há 4 dias

In April 2026, Kaspersky GERT responded to an incident at a Middle East manufacturing organization where the actor gained domain admin-equivalent control of Active Directory. The actor created and linked a malicious GPO named PAYLOAD at the domain root. It pushed ransom notes, a wallpaper and lock screen, a logon banner and a local administrator lockout to every domain-joined Windows workstation. No Windows encryptor, endpoint persistence or malicious processes were found. The only ransomware recovered was a PAYLOAD ESXi variant on Linux servers. Data was also exfiltrated from file servers and other systems and later published on the dark web.

Detalhes técnicos

  • Initial access: a valid account (T1078) used on the FortiGate SSL VPN (T1133). Insufficient logging prevented determining how the credential was obtained. Password spraying, phishing and purchase from an initial access broker were all considered plausible. The lateral movement and privilege escalation path to GPO write rights could not be reconstructed.
  • PAYLOAD GPO: used the Group Policy Files CSE to drop hello.txt as read-only README-payload.txt on the desktop and in C:\ and D:\. The Group Policy Registry CSE set legalnoticecaption to "Welcome to Payload!" and legalnoticetext to the ransom note. payload.jpg was set as wallpaper and lock screen, and the Security Settings CSE (GptTmpl.inf) was edited to revoke administrator rights and lock the account. Loopback processing was used.
  • Second GPO, "win Firewall Off": disabled Windows Firewall on the domain, private and public profiles (T1562.004).
  • Delayed detonation: the GPO was created on 13 April and took effect on 14 April, when machines rebooted. This breaks the link between the GPO creation event and the visible impact.
  • Family capabilities (from public reverse engineering, not confirmed in this incident): Windows Event Log clearing (T1685.005), security and backup process and service termination (T1685, T1489), and VSS deletion (T1490).
  • Ecosystem techniques (not attributed to this case): ETW patching, BYOVD (T1068) and ESXi policy weakening.
  • Detection: enable DS Access auditing and alert on Event IDs 5137, 5136 and 5141, especially gPLink changes at the domain root by non-standard accounts. Monitor SYSVOL for unexpected files and modified registry.pol or GptTmpl.inf, and review the Group Policy Operational log. Treat SYSVOL changes with no matching 5136 event as suspicious, since they may indicate direct editing with tools such as PowerView or SharpGPOAbuse.

Remediação

Remove the malicious source GPOs from the domain controllers first, because endpoint cleanup is ineffective while the policy refresh re-applies them. The article then recommends a four-phase approach: domain controller actions, Active Directory and GPO hardening, credential and access hardening, and detection and monitoring. The text is truncated before the detailed steps.

Linha do tempo

  1. securelist.com ↗ · pub. 21/09/2026 07:00 · coletado 19/10 17:56 primeiro registro

    PAYLOAD extortion group abuses domain-root GPO to disrupt a Middle East manufacturer without deploying a Windows encryptor

    ler a análise desta fonte

    In April 2026, Kaspersky GERT responded to an incident at a Middle East manufacturing organization where the actor gained domain admin-equivalent control of Active Directory. The actor created and linked a malicious GPO named PAYLOAD at the domain root. It pushed ransom notes, a wallpaper and lock screen, a logon banner and a local administrator lockout to every domain-joined Windows workstation. No Windows encryptor, endpoint persistence or malicious processes were found. The only ransomware recovered was a PAYLOAD ESXi variant on Linux servers. Data was also exfiltrated from file servers and other systems and later published on the dark web.

    Technical Details

    • Initial access: a valid account (T1078) used on the FortiGate SSL VPN (T1133). Insufficient logging prevented determining how the credential was obtained. Password spraying, phishing and purchase from an initial access broker were all considered plausible. The lateral movement and privilege escalation path to GPO write rights could not be reconstructed.
    • PAYLOAD GPO: used the Group Policy Files CSE to drop hello.txt as read-only README-payload.txt on the desktop and in C:\ and D:\. The Group Policy Registry CSE set legalnoticecaption to "Welcome to Payload!" and legalnoticetext to the ransom note. payload.jpg was set as wallpaper and lock screen, and the Security Settings CSE (GptTmpl.inf) was edited to revoke administrator rights and lock the account. Loopback processing was used.
    • Second GPO, "win Firewall Off": disabled Windows Firewall on the domain, private and public profiles (T1562.004).
    • Delayed detonation: the GPO was created on 13 April and took effect on 14 April, when machines rebooted. This breaks the link between the GPO creation event and the visible impact.
    • Family capabilities (from public reverse engineering, not confirmed in this incident): Windows Event Log clearing (T1685.005), security and backup process and service termination (T1685, T1489), and VSS deletion (T1490).
    • Ecosystem techniques (not attributed to this case): ETW patching, BYOVD (T1068) and ESXi policy weakening.
    • Detection: enable DS Access auditing and alert on Event IDs 5137, 5136 and 5141, especially gPLink changes at the domain root by non-standard accounts. Monitor SYSVOL for unexpected files and modified registry.pol or GptTmpl.inf, and review the Group Policy Operational log. Treat SYSVOL changes with no matching 5136 event as suspicious, since they may indicate direct editing with tools such as PowerView or SharpGPOAbuse.

    Remediation

    Remove the malicious source GPOs from the domain controllers first, because endpoint cleanup is ineffective while the policy refresh re-applies them. The article then recommends a four-phase approach: domain controller actions, Active Directory and GPO hardening, credential and access hardening, and detection and monitoring. The text is truncated before the detailed steps.