HTB Sherlock - Lockpick3.0 Writeup

HTB Sherlock - Lockpick3.0 Writeup

Sherlock Scenario

The threat actors of the Lockpick variant of Ransomware seem to have increased their skillset. Thankfully on this occasion they only hit a development, non-production server. We require your assistance performing some reverse engineering of the payload in addition to some analysis of some relevant artifacts. Interestingly, we can’t find evidence of remote access so there is likely an insider threat. Good luck! Please note on the day of release this is being utilized for a workshop, however, it will still be available (and free).

Artifacts

After unzipping the file, we find three files (Fig. 1):

  • ubuntu-client - malware
  • ubuntu-client-Snapshot2.vmem - dump of the developer server’s memory.
  • ubuntu-client-Snapshot2.vmsn - dump of the developer server’s state (link)
    Fig. 1. Contents of the unzipped file.
    Fig. 1. Contents of the unzipped file.

Solution

Task 1

Please confirm the file hash of the malware? (MD5)

After executing the command md5 ubuntu-client, I obtained the MD5 hash, which turned out to be correct (Fig. 2).

Fig. 2. MD5 hash of the provided malware.
Fig. 2. MD5 hash of the provided malware.

Answer: a2444b61b65be96fc2e65924dee8febd

Task 2

Please confirm the XOR string utilized by the attacker for obfuscation?

Before I began the memory dump analysis with Volatility3, I decided to first use the strings command. Using strings ubuntu-client-Snapshot2.vmem | grep ubuntu-client, I managed to identify the command executed by the attacker to launch the malicious software. The occurrences of this command were consistent and not numerous (Fig. 3).

Fig. 3. Command executed by the attacker to launch the malware.
Fig. 3. Command executed by the attacker to launch the malware.

Answer: xGonnaGiveIt2Ya

Task 3

What is the API endpoint utilized to retrieve the key?

Before I proceeded with dynamic analysis, I first checked what VirusTotal could tell me about this binary. Unfortunately, it did not reveal anything interesting that could lead me to a solution. Then, using the strings command, I tried to find something that might indicate the complete string, sufficient for performing the XOR operation. I failed to detect anything suitable, but I noticed two endpoints: /connect and /upload/ (Fig. 4).

Fig. 4. Result of the <code>strings ubuntu-client</code> command.
Fig. 4. Result of the strings ubuntu-client command.
From the results obtained, I understood that the attacker first uses the XOR operation to acquire the address, then concatenates it with the endpoint I found. At that point, I decided to run ubuntu-client in gdb. The first attempt ended in failure due to the missing library libcrypto.so.1.1 (Fig. 5).
Fig. 5. First attempt to run <code>gdb ubuntu-client</code>.
Fig. 5. First attempt to run gdb ubuntu-client.
In the package manager apt, I was unable to find a counterpart, so I looked for a way to build the required library. For this, I used this article. With the following commands, I managed to download and compile the missing library.

wget -c https://www.openssl.org/source/openssl-1.1.1s.tar.gz && \
tar xf openssl-1.1.1s.tar.gz && \
cd openssl-1.1.1s/ && \
./config --prefix="/usr/local/openssl" && \
make

Then, using the environmental variable LD_LIBRARY_PATH, I directed gdb where to look for the missing dependencies. By executing LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/michal/openssl-1.1.1s gdb ubuntu-client, I was able to run the program. For the malware analysis, I used a gdb extension named peda, which significantly facilitates software analysis. Then in gdb, using the command info functions, I listed the functions used by the malicious software. My attention was caught by curl_easy_setopt@plt. plt indicates that it is a function loaded from an external library, and curl_easy_setopt, according to the documentation, is a function used to establish a curl connection. Therefore, using the command b curl_easy_setopt, I set a breakpoint on this method’s invocation and then started debugging with run xGonnaGiveIt2Ya (Fig. 6).

Fig. 6. Second attempt to run <code>gdb ubuntu-client</code>.
Fig. 6. Second attempt to run gdb ubuntu-client.
At the first capture of the program at the breakpoint, I read the URL address used to retrieve keys (Fig. 7), which confirmed my assumptions from the first step that the attacker concatenated the endpoint with the XORed address.
Fig. 7. Detected API address used to retrieve the key.
Fig. 7. Detected API address used to retrieve the key.

Answer: https://plankton-app-3qigq.ondigitalocean.app/connect

Task 4

What is the API endpoint utilized for the upload of files?

During the software analysis using the strings command, I discovered two endpoints: /connect and /uploads/. After determining the full address used for retrieving the key in Task 3, I replaced /connect with /uploads/.

Answer: https://plankton-app-3qigq.ondigitalocean.app/upload/

Task 5

What is the name of the service created by the malware?

I must admit, this task took me the most time. Initially, I did not understand why the provided memory dumps were not properly handled by Volatility3 and Volatility tools. Only after some time did I discover that I needed to use additional symbols not defaultly included in Volatility3. At first, I came across a thread suggesting to first identify which kernel was used by the machine from which the dump was made. Using the command python3 vol.py -f ../ubuntu-client-Snapshot2.vmem banners, I determined that Ubuntu used the kernel 5.4.0-163-generic (Fig. 8).

Fig. 8. Kernel version used by the development machine.
Fig. 8. Kernel version used by the development machine.
Then I used this repository and copied its contents to the volatility3/symbols/linux directory, which allowed me to perform the analysis. After a while of fruitless file searching, I came up with the idea to look for a .service file corresponding to the time of executing the command ubuntu-client xGonnaGiveIt2Ya (Fig. 9).
Fig. 9. Time of command execution by the attacker.
Fig. 9. Time of command execution by the attacker.
After narrowing down the search results, I quickly found the service that had been created just after the malware was launched by the attacker (Fig. 10).
Fig. 10. Name of the service created by the malware.
Fig. 10. Name of the service created by the malware.

Answer: ubuntu_running.service

Task 6

What is the technique ID utilized by the attacker for persistence?

This was the simplest task – by entering keywords and clicking on the first link, I obtained the answer (Fig. 11).

Fig. 11. Searched phrase in Google.
Fig. 11. Searched phrase in Google.

Answer: T1543.002