Threat Update: CaddyWiper | Splunk
By Splunk Threat Research Team
Published: 2022-04-01 · Archived: 2026-04-05 17:50:50 UTC
Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we
no longer use. For more information on our updated terminology and our stance on biased language, please visit
our blog post. We appreciate your understanding as we work towards making our community more inclusive for
everyone.
As the conflict in Eastern Europe continues, the Splunk Threat Research Team (STRT) is constantly monitoring
new developments, especially those related to destructive software. As we have showcased in previous releases in
relation to destructive software and HermeticWiper, malicious actors modify their TTPs in order to become more
effective and achieve their objectives. In the case of HermeticWiper, we witnessed the introduction of new
features since the increment of malicious cyber activity targeting Ukraine from last month.
We now have a new payload recently discovered by ESET named CaddyWiper, indicating no code sharing with
previous malicious payloads during this campaign. There is one thing however that has been seen during the
deployment of payloads, and that is the use of Group Policy Objects (GPOs).
Group Policy Objects are Microsoft Active Directory network policies that can be applied selectively to
computers, organizational units, applications, and individual users. Splunk Security research has previously shown
how to use GPOs to defend against Ransomware, as the selective and massive application of these settings helps
streamline, enforce and harden security policies.
However, as we have witnessed, GPOs can be used to harm if malicious actors can compromise domain
administrators. This new malicious payload, incorporates the following features:
Domain Controller killswitch. If payload detects installation on a Domain Controller it stops its functions.
If not in a Domain Controller it destroys users data “C:\Users” and subsequent mapped drives (this may
include network mapped drives).
If not in a Domain Controller it destroys drive partitions including boot partitions (\\.\PhysicalDrive9 to
\\.\PhysicalDrive0)
The above new features indicate the intention of malicious actors to maintain access to Domain Controllers and
deploy destructive software without the need to have to compromise and get access again if they were destroyed
and had to be reinstalled. This approach is much more tactical and it also gives attackers the possibility to modify,
re-apply, or enforce GPOs that can achieve the deployment of this destructive payload. Below is a breakdown of
these features.
Domain Controller Kill Switch
https://www.splunk.com/en_us/blog/security/threat-update-caddywiper.html
Page 1 of 4

This wiper will prepare the module name and API name string on the stack to dynamically parse it upon
execution. Then it will execute DsRolePrimaryDomainInformation() API to retrieve the state data of the targeted
host. If the state role of the computer is DsRole_RolePrimaryDomainController caddywiper will exit its process.
Overwriting Files with Zeroed Buffer
If the computer is not a Domain Controller it will start to do its payload. One of them is overwriting files in
C:\users directory and from Drive D:\ until Drive Z:\.
If it finds a file that is not a folder and has a hidden system attribute, it will adjust the Security identifier
permission of its process as well as its TokenPrivileges to “SeTokenOwnershipPrivilege” to be able to access
those files.
https://www.splunk.com/en_us/blog/security/threat-update-caddywiper.html
Page 2 of 4

After that checking, Caddywiper will initialize a zeroed buffer based on the file size of the file it found. If the file
size is greater than 0xA00000, It will set the maximum zeroed buffer size to 0xA00000. That buffer will be used
to overwrite the files and make them unrecoverable.
Wiping Boot Partitions
https://www.splunk.com/en_us/blog/security/threat-update-caddywiper.html
Page 3 of 4

This payload will enumerate all possible boot sectors partitions from \\.\PhysicalDrive9 to \\.\PhysicalDrive0 to
overwrite it with a zeroed buffer with size of 1920 bytes. The wiping was executed using DeviceIoControl
IOCTL_DISK_SET_DRIVE_LAYOUT_EX.
Source: https://www.splunk.com/en_us/blog/security/threat-update-caddywiper.html
https://www.splunk.com/en_us/blog/security/threat-update-caddywiper.html
Page 4 of 4