HTB Sherlock - Lockpick2.0 Writeup

Sherlock Scenario

We’ve been hit by ransomware again, but this time the threat actor seems to have upped their skillset. Once again, they have managed to encrypt a large set of our files. It is our policy NOT to negotiate with criminals. Please recover the files they have encrypted—we have no other option! Unfortunately, our CEO is on a no-tech retreat and cannot be reached.

Warning: This Sherlock includes software that will interact with your computer and files. This software has been intentionally included for educational purposes and is NOT intended to be executed or used otherwise. Always handle such files in isolated, controlled, and secure environments. Once the Sherlock zip has been unzipped, you will find a DANGER.txt file. Please read this to proceed.

Artifacts

To solve the task, we have received the following files (Fig. 1):

• DANGER.txt - contains a warning and the password to extract the malware.zip archive,
• share - a directory with files encrypted by ransomware and a note left by the attackers,
• malware.zip - the malware we need to analyze to solve the task.

  

  The share directory contains three files. The countdown.txt file has information left by the attacker, including a note about the ransom. It includes the Bitcoin wallet address and the amount that needs to be paid for decrypting the files. The other two files with the .24bes extension are encrypted by the malware and will need to be decrypted in the further part of the task (Fig. 2).

  

  After extracting the malware.zip directory, we get the update file. Checking the file type with the file command reveals that it is an ELF file, which means it is an executable for Linux systems (Fig. 3).

  

  The first step I took in analyzing the malware was to check what VirusTotal had to say. Unfortunately, I did not find much information besides the fact that it is malicious software. However, I noticed that VirusTotal indicated that the software is packed using UPX (Fig. 4).

  

  To be sure, I used the strings command to check what strings are in the file. I received clear confirmation that the file was packed with UPX (Fig. 5). This provided the answer to Task 8 and also initiated my search for ways to unpack it.

  

  It turned out that the file can be unpacked with the same tool that was used to pack it. I downloaded upx from the repository and then unpacked the file using the command ./upx -d ../update. After checking the file type with the file command, it was found that the file was not stripped, meaning that all debug information is available in the binary. This makes the file easier to analyze (Fig. 6).

  

  At this point, I could run the IDA decompiler and proceed with further analysis. The first question on the list was to determine what type of encryption is used by the malicious software. After loading the file into IDA, I focused on finding the answer to this question. Since the software was not stripped, I could easily browse through the functions written by the attacker. During this analysis, I noticed the encrypt_file function, and after obtaining the pseudocode, I found the call to EVP_aes_256_cbc on line 23. This indicates that the software encrypts files using a symmetric block cipher (AES 256 in CBC mode). Once the key used by the attacker for encryption is found, the files can be decrypted without any problem (Fig. 7).

  

  Next, I needed to find the key. To determine where the attacker obtains it from, I returned to the main function. There, on line 16, I found the function get_key_from_url (Fig. 8).

  

  While analyzing this function, I discovered that before setting the address from which the key is to be fetched (line 22), an XOR operation is performed (line 20) (Fig. 9).

  

  I determined that it would be faster to obtain the key using dynamic analysis (yes, I know XOR is very simple, but I’m not very proficient with the IDA tool). Therefore, I ran update using gdb-peda. I set a breakpoint on the call to curl_easy_setopt (b curl_easy_setopt), which, according to my analysis, is called first after the program starts and the XOR operation is performed. After executing the run command, I immediately obtained the address from which the key for encrypting the files is fetched (Fig. 10).

  

  The file obtained from this address was named updater, which allowed me to answer Task 4, and after executing the md5 updater command, I obtained the answer to Task 5 (Fig. 11). At this point, I thought I had almost everything. The only thing left was to find the IV.

  

  The key used for encryption was in binary format, so I encoded it into Base64 using the command cat updater | base64. I then prepared the configuration in CyberChef for decrypting the files. After configuring CyberChef, I noticed that it reported an error regarding the key length. The key I initially obtained was 48 bytes long, whereas, based on earlier information, AES-256 encryption requires a key length of 32 bytes (Fig. 12).

  

  I re-examined the get_key_from_url function and noticed that the key is copied to the output parameter using the memcpy function, with a length set in hex to 0x20, which corresponds to 32 bytes. This means that the memcpy function only copies the first 32 bytes of the key (Fig. 13).

  

  I returned to CyberChef and removed the unnecessary bytes to achieve the expected key length. In theory, I now had the correct key. I selected the first file I wanted to decrypt, converted its format to Base64, and then pasted it into CyberChef. I only needed to obtain the IV. IV in AES is an optional value, so before returning to the code to find it, I set the IV value to all zeros. It turned out that this was the expected IV value, and I successfully decrypted the file. Thus, I now had a mechanism to decrypt the remaining files (Fig. 14).

  

  At this point, I had all the necessary information and could proceed to answer the questions.

Solution

Task 1

What type of encryption has been utilized to encrypt the files provided?

The answer to this question was found during the initial analysis of the file. In the encrypt_file function, on line 22 (Fig. 15).

Answer: AES

Task 2

Which market is our CEO planning on expanding into? (Please answer with the wording utilized in the PDF)

After decoding the files using the method described above, I first tried to open the decrypted file using the default PDF viewer available on the system. To my surprise, I received an error message (Fig. 16).

The decryption had been successful, and after checking the file header, everything looked fine. Therefore, I decided to try opening the file with a different tool. I chose Firefox, which displayed the file correctly and allowed me to obtain the answer to the question (Fig. 17).

Answer: Australian Market

Task 3

Please confirm the name of the bank our CEO would like to takeover?

After decrypting the DOCX file, it opened without any problems. I found the answer to the question in the first lines of the letter (Fig. 18).

Answer: Notionwide

Task 4

What is the file name of the key utilized by the attacker?

The answer to this question was obtained during the analysis of the malicious software (Fig. 19).

Answer: updater

Task 5

What is the file hash of the key utilized by the attacker?

The answer to this question was obtained during the analysis of the malicious software (Fig. 19).

Answer: 950efb05238d9893366a816e6609500f

Task 6

What is the BTC wallet address the TA is asking for payment to?

In the share directory, besides the encrypted files, there is a countdown.txt file, which is a note left by the attacker. After reading it, I found information about the Bitcoin wallet address where the ransom should be transferred (Fig. 20).

Answer: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2

Task 7

How much is the TA asking for?

The same note also contains information about the amount of the ransom (Fig. 21).

Answer: £1000000

Task 8

What was used to pack the malware?

At the very beginning of the malware analysis, I found the answer to this question (Fig. 22).

Answer: upx