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
- malwareubuntu-client-Snapshot2.vmem
- dump of the developer server’s memory.ubuntu-client-Snapshot2.vmsn
- dump of the developer server’s state (link)
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).
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).
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).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).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).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.
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).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).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).
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).
Answer: T1543.002