Tryhackme Carnage Walkthrough

Eric Fischer from the Purchasing Department at Bartell Ltd has received an email from a known contact with a Word document attachment. Upon opening the document, he accidentally clicked on “Enable Content.” The SOC Department immediately received an alert from the endpoint agent that Eric’s workstation was making suspicious connections outbound. The pcap was retrieved from the network sensor and handed to you for analysis.

Carnage is a defense focused room designed from the perspective of a SOC department. One of the employees from the purchasing department by the name of Eric Fischer who upon receiving a suspicious Word document enabled macros by clicking “Enable Content”. The SOC department then received the alert from an endpoint agent from the compromised workstation making connections outbound. Our task is to then review a packet capture to uncover clues about the malicious activity.

Task 1: Scenario

Our virtual machine is directly tied to the THM room. Simply select the start machine button and a split view machine should boot up with all the required tools to complete the room. Let’s begin.

Task 2: Traffic Analysis

To officially begin investigating, our virtual machine is spun up in Ubuntu/Linux with tools like Wireshark already installed and our pcap file is designated in our Desktop, where the “Analysis” folder will contain our pcap. Once inside this folder, our pcap “carnage.pcap” can be opened with a simple double click and ready for the traffic to be analyzed.

Once Wireshark opens, our traffic is displayed. Immediately, our first question points us to the first set of data we need to establish a few facts. Our objective is to find the time and date our malicious actor gained connection.

We can filter out this packet by only viewing http data. By inserting http as our filter we can take a look at http data that can contain GET, POST, and OK responses.

Immediately, a http GET request is shown.

The first GET request was made to the designated destination IP where a zip file was downloaded. You can view the date and time by looking at the time tab in Wireshark. Although our time is displayed it’s not in the correct format.

This can be changed by simply selecting the View tab, then navigating to Time Display Format and selecting the correct format asked by THM.

Our tab is now formatted correctly displaying the frame time.

You can copy the filter by right-clicking and selecting Copy→ As Filter, which will then be sent to the clipboard in the left/middle section of the virtual machine with a little arrow, where we can copy and paste from the virtual machine.

The time tab is now copied and sent to the clipboard with our answer in the correct time format.

Question 1: What was the date and time for the first HTTP connection to the malicious IP?

The connection was first made by the malicious IP in the first GET request we analyzed.

With our connection’s date and time now being identified, the same packet can tell us more information about what occurred by following the TCP stream. Since HTTP data uses TCP as its transport protocol, we can view the request and responses being made.

To follow a TCP stream, simply right click a packet, select the Follow tab → Follow TCP Stream

From following the stream of the first packet, we can see the full stream conversation where we see the GET request of the file that was downloaded as well as the domain where the file was being hosted on.

Question 2: What is the name of the zip file that was downloaded?

Following the TCP stream displays the GET request to /incidunt-consequatur/ with the name of the file downloaded.

Question 3: What was the domain hosting the malicious zip file?

Below the GET request displays the name of the domain that’s hosting the malicious file.

Scrolling down to view more of the existing stream conversation, an HTTP OK response code, indicating a successful response to the GET request was made.

Question 4: Without downloading the file, what is the name of the file in the zip file?

The name of the malicious file used by the attacker used to enable macros is displayed in the same stream. Looking at the HTTP/1.1 OK status code gives us this information.

By looking at this http response code, we get to view the name of the server as well as the version. Looking further, we can see the contents of the zip file as well as the name.

Question 5: What is the name of the webserver of the malicious IP from which the zip file was downloaded?

Looking at the same stream, we see the name of the web server looking at the line beginning with server:

Question 6: What is the version of the webserver from the previous question?

The version of the web server can be found looking at the line starting with x-powered by:

Great! We’ve established a set of hard facts simply enumerating what the exact file our buddy Eric downloaded, the name of the web server as well as the version, the name of the zip file first downloaded, and the domain attached to the host through just a few steps. Let’s keep rolling. ;D

Moving forward with our investigation, THM gives us a hint to narrow our search down to pinpoint a set of domains that downloaded malicious files onto the victim workstation. We can solely use the full https traffic with the time frame to display our results but that would still display too many packets. Instead, we can narrow our search down to just a few packets using a simple filter:

tls.handshake.type==1 and (frame.time >= “2021–09–24 16:45:11”) && (frame.time <= “2021–09–24 16:45:30”)

Although it may look confusing at first, it’s really simple when broken down:

tls.handshake.type

• Since http(s)uses encryption for traffic to be secure, in this case, our network uses tls v1.2 as it’s encryption protocol. Older versions would use ssl.
• We use ==1 to specify the beginning of a tls handshake, where the client sends a “hello” to the server.
• SEE: TLS Handshake to see how it works.

and

• Is a simple operator that means the start of a new filter expression

frame.time

• Is used to specify a specific time in a pcap file, in this case, THM gives us two time frames to narrow our filter.
• Since we are analyzing two frames we use &&
• NOTE: Take a look at the mathematical operators that I use, the reason >= and <= are used is to specify the time frame as in between. We change these operators depending on the use case for the time frame.
• SEE: Filter for a specific time frame in Wireshark. | Securitron Linux blog.

