HTB Sherlock - Einladen Writeup

HTB Sherlock - Einladen Writeup

Sherlock Scenario

Our staff recently received an invite to the German embassy to bid farewell to the Germany Ambassador. We believe this invite was a phishing email due to alerts that fired on our organisation’s SIEM tooling following the receipt of such mail. We have provided a wide variety of artifacts inclusive of numerous binaries, a network capture, DLLs from the host system and also a .hta file. Please analyse and complete the questions detailed below!

⚠️ Warning This is a warning that this Sherlock includes software that is going to 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.

Artefacts

After unpacking the ZIP file, we find the files DANGER.txt and malware.zip. The DANGER.txt file contains a warning about the contents of the ZIP file, along with the password needed to unpack malware.zip. After unpacking malware.zip, we obtain a directory named suspicious_files, which contains the files necessary to solve the task. In total, after unpacking malware.zip, we have 12 files available (Fig. 1).

Fig. 1. Downloaded artefacts.
Fig. 1. Downloaded artefacts.

Solution

Task 1

The victim visited a web page. The HTML file of the web page has been provided as downloader.html sample file.The web page downloads a ZIP file named Invitation_Farewell_DE_EMB.zip. What is the SHA-256 hash of the ZIP file?

In the suspicious_files directory, there is a file named Invitation_Farewell_DE_EMB.zip. Using the command shasum -a 256 Invitation_Farewell_DE_EMB.zip, I obtained the required hash (Fig. 2).

Fig. 2. SHA-256 hash for the file <code>Invitation_Farewell_DE_EMB.zip</code>.
Fig. 2. SHA-256 hash for the file Invitation_Farewell_DE_EMB.zip

Answer: 5D4BF026FAD40979541EFD2419EC0B042C8CF83BC1A61CBCC069EFE0069CCD27

Task 2

The downloaded ZIP file contains a HTA file, which creates multiple files. One of those files is a signed by Microsoft Corporation. In HTA file, which variable’s value was the content of that signed file?

To verify the contents of the Invitation_Farewell_DE_EMB.zip file, I first inspected its contents using the command zipinfo -m Invitation_Farewell_DE_EMB.zip. Inside, there was a file named Invitation_Farewell_DE_EMB.hta, which looked identical to the one available in the main task directory. After analyzing its content, I noticed that the phrase f.GetFolder appeared in all places where the script creates files. By using the grep command, I obtained a list of files created by the script (Fig. 3).

Fig. 3. Contents of the ZIP file, list of files created by the HTA script.
Fig. 3. Contents of the ZIP file, list of files created by the HTA script.

Since the HTB hint indicated that the file we were looking for ends with the letter v, my suspicions immediately turned to the file msoev.exe. To confirm, I verified the digital signature for this file in the Windows system (Fig. 4).
Fig. 4. Digital signature for the file <code>msoev.exe</code>.
Fig. 4. Digital signature for the file msoev.exe.

Answer: msoev

Task 3

The threat actor was acting as an embassy of a country. Which country was that?

I found the answer to this question first. The hint was hidden in the task’s logo, where you can see the country’s flag. :) Additionally, at a later stage, I found the same answer in the Invitation.pdf file (Fig. 5).

Fig. 5. Invitation received by the victim.
Fig. 5. Invitation received by the victim.

Answer: Germany

Task 4

The malware communicated with a chatting platform domain. What is the domain name (inclusive of sub domain) the malware connects to?

In the suspicious_files directory, there is a pcap file named msoev.pcapng. From the file’s name, it can be inferred that this is a capture of the communication established by the malware. After opening the file in Wireshark and applying a DNS filter, I noticed that the only domain with chat in its name is toyy.zulipchat.com (Fig. 6).

Fig. 6. Detected domain that the msoev.exe software connected to.
Fig. 6. Detected domain that the msoev.exe software connected to.

Answer: toyy.zulipchat.com

