Lockpick 4.0 Writeup

Lockpick4.0 is the 4th edition to a series of sherlocks that places you at Forela.org’s Incident Response (IR) team our job is to reverse engineer the malware to find Indicators of Compromise. There are 11 tasks to complete which I will walk us through.

Make sure you have set up an isolated sandbox to do this challenge in as we will use dynamic analysis which involves detonating parts of the ransomware.

After downloading and extracting the malware we will notice a hard disk image file. Double clicking the file to mount the volume to our sandbox reveals 2 files and 2 folders. The 2 folders come with most new volumes so we can ignore them for now. However, the 2 files are of interest to us. Opening the ReadMe.txt shows a social engineering attempt to get us to double click on ‘defenderscan.js’. This is where we will focus our attention.

Opening up ‘defenderscan.js’ in notepad++ or any editor of your choice we can see on lines 2 and 3 what appears to be some base64 encoded data (if it ends with = you can just try to base64 decode as there is a good chance it is base64 encoded data). Using notepad++ plugins I decoded the first string.

Here we can see that these are more JavaScript functions. The 2nd string does not appear to be functions and is data of some kind (We are unsure at the moment so we will leave that base64 encoded).

Task 2 - What is the string that the ransomware uses to check for local administrator privileges?

S-1-5-32-544

Scrolling through the functions just trying to get a general jist of what this script is doing we can answer this task.
Here we can clearly see that they are matching on a string S-1-5-32-544 to check whether the current user is a local admin.

Scrolling a bit further we see more base64 encoded strings. Decoding those reveal more interesting things.

If the user is not a local admin or a domain admin we call Bypass-GondorGate which attempts to elevate privileges. If the user is a local admin it will construct a command.

First let’s check out Bypass-GondorGate. We can see that it is dropping a .inf file called ScrollOfEru.inf into our temp folder. Then it starts cmstp.exe and passes the dropped file as an argument.

Task 3 - What is the MITRE ATT&CK ID for the technique used by the threat actor to elevate their privileges?

T1218.003

Googling for mitre att&ck cmstp.exe .inf leads us to the mitre att&ck id for System Binary Proxy Execution.

Now lets move onto the else statement. Cleaning this up a bit we can see that it excludes MsMpeng.exe and mpsvc.dll from windows defender. It then sets the content of ‘defenderscan:lolbin’ to a file in the current directory called ‘MsMpeng.exe’ and the content of ‘defenderscan:payload’ to a file in the current directory called ‘mpsvc.dll’. However, we dont see either a lolbin function or a payload function? Remember that the current code we are looking at exists in a base64 encoded string. So we need to find where this base64 string is decoded in the script.

Task 4 - The ransomware starts a process using a signed binary, what is the full name of the signer?

Before we do that though we can see that MsMpeng.exe is being used to launch the ransomware therefore if we look at the digital signature for MsMpeng.exe. We can answer task 4.

Microsoft Corporation

Task 1 - What is the MD5 hash of the first file the ransomware writes to disk?

2c92c3905a8b978787e83632739f7071

This might be quite hard to see but essentially what is happening is both base64 strings are being decoded. One is being dumped to a file named redbadger.webp and one is included in a command that is being run.

Now we have two options we can take. One is we can write scripts to dump both the webp and the commands, however, this will take a while to do. I opted to just take a snapshot of my VM from here and see what actually happens when I detonate the ransomware.

Double clicking on defenderscan.js we see redbadger.webp in our directory this is the first file written to disk.

Now when I detonated the ransomware I saw two files MsMpeng.exe & mpsvc.dll appear and then quickly disappear. So I reverted back to the snapshot I took before and commented out all the DeleteFile and Remote-Items in the script.

I then converted this back into base64 data and ran the script again. This allowed me to copy and paste the MsMpeng.exe & mpsvc.dll to my desktop. Quickly looking at these files in detect it easy it tells us that they are c compiled binaries so I opened MsMpeng.exe in Ghidra.

Remember the ‘lolbin’ and ‘payload’ functions from earlier? This gives us a hint that the payload actually exists in mpsvc.dll.

Task 5 - What is the final payloads’ entry point function?

ServiceCrtMain