With our filter applied, our pcap is filtered to just a few results:

Question 7: Malicious files were downloaded to the victim host from multiple domains. What were the three domains involved with this activity?

We can see the 3 domains by looking at the few packets from the filter applied. You can also view the domains in VirusTotal to weed out the malicious domains.

Question 8: Which certificate authority issued the SSL certificate to the first domain from the previous question?

Since we found the first domain with the filter we applied, we can follow the TCP stream conversation to view the certificate.

Question 9: What are the two IP addresses of the Cobalt Strike servers? Use VirusTotal (the Community tab) to confirm if IPs are identified as Cobalt Strike C2 servers. (answer format: enter the IP addresses in sequential order)

Cobalt Strike C2 servers are adversary software designed specifically for red teams. This blog post from Mandiant goes into great detail outlying the components of a Cobalt Strike server. A simple read can make you confident in understanding how malicious actors can use this software for their advantage.

SEE: Defining Cobalt Strike Components So You Can BEA-CONfident in Your Analysis | Mandiant

There are many ways an analyst can identify these types of beacons, whether through plaintext beacon logs, java serialized bins, watermarks, public keys, GET and POST requests, etc. are all invaluable artifacts a analyst can interpret for their investigation.

For the sake of this THM room, our goal is to use VirusTotal as a way to seek artifacts through the use of a community-driven database where users can submit their findings. We can essentially check IP’s into the VirusTotal database to see if a user has already identified Cobalt Strike servers.

We can view conversations in Wireshark of all IP’s conversing with each other as a method to check for IP’s. Since Cobalt Strike communicates through GET and POSTS requests, we can filter our pcap file to narrow our search.

We use: http.request.method== “GET”

Our filter is now applied. We can then open up the conversations tab by clicking Statistics → Conversations

From here, we can simply test the selection of IP’s listed to VirusTotal to see which IP’s are identified as Cobalt Strike C2 servers. Remember that C2 servers communicate through GET and POST requests, so you can look at the IP’s that are constantly communicating to weed out the proper IP’s.

Once we check the Community tab in VirusTotal we see our target information.

Question 10: What is the Host header for the first Cobalt Strike IP address from the previous question?

From looking at the Community tab once again, you can see the name of the host header.

Question 11: What is the domain name for the first IP address of the Cobalt Strike server? You may use VirusTotal to confirm if it’s the Cobalt Strike server (check the Community tab).

The domain name can be found by looking at the C2 server line from the community tab. It can also be found by looking at the Details tab where “Last HTTPS Certificate” is located.

Question 12: What is the domain name of the second Cobalt Strike server IP? You may use VirusTotal to confirm if it’s the Cobalt Strike server (check the Community tab).

You can follow the same steps as in Question 11, where you look at the Details or Community Tab to see the domain name.

Question 13: What is the domain name of the post-infection traffic?

Our next question asks us to take a look at the POST traffic. Similar to the GET filter we applied we use:

http.request.method== “POST”

We can follow the TCP stream of the first packet to see the entire conversation.

Question 14: What are the first eleven characters that the victim host sends out to the malicious domain involved in the post-infection traffic?

Looking at the same stream conversation will display the name of the host.

Question 15: What was the length for the first packet sent out to the C2 server?

We can take a look at the length tab from the filter we applied to see the packet length.

Question 16: What was the Server header for the malicious domain from the previous question?

Looking a bit further down from the same TCP stream we analyzed, we can see the name of the server.

Question 17: The malware used an API to check for the IP address of the victim’s machine. What was the date and time when the DNS query for the IP check domain occurred? (answer format: yyyy-mm-dd hh:mm:ss UTC)

Since our question is asking to take a look at DNS queries that use an API to check for the IP addresses on the victim workstation, we can filter our packet to DNS alongside with our packet to contain the word “api”. Our filter should look like this:

dns && frame contains “api”

With our filter ready, the filter will segment through the entire pcap file looking for a frame that contains the word api in any DNS queries.

Taking a look at packet NO. 24,147 is a point of interest. Within this packet, we see information pertaining to an api being used. The first query with this info contains the correct time.

Question 18: What was the domain in the DNS query from the previous question?

Taking a look at the info tab or following the UDP(dns) stream will show the domain name.

Question 19: Looks like there was some malicious spam (malspam) activity going on. What was the first MAIL FROM address observed in the traffic?

We can specify spam activity by using frame contains once again to specify our spam.

frame contains “MAIL FROM”

Looking at the first MAIL FROM address and following the TCP stream conversation, the address of the sender is displayed

Question 20: How many packets were observed for the SMTP traffic?

We can filter our traffic to smtp, from there we can look at the bottom of the Wireshark browser that displays some stats of the traffic you are viewing to get our last and final flag.

In conclusion, I have acquired valuable knowledge by thoroughly examining malicious Cobalt Strike C2 server traffic and spam. Through careful analysis, I have uncovered the employee’s action of opening a malicious xls attachment, enabling its content, and subsequently receiving malicious connections on the workstation. By utilizing Wireshark, I successfully traced the relevant artifacts and assembled a comprehensive investigation. I trust that my writeup has effectively conveyed the process of alert investigation and artifact discovery. Thank you for your attention!