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:
C:\Users\* (logical)
D:-Z:\* (logical)
PHYSICALDRIVE9-PHYSICALDRIVE0 (physical)
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.
Figure 1: PeStudio Information
Figure 2: CFF Explorer Information
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.
Figure 3: UPX Options
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.
Figure 4: PeStudio Imports
Figure 5: CFF Explorer Imports
In-Depth Analysis
Stack Strings
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
Figure 6: Windows APIs and DLLs
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:\
Figure 7: Wiper Function Calls
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.):
FindFirstFileA4
FindNextFileA5
CreateFileA6
GetFileSize7
LocalAlloc8
SetFilePointer9
WriteFile10
LocalFree11
CloseHandle12
FindClose13
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:
SetEntriesInaAclA14
AllocateAndInitializeSid15
SetNamedSecurityInfoA16
GetCurrentProcess17
OpenProcessToken18
SeTakeOwnershipPrivilege19
FreeSid20
LocalFree
CloseHandle
Figure 8: Sample Stack String WinAPI Call
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:
LookupPrivilegeValueA21
AdjustTokenPrivileges22
GetLastError23
This will let the malware to overwrite permissions on each file, so it is referenced as “MalwarePrivilegeCheck”.
Figure 9: Privilege Check
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.
Figure 10: Completion of All Drives Wiped
This subfunction makes the following stack string API calls:
DeviceIoControl24
CreateFileW
CloseHandle
Figure 11: 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.
Figure 12: Physical Drive 9-0
Conclusion
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 help@securityresearch.us.
Post comments (0)