Mohannad Raafat

Mohannad Raafat

I’m a person who has a passion for Cybersecurity especially Malware Analysis & Reverse Engineering.

[PrincessLocker V2.0] ransomware with not so royal encryption

6 minute read

File Summary

Packed  
MD5 93cb0053e883fb262f9f795f327152f8
File Type PE32 executable
Unpacked  
MD5 0068bac6093a33351807aecc9c842e4a
File Type PE32 executable

Analysis Summary

  • This ransomware has 2 stages of execution, It uses (self-injection) to avoid detection.
  • It checks infection by looking for specific mutex and a file to avoid re-infecting the computer.
  • Then, It sends some information about the victim to the attacker such as (OS version, Username, Victim ID, The system’s Locale ID, Encryption key, etc….).
  • Finally, It starts encrypting files with the AES-128 key.

Behavior Analysis

Once executed, Princess Ransomware runs silently. It does not delete itself, but just encrypts all the data in the background. After finishing the encryption, it pops up a default browser and displays the ransom note. It drops notes in three file formats: HTML, URL shortcut, and TXT.

=_THIS_TO_FIX_[Extension].txt
=_THIS_TO_FIX_[Extension].html
=_THIS_TO_FIX_[Extension].url

0

1

2

and here it sends something like base64 string to C&C using UDP on:
176.10.125.1/24:6901 - 176.10.126.1/24:6901 - 176.10.127.1/24:6901

34 35

Let’s getting deeper.

Stage 1: Self Injection

This executable is making a technique called self-injection to protect itself from detection. So it makes the following:

  1. Allocate some memory for the unpacked executable.
  2. Write the PE file for it.
  3. Make this portion of memory EXECUTABLE.
  4. Execute.

3

Now, let’s unpack it. On our debugger, we can set a breakpoint at VirualAlloc and notice if there is a sign of a PE file.

Here I can see .text - .rdata sections.

4

but, I don’t see the DOS header signature (MZ) or the stub string. This is some garbage data and to be sure that is a PE file we can set a Hardware breakpoint at the base address of this allocated memory (break on execute).

And here, the execution stops at this point. So this is defiantly a PE File.

5

After dumping this portion, we have to fix the PE file to be a valid one. So we have to replace this garbage data with a good one but we need a reference to know where this garbage ends. This malware corrupts the DOS header and the stub but it can’t corrupt the File header as the OS loader needs it while loading the executable in memory.

I will use the Machine value as a reference. On 32-bit executable, the Machine value is 0x014C. So I will search for this value and replace all garbage before it with good data from another executable.

6

Notice that It executes this portion in memory so this PE file is Mapped and to analyze it I have to Unmap it. Before fixing the headers let’s show a brief of PE construction in memory.

PE file has several segments, each segment must be aligned inside one page (Sized 4096 bytes) in memory. So there could be unused space on each page.

Unlike the Unmapped PE file, segments are constructed continuously.

7

To unmap it, we can modify the Raw Data to match the Virtual Address of the section and also the size of each section.

  • Raw Data is a pointer that specifies the start of each section on disk.
  • Virtual Address is a pointer that specifies the start of each section in memory.

8

But here there is a problem. Let’s open HxD to check what is wrong.

When I go to the .text address, I see that it starts before (0x1000) so that is a misalignment problem. To fix it, we can insert 00 bytes (padding) to align .text at (0x1000). We can remove the .reloc section as this unmapped PE file.

Before each section, there must be some null bytes (Unused area as we discussed).

9

10

This file is ready now to put in IDA for Static Code Analysis, but we will make another thing to work with the debugger.

11

The PE size is bigger than the actual size on the disk so it won’t work. We can add padding bytes at the end of the file to match the 2 sizes (12800 bytes of 00 to add).

Now we can start analyzing stage 2.

Stage 2: Ransomware

Checking Infection

This ransomware has double-checking of existence. First, it starts to open a mutex named lCQhNOCPFC and if it’s existed, it will be terminated.

12 13

There is a function called many times across the code decrypt_some_string, it’s used to decrypt some strings like mutex name, some DLL(s) names,…etc

14

Then, It checks for a file called vnjJCGkc.PyO at the roaming folder inside AppData, It calls Check_File_Existence and inside it calls CreateFileW with dwCreationDisposition OPEN_EXISTING so if the file exists, the return value will be 1 and the ransomware terminates.

15 16

Checking Drives

Now, it calls Get_Drive_Info to check all available drives using GetLogicalDrives, Drive Type using GetDriveTypeW (it attacks FIXED and REMOTE drives).

18 17

