Top Categories

Spotlight

Top Voted
Sorry, there is nothing for the moment.

Analysis of CaddyWiper: Malware Targeting Ukrainian Organizations

Cyber security + Malware Analysis Dillon Johnson todayMay 30, 2022 304 5

Background
share close

Summary

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.

Written by: Dillon Johnson

Tagged as: , , .

Rate it

Post comments (0)

Leave a reply

Your email address will not be published. Required fields are marked *