Nine out of 10 cybersecurity professionals are concerned about cloud security. Some of their biggest challenges is protecting against data loss and leakage, data privacy threats, and breaches of confidentiality.
Caddy Wiper is a family of malware seen recently in attacks on Ukraine that is associated with causing damage to infected systems by completely wiping their drives, thus rendering them unrecoverable. The sample in this analysis will wipe the following logical and physical drive locations if the system it is running on is not a Windows Domain Controller:
Basic Static Analysis
To understand what Caddy.exe is, we can open the file in CFF Explorer and PeStudio to get an idea of the internal workings.
Here we can see that they both immediately flag the file as being packed with UPX1. Unpacking can be done by using the UPX tool itself. Running the command by itself lists the available options for use.
To unpack this executable, we can simply run upx -d caddy.exe . The unpacked file can be analyzed using PeStudio and CFF Explorer again to get an idea of what the file does. IDA or Ghidra in association with a good debugger like x64 dbg.
PeStudio and CFF Explorer both show that there is a Windows API call to DsRoleGetPrimaryDomainInformation2, which is used to see if the system is a domain controller or not.
Stack strings3 are a common malware evasion technique to masquerade Windows API calls, hiding their true intentions from analysis tools (AV, EDR, etc.)
Now that we have an idea of the file, we can dissect the assembly from the file and follow the logic to understand what this file does with that import and if there is anything else to see.
Right in the beginning, we see that there are a bunch of stack strings that appear to be Windows’ DLLs and API calls
Stepping through the file to this point. We see immediately following this is a function call at location 4010E5. This function then takes the stack strings from memory and uses them to load a Window’s DLL API function. Referenced as “Win32APICallManager”
The first call is LoadLibraryA which loads up our sample. Now that the sample is loaded into memory, it is time to see what it does with our system. After checking if the current computer is a domain controller and verifying that it is not running on a DC, the process then begins the sequence of wiping the files on the system starting with C:\Users and then progressing through every drive letter until Z:\
Logical Drive Destruction
This wiper function works by programmatically and recursively calling the following Windows APIs using the subfunction at offset 401530 (named Win32APICallManager) against each of the above-mentioned locations (i.e., C:\Users\*, D:\*, E:\*, etc.):
The sample then tries to bypass file privileges to overwrite the data. It called a subfunction at 401A10 names “FilePrivilegeBypass”. This function makes the following API calls using stack strings as seen before:
After calling the SeTakeOwnerShipPrivilege, the sample then makes a call to subfunction at offset 401750 which takes advantage of stack strings API calls again. Here this function is calling:
This will let the malware to overwrite permissions on each file, so it is referenced as “MalwarePrivilegeCheck”.
Once the file has done this for all the files on all the drives mentioned previously (C:\Users\* and D-Z:\*), the process is repeated for non-mounted drives. The sample returns to the main function and calls the subfunction 4011D0.
This subfunction makes the following stack string API calls:
Physical Drive Destruction
At the end of this, we can see it is doing the wiping operations again each physical drive from 9 backward to 0.
This sample not only destroys every file visible to the operating system it also overwrites the partitions of each physical drive, rendering the entire drive itself worthless.
If you have questions and want a deeper discussion about the malware and prevention techniques, you can contact us at firstname.lastname@example.org.
Post comments (0)