Task 5

How many DNS A records were found for that domain?

In response to the query from packet 69, we receive 6 A records for the subdomain toyy.zulipchat.com (Fig. 7).

Fig. 7. IP addresses assigned to <code>toyy.zulipchat.com</code>.
Fig. 7. IP addresses assigned to toyy.zulipchat.com

Answer: 6

Task 6

It seems like the chatting service was running on a very known cloud service using a FQDN, where the FQDN contains the IP address of the chatting domain in reversive format somehow. What is the FQDN?

Analyzing the pcap file with the DNS filter applied, we get only 28 records. Among these results, it’s easy to spot the FQDN associated with a “very well-known” cloud service (Fig. 8).

Fig. 8. Detected FQDN.
Fig. 8. Detected FQDN.

Answer: ec2-35-171-197-55.compute-1.amazonaws.com

Task 7

What was the parent PID (PPID) of the malware?

Initially, I thought that the PPID, like other information, would be easily accessible in the pcap file. However, it turned out that all communication with the server was encrypted. Without a private key, there was nothing I could do. Fortunately, there was another file in the suspicious_files directory that could contain the answer to the question - Logfile.PML. This file contains information recorded by Process Monitor. Upon opening the file, the answer was visible right in the first line (Fig. 9).

Fig. 9. Process Monitor and PPID.
Fig. 9. Process Monitor and PPID.

Answer: 4156

Task 8

What was the computer name of the victim computer?

By hovering over the additional information, I found the answer to this question (Fig. 10).

Fig. 10. Victim computer name.
Fig. 10. Victim computer name.

Answer: DESKTOP-O88AN4O

Task 9

What was the username of the victim computer?

In Windows, the username corresponds to the name of the home directory (Fig. 11).

Fig. 11. Victim computer username.
Fig. 11. Victim computer username.

Answer: TWF

Task 10

How many times were the Windows Registry keys set with a data value?

After filtering events related to setting registry values in ProcMon, I obtained the answer (Fig. 12).

Answer: 11

Task 11

Did the malicious mso.dll load by the malware executable successfully?

This time, I filtered all events that contained the mso.dll file in the path. All operations visible in figure 12 were successful (Fig. 13).

Fig. 13. Loading the malicious mso.dll file
Fig. 13. Loading the malicious mso.dll file.

Answer: yes

Task 12

The JavaScript file tries to write itself as a .bat file. What is the .bat file name (name+extension) it tries to write itself as?

Initially, I decided to manually deobfuscate the unc.js file (Fig. 14).

Fig. 14. Contents of the <code>unc.js</code> file.
Fig. 14. Contents of the unc.js file.

However, during this process, which took me a while, I made a mistake, causing the BAT file name to be incorrect. I have to admit, I got a bit frustrated with myself, probably because I mixed up one or two letters while replacing the characters. On my second attempt, I decided to try using the any.run platform. Since I don’t have a subscription, I used the free version. You can find the instance of running the script here. After running the script, I realized it was a very good decision, and I quickly found the correct answer to the question (Fig. 15).
Fig. 15. Running the malicious <code>unc.js</code> file in the any.run environment.
Fig. 15. Running the malicious unc.js file in the any.run environment.

Answer: richpear.bat

Task

13 The JavaScript file contains a big text which is encoded as Base64. If you decode that Base64 text and write its content as an EXE file. What will be the SHA256 hash of the EXE?

The Base64 code in the unc.js file is located in line 28 (Fig. 16).

Fig. 16. Base64 code in the <code>unc.js</code> file.
Fig. 16. Base64 code in the unc.js file.
I copied it and saved it in a separate file unc.b64.js. Then, using the command cat unc.b64.js | base64 -d > unc.js.exe, I decoded the file and saved it as an EXE file. When checking the SHA256 hash, I noticed that it is exactly the same as for the EmpireClient.exe file (Fig. 16).
Fig. 17. SHA256 hashes for the decoded file from <code>unc.js</code> and <code>EmpireClient.exe</code>.
Fig. 17. SHA256 hashes for the decoded file from unc.js and EmpireClient.exe.

