“Wrongsomewhere” write-up: DG’hAck 2023

Like last year during DG'hAck 2022, we looked at the challenges proposed by the DGA as they are always quite fun to solve. This 2023 challenge (see https://www.dghack.fr/), even if being worth not a lot of points, was nice, here is how we solved it.

Challenge

Translated to English as the original is in French.

A new ransomware is spreading on the internet.

Too many old ladies are being scammed by this one, it's time to act!

One of the victims granted us remote access to their machine, please investigate and find the key to decrypt the files.

The files provided are the exe of the malware: wrongsomewhere.exe. We are warned to not launch it on our machine as it is a ransomware.

First instinct: launch it in esReven

My first instinct as someone working on esReven was to use it to reverse this challenge. As we provide a way to automatically record binary execution, it was as easy as to push a few buttons and my trace was generated and accessible in under 3 minutes.

Here is the call tree for the main function:

As you can see, we have the symbols of the binary, that's probably a part of why this challenge wasn't worth a lot of point.

If we looked at the functions called, we can deduce what it is doing quite easily:

• Trying to open a registry key
• Creating a registry key (we could assume that the open failed and it want to create it now)
• Generating multiple random values, probably to generate the encryption key
• Storing something in the created registry key, probably the encryption key
• Iterate on the files inside a folder, for each one:
  • Read the content of the file
  • Encrypt the content
  • Write it back to the file

Because we have the whole trace available to us, we can validate our hypotheses by looking at the different arguments and the assembly executed.

Generation of the key

The call to RegOpenKeyExA was to open the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\OneDrive\error and returned 0x2, so it failed to open it as it wasn't created yet. The call to RegCreateKeyExA is to create the key with the same name.

The malloc is called with a size of 61 and following it we have 60 calls to rand. If we look at the executed code of first_pass that is calling rand, we can see that it is indeed generating a random null-terminated string. Each call to rand in the loop is used to generate one character at a time and it is stored in the buffer allocated with malloc.

The call to RegSetValueExA is storing this string as is in the registry key. That's probably how we will be able to retrieve the encryption key on the victim's machine.

Encrypting the files

If we look at the constructor of SymmetricEncryptor, here is what we can see:

Given the string in parameter, it is storing the 16 first bytes of the key in a property, those first 16 bytes will probably be used as a key to encrypt the files with a block size of 16 bytes.

Now, if we look at SymmetricEncryptor::encrypt, we can see that the content of the file is given as the first parameter and the size of the content as the second argument. Now let's look at how it is doing its encryption:

We can see that we use one byte of the key at a time, xoring it with the content.

We now have a way to retrieve the encryption key (in a registry key) and the encryption used, we should have everything needed to retrieve the content of the flag on the victim's machine.

Finding the flag on the victim's machine

We have access to the victim's machine over VNC. We can see on the desktop the ransomware executable and a folder named Documents.

In it there is a flag.txt file, if we open it with notepad we can see that it contains garbage as it is encrypted.

Now, let's retrieve the encryption key.

The encryption key is ZndeAeUrTltyJVZvFVOJrKcFhklhqljzryWPdUQpakaGPjiyBniXvenYwMvU.

As we are over VNC, we don't have access to the file and the clipboard over VNC wasn't working on my side, so I used a powershell command to dump the content as bytes and a little bit of OCR to read the output.

From there, with a small python script, we can decrypt the file:

# Key retrieved from the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\OneDrive\error
key = "ZndeAeUrTltyJVZvFVOJrKcFhklhqljzryWPdUQpakaGPjiyBniXvenYwMvU"[:16]

# Bytes extracted from `flag.txt
data = [
    30, 41, 44, 36, 2, 46, 46, 32, 96, 2, 39, 73, 39, 1, 110, 4, 105, 29, 59, 81, 51, 86, 10, 70, 11, 47, 6, 72,
    39, 101, 5, 50, 106, 49, 10, 85, 53, 58, 0, 1, 103, 51, 32, 17, 123, 37, 5, 70, 52, 93, 59, 35, 113, 23, 10,
    65, 34, 93, 24, 4
]

flag = ""
for i in range(len(data)):
    flag += chr(data[i] ^ ord(key[i % len(key)]))

print(flag)

Giving us DGHACK{R4nS0mW4r3s_4r3_4_Cr1m3_D0_n0t_Us3_Th1s_0n3_F0r_3v1l}

What about static analysis?

Following the completion of the challenge, I decided to check in Ghidra to see if it could be done easily just with a static analysis. This revealed additional interesting things.

In Ghidra, we can see that the main isn't always calling the function first_pass, but has arguments to drive the behavior of the ransomware. We can for example ask it to decrypt the files by giving it the option -d FILE and entering the key in a prompt.

We can also see that the registry key name is not in clear in the binary and decrypted in the call to a function named op. Thanks to esReven, I didn't have to worry about that during the dynamic analysis as I just looked at the call to RegOpenKeyExA and didn't have to check where the argument was coming from.

If we look at the argument in the trace with the memory history, we can see the writes in the function op when it is being decrypted. It's one of the advantage of doing dynamic analysis, if something is decrypted somewhere it will appear in the trace directly.

Using the -d option is clearly easier to retrieve the flag from the VM and was probably the intended way:

Conclusion

The challenge was quite easy to solve with esReverse in a small time, but we also saw that dynamic analysis should be done in conjuction with static analysis. That's why in esReven we also provide a synchronisation mechanism with tools like IDA, Ghidra, Binary ninja, etc so that the reverse engineers can easily use them simultaneously.

Thanks to the DGA for providing this CTF, as last year, it was nice and we are looking forward for the next edition.