HTB Sherlock - OpTinselTrace-5 Writeup

Sep 16, 2024 7 min read

Sherlock Scenario

You’ll notice a lot of our critical server infrastructure was recently transferred from the domain of our MSSP - Forela.local over to Northpole.local. We actually managed to purchase some second-hand servers from the MSSP who have confirmed they are as secure as Christmas is! It seems not, as we believe Christmas is doomed, and the attackers seemed to have the stealth of a clattering sleigh bell, or they didn’t want to hide at all!!!!!! We have found nasty notes from the Grinch on all of our TinkerTech workstations and servers! Christmas seems doomed. Please help us recover from whoever committed this naughty attack! Please note - these Sherlocks are built to be completed sequentially and in order!

Artifacts

To solve the task, we received the following files:

DANGER.txt - contains a warning and the password to extract the archive encrypted_files_suspicious_file.zip,
encrypted_files_suspicious_file.zip - contains files encrypted by ransomware as well as the ransomware itself,
DC01.northpole.local-KAPE.zip - contains artifacts collected from the compromised server using the KAPE software.

In total, we have 762 files available to solve the task.

Solution

Task 1

Which CVE did the Threat Actor (TA) initially exploit to gain access to DC01?

At first, I was looking for a starting point. After reviewing all the artifacts, I decided that logs would be a good place to begin my analysis. Since I didn’t have a clearly defined goal yet, I decided to use the “hunt” option in the Chainsaw tool. I downloaded the Sigma rules from this repository and started the search.

The initial results contained a huge number of events, making it difficult to find relevant information. So, I decided to narrow down the information by using the command ./target/release/chainsaw hunt --skip-errors ../htb/Logs -s ../sigma/ --mapping mappings/sigma-event-logs-all.yml --log >logs.txt to create a text file with the events. The file contained 58,650 lines, so manual review was not feasible. I then began filtering the results using the grep tool, removing entries that were not significant. By using the command cat logs.txt | grep -vE "User Logoff Event|Uncommon New Firewall Rule Added In Windows Firewall Exception List|Firewall Rule Modified In The Windows Firewall Exception List", I was able to significantly reduce the list of results. While reviewing the list, one entry caught my attention: Possible DC Shadow Attack (Fig. 2).

I thought this might be the information I was looking for. Next, I decided to find out more about this rule and searched for additional information on Google. After entering the phrase Possible DC Shadow Attack cve, I immediately noticed information about a CVE related to this attack (Fig. 3).

Fig. 3. Found CVE associated with the suspicious activity <code>Possible DC Shadow Attack</code>. — Fig. 3. Found CVE associated with the suspicious activity `Possible DC Shadow Attack`.

Answer: CVE-2020-1472

Task 2

What time did the TA initially exploit the CVE? (UTC)

Analyzing the behavior of the CVE-2020-1472 vulnerability, I began searching for unusual activity that might have occurred. At 2023-12-13T09:25:22.529195+00:00, the first Mimikatz execution was detected, which suggests that the attacker already had access to the server. A few lines earlier, I found information about the installation of new software. Even earlier, at the same time, there was a logon event, which, according to the information in the CVE description, is the final phase of the exploit (Fig. 4).

Answer: 2023-12-13 09:24:23

Task 3

What is the name of the executable related to the unusual service installed on the system around the time of the CVE exploitation?

Once I had a starting point, the time when the attacker began their activities on the compromised server, I could include it in further searches. To find the name of the file of the new service, I began by analyzing event number 7045, which provides information about the installation of new software. The command ./target/release/chainsaw search -t 'Event.System.EventID: =7045' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" returned only one result, which turned out to be the answer (Fig. 5).

Answer: hAvbdksT.exe

Task 4

What date & time was the unusual service start?

In the previous task, I not only obtained the name of the file that was executed but also the name of the service. I refined my search query to ./target/release/chainsaw search 'vulnerable_to_zerologon' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" and got three results. The first result referred to a request to start the service, the second to its execution, and the third to its stop. The correct answer was the second result, which was the execution (Fig. 6).

Fig. 6. Time of the unusual service start.

Answer: 2023-12-13 09:24:24

Task 5

What was the TA’s IP address within our internal network?

I once again used the timestamp to narrow down the results and then searched for all 4624 events related to successful user logins using the command ./target/release/chainsaw search -t 'Event.System.EventID: =4624' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23". In the second result, I found the attacker’s IP address (Fig. 7).

Answer: 192.168.68.200

Task 6

Please list all user accounts the TA utilized during their access. (Ascending order)

Knowing the attacker’s IP address, I used it to search the logs again. With the command ./target/release/chainsaw search '192.168.68.200' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" | grep TargetUserName | sort | uniq, I listed the user accounts that the attacker used. I excluded the usernames ANONYMOUS LOGON and DC01 because the attacker failed to log in to them. Only two unique accounts remained: Administrator and Bytesparkle (Fig. 8).

Fig. 8. User accounts used by the attacker.

Answer: Administrator, Bytesparkle

Task 7

What was the name of the scheduled task created by the TA?

At first, I tried to find log events related to the creation of a new task, but my searches were unsuccessful. Therefore, I decided to search in the directory DC01.northpole.local-KAPE/uploads/auto/C%3A/Windows/System32/Tasks. Since the task configuration files are binary, I combined their contents into a single text file using the command find . -exec cat {} \; > ../tasks.txt. Then, in a text editor, I searched for tasks created after the attacker gained access. It turned out that there was only one such task (Fig. 9).

Fig. 9. The name of the task created by the TA.

Answer: svc_vnc

Task 8

Santa’s memory is a little bad recently! He tends to write a lot of stuff down, but all our critical files have been encrypted! Which creature is Santa’s new sleigh design planning to use?

To solve the task, we also received several files that were encrypted, along with a suspicious DLL file. As a first step, I decided to inspect the contents of the DLL using the strings command. While reviewing the output, just after the note’s text, I noticed a string EncryptingC4Fun!, which I assumed to be the password needed to decrypt the files. A little further down, after the list of extensions, I spotted another interesting string indicating that the XOR operation had failed (Fig. 10).

Fig. 10. Analysis of the malicious file contents using the <code>strings</code> command. — Fig. 10. Analysis of the malicious file contents using the `strings` command.

Before proceeding with further analysis and investigation of how the Not Petya malware worked, I decided to try the simplest method. I selected the file topsecret.png.xmax for testing. I encoded its contents to base64, then pasted it into CyberChef. I used filters to decode from base64 and applied an XOR operation with the previously detected password. Finally, I selected the option for CyberChef to detect the file type. To my surprise, the tool correctly recognized the file as a PNG image (Fig. 11).

Fig. 11. Successful ‘decryption’ of the file. — Fig. 11. Successful ‘decryption’ of the file

I downloaded the “decrypted” file from CyberChef, and upon opening it, I saw an image depicting Santa’s new sleigh design with a unicorn (Fig. 12).

Fig. 12. Contents of the file topsecret.png.

Answer: Unicorn

Task 9

Please confirm the process ID of the process that encrypted our files.

I must admit that finding the answer to this question took me quite some time. Initially, I tried searching for a list of processes in the files provided for the task. I also searched through Windows Defender logs, but I didn’t find anything useful there either. Finally, I had the idea to try the simplest solution and search the logs for the string xmax, which appeared in the names of encrypted files. Using the command ./target/release/chainsaw search 'xmax' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23", I found a list of files that were encrypted, along with the process ID responsible for the encryption (Fig. 13).

Fig. 13. Process ID that encrypted the files.

Answer: 5828