Taking a look at the entry in the executable we can see that all this does is call ServiceCrtMain which is an import from mpsvc.dll. So lets open up mpsvc.dll in Ghidra.

Task 9 - What is the MITRE ATT&CK ID the ransomware uses to run its final payload?

T1574.002

Thinking about how the payload is ran. I thought about DLL hijacking as this is essentially what is happening. Therefore, I looked up the att&ck id for DLL hijacking.

Task 6 - How many Anti-Debugging techniques does the ransomware implement and what is the Windows API function that the final technique leverages?

3, SetUnhandledExceptionFilter

In Ghidra by looking at ServiceCrtMain we can see three anti-debugging techniques.

The first one is pretty trivial as it calls IsDebuggerPresent(). This technique will check the PEB (Process Environment) IsDebuggerPresent flag.

The second technique checks if a parent process exists and that this parent process is PowerShell. As in ‘defenderscan.js’ we launch this program using powershell. If PowerShell is not the parent process then it exits.

The third technique makes use of SetUnhandledExceptionFilter. This can be read more about here. Essentially, we register an exception handler and then raise an exception (here by having an int3 instruction which is not part of the instruction set). If the exception handler we register is not called then it is safe to assume the process is being debugged.

Task 7 - The ransomware targets files with specific extensions, what is the list of extensions targeted in the exact order as the ransomware configuration stores them?

.doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, .txt, .csv, .rtf

After these debug checks another function is called. Which seems to load a resource using MAKEINTRESOURCE(0x65) which has type RT_RCDATA (raw data).

After jumping back and fourth through all the functions called and all the code. We come across some interesting strings and functions.

Some space is allocated on the heap and then BCryptDecrypt is called. So let’s check out what is being decrypted.

To do this you probably want to rebase the program in Ghidra to 0.

Whacking open MsMpeng.exe in x64dbg we first need to defeat all the anti-debug measures. So let’s set some breakpoints.

The first one is pretty easy.

The JNZ can be changed to a JZ or we can change the ZF (Zero Flag) to zero. If you have Scylla Hide which you should then just enable IsDebuggerPresent in your profile.

By pressing ctrl+g then entering mpsvc.dll base address + 25bb3 we can set a breakpoint by hitting F2.

The second one we could just do bp _wcsicmp in the command input and alter the return result. Or change the JZ to JNZ or just change the ZF register again.

mpsvc.dll base address + 25cfe

The third one is the exact same we can NOP it change the JNZ to a JZ or just change the zero flag.

mpsvc.dll base address + 25c2a

You can choose to patch the binary and dump it so that you never have to do these again. There are plenty of YouTube tutorials that teach you how to do this.

So after setting all these breakpoints we also want to set a breakpoint on BCryptDecrypt which we can do by doing bp BCryptDecrypt in the command window.

Now run until we hit BCryptDecrypt making sure we correctly defeat the anti-debug measures.

Looking at the docs. For BCryptDecrypt we can see that the address of the output buffer is the 7th argument in this function. We know that according to the x64 calling convention the first four arguments are in registers RCX, RDX, R8, R9 the rest of the arguments are pushed onto the stack. Thankfully x64dbg can tell us all these arguments.

If we follow this address in dump and step over the call. We will see some interesting text.

We can clearly see what files the ransomware targets.

Task 10 - What is the full URL including port number of the ransomware groups customer service portal?

yrwm7tdvrtejpx7ogfhax2xuxkqejp2qjb634qwwyoyabkt2eydssrad.onion:9001

There is some more data labelled html_content which looks to be base64 encoded. So lets base64 decode that data.

Task 8 - What is the FQDN of the ransomware server the malware connects to?

api.ltchealthcare.co

Now back in Ghidra in ServiceCrtMain we see references to WinHTTPOpen and functions related to HTTP web requests.

Looking through the docs we know that the server name gets passed to WinHttpConnect. So lets breakpoint on WinHttpConnect and inspect it’s arguments again.

Task 11 - What is the file extension used to store the newly encrypted files?

.evil

For this I created a .txt file on my desktop. I then just spoofed a response from the server with a IV and a key. This then produced a .evil file on my desktop. However, if you grant internet access to your sandbox it will produce the same outcome.