Answer: db84db8c5d76f6001d5503e8e4b16cdd3446d5535c45bbb0fca76cfec40f37cc

Task 14

The malware contains a class Client.Settings which sets different configurations. It has a variable Ports where the value is Base64 encoded. The value is decrypted using Aes256.Decrypt. After decryption, what will be its value (the decrypted value will be inside double quotation)?

Having learned from the experience in Task 12, I decided that it would be faster to perform dynamic analysis rather than static analysis. First, I verified the type of the EmpireClient.exe file using the command file EmpireClient.exe. It turned out that the file was created using the .Net technology, which made me very happy because this technology is easy to decompile (Fig. 18). If obfuscation was not used, the code would be readable and relatively easy to analyze.

Fig. 18. Detected type of the <code>EmpireClient.exe</code> file.
Fig. 18. Detected type of the EmpireClient.exe file.
For dynamic analysis, I used dnSpy. I knew I had to find the Client.Settings class and the Ports variable. In line 21, the value is assigned after decryption. I set a breakpoint on that line and then started the debugger. After the debugger stopped, I performed a step-over, and in the Locals window at the bottom, I found the answer according to the task’s instructions (Fig. 19).
Fig. 19. Debugging the malicious <code>EmpireClient.exe</code> file using dnSpy.
Fig. 19. Debugging the malicious EmpireClient.exe file using dnSpy.

Answer: 666,777,111,5544

Task 15

The malware sends a HTTP request to a URI and checks the country code or country name of the victim machine. To which URI does the malware sends request for this?

Having the malware decompiled, I started reviewing its code. During the analysis, I came across the namespace Client.Helper and the Antisng class, which is responsible for detecting the victim’s country of origin. In the GetCountryName and GetCountryCode methods, I found the URI http://ip-api.com/json/, which returns information such as the country and city the client is connecting from based on the IP address (Fig. 20).

Fig. 20. URI used by the attacker to check the victim&rsquo;s country name.
Fig. 20. URI used by the attacker to check the victim’s country name.

Answer: http://ip-api.com/json/

Task 16

After getting the country code or country name of the victim machine, the malware checks some country codes and a country name. In case of the country name, if the name is matched with the victim machine’s country name, the malware terminates itself. What is the country name it checks with the victim system?

In the same class, at the very beginning, I found the GetSNG method, where the codes and the name of the country for which the software terminates its operation were located (Fig. 21).

Fig. 21. The country name for which the software terminates its operation.
Fig. 21. The country name for which the software terminates its operation.

Answer: Russia

Task 17

As an anti-debugging functionality, the malware checks if there is any process running where the process name is a debugger. What is the debugger name it tries to check if that’s running?

The Client.Anty_Analisys namespace immediately caught my attention. In line 17, I found the answer to the question (ironically, I am currently analyzing this binary with the same tool :)) (Fig. 22).

Fig. 22. Detected debugger name.
Fig. 22. Detected debugger name

Answer: dnSpy

Task 18

For persistence, the malware writes a Registry key where the registry key is hardcoded in the malware in reversed format. What is the registry key after reversing?

The EmpireClient.exe code is written very clearly, so finding the namespace responsible for persistence was no problem. In the Client.Install namespace, in line 54, I found the reversed registry name. It was the only occurrence, so it was very easy to locate (Fig. 23).

Fig. 23. Detected registry name.
Fig. 23. Detected registry name

Answer: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\

Task 19

The malware sets a scheduled task. What is the Run Level for the scheduled task/job it sets?

In the same class, a few lines above (line 42), I found the answer (Fig. 24).

Fig. 24. Detected run level for the scheduled task.
Fig. 24. Detected run level for the scheduled task.

Answer: highest