Detection engineering is both a role and an activity. It’s the discipline of building and maintaining the logic that identifies malicious or risky behavior within your organization. It’s where security analysis meets software engineering, turning raw logs and telemetry into actionable detections that defenders can rely on.
Detection engineers bridge the gaps between security operations, threat intelligence, and infrastructure. They understand how attackers operate, how defenders respond, and how systems generate the data that supports those detections. A well-built detection can mean the difference between an alert that matters and one that drowns in noise.
Precision and Recall: The Balancing Act
Every detection faces a trade-off between precision and recall.
Precision measures how much you can trust your alerts: of everything that fired, how much was actually malicious? High precision = fewer false positives = analysts trust the tool.
Recall measures how much you’re catching: of everything malicious that happened, how much did you detect? High recall = fewer blind spots = threats don’t slip through.
Detection engineering lives in the tension between the two: too much precision risks missing subtle threats; too much recall floods analysts with false positives. The goal is calibration through testing, iteration, and feedback.
Core Components of Detection Engineering
1. Scoping and Prioritization
Start with intent. What are you trying to detect, and why? Define the threats, behaviors, or assets that matter most, then align your work with frameworks such as MITRE ATT&CK®. Evaluate risk and value to determine which detections provide the highest impact for the effort required. Prioritize based on business importance and available telemetry.
2. Data and Telemetry
Great detections rely on great data. Keep inventory of your logs. Validate that each contains the data you need. Normalize and enrich your logs so detections remain consistent across tools and environments. Understanding how logs are generated is essential to writing logic that fits your environment.
3. Detection Logic Development
This is where hypothesis meets code. Write queries or rules that detect behaviors, not just static indicators. Combine multiple approaches:
Signatures for known indicators of compromise (IoCs)
Behavioral logic for Tactics, Techniques, and Procedures (TTPs) and patterns
Anomaly models for statistical outliers
4. Testing and Validation
Use adversary emulations or frameworks like Atomic Red Team to verify that your detections actually fire and your logging is working. Measure quality through precision, recall, and additional factors like confidence (how certain you are it’s malicious) and criticality (how severe the impact would be).
5. Deployment and Tuning
Monitor performance, including trigger frequency, false positive rates, and analyst response time. Detection engineering is iterative and ongoing, not “write once and done.”
6. Documentation and Knowledge Transfer
Good detections come with context. Record what the detection looks for, why it matters, what data it uses, and how it was tested. Version control your rules using Git and promote collaboration so analysts, hunters, and engineers can learn from one another. Playbooks and detection libraries ensure institutional knowledge does not disappear when staff change roles.
7. Metrics and Continuous Improvement
Track measurable outcomes such as coverage across ATT&CK® techniques, number of validated detections, false positive rates, and mean time to detect. Regularly retire stale detections, update ones that drift, and automate validation wherever possible. Detection-as-Code practices keep everything maintainable and scalable.
Building the Skillset
Detection engineering requires a strong foundation in logging, security tooling, and incident response. You should understand when it’s best to detect, when to block, and how to use data sources effectively.
Whether you’re building your first rule or managing hundreds, the mindset remains the same: test everything, learn constantly, and make each detection better than the last.
In April 2026, we at Kaspersky’s Global Emergency Response Team (GERT) responded to a security incident at a manufacturing organization in the Middle East. The threat actor obtained domain admin-equivalent control of the organization’s Active Directory environment and authored a malicious Group Policy Object (GPO) named PAYLOAD, linking it at the domain root. Through that single object, the actor delivered ransom notes, hijacked the desktop wallpaper and lock screen, enforced a logon banner, and disabled the local administrator account across every domain-joined Windows workstation — all without dropping a ransomware binary or encrypting any data. The only ransomware we found in this incident was PAYLOAD sample targeting ESXi on Linux servers. Besides that, data exfiltration was observed originating from the file servers and several additional systems, and was later published on the dark web.
Living-off-the-land abuse of trusted AD infrastructure. Group Policy is a signed, allowlisted, SYSTEM-privileged distribution channel that the majority of endpoint detection and response tools is designed not to inspect. By delivering impact through GPO rather than through malware, the actor sidestepped the entire file- and process-based detection stack.
Encryptionless extortion. Industry telemetry shows extortion-only incidents grow significantly year-on-year. PAYLOAD fits this model; the leverage is operational disruption and the threat of escalation rather than cryptographic denial of data.
We confirmed that no files were encrypted on Windows machines, no malicious binaries were resident on disk, no endpoint persistence was established, and no malicious processes were running at the time of analysis. The entire attack lived inside Active Directory itself. The defensive implication is stark: an organization whose detection strategy depends on catching a ransomware executable would have seen nothing until the first endpoint rebooted and the ransom wallpaper appeared.
In this article, we will describe the GPO attack chain and provide operational advice on how to detect such threats, including detailed remediation recommendations.
Group Policy as an attack surface
Attacks through group policies are nothing new. They can inflict significant, domain-wide damage with multiple malicious capabilities. A Group Policy Object (GPO) is essentially a combination of a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in SYSVOL. The Group Policy scope depends on whether the GPC is linked to the directory tree at the domain, site, or organization unit (OU) level. A link at the domain root means the policy applies to every computer and user object beneath it. Thus, a GPO compromised at the domain root can affect all in-scope domain users and computers, potentially granting an attacker complete control over the corporate network. What makes GPO abuse even more dangerous is that group policies are processed in a trusted, high-privilege environment, ensuring persistence because endpoint cleanup is not enough to remove them.
We have already discussed GPO architecture and ways it can be compromised in greater detail in an earlier blog post. Other public threat intelligence has also repeatedly documented this technique in ransomware operations. Microsoft observed Ryuk operators distributing ransomware through Group Policy, SYSVOL startup items, and PsExec. LockBit affiliates have been documented modifying SYSVOL Group Policy files, including ScheduledTasks.xml, to support ransomware execution and propagation. BlackCat/ALPHV operators have also abused GPOs to create scheduled tasks and deploy ransomware.
Another notable example of GPO abuse is PAYLOAD ransomware, which weaponizes GPO Preferences and policy settings for pure impact rather than as a launcher for an encryptor. Let’s take a closer look at this attack, which is detailed further below.
Attack timeline
During the April 2026 investigation, we managed to reconstruct the attack timeline as outlined below:
Date
Event
11 April
Initial access. Threat actor authenticates to the FortiGate SSL VPN using a valid but compromised domain credential.
13 April
GPO authored. Malicious GPO, PAYLOAD ({C897F2C7-C2AC-4E6F-BF48-58036FF29E79}) created and linked at the domain root, configuring ransom notes, wallpaper, lock screen, logon banner, and administrator account disablement.
13 April
SYSVOL staging. The payload.jpg and hello.txt files written to \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
13 April
Second GPO. GPO named win Firewall Off ({22099AD2-E062-4F56-B574-5099BBA4E7A6}) linked at the domain root, disabling Windows Firewall on all profiles.
13 April
Dormancy. GPO cached on endpoints but computer configuration not yet applied — no endpoint had rebooted since the policy update.
13 April
Data exfiltration. Data exfiltration was observed originating from the file servers and several additional systems.
14 April
Detonation. Most of the endpoints begin rebooting; computer configuration policies apply. Ransom wallpaper, logon banner, and notes appear. Operational disruption begins.
15 April
Response. Kaspersky GERT engaged. Forensic triage of affected workstations and the domain controller initiated.
16 April
Assessment. GERT confirms no file encryption, no resident malware, no endpoint persistence.
Next, we will discuss each of these stages in more detail and share the findings from our incident response activities.
Incident overview
Initial access
The entry vector was a compromised valid account (MITRE ATT&CK T1078) used to authenticate through the organization’s FortiGate SSL VPN — an external remote service (T1133). Insufficient logging on the FortiGate appliance prevented us from reconstructing how the credential was originally compromised.
Three hypotheses were considered plausible in the context of the attack, in no particular order:
Password spraying or credential stuffing against the SSL VPN portal.
Phishing-led credential harvesting.
Purchase of pre-compromised credentials from an initial access broker (IAB).
Once on the internal network, the actor operated with the compromised security principal’s privileges. Because the account was able to create and link a GPO at the domain root, it held either domain admin privileges or a delegated equivalent (e.g., membership of Group Policy Creator Owners combined with link rights on the domain object).
FortiGate SSL VPN authentication logs and ESXi/virtualization privilege escalation logs were insufficient to reconstruct the lateral movement and privilege escalation chain between initial VPN access and the GPO write privilege level. The most common real-world routes to GPO control — DCSync, Kerberoasting of privileged service accounts, and Pass-the-Hash/Pass-the-Ticket — could not be confirmed or ruled out.
Execution
Rather than deploying an encryptor, the actor abused the victim’s Active Directory policy infrastructure, resulting in malicious GPOs being configured and linked at the domain root to deliver the observed impact across domain-joined systems. The two GPOs below constitute the entire offensive toolkit observed.
The PAYLOAD GPO
We performed a Resultant Set of Policy (RSOP) analysis, which helped us list all policy settings on the affected workstations. From these results, we reconstructed the following changes delivered by PAYLOAD:
Drop SYSVOL\hello.txt to the desktop and root directories C:\ and D:\ as a read-only README-payload.txt by tampering with the “Group Policy Files” client-side extension (CSE).
Modify the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ registry key, changing the legalnoticecaption value to "Welcome to Payload!" and the legalnoticetext to the ransom note text through the “Group Policy Registry” CSE.
Set payload.jpg located in the targeted domain controller’s SYSVOL as the lock screen image by altering the personalization policy, and as the wallpaper by altering the desktop policy at the user level.
Revoke administrator rights for the administrator account (locking the account) by editing the Security Settings CSE in the GptTmpl.inf file.
Settings changed by PAYLOAD GPO
This activity was enabled entirely through a legitimate group policy mechanism, meaning there is no malware code for security solutions to look for because the malicious logic is contained within the policy configuration.
The win Firewall Off GPO
A second domain-root-linked GPO, named “win Firewall Off”, disabled Windows Firewall across the domain, private and public profiles on all endpoints (T1562.004). Deployed independently of PAYLOAD, this object degraded host defenses and ensured the actor retained unimpeded network reach to endpoints for any follow-on activity.
Settings changed by win Firewall Off GPO
The one-day delay detonation
The most forensically instructive detail is the one-day gap between GPO creation (13 April) and visible impact (14 April). Analysis of Master File Table (MFT) timestamps and the Group Policy History registry key confirmed the policy was written to SYSVOL and cached on endpoints on 13 April. However, computer configuration settings (wallpaper and lock screen machine policy, security settings, firewall disabling) only apply upon reboot or policy refresh — and no endpoint had rebooted in the interim. The attack therefore remained dormant in the GPO cache for one day before detonating en masse when machines were restarted in accordance with standard procedures.
We have to point out here that this delayed policy application is characteristic of GPO-based operations and has two potential consequences for defenders. Firstly, it may grant the actor a quiet window for exfiltration, persistence, or further staging between weaponization and impact. Secondly, it can be used to sever the temporal link between the cause (a GPO-creation event in the directory log) and the effect (mass user-visible disruption occurring at a later time), complicating timeline reconstruction unless directory service auditing is in place.
Forensic findings
Initial incident response engagement revealed a number of findings associated with the attack that we share below.
No file encryption
A full review of the MFT on affected workstations found no files bearing a .payload extension characteristic to PAYLOAD ransomware and no evidence of bulk renaming or encryption I/O patterns. The attackers’ objectives were operational disruption and extortion via visual impact and access denial.
No endpoint persistence
All standard persistence locations were clean:
Scheduled tasks — no malicious tasks
Run/RunOnce keys — clean
Startup folders (user and system) — clean
Services — no malicious service installed
WMI event subscriptions — none
Boot sector/MBR — unmodified
The attack’s persistence mechanism is the GPO link itself on the domain controller, with no endpoint-resident component.
No active malicious processes
Live process and memory analysis revealed no injected threads, process hollowing or anomalous outbound connections.
Registry timeline analysis
Group Policy History, Shadow and State registry keys on the workstation recorded the application of PAYLOAD on 13 April:
HKLM\…\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1
HKLM\…\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0
HKLM\…\Group Policy\State\Machine\GPO-List\7
HKCU\…\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1
HKCU\…\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5
The presence of the “Loopback-GPO-List” entry indicates the GPO was processed in loopback mode, ensuring the user configuration (wallpaper) applied regardless of which user logged on to the machine.
SYSVOL artifacts
Two files were staged on the domain controller’s SYSVOL share and served to endpoints through the Files Group Policy Preference CSE:
payload.jpg — the ransom image used for both wallpaper and lock screen.
hello.txt — the ransom note, distributed to desktops and drive roots as README-payload.txt.
Detection engineering
Because no malicious binary or process exists, the detection logic should focus on the directory service and SYSVOL indicators. Below are the highest-value telemetry sources for identifying the described malicious activity.
Directory service change auditing (DS Access)
Enable Advanced Audit Policy → DS Access → Audit Directory Service Changes on all domain controllers and set up alerts for the following events:
Event ID
Meaning
Hunt focus
5137
A directory service object was created
The account that created new groupPolicyContainer objects must be an authorized GPO administrator
5136
A directory service object was modified
Changes to gPLink on the domain root or sensitive organizational units; changes to gPCMachineExtensionNames/gPCUserExtensionNames/gPCFileSysPath/versionNumber for all GPOs
5141
A directory service object was deleted
GPO deletions (relevant for tamper detection and remediation assessment)
A gPLink modification at the domain root by a non-standard account is one of the most telling indicators of this attack class.
SYSVOL file integrity monitoring
Monitor \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\ for unexpected files, particularly image files, text files, scripts, ScheduledTasks.xml, and modified registry.pol/GptTmpl.inf files that were created by sources other than legitimate replication.
Endpoint policy application telemetry
On endpoints, GPO application is logged in the Group Policy Operational log (Microsoft-Windows-GroupPolicy/Operational) and reflected in the History and Shadow registry keys shown above. A sudden domain-wide change to the applied policy set is a strong post-detonation signal.
Missing 5136 events
If the contents of a GPO’s SYSVOL change without a corresponding 5136 event, this can indicate direct SYSVOL/template editing (e.g., via open-source tools such as PowerView or SharpGPOAbuse) that bypasses the normal Group Policy Management Console (GPMC) modification path. While we recommend treating the absence of expected audit events as suspicious, it should be noted that this can be caused by misconfigured auditing.
Anti-forensics and recovery-inhibition capabilities
Confirmed PAYLOAD family capabilities
The Windows endpoint attack described in this report was implemented through malicious Group Policy Objects and did not involve a recovered ransomware executable, resident endpoint malware, confirmed file encryption or active malicious processes at the time of the forensic examination. However, PAYLOAD cryptomalware for Windows does exist, and other sources, including public analysis of its samples, reveal further malicious capabilities of this ransomware that could be used by security teams to enrich detection logic and security policies.
The behaviors documented in this section must therefore be interpreted as family-level capabilities identified through the public reverse engineering of PAYLOAD ransomware samples. They were not confirmed as having executed during the GPO-based incident unless corresponding evidence was identified in the host, memory, process, event-log, or hypervisor.
Windows Event Log clearing
Public reverse engineering of the PAYLOAD Windows variant reveals an optional event log clearing capability (T1685.005, formerly T1070.001). The ransomware dynamically resolves Windows Event Log APIs, enumerates available event log channels, and clears individual channels.
Implementation artifacts include:
Runtime loading of wevtapi.dll
EvtOpenChannelEnum
EvtNextChannelPath
EvtClearLog
Enumeration of Security, System, Application, and PowerShell logs, and operational channels
A command-line option controlling whether log clearing is performed
Clearing event logs reduces the availability of records related to process execution, authentication, PowerShell, service control, and system changes. However, it does not necessarily remove events that were already forwarded to a SIEM, Windows Event Collector, EDR backend, or protected log archive.
Forensic indicators
Windows Security Event ID 1102
Event logging shutdown or failure events
Sudden reductions in event record identifiers
Multiple event channels restarting from low record numbers
Gaps between endpoint and centrally forwarded telemetry
Execution of utilities or APIs associated with log management
Direct access to EVTX files (Windows Event Log files) under the Windows event log directory
We should note that these indicators can’t be interpreted on their own. For instance, Event ID 1102 should be correlated with a number of aggravating factors, such as:
Event ID 4688 or Sysmon Event ID 1 for process creation
Event ID 4624 for the associated administrative logon
EDR process trees
PowerShell operational logging
Windows Event Forwarding records
Privileged access management activity
At the same time, the absence of Event ID 1102 does not prove that log clearing did not occur. Direct deletion, truncation, service impairment, or an incomplete audit configuration may produce different evidence.
Security process and service termination
PAYLOAD analysis reveals that the Windows ransomware variant contains logic that targets security processes and services (T1685 and T1489). This capability is intended to stop security products, backup software, database services, and applications that may lock files targeted for encryption.
Process and service termination serves several objectives:
Reduce endpoint detection and response visibility.
Release file handles so data can be modified.
Interrupt backup and recovery services.
Prevent databases and enterprise applications from protecting active data.
Reduce interference with encryption operations.
Forensic indicators
Security agent services changing from running to stopped
Event ID 7036 service state changes
Event ID 7040 service start type changes
Event ID 4688 or Sysmon Event ID 1 for service control utilities
Sysmon Event ID 5 for terminated processes
EDR health degradation affecting many endpoints
Repeated termination attempts against security or backup processes
Execution of dedicated process killing utilities
VSS deletion, backup and recovery suppression
Public PAYLOAD sample analysis reports the deletion of Windows Volume Shadow Copies before encryption (T1490). This behavior removes local restore points and reduces the victim’s ability to recover files without external backups.
Recovery inhibition is broader than VSS deletion and may include multiple other malicious techniques, including the following:
Deleting shadow copies, backup catalogs, and hypervisor snapshots
Disabling recovery services
Modifying boot recovery settings
Compromising backup management platforms
Deleting or encrypting backup repositories
In the PAYLOAD Windows sample that is proven to perform encryption, VSS deletion is confirmed to have taken place before encryption. A broader compromise of the backup platform was not established in the investigated incident.
Forensic indicators
Execution of shadow copy management utilities
Backup catalog deletion attempts
Recovery configuration changes
Backup service termination
Mass snapshot deletions
Backup administrator logons outside normal maintenance windows
Backup retention or immutability changes
Backup jobs failing immediately before disruptive activity
Ecosystem-relevant ransomware techniques
Above, we discussed the techniques specific to PAYLOAD ransomware. In this section, we’ll review other common ransomware techniques, such as BYOVD abuse and ESXi policy weakening, that remain relevant risks in the ransomware ecosystem. However, these techniques should not be attributed to this incident without supporting driver load, process, memory, ESXi, vCenter, or backup platform telemetry. We describe these techniques below as they may prove useful in other ransomware-related forensic investigations.
The examples used in this section are therefore ecosystem-relevant: they are commonly observed in ransomware operations but not conclusively attributed to the analyzed PAYLOAD samples.
ETW suppression and in-memory patching
Event Tracing for Windows (ETW) is a kernel-supported tracing architecture used by Windows components, diagnostic utilities, security products, and endpoint monitoring systems.
Although we didn’t encounter this technique in our case, some ransomware families can patch ETW-related functions inside the ransomware process (T1685, formerly T1562.001). The reported routine changes the memory protection of code pages, overwrites the beginning of selected ETW functions so they return without producing events, restores the original protection, and refreshes the instruction cache.
Reported target functions include EtwEventWrite, EtwEventWriteFull, EtwEventWriteTransfer, and EtwRegister.
This modification applies to the process-local mapping of ntdll.dll. It does not disable ETW globally across Windows, but it can reduce the telemetry generated by the modified process.
Forensic indicators
Writable or recently modified executable pages within ntdll.dll
Memory protection changes affecting ETW function addresses
In-memory code differing from the corresponding clean DLL on disk
EDR memory tampering alerts
Unexpected calls to memory protection APIs followed by telemetry silence
Process execution visible in network or filesystem telemetry but absent from expected ETW-derived sources
Inconsistent telemetry between EDR, Sysmon, Windows Event Logs, and network monitoring
It should be noted that telemetry gaps are not conclusive evidence of ETW patching. Other factors include agent upgrades, network outages, endpoint shutdowns, SIEM ingestion failures, collector backpressure, and filtering or licensing changes.
Memory acquisition is the strongest validation source when process-local ETW patching is suspected.
Vulnerable signed driver abuse, BYOVD
Bring Your Own Vulnerable Driver (BYOVD) involves introducing or abusing a legitimately signed but vulnerable kernel driver (T1068 and T1685). The attacker exploits the driver’s exposed functionality to gain kernel-level capabilities, modify protected memory, terminate security processes, remove security callbacks, or bypass operating system security controls.
BYOVD is highly relevant to contemporary ransomware operations. However, the reviewed public PAYLOAD analyses do not provide sufficient evidence to conclude that BYOVD is an intrinsic PAYLOAD capability.
It should therefore be presented as an ecosystem-relevant technique rather than a confirmed PAYLOAD feature.
Forensic indicators
Unexpected .sys files written to user-writable or temporary directories
New kernel driver services
Sysmon Event ID 6
Driver hashes matching Microsoft or community vulnerable driver blocklists
Invalid, revoked, expired, or unusual driver signatures
Driver load followed by EDR termination
New privileged processes immediately following driver loading
Code Integrity or Defender alerts
Service creation events referencing driver files
ESXi security policy weakening
Ransomware operators are increasingly targeting ESXi and vCenter because compromising the virtualization layer provides access to many business-critical virtual machines.
Public research typically describes operators performing the following activities (T1685, T1490 and T1489):
Enabling SSH on ESXi hosts
Changing root passwords
Disabling execInstalledOnly
Modifying lockdown mode exceptions
Stopping virtual machines
Deleting snapshots and backups
Changing host firewall policies
Copying custom ransomware binaries to hypervisors
On the target organization’s Linux servers we saw an ESXi PAYLOAD variant, which makes this behavior operationally relevant. Nevertheless, the reviewed evidence does not indicate that PAYLOAD operators used any of these policy-weakening actions in the investigated incident.
Forensic indicators
Unexpected ESXi SSH enablement
Changes to execInstalledOnly
Secure Boot enforcement changes
Lockdown mode configuration changes
Root password changes
New or unusual administrator accounts
Bulk VM shutdown activity
Bulk snapshot deletion
New binaries in datastore or temporary paths
vCenter tasks originating from unexpected accounts or systems
Missing or disabled remote syslog forwarding
Remediation
To contain the described threat and limit possible damage, several remediation steps should be taken. Below, we recommend a four-phase remediation approach for containing this threat and restoring the affected environment.
Phase 1 — domain controller actions (to be performed first)
When dealing with PAYLOAD GPO, the first priority of the remediation plan should be to remove the source GPOs. Until this is done, endpoint cleanup is ineffective because the next policy refresh re-infects cleaned machines.
The immediate domain controller actions to be taken are:
Delete PAYLOAD GPO. Remove {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} via GPMC.
Delete or revert win Firewall Off GPO. Remove {22099AD2-E062-4F56-B574-5099BBA4E7A6}.
Clean SYSVOL. Delete jpg and hello.txt from \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
Rotate credentials. Reset the compromised account; audit all privileged accounts and group memberships for unauthorized changes; rotate krbtgt twice if domain admin compromise is confirmed.
Force refresh. Perform gpupdate /force across endpoints after deletion; re-enable local administrator and firewall via clean policy.
Phase 2 — Active Directory and GPO hardening
Adopt the AD tiered administration model and confine domain admins to Tier 0 with no interactive logon to workstations and member servers.
Separate GPO creation from GPO linking rights, and grant both only to a dedicated, audited administrator role.
Enable GPO change auditing (Event IDs 5136, 5137, 5141) and forward to a SIEM.
Monitor SYSVOL with file integrity tooling.
Phase 3 — credential and access hardening
Enforce phishing-resistant MFA on all VPN and remote access entry points.
Deploy Windows LAPS to generate unique, rotated local administrator passwords.
PAYLOAD demonstrates a maturing tactic of turning the victim’s own trusted infrastructure into a weapon. By weaponizing Group Policy, the actor achieved a domain-wide impact without a single malicious binary on any endpoint, evaded file- and process-based detection entirely, and caused organization-wide disruption within seconds of the first reboot.
The absence of encryption is the most strategically significant finding and is consistent with the 2026 trend toward encryptionless extortion. At Kaspersky GERT, we assess with moderate confidence that the missing encryption reflects one of two scenarios: (1) a deliberate decision to stay below the irreversible data destruction threshold while preserving the option of a follow-on encryption phase, or (2) an operation interrupted before full execution.
The absence of encrypted files must not be mistaken for the absence of a serious compromise — the most critical impact lies in the actor gaining domain admin-level control. This incident proves that a threat actor with domain admin access and a working knowledge of group policy internals can inflict domain-wide disruption equivalent to a ransomware attack without writing a single malicious file to any endpoint.
Detection strategies anchored solely in file- or process-based indicators are blind to this attack class. Effective controls include directory service change auditing, SYSVOL integrity monitoring, and privileged access governance, which allow for GPO protection.
Detection by Kaspersky solutions
Kaspersky security solutions effectively detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.
To protect organizations that use our Kaspersky SIEM system, we have prepared a package of correlation rules designed to help detect this type of malicious activity. The rules are now available for customers to download from the SIEM repository; the package name is: [OOTB] Group policy hijacked: PAYLOAD ransomware – ENG.
The “Group policy hijacked: PAYLOAD ransomware” package contains rules that detect suspicious file creation or modification in the SYSVOL shared folder on a domain controller, as well as changes to critical attributes and settings of domain group policies. Some rules may require adjustment if they trigger in response to legitimate activity, such as synchronization between domain controllers or the configuration of a new group policy.
To ensure the detection rules function correctly, verify that events from Windows systems are being received in full, including events with the following identifiers: Sysmon: 11, Security — 4663, 5136, 4657.
We also recommend applying the following rules available in the repository to detect all attack stages.
Detection of Windows Event Log clearing to cover up traces of an attack: R050_03_Windows Event Log was cleared
Detection of suspicious access to the LSASS process, which may indicate attempts to dump credentials: R262_Suspicious access to the LSASS process
Detection of the Volume Shadow Copy service being started, which is used to create shadow copies before deleting them: R231_20_Running the Volume Shadow Copy service
Detection of shadow copy deletion: R321_Shadow copy deletion
Detection of Windows Defender disablement: R076_01_Windows Defender Antivirus was disabled
Detection of attempts to disable or modify the system firewall: R240_03_Disabling system firewall via the registry
Detection of a service installation from a non-system folder, which may indicate malware persistence techniques: R281_01_Installation of a service from a non-system folder
For the rules in this list to function correctly, it is necessary to configure Security event auditing for event IDs 4663, 5136, 4657, 7036, and 1102.
In addition to the SIEM system, when audit settings are configured correctly, the process of creating, modifying, and deleting GPOs generates a large number of characteristic artifacts on the domain controller, enabling Kaspersky Endpoint Detection and Response Expert to promptly alert the user to anomalies in the infrastructure.
The creation of a new GPO is covered by the gpo_creation rule, which triggers in response to the corresponding event in the infrastructure. Changes to existing policies are detected by the following rules:
The setting_the_gpcfilesyspath_attribute rule detects the use of the gPCFileSysPath attribute of a Group Policy Object, which specifies the path to the GPO’s contents in SYSVOL.
In the next major version update of Kaspersky EDR Expert, a new event type, GPO, will be introduced, allowing users to track changes to Group Policy Objects.
For information security officers, GPO events will serve as an additional source of context when investigating activity in Active Directory and will help detect changes that could affect the configuration, access rights, and security of endpoints before a potentially malicious policy is deployed.
MITRE ATT&CK mapping
Tactic
Technique
Observed behavior
Initial Access
T1078 — Valid Accounts
Compromised domain credential used for VPN authentication
Initial Access
T1133 — External Remote Services
FortiGate SSL VPN used as entry point
Privilege Escalation
T1078.002 — Domain Accounts
Account held domain-level GPO create/link rights
Privilege Escalation/Defense Impairment
T1484.001 — Group Policy Modification
Malicious PAYLOAD GPO created and linked at domain root; re-applies on every refresh/reboot; uses trusted channel to evade EDR
Defense Impairment
T1686 — Disable or Modify System Firewall
win Firewall Off GPO disables Windows Firewall on all profiles
Impact
T1491.001 — Internal Defacement
Wallpaper and lock screen replaced with ransom image
Impact
T1531 — Account Access Removal
Local Administrator account disabled via GPO Security Settings
Collection
T1005 — Data from Local System
Data exfiltration was observed originating from the file servers
Command and Control
T1071 — Application Layer Protocol
No live C2 confirmed; delivery achieved entirely via GPO
Indicators of compromise
GPOs
PAYLOAD ransomware GPO: {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}
win Firewall Off GPO: {22099AD2-E062-4F56-B574-5099BBA4E7A6}
File names and MD5 hashes
payload.jpg: Ransom wallpaper and lock screen image (SYSVOL)
hello.txt: Ransom note source (SYSVOL)
README-payload.txt: Ransom note dropped to desktops and drive roots
killer.exe (0108656A3E1ADE6CA4F21B084F5E1208): process killer tool
kill.exe (BEA5E267F24D7DA59F6821BFFDBFF293): process killer tool
In April 2026, we at Kaspersky’s Global Emergency Response Team (GERT) responded to a security incident at a manufacturing organization in the Middle East. The threat actor obtained domain admin-equivalent control of the organization’s Active Directory environment and authored a malicious Group Policy Object (GPO) named PAYLOAD, linking it at the domain root. Through that single object, the actor delivered ransom notes, hijacked the desktop wallpaper and lock screen, enforced a logon banner, and disabled the local administrator account across every domain-joined Windows workstation — all without dropping a ransomware binary or encrypting any data. The only ransomware we found in this incident was PAYLOAD sample targeting ESXi on Linux servers. Besides that, data exfiltration was observed originating from the file servers and several additional systems, and was later published on the dark web.
Living-off-the-land abuse of trusted AD infrastructure. Group Policy is a signed, allowlisted, SYSTEM-privileged distribution channel that the majority of endpoint detection and response tools is designed not to inspect. By delivering impact through GPO rather than through malware, the actor sidestepped the entire file- and process-based detection stack.
Encryptionless extortion. Industry telemetry shows extortion-only incidents grow significantly year-on-year. PAYLOAD fits this model; the leverage is operational disruption and the threat of escalation rather than cryptographic denial of data.
We confirmed that no files were encrypted on Windows machines, no malicious binaries were resident on disk, no endpoint persistence was established, and no malicious processes were running at the time of analysis. The entire attack lived inside Active Directory itself. The defensive implication is stark: an organization whose detection strategy depends on catching a ransomware executable would have seen nothing until the first endpoint rebooted and the ransom wallpaper appeared.
In this article, we will describe the GPO attack chain and provide operational advice on how to detect such threats, including detailed remediation recommendations.
Group Policy as an attack surface
Attacks through group policies are nothing new. They can inflict significant, domain-wide damage with multiple malicious capabilities. A Group Policy Object (GPO) is essentially a combination of a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in SYSVOL. The Group Policy scope depends on whether the GPC is linked to the directory tree at the domain, site, or organization unit (OU) level. A link at the domain root means the policy applies to every computer and user object beneath it. Thus, a GPO compromised at the domain root can affect all in-scope domain users and computers, potentially granting an attacker complete control over the corporate network. What makes GPO abuse even more dangerous is that group policies are processed in a trusted, high-privilege environment, ensuring persistence because endpoint cleanup is not enough to remove them.
We have already discussed GPO architecture and ways it can be compromised in greater detail in an earlier blog post. Other public threat intelligence has also repeatedly documented this technique in ransomware operations. Microsoft observed Ryuk operators distributing ransomware through Group Policy, SYSVOL startup items, and PsExec. LockBit affiliates have been documented modifying SYSVOL Group Policy files, including ScheduledTasks.xml, to support ransomware execution and propagation. BlackCat/ALPHV operators have also abused GPOs to create scheduled tasks and deploy ransomware.
Another notable example of GPO abuse is PAYLOAD ransomware, which weaponizes GPO Preferences and policy settings for pure impact rather than as a launcher for an encryptor. Let’s take a closer look at this attack, which is detailed further below.
Attack timeline
During the April 2026 investigation, we managed to reconstruct the attack timeline as outlined below:
Date
Event
11 April
Initial access. Threat actor authenticates to the FortiGate SSL VPN using a valid but compromised domain credential.
13 April
GPO authored. Malicious GPO, PAYLOAD ({C897F2C7-C2AC-4E6F-BF48-58036FF29E79}) created and linked at the domain root, configuring ransom notes, wallpaper, lock screen, logon banner, and administrator account disablement.
13 April
SYSVOL staging. The payload.jpg and hello.txt files written to \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
13 April
Second GPO. GPO named win Firewall Off ({22099AD2-E062-4F56-B574-5099BBA4E7A6}) linked at the domain root, disabling Windows Firewall on all profiles.
13 April
Dormancy. GPO cached on endpoints but computer configuration not yet applied — no endpoint had rebooted since the policy update.
13 April
Data exfiltration. Data exfiltration was observed originating from the file servers and several additional systems.
14 April
Detonation. Most of the endpoints begin rebooting; computer configuration policies apply. Ransom wallpaper, logon banner, and notes appear. Operational disruption begins.
15 April
Response. Kaspersky GERT engaged. Forensic triage of affected workstations and the domain controller initiated.
16 April
Assessment. GERT confirms no file encryption, no resident malware, no endpoint persistence.
Next, we will discuss each of these stages in more detail and share the findings from our incident response activities.
Incident overview
Initial access
The entry vector was a compromised valid account (MITRE ATT&CK T1078) used to authenticate through the organization’s FortiGate SSL VPN — an external remote service (T1133). Insufficient logging on the FortiGate appliance prevented us from reconstructing how the credential was originally compromised.
Three hypotheses were considered plausible in the context of the attack, in no particular order:
Password spraying or credential stuffing against the SSL VPN portal.
Phishing-led credential harvesting.
Purchase of pre-compromised credentials from an initial access broker (IAB).
Once on the internal network, the actor operated with the compromised security principal’s privileges. Because the account was able to create and link a GPO at the domain root, it held either domain admin privileges or a delegated equivalent (e.g., membership of Group Policy Creator Owners combined with link rights on the domain object).
FortiGate SSL VPN authentication logs and ESXi/virtualization privilege escalation logs were insufficient to reconstruct the lateral movement and privilege escalation chain between initial VPN access and the GPO write privilege level. The most common real-world routes to GPO control — DCSync, Kerberoasting of privileged service accounts, and Pass-the-Hash/Pass-the-Ticket — could not be confirmed or ruled out.
Execution
Rather than deploying an encryptor, the actor abused the victim’s Active Directory policy infrastructure, resulting in malicious GPOs being configured and linked at the domain root to deliver the observed impact across domain-joined systems. The two GPOs below constitute the entire offensive toolkit observed.
The PAYLOAD GPO
We performed a Resultant Set of Policy (RSOP) analysis, which helped us list all policy settings on the affected workstations. From these results, we reconstructed the following changes delivered by PAYLOAD:
Drop SYSVOL\hello.txt to the desktop and root directories C:\ and D:\ as a read-only README-payload.txt by tampering with the “Group Policy Files” client-side extension (CSE).
Modify the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ registry key, changing the legalnoticecaption value to "Welcome to Payload!" and the legalnoticetext to the ransom note text through the “Group Policy Registry” CSE.
Set payload.jpg located in the targeted domain controller’s SYSVOL as the lock screen image by altering the personalization policy, and as the wallpaper by altering the desktop policy at the user level.
Revoke administrator rights for the administrator account (locking the account) by editing the Security Settings CSE in the GptTmpl.inf file.
Settings changed by PAYLOAD GPO
This activity was enabled entirely through a legitimate group policy mechanism, meaning there is no malware code for security solutions to look for because the malicious logic is contained within the policy configuration.
The win Firewall Off GPO
A second domain-root-linked GPO, named “win Firewall Off”, disabled Windows Firewall across the domain, private and public profiles on all endpoints (T1562.004). Deployed independently of PAYLOAD, this object degraded host defenses and ensured the actor retained unimpeded network reach to endpoints for any follow-on activity.
Settings changed by win Firewall Off GPO
The one-day delay detonation
The most forensically instructive detail is the one-day gap between GPO creation (13 April) and visible impact (14 April). Analysis of Master File Table (MFT) timestamps and the Group Policy History registry key confirmed the policy was written to SYSVOL and cached on endpoints on 13 April. However, computer configuration settings (wallpaper and lock screen machine policy, security settings, firewall disabling) only apply upon reboot or policy refresh — and no endpoint had rebooted in the interim. The attack therefore remained dormant in the GPO cache for one day before detonating en masse when machines were restarted in accordance with standard procedures.
We have to point out here that this delayed policy application is characteristic of GPO-based operations and has two potential consequences for defenders. Firstly, it may grant the actor a quiet window for exfiltration, persistence, or further staging between weaponization and impact. Secondly, it can be used to sever the temporal link between the cause (a GPO-creation event in the directory log) and the effect (mass user-visible disruption occurring at a later time), complicating timeline reconstruction unless directory service auditing is in place.
Forensic findings
Initial incident response engagement revealed a number of findings associated with the attack that we share below.
No file encryption
A full review of the MFT on affected workstations found no files bearing a .payload extension characteristic to PAYLOAD ransomware and no evidence of bulk renaming or encryption I/O patterns. The attackers’ objectives were operational disruption and extortion via visual impact and access denial.
No endpoint persistence
All standard persistence locations were clean:
Scheduled tasks — no malicious tasks
Run/RunOnce keys — clean
Startup folders (user and system) — clean
Services — no malicious service installed
WMI event subscriptions — none
Boot sector/MBR — unmodified
The attack’s persistence mechanism is the GPO link itself on the domain controller, with no endpoint-resident component.
No active malicious processes
Live process and memory analysis revealed no injected threads, process hollowing or anomalous outbound connections.
Registry timeline analysis
Group Policy History, Shadow and State registry keys on the workstation recorded the application of PAYLOAD on 13 April:
HKLM\…\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1
HKLM\…\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0
HKLM\…\Group Policy\State\Machine\GPO-List\7
HKCU\…\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1
HKCU\…\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5
The presence of the “Loopback-GPO-List” entry indicates the GPO was processed in loopback mode, ensuring the user configuration (wallpaper) applied regardless of which user logged on to the machine.
SYSVOL artifacts
Two files were staged on the domain controller’s SYSVOL share and served to endpoints through the Files Group Policy Preference CSE:
payload.jpg — the ransom image used for both wallpaper and lock screen.
hello.txt — the ransom note, distributed to desktops and drive roots as README-payload.txt.
Detection engineering
Because no malicious binary or process exists, the detection logic should focus on the directory service and SYSVOL indicators. Below are the highest-value telemetry sources for identifying the described malicious activity.
Directory service change auditing (DS Access)
Enable Advanced Audit Policy → DS Access → Audit Directory Service Changes on all domain controllers and set up alerts for the following events:
Event ID
Meaning
Hunt focus
5137
A directory service object was created
The account that created new groupPolicyContainer objects must be an authorized GPO administrator
5136
A directory service object was modified
Changes to gPLink on the domain root or sensitive organizational units; changes to gPCMachineExtensionNames/gPCUserExtensionNames/gPCFileSysPath/versionNumber for all GPOs
5141
A directory service object was deleted
GPO deletions (relevant for tamper detection and remediation assessment)
A gPLink modification at the domain root by a non-standard account is one of the most telling indicators of this attack class.
SYSVOL file integrity monitoring
Monitor \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\ for unexpected files, particularly image files, text files, scripts, ScheduledTasks.xml, and modified registry.pol/GptTmpl.inf files that were created by sources other than legitimate replication.
Endpoint policy application telemetry
On endpoints, GPO application is logged in the Group Policy Operational log (Microsoft-Windows-GroupPolicy/Operational) and reflected in the History and Shadow registry keys shown above. A sudden domain-wide change to the applied policy set is a strong post-detonation signal.
Missing 5136 events
If the contents of a GPO’s SYSVOL change without a corresponding 5136 event, this can indicate direct SYSVOL/template editing (e.g., via open-source tools such as PowerView or SharpGPOAbuse) that bypasses the normal Group Policy Management Console (GPMC) modification path. While we recommend treating the absence of expected audit events as suspicious, it should be noted that this can be caused by misconfigured auditing.
Anti-forensics and recovery-inhibition capabilities
Confirmed PAYLOAD family capabilities
The Windows endpoint attack described in this report was implemented through malicious Group Policy Objects and did not involve a recovered ransomware executable, resident endpoint malware, confirmed file encryption or active malicious processes at the time of the forensic examination. However, PAYLOAD cryptomalware for Windows does exist, and other sources, including public analysis of its samples, reveal further malicious capabilities of this ransomware that could be used by security teams to enrich detection logic and security policies.
The behaviors documented in this section must therefore be interpreted as family-level capabilities identified through the public reverse engineering of PAYLOAD ransomware samples. They were not confirmed as having executed during the GPO-based incident unless corresponding evidence was identified in the host, memory, process, event-log, or hypervisor.
Windows Event Log clearing
Public reverse engineering of the PAYLOAD Windows variant reveals an optional event log clearing capability (T1685.005, formerly T1070.001). The ransomware dynamically resolves Windows Event Log APIs, enumerates available event log channels, and clears individual channels.
Implementation artifacts include:
Runtime loading of wevtapi.dll
EvtOpenChannelEnum
EvtNextChannelPath
EvtClearLog
Enumeration of Security, System, Application, and PowerShell logs, and operational channels
A command-line option controlling whether log clearing is performed
Clearing event logs reduces the availability of records related to process execution, authentication, PowerShell, service control, and system changes. However, it does not necessarily remove events that were already forwarded to a SIEM, Windows Event Collector, EDR backend, or protected log archive.
Forensic indicators
Windows Security Event ID 1102
Event logging shutdown or failure events
Sudden reductions in event record identifiers
Multiple event channels restarting from low record numbers
Gaps between endpoint and centrally forwarded telemetry
Execution of utilities or APIs associated with log management
Direct access to EVTX files (Windows Event Log files) under the Windows event log directory
We should note that these indicators can’t be interpreted on their own. For instance, Event ID 1102 should be correlated with a number of aggravating factors, such as:
Event ID 4688 or Sysmon Event ID 1 for process creation
Event ID 4624 for the associated administrative logon
EDR process trees
PowerShell operational logging
Windows Event Forwarding records
Privileged access management activity
At the same time, the absence of Event ID 1102 does not prove that log clearing did not occur. Direct deletion, truncation, service impairment, or an incomplete audit configuration may produce different evidence.
Security process and service termination
PAYLOAD analysis reveals that the Windows ransomware variant contains logic that targets security processes and services (T1685 and T1489). This capability is intended to stop security products, backup software, database services, and applications that may lock files targeted for encryption.
Process and service termination serves several objectives:
Reduce endpoint detection and response visibility.
Release file handles so data can be modified.
Interrupt backup and recovery services.
Prevent databases and enterprise applications from protecting active data.
Reduce interference with encryption operations.
Forensic indicators
Security agent services changing from running to stopped
Event ID 7036 service state changes
Event ID 7040 service start type changes
Event ID 4688 or Sysmon Event ID 1 for service control utilities
Sysmon Event ID 5 for terminated processes
EDR health degradation affecting many endpoints
Repeated termination attempts against security or backup processes
Execution of dedicated process killing utilities
VSS deletion, backup and recovery suppression
Public PAYLOAD sample analysis reports the deletion of Windows Volume Shadow Copies before encryption (T1490). This behavior removes local restore points and reduces the victim’s ability to recover files without external backups.
Recovery inhibition is broader than VSS deletion and may include multiple other malicious techniques, including the following:
Deleting shadow copies, backup catalogs, and hypervisor snapshots
Disabling recovery services
Modifying boot recovery settings
Compromising backup management platforms
Deleting or encrypting backup repositories
In the PAYLOAD Windows sample that is proven to perform encryption, VSS deletion is confirmed to have taken place before encryption. A broader compromise of the backup platform was not established in the investigated incident.
Forensic indicators
Execution of shadow copy management utilities
Backup catalog deletion attempts
Recovery configuration changes
Backup service termination
Mass snapshot deletions
Backup administrator logons outside normal maintenance windows
Backup retention or immutability changes
Backup jobs failing immediately before disruptive activity
Ecosystem-relevant ransomware techniques
Above, we discussed the techniques specific to PAYLOAD ransomware. In this section, we’ll review other common ransomware techniques, such as BYOVD abuse and ESXi policy weakening, that remain relevant risks in the ransomware ecosystem. However, these techniques should not be attributed to this incident without supporting driver load, process, memory, ESXi, vCenter, or backup platform telemetry. We describe these techniques below as they may prove useful in other ransomware-related forensic investigations.
The examples used in this section are therefore ecosystem-relevant: they are commonly observed in ransomware operations but not conclusively attributed to the analyzed PAYLOAD samples.
ETW suppression and in-memory patching
Event Tracing for Windows (ETW) is a kernel-supported tracing architecture used by Windows components, diagnostic utilities, security products, and endpoint monitoring systems.
Although we didn’t encounter this technique in our case, some ransomware families can patch ETW-related functions inside the ransomware process (T1685, formerly T1562.001). The reported routine changes the memory protection of code pages, overwrites the beginning of selected ETW functions so they return without producing events, restores the original protection, and refreshes the instruction cache.
Reported target functions include EtwEventWrite, EtwEventWriteFull, EtwEventWriteTransfer, and EtwRegister.
This modification applies to the process-local mapping of ntdll.dll. It does not disable ETW globally across Windows, but it can reduce the telemetry generated by the modified process.
Forensic indicators
Writable or recently modified executable pages within ntdll.dll
Memory protection changes affecting ETW function addresses
In-memory code differing from the corresponding clean DLL on disk
EDR memory tampering alerts
Unexpected calls to memory protection APIs followed by telemetry silence
Process execution visible in network or filesystem telemetry but absent from expected ETW-derived sources
Inconsistent telemetry between EDR, Sysmon, Windows Event Logs, and network monitoring
It should be noted that telemetry gaps are not conclusive evidence of ETW patching. Other factors include agent upgrades, network outages, endpoint shutdowns, SIEM ingestion failures, collector backpressure, and filtering or licensing changes.
Memory acquisition is the strongest validation source when process-local ETW patching is suspected.
Vulnerable signed driver abuse, BYOVD
Bring Your Own Vulnerable Driver (BYOVD) involves introducing or abusing a legitimately signed but vulnerable kernel driver (T1068 and T1685). The attacker exploits the driver’s exposed functionality to gain kernel-level capabilities, modify protected memory, terminate security processes, remove security callbacks, or bypass operating system security controls.
BYOVD is highly relevant to contemporary ransomware operations. However, the reviewed public PAYLOAD analyses do not provide sufficient evidence to conclude that BYOVD is an intrinsic PAYLOAD capability.
It should therefore be presented as an ecosystem-relevant technique rather than a confirmed PAYLOAD feature.
Forensic indicators
Unexpected .sys files written to user-writable or temporary directories
New kernel driver services
Sysmon Event ID 6
Driver hashes matching Microsoft or community vulnerable driver blocklists
Invalid, revoked, expired, or unusual driver signatures
Driver load followed by EDR termination
New privileged processes immediately following driver loading
Code Integrity or Defender alerts
Service creation events referencing driver files
ESXi security policy weakening
Ransomware operators are increasingly targeting ESXi and vCenter because compromising the virtualization layer provides access to many business-critical virtual machines.
Public research typically describes operators performing the following activities (T1685, T1490 and T1489):
Enabling SSH on ESXi hosts
Changing root passwords
Disabling execInstalledOnly
Modifying lockdown mode exceptions
Stopping virtual machines
Deleting snapshots and backups
Changing host firewall policies
Copying custom ransomware binaries to hypervisors
On the target organization’s Linux servers we saw an ESXi PAYLOAD variant, which makes this behavior operationally relevant. Nevertheless, the reviewed evidence does not indicate that PAYLOAD operators used any of these policy-weakening actions in the investigated incident.
Forensic indicators
Unexpected ESXi SSH enablement
Changes to execInstalledOnly
Secure Boot enforcement changes
Lockdown mode configuration changes
Root password changes
New or unusual administrator accounts
Bulk VM shutdown activity
Bulk snapshot deletion
New binaries in datastore or temporary paths
vCenter tasks originating from unexpected accounts or systems
Missing or disabled remote syslog forwarding
Remediation
To contain the described threat and limit possible damage, several remediation steps should be taken. Below, we recommend a four-phase remediation approach for containing this threat and restoring the affected environment.
Phase 1 — domain controller actions (to be performed first)
When dealing with PAYLOAD GPO, the first priority of the remediation plan should be to remove the source GPOs. Until this is done, endpoint cleanup is ineffective because the next policy refresh re-infects cleaned machines.
The immediate domain controller actions to be taken are:
Delete PAYLOAD GPO. Remove {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} via GPMC.
Delete or revert win Firewall Off GPO. Remove {22099AD2-E062-4F56-B574-5099BBA4E7A6}.
Clean SYSVOL. Delete jpg and hello.txt from \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
Rotate credentials. Reset the compromised account; audit all privileged accounts and group memberships for unauthorized changes; rotate krbtgt twice if domain admin compromise is confirmed.
Force refresh. Perform gpupdate /force across endpoints after deletion; re-enable local administrator and firewall via clean policy.
Phase 2 — Active Directory and GPO hardening
Adopt the AD tiered administration model and confine domain admins to Tier 0 with no interactive logon to workstations and member servers.
Separate GPO creation from GPO linking rights, and grant both only to a dedicated, audited administrator role.
Enable GPO change auditing (Event IDs 5136, 5137, 5141) and forward to a SIEM.
Monitor SYSVOL with file integrity tooling.
Phase 3 — credential and access hardening
Enforce phishing-resistant MFA on all VPN and remote access entry points.
Deploy Windows LAPS to generate unique, rotated local administrator passwords.
PAYLOAD demonstrates a maturing tactic of turning the victim’s own trusted infrastructure into a weapon. By weaponizing Group Policy, the actor achieved a domain-wide impact without a single malicious binary on any endpoint, evaded file- and process-based detection entirely, and caused organization-wide disruption within seconds of the first reboot.
The absence of encryption is the most strategically significant finding and is consistent with the 2026 trend toward encryptionless extortion. At Kaspersky GERT, we assess with moderate confidence that the missing encryption reflects one of two scenarios: (1) a deliberate decision to stay below the irreversible data destruction threshold while preserving the option of a follow-on encryption phase, or (2) an operation interrupted before full execution.
The absence of encrypted files must not be mistaken for the absence of a serious compromise — the most critical impact lies in the actor gaining domain admin-level control. This incident proves that a threat actor with domain admin access and a working knowledge of group policy internals can inflict domain-wide disruption equivalent to a ransomware attack without writing a single malicious file to any endpoint.
Detection strategies anchored solely in file- or process-based indicators are blind to this attack class. Effective controls include directory service change auditing, SYSVOL integrity monitoring, and privileged access governance, which allow for GPO protection.
Detection by Kaspersky solutions
Kaspersky security solutions effectively detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.
To protect organizations that use our Kaspersky SIEM system, we have prepared a package of correlation rules designed to help detect this type of malicious activity. The rules are now available for customers to download from the SIEM repository; the package name is: [OOTB] Group policy hijacked: PAYLOAD ransomware – ENG.
The “Group policy hijacked: PAYLOAD ransomware” package contains rules that detect suspicious file creation or modification in the SYSVOL shared folder on a domain controller, as well as changes to critical attributes and settings of domain group policies. Some rules may require adjustment if they trigger in response to legitimate activity, such as synchronization between domain controllers or the configuration of a new group policy.
To ensure the detection rules function correctly, verify that events from Windows systems are being received in full, including events with the following identifiers: Sysmon: 11, Security — 4663, 5136, 4657.
We also recommend applying the following rules available in the repository to detect all attack stages.
Detection of Windows Event Log clearing to cover up traces of an attack: R050_03_Windows Event Log was cleared
Detection of suspicious access to the LSASS process, which may indicate attempts to dump credentials: R262_Suspicious access to the LSASS process
Detection of the Volume Shadow Copy service being started, which is used to create shadow copies before deleting them: R231_20_Running the Volume Shadow Copy service
Detection of shadow copy deletion: R321_Shadow copy deletion
Detection of Windows Defender disablement: R076_01_Windows Defender Antivirus was disabled
Detection of attempts to disable or modify the system firewall: R240_03_Disabling system firewall via the registry
Detection of a service installation from a non-system folder, which may indicate malware persistence techniques: R281_01_Installation of a service from a non-system folder
For the rules in this list to function correctly, it is necessary to configure Security event auditing for event IDs 4663, 5136, 4657, 7036, and 1102.
In addition to the SIEM system, when audit settings are configured correctly, the process of creating, modifying, and deleting GPOs generates a large number of characteristic artifacts on the domain controller, enabling Kaspersky Endpoint Detection and Response Expert to promptly alert the user to anomalies in the infrastructure.
The creation of a new GPO is covered by the gpo_creation rule, which triggers in response to the corresponding event in the infrastructure. Changes to existing policies are detected by the following rules:
The setting_the_gpcfilesyspath_attribute rule detects the use of the gPCFileSysPath attribute of a Group Policy Object, which specifies the path to the GPO’s contents in SYSVOL.
In the next major version update of Kaspersky EDR Expert, a new event type, GPO, will be introduced, allowing users to track changes to Group Policy Objects.
For information security officers, GPO events will serve as an additional source of context when investigating activity in Active Directory and will help detect changes that could affect the configuration, access rights, and security of endpoints before a potentially malicious policy is deployed.
MITRE ATT&CK mapping
Tactic
Technique
Observed behavior
Initial Access
T1078 — Valid Accounts
Compromised domain credential used for VPN authentication
Initial Access
T1133 — External Remote Services
FortiGate SSL VPN used as entry point
Privilege Escalation
T1078.002 — Domain Accounts
Account held domain-level GPO create/link rights
Privilege Escalation/Defense Impairment
T1484.001 — Group Policy Modification
Malicious PAYLOAD GPO created and linked at domain root; re-applies on every refresh/reboot; uses trusted channel to evade EDR
Defense Impairment
T1686 — Disable or Modify System Firewall
win Firewall Off GPO disables Windows Firewall on all profiles
Impact
T1491.001 — Internal Defacement
Wallpaper and lock screen replaced with ransom image
Impact
T1531 — Account Access Removal
Local Administrator account disabled via GPO Security Settings
Collection
T1005 — Data from Local System
Data exfiltration was observed originating from the file servers
Command and Control
T1071 — Application Layer Protocol
No live C2 confirmed; delivery achieved entirely via GPO
Indicators of compromise
GPOs
PAYLOAD ransomware GPO: {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}
win Firewall Off GPO: {22099AD2-E062-4F56-B574-5099BBA4E7A6}
File names and MD5 hashes
payload.jpg: Ransom wallpaper and lock screen image (SYSVOL)
hello.txt: Ransom note source (SYSVOL)
README-payload.txt: Ransom note dropped to desktops and drive roots
killer.exe (0108656A3E1ADE6CA4F21B084F5E1208): process killer tool
kill.exe (BEA5E267F24D7DA59F6821BFFDBFF293): process killer tool
Kaspersky Security Services provide a comprehensive cybersecurity ecosystem, taking enterprise threat protection to another level. Services like Kaspersky Managed Detection and Response and Compromise Assessment allow for timely detection of threats and cyberattacks. SOC Consulting provides a practical approach ensuring the corporate infrastructure stays secured, while Incident Response is suited for timely remediation with a maximized recovery rate.
High-level overview of the MDR, IR and CA connection
This new report brings together statistics across regions and industries from our Managed Detection and Response and Incident Response services, and for the first time, it also includes insights from our Compromise Assessment and SOC Consulting services — all to provide you with more comprehensive view of different aspects of corporate information security worldwide.
The scope of MDR and IR services
Provision of Kaspersky’s MDR and IR services follows a global approach. The majority of customers accounted for the CIS (34.7%), the Middle East (20.1%), and Europe (18.6%).
Distribution of customers by geographical region, 2025
MDR telemetry
Following the previous year’s numbers, in 2025, the MDR infrastructure received and processed an average of 15,000 telemetry events per host every day, generating security alerts as a result. These alerts are first processed by AI-powered detection logic, after which Kaspersky SOC analysts handle them as required. Overall, a total of approximately 400,000 alerts were generated in 2025. After counting out false positives, 39,000 alerts were further investigated.
MDR telemetry statistics, 2025
Incident statistics
The distribution of remediation requests by industry has slightly changed as compared to previous years’ pattern. Government (18.5%) and industrial (16.6%) organizations are still the most targeted industries in regards to cyberattacks that require incident response activities. However, this year, the IT sector saw a growth in the number of IR requests, eventually being placed third in the overall industry distribution rankings and thus replacing financial organizations, which were targeted less often than in 2024. This is equally true for smaller-scale attacks that can be contained and remediated through automated means — the only difference is that medium- and low-severity incidents are more often experienced by financial organizations.
Distribution of all incidents by industry sector, 2025
Key trends and statistics
This section presents key findings and trends in cyberattacks in 2025:
The number of high-severity incidents decreased, following a downward trend that we’ve been observing since 2021. The majority of those incidents account for APT attacks and red teaming exercises, which indicates two landscape trends. On the one hand, skilled adversaries make efforts to increase impact, while on the other, organizations spend more resources on probing their defense systems.
The most common vulnerabilities exploited in the wild were related to Microsoft products. Half of all identified CVEs led to remote code execution, notably without authentication in some cases.
Exploitation of public-facing applications, valid accounts, and trusted relationships remain the most popular initial vectors, and their overall share has increased, accounting to over 80% of all attacks in 2025. In particular, attacks through trusted relationships are evolving: their share has increased to 15.5% from 12.8% in 2024. They are also becoming more complex: for instance, we witnessed a case where adversaries had compromised more than two organizations in sequence to ultimately gain access to a third target.
Standard Windows utilities remain a popular LotL tool. Adversaries use those to minimize the risk of detection during delivery to a compromised system. The most popular LOLBins we observed in high-severity incidents were powershell.exe (14.4%), rundll32.exe (5.9%), and mshta.exe (3.8%). Among the most popular legitimate tools used in incidents we flag Mimikatz (14.3%), PowerShell (8.1%), PsExec (7.5%), and AnyDesk (7.5%).
The full 2026 Global Report provides additional information about cyberattacks, including real-world cases discovered by Kaspersky experts. We also describe SOC Consulting projects and Compromise Assessment requests. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during Incident Response engagements.
Kaspersky Security Services provide a comprehensive cybersecurity ecosystem, taking enterprise threat protection to another level. Services like Kaspersky Managed Detection and Response and Compromise Assessment allow for timely detection of threats and cyberattacks. SOC Consulting provides a practical approach ensuring the corporate infrastructure stays secured, while Incident Response is suited for timely remediation with a maximized recovery rate.
High-level overview of the MDR, IR and CA connection
This new report brings together statistics across regions and industries from our Managed Detection and Response and Incident Response services, and for the first time, it also includes insights from our Compromise Assessment and SOC Consulting services — all to provide you with more comprehensive view of different aspects of corporate information security worldwide.
The scope of MDR and IR services
Provision of Kaspersky’s MDR and IR services follows a global approach. The majority of customers accounted for the CIS (34.7%), the Middle East (20.1%), and Europe (18.6%).
Distribution of customers by geographical region, 2025
MDR telemetry
Following the previous year’s numbers, in 2025, the MDR infrastructure received and processed an average of 15,000 telemetry events per host every day, generating security alerts as a result. These alerts are first processed by AI-powered detection logic, after which Kaspersky SOC analysts handle them as required. Overall, a total of approximately 400,000 alerts were generated in 2025. After counting out false positives, 39,000 alerts were further investigated.
MDR telemetry statistics, 2025
Incident statistics
The distribution of remediation requests by industry has slightly changed as compared to previous years’ pattern. Government (18.5%) and industrial (16.6%) organizations are still the most targeted industries in regards to cyberattacks that require incident response activities. However, this year, the IT sector saw a growth in the number of IR requests, eventually being placed third in the overall industry distribution rankings and thus replacing financial organizations, which were targeted less often than in 2024. This is equally true for smaller-scale attacks that can be contained and remediated through automated means — the only difference is that medium- and low-severity incidents are more often experienced by financial organizations.
Distribution of all incidents by industry sector, 2025
Key trends and statistics
This section presents key findings and trends in cyberattacks in 2025:
The number of high-severity incidents decreased, following a downward trend that we’ve been observing since 2021. The majority of those incidents account for APT attacks and red teaming exercises, which indicates two landscape trends. On the one hand, skilled adversaries make efforts to increase impact, while on the other, organizations spend more resources on probing their defense systems.
The most common vulnerabilities exploited in the wild were related to Microsoft products. Half of all identified CVEs led to remote code execution, notably without authentication in some cases.
Exploitation of public-facing applications, valid accounts, and trusted relationships remain the most popular initial vectors, and their overall share has increased, accounting to over 80% of all attacks in 2025. In particular, attacks through trusted relationships are evolving: their share has increased to 15.5% from 12.8% in 2024. They are also becoming more complex: for instance, we witnessed a case where adversaries had compromised more than two organizations in sequence to ultimately gain access to a third target.
Standard Windows utilities remain a popular LotL tool. Adversaries use those to minimize the risk of detection during delivery to a compromised system. The most popular LOLBins we observed in high-severity incidents were powershell.exe (14.4%), rundll32.exe (5.9%), and mshta.exe (3.8%). Among the most popular legitimate tools used in incidents we flag Mimikatz (14.3%), PowerShell (8.1%), PsExec (7.5%), and AnyDesk (7.5%).
The full 2026 Global Report provides additional information about cyberattacks, including real-world cases discovered by Kaspersky experts. We also describe SOC Consulting projects and Compromise Assessment requests. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during Incident Response engagements.
The cybersecurity community is still grappling with a sobering realization: one of the most ubiquitous tools in the developer’s toolkit, Notepad++, was hiding a critical vulnerability for over six months. Being so deeply embedded in daily workflows, many organizations did not realize they were vulnerable until a recent security update pulled back the curtain on a sophisticated Chinese state-sponsored campaign, dubbed “Lotus Blossom.”
Investigations have confirmed that the issue wasn’t just a coding error, it was a compromise at the hosting provider level. This means that for much of 2025, even organizations that followed best practices were still potentially open to backdoors from Chinese advanced persistent threat (APT) groups. Here is what you need to know to secure your environment.
Understanding the Notepad++ Vulnerability (CVE-2025-15556)
The vulnerability, tracked as CVE-2025-15556 (VulnDB ID: 430205), exploits a critical flaw in the Notepad++ updater component, WinGUP. In versions prior to the February 2026 patch, the updater failed to verify the file integrity signatures of downloaded installers.
By exploiting this lack of verification, threat actors are able to:
Intercept legitimate update requests originating from WinGUp servers
Redirect traffic to malicious servers via Man-in-the-Middle (MitM) attacks or DNS cache poisoning
Deliver trojanized executables (disguised as update.exe) that appeared to be legitimate software patches
Leveraging this vulnerability, attackers have gained a persistent presence in high-value sectors. According to reports from Kaspersky, the impact has spanned government and telecommunications, critical infrastructure, and financial services.
How CVE-2025-15556 Works
The state-sponsored Lotus Blossom campaign was executed in three attack chains, between July and October 2025. Each phase evolved to evade detection by changing file sizes, IP addresses, and delivery methods.
Phase
Timeline (2025)
Execution Method
Payload
Chain #1
July – August
1MB NSIS installer (update.exe)
Multi-stage attack launching a Cobalt Strike beacon via ProShow.exe.
Chain #2
September
140KB NSIS installer (update.exe)
Rotated C2 URLs to maintain stealth while dropping a Cobalt Strike beacon.
Chain #3
October
Backdoor Deployment
Dropped BluetoothService.exe, log.DLL, and shellcode to establish the Chrysalis backdoor.
Mapping CVE-2025-15556 to MITRE ATT&CK
Flashpoint has mapped Lotus Blossom TTPs (tactics, tools, and procedures) to the MITRE ATT&CK framework. Flashpoint analysts have identified the following techniques:
M1057: Data Loss Prevention M1031: Network Intrusion Prevention
Protecting Against CVE-2025-15556
Proactive defense requires not only reactive patching of CVE-2025-15556, but also active threat hunting using the TTPs identified by Flashpoint analysts. Flashpoint recommends the following actions:
Immediate Update: Ensure all instances of Notepad ++ are updated to v8.9.1 or higher immediately. This version enforces the signature verification that was missing in previous releases.
Audit System Paths: Scan for malicious file paths used for persistence.
Network Defense: Monitor and block traffic to malicious domains.
Endpoint Hardening: Implement Behavior Prevention on Endpoints (M1040) and Audit (M1047) to detect unauthorized registry run keys or new system services.
Outpace Threat Actors Using Flashpoint
Software trust is only as strong as the infrastructure behind it. As organizations respond to these recent updates, having best-in-class vulnerability intelligence and direct visibility into threat actor TTPs is the best defense.
| Niccolo Arboleda | Guest Author Niccolo Arboleda is a cybersecurity enthusiast and student at the University of Toronto. He is usually found in his home lab studying different cybersecurity […]
Login