Enumerating File & Folders

Now, it starts enumerating files and folders inside drives by calling Get_Files_And_Folders. First, it gets each folder path in lowercase (Starting with drive path)

19 20

21

Now, it will search for system folders inside every directory. First, it decrypts the folder name using decrypt_some_string, then it calls CheckExistance that returns 0 if exists. It loops 12 times for 12 folders.

  • I notice that the ransomware will not encrypt files inside these folders.
Folder Name    
recycle bin program data AppData
system volume information program files(x86) localsettings
temporary internet files windows recycler
program files microsoft msocache

22

Now, it starts enumerating files using FindFirstFileW and FindNextFileW to start encrypting them. It avoids encrypting the following extensions (probably).

.dll
.iso
.exe
.ico
.mp3

First, it adds wildcard (*) to the current path using Add_WildCard_To_Path then uses FindFirstFileW. There are 2 conditions, either it’s a file or a folder so It makes a (TEST) operation to determine where to go next.

23

If it’s a folder, it gets its path and calls Get_Files_And_Folders again, and does the previous operations. If it’s a file it gets its length and extension. Then making it in lowercase.

24 25

Note: I notice that FolderName starts with ‘.’, It will not enumerate inside. It won’t encrypt anything inside it. 26

Get Machine Info

First, it gets the System Locale ID and compares it with 0x419 and if matching, the malware is terminated.

According to MSDN this is Russian ID. So this malware doesn’t infect any machine in Russia.

Then it calls Get_Random_Stringand we will dig a little bit inside. (This function is used many times)

27

briefly, this function uses Dynamic DLL Loading to use some API(s) cryptography. Then It generates random strings that will be used as:

  • Victim ID.
  • Encryption extension.
  • String which will be used to derive the AES-128 key for encryption.
28 29

Next, it will call Get_OS_version. Let’s go inside:

It basically gets the version of the ntdll.dll file (i.e: 6.1.7601 for windows7).

30 31

Finally, It gets the Username and the Computer-name of the machine.

33

Notice that it uses this function a lot ConcatenateToOneString to concatenate all information into 1 long string. (It will use base64 to encode all information and send it to the attacker)

32

p=[Encryption Key]&x=bGlAheE4caBNnIcNjkQkkSIH6RlQ2nTl0voLyznylfj7h3jDm0bt4dLpwj3DEFx4gvnrbk0dUaqF7VTKLI89BqXSsT3wO2nJzuBMHwd76zNLvVYoenaFYHctfq8YY9ma&e=[Extention]&g=0&q=0&v=[Victim ID]&t=n&r=6722882958&a=0&i=Detect failed&o=[OS VERSION]&s=2616&l=1033&u=[ComputerName]-[Username]

Derive Encryption key

It uses Dynamic DLL Loading again as previously. First It uses CryptCreateHash and CryptHashData to hash a random string that is generated previously with SHA-256. Then It will use this hash to derive the AES-128 key.

36

37

Next it will calls CreateRansom_TXT_HTML_URL_Files to create ransom note at every folder in three file formats: HTML, URL shortcut, and TXT.

38

Encryption Process

It gets the full path of the file (with . at the end), then it adds the encryption extension. Next, it uses CreateFileW with the following:

dwFlagsAndAttributes = FILE_FLAG_DELETE_ON_CLOSE
dwCreationDisposition = OPEN_EXISTING
dwShareMode = FILE_SHARE_DELETE

Once the handle gotten from this function is closed, the original file will be deleted automatically and it makes the file shared when it’s deleted

In other words, this file won’t open.

39

Then, It will create a file with the same name (but has the encrypting extension). Finally, It will read the contents of the original file, encrypt them using CryptEncrypt and write the encrypted data inside.

40 41

42

Create_vnjJCGkc

Finally, It will create a vnjJCGkc file that will be a second check to avoid re-infecting this machine again and putting it inside the Roaming folder in AppData.

43

IOCs

Type Data
Hash 93cb0053e883fb262f9f795f327152f8
  0068bac6093a33351807aecc9c842e4a
C&C 176.10.125.1/24:6901
  176.10.126.1/24:6901
  176.10.127.1/24:6901
Mutex lCQhNOCPFC
File %AppData%\vnjJCGkc.PyO

References

OALabs
https://www.youtube.com/watch?v=WthvahlAYFY&t=1657s&ab_channel=OALabs

https://blog.malwarebytes.com/threat-analysis/2016/11/princess-ransomware/

https://www.trendmicro.com/en_us/research/18/h/ransomware-as-a-service-princess-evolution-looking-for-affiliates.html