TryHackMe on Drew Arpino (Stumblesec)

TryHackMe — Monday Monitor Challenge Room Walkthrough

Mon, 02 Mar 2026 00:00:00 +0000

TryHackMe: Monday Monitor Challenge Room Walkthrough

Wazuh SIEM Forensics: Investigating Persistence, Credential Dumping, and Exfiltration with Atomic Red Team.

Image Credit: https://tryhackme.com/room/mondaymonitor

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Monday Monitor blue team challenge from TryHackMe, you’re in the right place. This room is all about the investigative side of cyber defense, blending endpoint logging, analyzing SIEM events, with a sprinkle of adversary emulation to keep things interesting.

In this challenge, we’re stepping into the role of a cyber sleuth brought in to help Swiftspend Finance level up their security program. Several controlled tests were executed across the environment, and it’s our job to work through the evidence, validate detections, and piece together the full attack chain. Fortunately, we’re given access to their Wazuh SIEM dashboard that’s ingesting Sysmon data from the endpoint. That gives us a rich dataset of process activity, command lines, network connections, and behavioral signals to work with.

We’ll be using Wazuh’s security events module, saved searches, field filtering, and a bit of intuition to uncover everything from initial access to credential dumping and exfiltration. Along the way, tools like CyberChef help us decode suspicious payloads, and references to MITRE ATT&CK anchor our analysis in real‑world tactics, techniques, and procedures.

I’ll walk through each step clearly, and by the end you’ll have a solid sense of how to approach similar detection‑driven investigations using Wazuh. Sounds like fun, right? Let’s go!

And, hey, if you find this walkthrough helpful — whether it levels up your skills, gets you over a stumbling block, or just serves as a handy reference — please consider following me to get more content like this.

Thanks for reading and going on this investigation with me!

Challenge Scenario:

Swiftspend Finance, the coolest fintech company in town, is on a mission to level up its cyber security game to keep those digital adversaries at bay and ensure their customers stay safe and sound.

Led by the tech-savvy Senior Security Engineer John Sterling, Swiftspend’s latest project is about beefing up their endpoint monitoring using Wazuh and Sysmon. They’ve been running some tests to see how well their cyber guardians can sniff out trouble. And guess what? You’re the cyber sleuth they’ve called in to crack the code!

The tests were run on Apr 29, 2024, between 12:00:00 and 20:00:00. As you dive into the logs, you’ll look for any suspicious process shenanigans or weird network connections, you name it! Your mission? Unravel the mysteries within the logs and dish out some epic insights to fine-tune Swiftspend’s defences.

Question 1: Initial access was established using a downloaded file. What is the file name saved on the host?

For this room, we’re all about Wazuh, the open source security information event management (SIEM) platform. Swiftspend Finance recently paired Sysmon on the endpoint with Wazuh for centralized security monitoring. Let’s get into these logs and see what we can find.

To get started, launch the provided virtual machine and connect to the Wazuh dashboard in your web browser using the URL from the challenge. Once you’re logged in, navigate to the Security events module by selecting its icon on the dashboard.

Wazuh: Navigating to the Security events

Next, load the saved query Monday_Monitor to pull up the relevant logs for this challenge.

Wazuh: Loading the Monday_Monitor saved query

Once the query loads, we need to set the correct time window for when the security engineering team ran the tests. According to the challenge scenario:

The tests were run on Apr 29, 2024, between 12:00:00 and 20:00:00.

After clicking the Show dates button, set the time range options to Absolute and select the correct start and end timestamps.

Wazuh: Setting the date/time

With the groundwork complete, we can finally start digging into data that falls within the scope of the test.

Wazuh: Setup completed

To answer Question 1, we need to identify the downloaded file used for initial access. Since this is a controlled red team test conducted by Swiftspend’s Security Engineering team, and not a typical scenario where a user accidentally downloads and executing a malicious file, our first move is to explore the built‑in detection rules.

Click the + Add Filter button beneath the search bar. For filtering, set the field to rule.description with the operator is. In the value dropdown, look through what detection rules triggered during the test. Here, the Microsoft Office Product Spawning PowerShell rule stands out as a likely indicator that a malicious document might have established the initial access.

Wazuh: Filtering Microsoft Office Product Spawning Windows shell rule.descriptions

Before we dig further, let’s make the results easier to read. From the available fields on the left, add data.win.eventdata.commandLine to the selected fields. This lets us view process command lines without expanding individual records. With this in place, we can focus on events where Office spawned PowerShell and quickly see what each command executed.

Now we’ve got the right query, the right timing, the correct rule filter, and the process command line displayed. The last step is to identify download activity that reveals the file name. To do that, search for HTTP in the search box.

Wazuh: Searching for HTTP events to identify the downloaded file used for initial access

Perfect. This narrows the results down to two hits showing that powershell.exe downloaded SwiftSpend_Financial_Expenses.xlsm.

Questions 2 & 3:

What is the full command run to create a scheduled task?

What time is the scheduled task meant to run?

Our next tasks are to identify scheduled task creation and determine when that task is scheduled to run. This is important because creating a scheduled task is a common persistence technique, and spotting these entries in Wazuh gives us a strong signal that the test is attempting to plant something on the host. Let’s get to work!

First, Clear the rule.description filter we added in Question 1. To keep things simple, use the search field to look for schtasks.exe, the command‑line tool used to “create, delete, query, change, run, and end scheduled tasks on a local or remote computer”.

This search returns four results, and in the command line we can clearly see that schtasks.exe is being used to create a new scheduled task. Copying that full line gives us the answer to Question 2:

Wazuh: Identifying schtasks.exe activity

"cmd.exe" /c "reg add HKCU\SOFTWARE\ATOMIC-T1053.005 /v test /t REG_SZ /d cGluZyB3d3cueW91YXJldnVsbmVyYWJsZS50aG0= /f & schtasks.exe /Create /F /TN "ATOMIC-T1053.005" /TR "cmd /c start /min \"\" powershell.exe -Command IEX([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String((Get-ItemProperty -Path HKCU:\\SOFTWARE\\ATOMIC-T1053.005).test)))" /sc daily /st 12:34"

And conveniently nestled within this same command is the answer to Question 3. The /st argument specifies the scheduled time, and here it’s set to: 12:34.

This command line also hints at the tooling behind the test: Atomic Red Team. We can see the test path ATOMIC-T1053.005, which maps to the MITRE ATT&CK technique T1053.005 Scheduled Task/Job: Scheduled Task. Atomic tests like this are often used to validate detections, which fits perfectly with Swiftspend’s testing scenario.

Question 4: What was encoded?

Next up, we need to figure out the contents of the encoded string we saw in the previous command. In addition to creating a scheduled task, the command also adds a registry value named test under the key HKCU\SOFTWARE\ATOMIC-T1053.005. That value is stored as a REG_SZ string:

cGluZyB3d3cueW91YXJldnVsbmVyYWJsZS50aG0=

Wazuh: Identifying a Base64 encoded string in the command line

Later in the command, we see PowerShell calling FromBase64String, which tells us the value stored in the registry is Base64 encoded. So now we have the encoded string and the method used to decode it. All we need to do is decode the Base64 manually to uncover the actual payload.

One easy option is to copy the encoded string and paste it into CyberChef, the popular web‑based data manipulation tool. Once the string is in the input field, apply the From Base64 operation, and let CyberChef do its thing.

CyberChef: Decoding the Base64 encoded string

Voila! The decoded value reveals a simple ping command pointed at an external website, likely used as a heartbeat to test whether the host has outbound network connectivity: A nice find tucked away in the registry.

Question 5: What password was set for the new user account?

Moving right along, we’re now looking for evidence of a user account being created or modified, specifically, the password that was set for that account. No problem!

From the earlier questions, we already know the Atomic Red Team tests are relying on PowerShell to execute their activities. Let’s follow that thread and switch our filter from schtasks.exe to powershell.exe.

With this filter applied, we get a higher‑level view of all commands executed by PowerShell in the data.win.eventdata.commandLine field. While this is valuable context, we don’t need everything just yet. We only need the entry where a user account’s password is set.

Scroll through the results and you’ll stumble across a line showing PowerShell spawning the classic [net user](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user) command to modify Windows user accounts.

Wazuh: Identifying modification of the guest account

In this case, we see the guest account being updated, and its password is set to: I_AM_M0NIT0R1NG

Question 6: What is the name of the .exe that was used to dump credentials?

To answer Question 6, we need to identify the executable used to dump credentials on the device. With the powershell.exe filter still applied from the last question, you might’ve noticed several suspicious entries mixed in with the command output. A couple of minutes after the modification of the guest account, we stumble across something especially interesting: a command that references an output file named lsass.dmp.

Wazuh: Identifying OS Credential Dumping activity

Before we dive into the executable itself, let’s review why LSASS is such a high‑value target. According to Microsoft Learn, LSASS, or the Local Security Authority Subsystem Service:

Stores credentials in memory on behalf of users with active Windows sessions. The stored credentials let users seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without reentering their credentials for each remote service.

LSASS can store credentials in multiple forms, including:

Reversibly encrypted plaintext.

Kerberos tickets (ticket-granting tickets (TGTs), service tickets).

NT hash.

LAN Manager (LM) hash.

Reexamining the command in the logs, we see that the Atomic Red Team test executed an executable named: memotech.exe

This binary is responsible for generating the lsass.dmp file. And if the command line hasn’t already given it away, memotech.exe looks a whole lot like a disguised version of Mimikatz, an infamous credential dumping tool frequently used in both red team simulations and real‑world attacks.

Question 7: Data was exfiltrated from the host. What was the flag that was part of the data?

Our final challenge is to identify the command used for data exfiltration and locate the classic TryHackMe flag hidden inside the exfiltrated content. We’ll keep the powershell.exe filter applied from the previous questions so we can stay focused on the Atomic Red Team activity.

Scrolling through the remaining entries in the testing data, we’re looking for a command that clearly suggests data exfiltration. We stumble into it as a newer result in the logs. The main giveaway (aside from the flag itself) is the structure of the command. It includes a URL for Pastebin, a commonly abused text‑sharing site attackers use to store exfiltrated data (MITRE ATT&CK T1567.003.)

Wazuh: The content of the data exfiltration command

Reading through the full command, we find the outbound request that sends content directly to Pastebin. Embedded inside that transmitted data is the TryHackMe flag we’re looking for.

With that, we’ve wrapped up our investigation into the security engineering team’s Atomic Red Team tests. Nice work crossing the finish line!

Conclusion:

How fun was that! A big thank you to TryHackMe for another awesome challenge.

This walkthrough was a great example of how endpoint visibility can make or break an investigation. By combining Wazuh and Sysmon, we were able to trace an entire attack simulation chain from initial access to persistence, credential dumping, and data exfiltration. It highlighted endpoint monitoring and visibility is such a critical part of any defensive strategy.

As we moved through each question, we didn’t just follow the attacker’s activity. We also built a deeper understanding of how Wazuh presents data, how filtering and field selection guide analysis, and how small artifacts like encoded registry entries or scheduled task configurations can reveal much bigger things happening behind the scenes. Challenges like this are rewarding because each step builds naturally into the next, and the investigation feels both logical and engaging.

I chose this week’s challenge because even though I’m familiar with other SIEM platforms, I’d never actually used Wazuh. This was a great chance to learn the platform by testing it against an attack simulation and seeing how it handles real adversary techniques. It’s always satisfying when a controlled test lines up neatly with real‑world tradecraft, and Atomic Red Team makes that possible in such a clean and structured way. All in all, it was solid exposure to some new tooling and a good opportunity to get hands‑on time investigating activity inside a new SIEM environment.

Thanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we’re in this together!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

Challenge Link: https://tryhackme.com/room/mondaymonitor

Wazuh: https://wazuh.com/

Microsoft Learn — Schtasks.exe: https://learn.microsoft.com/en-us/windows/win32/taskschd/schtasks

Atomic Red Team GitHub: https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/Indexes/Indexes-Markdown/index.md

CyberChef: https://gchq.github.io/CyberChef/

Microsoft Learn — net user: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user

MITRE ATT&CK — OS Credential Dumping: LSASS Memory (T1003.001): https://attack.mitre.org/techniques/T1003/001/

MITRE ATT&CK — Mimikatz (S0002): https://attack.mitre.org/software/S0002/

MITRE ATT&CK — Exfiltration Over Web Service: Exfiltration to Text Storage Sites (T1567.003): https://attack.mitre.org/techniques/T1567/003/

TryHackMe — Tempest Challenge Walkthrough

Mon, 22 Dec 2025 00:00:00 +0000

TryHackMe | Tempest | Challenge Walkthrough

An Endpoint Forensic Investigation Challenge Using SysmonView, EvtxECmd, Brim, & CyberChef.

Image Credit: https://tryhackme.com/room/tempestincident

Introduction:

Think you’ve got what it takes to tame the Tempest?

If so, you’ve stumbled on the right blog! Welcome to my weekly walkthrough — a comprehensive (but spoiler-free) guide to the Tempest challenge from TryHackMe. This room is the first of the capstone challenges for their SOC Level 1 learning path.

For this challenge, we’re putting on our incident response hats and putting our skills to the test. The Tempest workstation has been compromised, and it’s up to us to calm the storm. We’re given three artifacts to dig into and piece together what happened.

This is a sprawling, in-depth case that will push us to think creatively and challenge our skills in endpoint and network analysis. We’ll pivot between tools and reconstruct the full attack chain — from analyzing malware execution all the way through network discovery, command and control, privilege escalation, and persistence.

For the analysis, we’ll use a mix of SysmonView, Eric Zimmerman’s EvtxECmd and Timeline Explorer, Brim, CyberChef, and even VirusTotal to validate our findings.

I’ll walk through each step clearly, and by the end, you’ll have a solid understanding of how to approach similar investigations in the wild. I don’t want to ruin any of the fun, so this walkthrough will not contain spoilers — but please use it as a reference and enjoy! Now, let’s get into it.

And if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.

Thanks for reading and going on this investigation with me!

Challenge Scenario:

This room aims to introduce the process of analysing endpoint and network logs from a compromised asset. Given the artefacts, we will aim to uncover the incident from the Tempest machine. In this scenario, you will be tasked to be one of the Incident Responders that will focus on handling and analysing the captured artefacts of a compromised machine.

Task 3: Preparation — Tools and Artifacts

Questions 1, 2, & 3:

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

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

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

Following the theory from Tasks 1 & 2, which are not covered in this blog, we can now get started and leap into action. Our first set of questions is to determine the unique SHA256 hash of each artifact that we’ll use throughout the rest of the investigation.

To perform this task, we can leverage the Get-FileHash cmdlet in PowerShell. From the Incident Files directory, run the command below:

Get-FileHash *

This will compute the hash for all files in the directory using the default algorithm, which is SHA256.

PowerShell: Getting the file hashes

Task 4: Initial Access — Malicious Document

Now we’re getting to work! The first true challenge starts here in Task 4. For this task, our job is to assess a malicious document used to compromise the Tempest device. From the available artifacts, we’ll select the Sysmon event logs. Since this is a capstone challenge for the SOC Level 1 analyst track, I’ll assume you’re already familiar with Sysmon.

The fun part is that instead of relying solely on the Windows Event Viewer, we’ll work a little smarter by leveraging SysmonView, a third-party utility designed for visualizing Sysmon event logs in XML format.

But first, we’ll need to convert all the events contained within Sysmon.evtx to XML for parsing. To do this, open the Sysmon.evtx file in Event Viewer. Then, press Save All Events As…, change the file format to XML, and save.

Event Viewer: Exporting Sysmon logs as XML

Now, we can pivot and open SysmonView, which is conveniently pinned to the taskbar of the analysis environment. Once it’s open, press File > Import Sysmon XML Events, and load up the events so we can get started.

Investigation Guide:

To aid with the investigation, you may refer to the cheatsheet crafted by the team applicable to this scenario:

Start with the events generated by Sysmon.

EvtxEcmd, Timeline Explorer, and SysmonView can interpret Sysmon logs.

Follow the child processes of WinWord.exe.

Use filters such as ParentProcessID or ProcessID to correlate the relationship of each process.

We can focus on Sysmon events such as Process Creation (Event ID 1) and DNS Queries (Event ID 22) to correlate the activity generated by the malicious document.

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

The first artifact we need to hunt for is the malicious document itself. A good place to start is filtering the logs for Sysmon Event ID 11, which corresponds to File Creation events. Using SysmonView, select the All Events View tab at the bottom, then drag the Event Type column to the filter bar and expand Event Type: File Created.

This displays all the File Creation events in a neat table. Scroll down to the oldest results to start building a timeline.

Once we expand the early events, we’ll find the evidence we need: the creation of a document file from chrome.exe. Checking the target file name will reveal the file name and path, suggesting it was downloaded from a website.

SysmonView: Identifying the malicious document

Questions 2 & 3:

What is the name of the compromised user and machine?

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

Next, we’ll need to collect some information about the environment, including the machine name, compromised user, and the process ID (PID) of the malicious document.

One approach to getting this information in one go is to remove the Event Type filter and search for the document’s name in the search box at the top. This filters the Sysmon events related to this specific file name. This leads us to a Process Create (Event ID 1) for WINWORD.EXE.

SysmonView: Identifying the Microsoft Word PID

As a bonus, by identifying this event, we also get all the metadata we need to answer both Questions 2 & 3!

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

The wording of Question 4 is a little confusing since there wasn’t any domain reference in Question 3 that I found. It’s all good — we can infer what we’re looking for: the IP address of a malicious domain contacted by WINWORD.EXE.

For this, jump to the Process View tab in SysmonView and scroll down the process list to select WINWORD.EXE. Then click the image path in the box below, and finally click both session GUIDs. This gives us a clean diagram of the relationships between events tied to the process—very neat!

Scrolling through the events, we’ll stumble across a suspicious-looking domain in the DNS query, along with a corresponding destination IP address. Correlating the suspicious domain with the IP address is good, but through additional threat intelligence or process of elimination, we can also determine that this IP is malicious. We’ll see more of that later!

SysmonView: Identifying the malicious IP address

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

Now Question 5 is a little tricky because you might notice our visualization doesn’t show any child process like PowerShell that would give us a clue. Not to worry — we’ll try a different approach and bust out some of Eric Zimmerman’s tools: EvtxECmd and Timeline Explorer.

The idea is to use EvtxECmd to parse the Sysmon.evtx file and produce a CSV file that we can load into Timeline Explorer to view and filter the data. This makes it easier to examine the relationship between the Microsoft Word process and any child processes spawned by the malware. Fortunately, both tools are already built into our environment and can be found in the following directories:

C:\Tools\EvtxECmd\EvtxECmd.exe C:\Tools\TimelineExplorer\TimelineExplorer.exe

First, open PowerShell and run the command below to execute EvtxECmd and output the results to CSV:

C:\Tools\EvtxECmd\EvtxECmd.exe -f “C:\Users\user\Desktop\Incident Files\sysmon.evtx” –csv “C:\Users\user\Desktop\Incident Files” –csvf Sysmon.csv

PowerShell: Executing EvtxECmd

Now comes the fun part. Open Timeline Explorer and load the new CSV file. We’ll need to do a few things here:

Filter on the EventID column for 1 (process creation)
Enter the parent process ID of WINWORD.EXE (496) into the PayloadData5 field to show any child processes we didn’t see in SysmonView
Check the Executable Info column for the first event chronologically

Timeline Explorer: Finding the encoded string

See the encoded blob following the FromBase64String function? That’s what we need to answer Question 5.

But we can take it a step further and decode it using something like CyberChef, which we’ll do for demonstration purposes. Within CyberChef, paste the encoded string into the input window. Then, add the From Base64 operation to the recipe.

CyberChef: Decoding the string

In the output, we’ll get some extremely helpful clues that we’ll use in Task 5.

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

Head back to the Timeline Explorer view and look closely — do you see anything unusual? The process executing the code is the Microsoft Support Diagnostic Tool (MSDT.exe), a legitimate diagnostic utility. Very strange.

Now that we have some of the puzzle pieces, let’s put them together. Let’s take to Google and see if there’s a known vulnerability where MSDT is called from Word to execute code.

We’ll immediately identify the following CVE from Microsoft:

A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.

Bingo! We’ve stumbled across exploitation of the famous “Follina” vulnerability, tracked as CVE-2022–.

Task 5: Initial Access — Stage 2 execution

Investigation Guide:

The Autostart execution reflects explorer.exe as its parent process ID.

Child processes of explorer.exe within the event timeframe could be significant.

Process Creation (Event ID 1) and File Creation (Event ID 11) succeeding the document execution are worth checking.

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

From the Base64 command we found in Task 4, Question 5, we can start to get an idea of where the file was written:

$app=[Environment]::GetFolderPath(‘ApplicationData’);cd “$app\Microsoft\Windows\Start Menu\Programs\Startup”

To understand the full path, we just need to first identify where the $app variable is pointing and then append the rest of the path that we see in the cd command. One approach is to declare the variable in PowerShell within the analysis environment to see what happens, and then transpose the path into the victim’s environment—check out what I mean below:

PowerShell: Testing the $app variable

The $app variable resolves to the ApplicationData folder for our user account. So, we need to change the username to the victim account name we identified in Task 4, Question 2 and put it all together to get our answer:

C:\Users<REDACTED>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Dropping the payload into this folder means the executable will run each time the victim user logs in, since it’s placed in the Startup directory. This is a common way a threat actor establishes persistence on a system.

Now that we’ve discovered where the payload is executed from, let’s dig in and figure out what it does. Focusing on the next steps of the investigation guide, we know the time of the file write was 17:13:35, and we need to look at events with explorer.exe as a parent.

Let’s jump back to SysmonView and visualize this with a handy diagram of all the events. Click the Hierarchy tab at the bottom of the window. Then, press Generate Diagram to spit out an incredibly helpful visual of the process relationships, which makes it a ton easier to identify child processes of explorer.exe.

SysmonView: Identifying suspicious PowerShell process

One of the child processes is powershell.exe, which is interesting, especially in the context of command execution. Let’s take a quick peek by opening the PowerShell box.

SysmonView: ProcessCreate Event Details for Powershell.exe

Inside, we’ll discover exactly what we need — the process command line of the payload. This tells us exactly what it does: download another binary, or second stage.

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

If we take a closer look at the command from the last question, we’ll discover that certutil was abused to download another .exe file via PowerShell. Let’s dig into it more.

Close the window and review the diagram. Find the child process below powershell.exe on the diagram—that’s our Stage 2.

SysmonView: Identifying the Stage 2 binary

Double-click it to open the details and grab the file hash for our list of indicators.

SysmonView: ProcessCreate Event Details for the Stage 2 binary

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

With the name of the executable, an easy way to identify the command-and-control (C2) server is to step back to the Process View tab. Recall that we can search for the name of the second-stage binary and easily view its related network connections to the C2 server as captured by Sysmon.

From the relationships mapped here, we can infer that the DNS query event and TCP connections to port 80 represent a pair:

SysmonView: Process View of the Stage 2 binary

This provides us with the domain, IP address, and port used for command and control by the second stage. These will be incredibly valuable artifacts for the network traffic analysis in Task 6.

Task 6: Initial Access — Malicious Document Traffic

Investigation Guide:

Since we have discovered network-related artefacts, we may again refer to our cheatsheet, which focuses on Network Log Analysis:

We can now use Brim and Wireshark to investigate the packet capture**.**

Find network events related to the harvested domains and IP addresses.

Sample Brim filter that you can use for this investigation: __path=="http" "<malicious domain>"

Now that we’ve gotten a better idea of what the malicious document is, which vulnerability it exploits, what the second stage is, and what C2 infrastructure it connects with, it’s time to dig further into the network traffic. For this, we’ll make a detour and pivot to a second artifact: capture.pcap.

This is a network packet capture file that we can use to go deep into investigating the communication between the malware and the command-and-control server.

To start, we’ll use Brim (now called Zui) to process and visualize the packet data with some awesome built-in queries.

Brim Overview

Go ahead and open up Brim, which is already installed in the analysis environment, and drop the capture.pcap into the input window. Once it loads, we’ll get started.

Question 1: What is the URL of the malicious payload embedded in the document?

Now we already know some valuable information, including the malware hosting domain and IP address, the C2 URL, and the C2 IP address.

Remember back in Task 4, Question 4 we identified an IP address and domain embedded in the malicious document? Because we have most of the information already, this is a logical starting point since we’re looking for network URL information related to the stage-one malicious document.

Since we’re looking to identify a URL request, an easy way to do this is to leverage the built-in Brim query HTTP Requests to determine which URL is being connected to. This will display an easy-to-read table containing the results we need.

Scroll down to the section containing the IP address from Task 4, Question 4, and we can see all the requests to this URL. There are a lot of interesting files here, but the one we’re focused on is the first: index.html.

Brim: Identifying URLs related to the C2 IP address

Question 2: What is the encoding used by the attacker on the c2 connection?

Back in Task 4, Question 5, we determined that the attacker used Base64 encoding to obfuscate the payload within the malicious document. Could it be the same encoding for the C2 connection? Let’s check the network traffic to confirm.

Within our HTTP Requests view in Brim, scroll down to the entries with C2 IP address. Notice that the corresponding values in URI column contain long strings? We’ll use one of these to check if they are also Base64 encoded.

Brim: Identifying Base64 strings in the URI

Copy any one of these as a test and jump back into CyberChef, once again applying the From Base64 operation.

CyberChef: Decoding a Base64 encoded parameter

Confirmed! This shows us that the encoding is indeed Base64 — but more importantly, it might also indicate that some command return data is being exfiltrated via HTTP requests.

Questions 3 & 4:

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

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

Now the cool part: by discovering that each of these strings contains the results of the executed commands, we can also identify the parameter that contains those results.

Take a look at the URI and notice a common parameter and URL used by the binary. This parameter consistently appears in requests that include Base64-encoded data, strongly suggesting it’s being used to transmit command output back to the attacker — something we already suspected from the previous question.

Brim: Identifying the URL and the Parameter

Similarly, the URL path reveals where the binary retrieves its next command to execute. These two pieces, the parameter and the URL, are important indicators for understanding the attacker’s C2.

Question 5: What is the HTTP method used by the binary?

To confirm how the binary communicates with the C2 server, check the method column in the HTTP Requests view in Brim. This shows whether the request uses GET, POST, etc.

Brim: Identifying the HTTP method

The value in this column reveals the exact HTTP method the attacker used to retrieve commands and send data which is another important detail for understanding how the C2 channel operates.

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

To find this clue, we’ll pull back from the HTTP Requests query and search for the C2 IP in the Brim search box. Since we’re looking for a user agent, include the user_agent field in the query to surface unique results:

167.71.222.162 user_agent

Now scroll over to the user_agent column, and you’ll find another breadcrumb that reveals the programming language used to compile the binary.

Task 7: Discovery — Internal Reconnaissance

Investigation Guide:

To continue with the investigation, we may focus on the following information:

Find network and process events connecting to the malicious domain.

Find network events that contain an encoded command.

We can use Brim to filter all packets containing the encoded string.

Look for endpoint enumeration commands since the attacker is already inside the machine.

In addition, we may refer to our cheatsheet for Brim to quickly investigate the encoded traffic with the following filters:

To get all HTTP requests related to the malicious C2 traffic: _path=="http" "<replace domain>" id.resp_p==<replace port> | cut ts, host, id.resp_p, uri | sort ts

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

Remember in the last task how we discovered that the attacker uses the C2 binary to send the results of commands executed on the victim’s system? Now we’ll take a closer look at those commands and their outputs, decode them, and build a complete picture of what was run.

We’ll use the handy command provided in the investigation guide and plugin the relevant information we’ve already gathered during our case:

_path==“http” “resolvecyber.xyz” id.resp_p==80| cut ts, host, id.resp_p, uri | sort ts

Once the results load, we’ll see the encoded commands we’re going to work with. Press the Export button in Brim and save the results as a .csv file—mine is called results.csv.

Brim: Filtering the C2 results for export

Next, we need a quick way to decode the Base64 strings following the q parameter. While we could copy and paste each one into CyberChef, let’s automate this with a PowerShell script.

Full disclosure: GenAI was a big help here since regex still feels like black magic to me. But I say keep with the times and leverage the modern tools at our disposal as long as we verify the output is accurate.

Get-Content .\results.csv | ForEach-Object { if ($_ -match ‘q=([^,]+)’) { $encoded = $matches[1] $decoded = [System.Text.Encoding]::UTF8.GetString( [System.Convert]::FromBase64String($encoded) ) $decoded } }

Here’s what the script does:

Reads the results.csv file
Matches q= followed by the encoded string (Task 6, Question 3)
Extracts the Base64 string and decodes it into readable text

Open Notepad and save this as a .ps1 script (I called mine decode.ps1) and run it. The output gives us incredible insight into the attacker’s actions—and right at the top, you’ll find the password we’re looking for in the $pass variable.

PowerShell: Running the decode.ps1 script

Question 2: 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?

Let’s keep reviewing the output of the script to learn more about the attacker’s reconnaissance activity. We can see that they used netstat to enumerate the listening ports.

PowerShell: Identifying a listening remote access port

When we review the open ports listed, a quick lookup on the Speedguide.net Ports Database helps us identify their purpose. One port stands out because it’s associated with Windows Remote Management (WinRM). This service can allow remote shell via PowerShell remoting when it’s enabled and authenticated, which makes it a juicy target for attackers.

Question 3 & 4:

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?

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

Arriving at the bottom of the script during our review, we notice something interesting: the attacker downloads another binary named ch.exe using PowerShell Invoke-WebRequest (iwr) from the URL we identified earlier when analyzing the malicious document traffic.

PowerShell: Identifying another suspicious binary

Switching back to SysmonView, we can pivot to the Process view tab and select ch.exe. From there, we’ll look for the related process creation event. This event will reveal two critical pieces of evidence to answer Question 3 & 4:

The full command line used to establish the reverse SOCKS proxy connection
The SHA256 hash of the binary itself

SysmonView: Using the process view to identify the proxy connection stand up

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

Now that we have the SHA256 hash of the tool used to establish the proxy, let’s pivot to some external threat intelligence to see if we can identify the specific utility. In this case, we’ll use the VirusTotal platform.

Navigate to VirusTotal and submit the hash of ch.exe to check if it’s been seen before and gather additional intelligence. Right away, you’ll notice that the sample has been observed previously, with most anti-malware vendors detecting it as malicious. For the purposes of Question 5, focus on the family label provided by VirusTotal, it’s the key to identifying the tool.

https://www.virustotal.com/gui/file/8a99353662ccae117d2bb22efd8c43d7169060450be413af763e8ad7522d2451

This particular utility is designed for TCP/UDP tunneling over HTTP, a technique attackers often abuse to create covert channels and bypass network restrictions. This aligns perfectly with the behavior we observed earlier when the attacker stood up a reverse SOCKS proxy.

Question 6: 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?

Jumping back over to the SysmonView Hierarchy map, something stands out: remember in Question 2 we identified a port associated with a specific service that could be used for a remote shell? We’ll actually stumble across the process name wsmprovhost.exe for that same service right in the graph, along with another suspicious file and a chain of process creations. Interesting!

SysmonView: Using the hierarchy view to identify the authenticated service

This indicates that the remote management service was abused by the adversary and may have been used for further actions like lateral movement. For now, this evidence is enough to conclude that this service was the one authenticated to by the attacker.

Stick with this view since we’ll be focused on examining these binaries in the next task.

Task 8: Privilege Escalation — Exploiting Privileges

Investigation Guide:

With this, we can focus on the following network and endpoint events:

Look for events executed after the successful execution of the reverse socks proxy tool.

Look for potential privilege escalation attempts, as the attacker has already established a persistent low-privilege access.

Question 1: 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?

Now that we’ve confirmed the attacker authenticated using wsmprovhost.exe, let’s turn our attention to the next child process creation event highlighted in the diagram.

SysmonView: Identifying the privilege escalation binary

Double-click the event to grab the SHA256 hash of the binary. This will give us the two pieces of evidence we need:

The executable name
The SHA256 hash

SysmonView: ProcessCreate Event Details of the privilege escalation binary

To submit the answer, combine the executable name and file hash. Identifying this binary and its hash not only answers the question but also provides us with another IOC for our list for hunting.

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

Now that we have the file hash in hand, we’ll once again turn to VirusTotal to enrich our findings and learn more about what this tool is. Submit the hash and review the results.

VirusTotal: https://www.virustotal.com/gui/file/8524fbc0d73e711e69d60c64f1f1b7bef35c986705880643dd4d5e17779e586d/detection

This time, the analysis provides more than just detection verdicts, but also includes helpful code insights and threat/family labels. These labels tell us what kind of tool this binary actually is, based on vendor and community analysis and can help add valuable context to the investigation.

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

After reviewing the VirusTotal results, we have a better idea of what this tool does and what the impact is — but we’re missing a critical detail: the specific user privilege that enables this exploit.

Since we know the name of the tool, we can do a targeted Google search to see if other security researchers have documented its behavior. Take your pick!

For my context, I stumbled across a fantastic blog post from itm4n, the author of the tool, explaining how it works in great detail:

PrintSpoofer - Abusing Impersonation Privileges on Windows 10 and Server 2019 _Over the last few years, tools such as RottenPotato, RottenPotatoNG or Juicy Potato have made the exploitation of…_itm4n.github.io

From the blog, we quickly learn that this exploit abuses powerful impersonation privileges. These privileges allow a process to run code or even create a new process in the context of another user. For example:

These two privileges are very powerful indeed. They allow you to run code or even create a new process in the context of another user. To do so, you can call CreateProcessWithToken() if you have **<REDACTED>** or CreateProcessAsUser() if you have SeAssignPrimaryTokenPrivilege.

Understanding these privileges is important because they enable attackers to escalate from a standard user to SYSTEM-level access, which is obviously not great.

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

Moving right along, it’s time to look at the next process creation event for the second tool used to establish a new C2 channel. This event is highlighted in the diagram and gives us exactly what we need to answer Question 4 — the name of the binary.

SysmonView: Identifying the second C2 binary

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

You might have already guessed, but to determine the network connections used by the “final” binary to establish the second C2 connection, we’ll go back to the Process view tab and search for the executable name. Once we do that, we can easily identify the related network connection events, which will show us the domain, IP address, and the second port.

SysmonView: Using the process view tab to identify network connections

Task 9: Actions on Objective — Fully-owned Machine

Investigation Guide:

Now, the attacker has gained administrative privileges inside the machine. Find all persistence techniques used by the attacker.

In addition, the unusual executions are related to the malicious C2 binary used during privilege escalation.

Investigation Guide

Now, we can rely on our cheatsheet to investigate events after a successful privilege escalation:

Useful Brim filter to get all HTTP requests related to the malicious C2 traffic : _path=="http" "<replace domain>" id.resp_p==<replace port> | cut ts, host, id.resp_p, uri | sort ts

The attacker gained SYSTEM privileges; now, the user context for each malicious execution blends with NT Authority\System.

All child events of the new malicious binary used for C2 are worth checking.

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

Now we’re in the final phase of the investigation and the stakes are high. The adversary has achieved SYSTEM-level privileges, and we need to identify actions taken on the victim’s system.

Our first task is to jump back over to Brim and collect new evidence based on the port we identified in Task 8, Question 5. Assuming the attacker’s C2 tactics, techniques, and procedures are consistent, we’ll repeat the same analysis process we used in Task 7, Question 1.

Back in Brim, update the query to filter for the new port:

_path==“http” “resolvecyber.xyz” id.resp_p==8080 | cut ts, host, id.resp_p, uri | sort ts

Export the results again to .csv. This time, save the export as results2.csv—which means we’ll need to make a small modification to the decode.ps1 script we created earlier to account for the new file name.

Open the script in PowerShell ISE, update the file name to results2.csv, and run it directly in PowerShell ISE. This will perform the same parsing and decoding operations as before, allowing us to examine the contents of the URL parameters to determine what the attackers did after elevating to SYSTEM privileges.

PowerShell ISE: Modifying the decode.ps1 script

PowerShell ISE: Identifying user account additions

Toward the bottom of the output, we’ll find evidence that the attacker leveraged [net user](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user) commands to create two accounts. This is exactly what we need to answer Question 1.

Question 2: 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?

Jumping back up to the top of our script output, we’ll also find evidence that the first attempt at running these commands failed because they were missing a crucial option. Compare the version that failed with the successful ones we found in the previous question to determine the missing option.

PowerShell ISE: Identifying failed user account additions

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

While we could pivot to the third artifact, windows.evtx, and manually identify the account creation event, we have another option: leverage Microsoft’s documentation to confirm the standard event ID associated with this activity.

According to Microsoft Learn, this is part of the Windows Security Auditing framework and is logged whenever an account is successfully created. I’ll put the link below for further reading.

A user account was created. - Windows 10 _Describes security event A user account was created. This event is generated a user object is created._learn.microsoft.com

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

Back to the command analysis in PowerShell ISE, we’re searching for an event where the attacker added one of the newly created user accounts to the local administrators group for further privilege escalation and persistence.

Toward the bottom of the output, we’ll find evidence of this action using the net localgroup command. This is an old classic technique attackers use to grant elevated privileges to accounts they create/control.

PowerShell ISE: Identifying additions to the local administrators group

Question 5: 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?

Once again, rather than manually analyzing the windows.evtx artifact, we’ll lean on Microsoft’s documentation to confirm the standard event ID for this activity. According to Microsoft Learn, this event is logged whenever a user is added to a local group, including sensitive groups like Administrators.

A member was added to a security-enabled local group. - Windows 10 _Describes security event A member was added to a security-enabled local group._learn.microsoft.com

Question 6: 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?

At long last, we’ve made it to the end of the Tempest incident investigation. Our final task is to identify the persistence technique deployed by the attacker.

In the command output, we’ll find evidence that the attacker created a service using sc.exe and set it to auto-start. This service executes the final.exe binary we identified back in Task 8, Question 5. Another “oldie but goodie” technique that ensures the attacker’s code runs automatically whenever the system starts.

PowerShell ISE: Identifying suspicious service creation

But that’s only half the answer — we need the full command line. No problem! Let’s have one last hoorah with SysmonView. Using either the hierarchical view or the process view, locate sc.exe, double-click it, and check out the full command line.

SysmonView: Identifying the full commandline of the suspicious service creation

Bingo! Now we have the complete command from the Sysmon event log and have fully identified this persistence technique. Take a deep breath — we’ve closed out this investigation. Great job!

Conclusion:

Whew! That was a long one — but we made it to the end. A big thank you to TryHackMe for putting together such a thorough and challenging capstone.

This challenge was a fantastic way to wrap up the SOC Level 1 learning path. It tied together so many concepts covered in the content and offered a realistic example of an incident response engagement. Along the way, we not only followed the attacker’s trail but also learned how to better utilize our tools in the field.

I chose this week’s challenge to start closing out the SOC Level 1 path and get some hands-on practice with SysmonView, which I hadn’t used before. It didn’t disappoint! It made analyzing those ever-valuable Sysmon event logs so much faster than manual review alone. And because this challenge was so lengthy, it was incredibly rewarding — each question flowed logically into the next, making the investigation feel linear and cohesive. Awesome stuff!

Thanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap and consider following me! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!

If you liked my style and plan to continue the SOC Level 1 learning path, stick around and check out my walkthrough of the next capstone challenge:

TryHackMe - Boogeyman 1 Challenge Walkthrough

Until next time — stay curious and be safe out there!

Tools & References:

Challenge Link: https://tryhackme.com/room/tempestincident

Eric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md

CyberChef: https://gchq.github.io/CyberChef/

MSRC — CVE-2022–30190: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30190

Speedguide.net — Ports Database: https://www.speedguide.net/ports.php

VirusTotal — ch.exe: https://www.virustotal.com/gui/file/8a99353662ccae117d2bb22efd8c43d7169060450be413af763e8ad7522d2451

VirusTotal — spf.exe: https://www.virustotal.com/gui/file/8524fbc0d73e711e69d60c64f1f1b7bef35c986705880643dd4d5e17779e586d/detection

itm4n’s blog: PrintSpoofer — Abusing Impersonation Privileges on Windows 10 and Server 2019: https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/

Microsoft Learn — net user: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user

Microsoft Learn — 4720(S): A user account was created: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4720

Microsoft Learn — 4732(S): A member was added to a security-enabled local group: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4732

TryHackMe — Warzone 2 Room Walkthrough

Sun, 19 Oct 2025 00:00:00 +0000

TryHackMe — Warzone 2 Room Walkthrough

A Second Network Packet Capture Investigation Using Brim/Zui, Network Miner, and VirusTotal.

Image Credit: https://tryhackme.com/room/warzonetwo

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Warzone 2 room from TryHackMe, you’re in the right place. This challenge is the second in a series of fantastic rooms aimed at introducing you to forensic network packet analysis using some lesser-known tools.

If you want to follow along in order, you can start with the Warzone 1 room first:

TryHackMe — Warzone 1 Room Walkthrough

Challenge Scenario:

You work as a Tier 1 Security Analyst L1 for a Managed Security Service Provider (MSSP). Again, you’re tasked with monitoring network alerts.

An alert triggered: Misc activity, A Network Trojan Was Detected, and Potential Corporate Privacy Violation.

The case was assigned to you. Inspect the PCAP and retrieve the artifacts to confirm this alert is a true positive.

In this challenge, we’re stepping back into the shoes of a Security Analyst at an MSSP, monitoring network traffic alerts for one of your customers when suddenly, an alert fires from their IDS/IPS. We’re given a network packet capture file, a PCAP, and need to quickly determine if this is a true positive by analyzing the artifacts within the traffic.

Now that you’ve already got some experience, you might guess what’s in our toolkit for this investigation. We’ll be busting out Brim again to process, search, and analyze the PCAP, and then pivoting to Network Miner for a file analysis. We’ll also enrich our findings by consulting VirusTotal to add context to any indicators of compromise (IOCs) we discover.

I’ll walk through each step clearly, and avoid spoiling the answer. By the end, you’ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let’s get into it!

And if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team — please give it a clap and consider following me for more content like this.

Thanks for reading and going on this investigation with me!

Question 1: What was the alert signature for A Network Trojan was Detected?

Once in our analysis environment, let’s get acquainted with our toolset so we can start forming a plan. You’ll find everything we need in the Tools folder on the Desktop.

Contents of the Tools Folder

To answer Question 1, we’re searching for an alert signature. So, our first stop will be to use Brim (now called Zui) because it has the ability to use Suricata intrusion detection rules to help quickly identify threats or malicious traffic within the packet capture.

Go ahead and launch it — and speaking of packet captures, once Brim is open, load the challenge file Zone2.pcap , and wait for it to process the capture file.

Brim: Loading Zone2.pcap

Once the file is loaded, let’s get an overview of the Suricata rule hits detected in the network traffic. Select the Zone2.pcap file, click Suricata Alerts by Category under the Queries header, and review the displayed alert categories.

Brim: Overview of Suricata Alerts by Category

We’re going to focus on a Network Trojan was detected since that’s what the question is asking about. Our next step is to find the alert signature for this category.

To do this, right-click the a Network Trojan was detected row and select New search with this value.

Brim: Selecting New search with the a Network Trojan was detected value.

This selection adjusts the query to display packets matching the Suricata rule — and more importantly, it reveals the details we need to answer Question 1 under the alert.signature column.

Brim: Identifying the alert signature

Question 2: What was the alert signature for Potential Corporate Privacy Violation?

Our next task is to determine the alert signature for a second alert category: Potential Corporate Privacy Violation.

For this, we’ll simply perform the same process we used in Question 1 — select New search with this value for the Potential Corporate Privacy Violation category.

Brim: Selecting New search with the a Potential Corporate Privacy Violation value.

This time, we’ll see a different alert.signature value compared to Question 1.

Brim: Identifying the alert signature.

Question 3: What was the IP to trigger either alert? Enter your answer in a defanged format.

Answering Question 3 requires us to determine the IP address that triggered either alert. The wording is a bit confusing, but we’re looking for the source IP address (src_ip) associated with the HTTP file download. Either alert will display the same information.

Brim: Identifying the source IP of the alert

Before we can submit the answer, we need to defang the IP address. This is a common practice to ensure that malicious IPs and URLs aren’t accidentally clicked or activated. While this is easy to do manually, let’s work a little smarter and use CyberChef for the task.

The offline version of CyberChef is included in the Tools folder, but the online version works just as well. To defang the source IP address:

Open CyberChef.
Select the Defang IP Addresses operation.
Paste the source IP address into the Input field.

And voilà — we have the defanged IP address.

Question 4: Provide the full URI for the malicious downloaded file. In your answer, defang the URI.

Now that we’ve identified a suspicious IP address, we can pivot our search and focus on that address. To do this, simply open a new tab in Brim and enter the IP address to view the results.

Without any additional filtering, you’ll see that the first result with the notice label contains the full URL of a downloaded .cab file.

Brim: Finding the URL of the malicious download

Once again, before we submit the answer, we’ll need to hop into CyberChef to defang the URL.

CyberChef: Defanging the URL of the malicious download

Question 5: What is the name of the payload within the cab file?

To answer Question 5, we’ll turn our attention to examining the malicious .cab file we identified in the last question. For this job, we’re going to make a quick detour in our tooling and swap over to Network Miner, also contained in the Tools folder on the Desktop.

Open up Network Miner and load the Zone2.pcap. This is where Network Miner shines — it can easily parse, identify, and categorize various elements within the network traffic streams, including reassembling files. This will make determining the contents of the .cab file much easier.

Let’s put this into practice and select the Files tab. The top entry filename might look familiar — this is the .cab file we’re looking for.

Now, a quick note on .cab files: they’re short for cabinet files, a native Windows archive format used to compress and bundle files, often for software installation. That makes them a perfect disguise for attackers trying to sneak payloads past defenses. If you stumble across one in a network capture, it may be worth a closer look.

Network Miner: Grabbing the file hash of the malicious file

Rather than do any analysis directly on the file, we’ll pivot out to VirusTotal to check if this sample has been submitted to the platform before. For this, we’ll need the hash of the .cab file, which we can get by double-clicking the entry in Network Miner and copying the SHA256 hash.

Now that we have the file hash, use your web browser outside of the TryHackMe VM (since it doesn’t have direct internet access) and navigate to https://virustotal.com. Submit the copied file hash into the search box to see the results.

https://www.virustotal.com/gui/file/3769a84dbe7ba74ad7b0b355a864483d3562888a67806082ff094a56ce73bf7e

Immediately, we’ll see that nearly all vendors on the platform have marked this file as malicious. But what we’re interested in is the file name field below the hash — this tells us the payload name within the .cab file and is what we’ll need to answer Question 5.

Question 6: What is the user-agent associated with this network traffic?

Question 6 requires us to determine the user-agent string associated with the network traffic. In legitimate use cases, these strings help identify the client browser or application connecting to a resource over HTTP. They can sometimes give us clues about the origin of a request, but unfortunately, they’re also easily spoofed, so we’ll treat them as hints, not hard evidence.

We can perform this task in either Network Miner or Brim. For the purposes of this walkthrough, I’ll demonstrate using Brim.

Since we already have the search open for the source IP of the malicious traffic, we’ve got a head start. Remember how I mentioned user-agent strings apply to HTTP traffic? Focus on the row labeled http — this is where we’ll find the user_agent string.

This long string tells us a bit about the browser and operating system the victim used to retrieve the malicious .cab file. While deeper analysis is out of scope for this challenge, it’s a fun side activity to plug the string into a User Agent Lookup tool and see what you can learn. For example:

https://www.whatismyip.net/tools/user-agent-lookup.php

Question 7: What other domains do you see in the network traffic that are labelled as malicious by VirusTotal? Enter the domains defanged and in alphabetical order. (format: domain[.]zzz,domain[.]zzz)

Now that we’ve gotten some additional context about the request, it’s time to return to our hunt for suspicious domains. This process combines the data in Brim with threat intelligence from VirusTotal.

First, we’ll leverage Brim’s Unique DNS Queries page to determine all of the DNS requests in the traffic. You’ll find this query under the Queries menu.

Brim: Viewing Unique DNS Queries

This will list out all of the DNS requests. Yikes — there are quite a few domains.

So, let’s head back to our VirusTotal search for the .cab file hash. Press the Relations tab and turn your attention to the Contacted Domains section. Here, we’ll find several domains contacted by this binary, complete with their own detection ratings.

VirusTotal: Contacted Domains under Relations tab

Focusing on the ones flagged as malicious, we can correlate them with the results back in Brim.

Notice a problem? We’ve got more than two entries matching — but the question only wants two.

No problem! Let’s filter this down further by using the Suricata Alerts by Source and Destination tab. We’ve already analyzed the two labeled Potentially Bad Traffic and A Network Trojan was detected.

Brim: Filtering by Misc activity alert

Instead, we’ll check the one with the alert field labeled Misc activity and perform a new search.

Brim: Identifying the malicious domains

This returns results for the IP associated with Misc activity, where we can find two domains that were also present in the DNS queries and flagged as malicious on VirusTotal. Correlating the results from these three views gives us high confidence in answering Question 7.

Now all we need to do is defang them in CyberChef again and put them in alphabetical order.

Question 8: There are IP addresses flagged as Not Suspicious Traffic. What are the IP addresses? Enter your answer in numerical order and defanged. (format: IPADDR,IPADDR)

Back to the Suricata Alerts by Source and Destination tab. Question 8 asks us to analyze the alert tag Not Suspicious Traffic. Fortunately, the information is readily available, and we can quickly identify the IP addresses associated with this tag.

Brim: Identifying IP addresses with the “Not Suspicious Traffic” tag.

As before, once we’ve located the IPs, we’ll head over to CyberChef. Paste the IPs into the input window in numerical order, apply the Defang IP Address operation, and you’ll have them formatted correctly for submission.

Question 9: For the first IP address flagged as Not Suspicious Traffic. According to VirusTotal, there are several domains associated with this one IP address that was flagged as malicious. What were the domains you spotted in the network traffic associated with this IP address? Enter your answer in a defanged format. Enter your answer in alphabetical order, in a defanged format. (format: domain[.]zzz,domain[.]zzz,etc)

Let’s dig into some analysis of the IP addresses marked as Not Suspicious Traffic from the previous question and validate the results.

We’ll start by searching for the first IP — the one beginning with 64. This will show us all associated log entries, but it’s a bit unwieldy to sort through. To make things easier, we can apply some filtering and focus on entries with a server_name tag, which helps us narrow down any associated domain names.

|server_name

Brim: Surfacing domain names associated with an IP address

This gives us three distinct domains associated with this IP address in the PCAP.

Let’s jump back over to VirusTotal and search the IP address, navigating to the Relations tab. Take a look at the Passive DNS Replication area — notice anything interesting?

VirusTotal: Correlating domain names with threat intelligence

All three domains we surfaced in Brim also appear in the VirusTotal entry, complete with indicators of malicious activity. It turns out this IP is more suspicious than we originally believed.

Question 10: Now for the second IP marked as Not Suspicious Traffic. What was the domain you spotted in the network traffic associated with this IP address? Enter your answer in a defanged format. (format: domain[.]zzz)

We’ve made it to the last question! Our final objective is to analyze the second IP we found in Question 8 labeled Not Suspicious Traffic.

Brim: The second IP address labeled “Not Suspicious Traffic”

Then, we’ll perform the same steps we did for Question 9 — search the IP address and filter the entries for the server_name tag. Once we have the results, there’s only a single domain listed. That’s the one we need to wrap up this investigation.

Brim: Surfacing domain names associated with a second IP address

Before you defang the answer, if you’re curious, you can check this result on VirusTotal as well. At the time of this writing, this domain does indeed appear to be not suspicious. That’s a good reminder to always cross-check your results to make a more informed determination about a threat.

It also serves as a reminder that indicators of compromise, like domains, are easy for a threat actor to change. Timely threat intelligence can make all the difference!

Conclusion:

How fun was that! A big thank you to TryHackMe for the part two of this fun and realistic challenge.

By once again analyzing the PCAP file containing suspicious network traffic using Brim and Network Miner, and enriching our findings with VirusTotal, we successfully identified several malicious IP addresses and domains associated with a threat actor. Then we determined what files were downloaded from the malicious infrastructure and learned more about the threat. Putting all the evidence together, we can confirm the alert as a true positive and move on to the containment phase.

I chose this weekly challenge to spend more hands-on time with Brim/Zui and the awesome Suricata rules built in. I also really appreciate the immense capabilities of Network Miner — I’m always impressed by how easy it is to use, and how much depth it offers particularly for quick file analysis and reassembly. In the real world, I’ve used both tools numerous times to visualize data in a PCAP and uncover information that was time-consuming and difficult to find using other tools. It’s absolutely worth keeping in the kit.

Thanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!

It’s a Warzone out there, stay curious and be safe!

Tools & References:

Challenge Link: https://tryhackme.com/room/warzonetwo

Brim/ZUI: https://zui.brimdata.io/

Network Miner: https://www.netresec.com/?page=NetworkMiner

VirusTotal: https://www.virustotal.com/

CyberChef: https://gchq.github.io/CyberChef/

WhatIsMyIP — User Agent Lookup: https://www.whatismyip.net/tools/user-agent-lookup.php

TryHackMe — Traverse Challenge Walkthrough

Sun, 24 Aug 2025 00:00:00 +0000

TryHackMe — Traverse Challenge Walkthrough

Investigating and Restoring a Compromised Web Application Using a Web Browser, OWASP ZAP, and Postman

Image Credit: https://tryhackme.com/room/traverse

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Traverse challenge from TryHackMe, you’re in the right spot. This challenge is a fantastic deep dive into investigating a compromised web application — let’s check out the scenario below.

Challenge Scenario:

Bob is a security engineer at a firm and works closely with the software/DevOps team to develop a tourism web application. Once the website was moved from QA to Production, the team noticed that the website was getting hacked daily and wanted to know the exact reason. Bob consulted the blue team as well but has yet to be successful. Therefore, he finally enrolled in the Software Security pathway at THM to learn if he was doing something wrong.

It sounds like we’ve got our work cut out for us to get Bob and his team back on track. But unlike Bob, we’ve already completed the Software Security pathway — and this challenge is one of its capstones, tying together all the key concepts. That means we’re well equipped to tackle this challenge. We’ll explore topics like the OWASP Top 10, SSDLC, Dynamic Application Security Testing, and more.

To accomplish this, we’ll leverage our knowledge of web applications and use tools like OWASP ZAP and Postman to complete our objectives. Sounds like fun, right? Let’s get into it!

In the spirit of learning, this write-up is spoiler-free_._ But, if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.

Thanks for reading and going on this investigation with me!

Question 1: What type of encoding is used by the hackers to obfuscate the JavaScript file?

Let’s kick off this investigation by spinning up the challenge virtual machine and launching your TryHackMe AttackBox.

Our first task is to determine what encoding is used to obfuscate the JavaScript file. To do this, open the Firefox browser from the AttackBox and navigate to the URL for the challenge. Once the page loads, we’ll see that the website has been defaced with a message from the attacker — uh oh!

Browser: Navigating to the defaced web site

For our purposes, we’ll need to leverage the browser’s Developer Tools to identify any JavaScript files loaded by the website and see if we can find anything suspicious. First, press F12 to load up the developer tools.

Browser: Using developer tools to identify JavaScript loaded by the page

On the Inspector tab, we’ll discover two commented JavaScript files, but the one we’re interested in is custom.min.js, indicated by the comment “THIS IS CUSTOM JS FILE.“Let’s flip over to the Network tab of the developer tools. Select the JS filter to help us quickly locate the two scripts. Then, select the custom.min.js file and click the Response tab.

Browser: Identifying the encoded JavaScript payload

Within the response payload, we can see a suspicious comment likely left by the attacker. Right below it, we see that the payload is obfuscated. Based on the format, we can determine the encoding.

Since this walkthrough doesn’t contain spoilers, you’ll have to figure out which common encoding method is used on your own. We’ll confirm this in Question 2 once we start decoding operations.

Question 2: What is the flag value after deobfuscating the file?

Now that we’ve identified the encoded payload, our next objective is to decode it and uncover the flag hidden within. We can accomplish this by leveraging CyberChef, which is conveniently bookmarked in the AttackBox’s Firefox browser.

After opening CyberChef, paste the encoded payload into the input window. Since we already know the type of encoding from Question 1, we’ll need to add the “From [Redacted]” operation to the recipe.

CyberChef: Decoding the JavaScript payload

Once the operation completes, look for a function resembling ("Flag: "+n+" "+e+" "+o+" "+i). This is our clue. All we need to do now is refer to the variables n, e, o, and i. Each one is assigned a dictionary word. When we combine them, we get the flag — and a hint to continue our investigation.

Question 3: Logging is an important aspect. What is the name of the file containing email dumps?

To answer Question 3, we need to map any additional URLs on the compromised web application — specifically any resource that could contain email dumps.

For this challenge, we’ll leverage the Spider capabilities of the OWASP ZAP tool**,** which was covered in the Dynamic Application Security Testing room of the Software Security module. For context, according to the ZAP documentation, the Spider is:

A tool that is used to automatically discover new resources (URLs) on a particular Site. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. The Spider then visits these URLs, it identifies all the hyperlinks in the page and adds them to the list of URLs to visit and the process continues recursively as long as new resources are found.

So, the idea is that by leveraging the Spider, we can automatically discover new resources and not have to manually hunt through the browser — awesome! Let’s try it out.

First, press the Tools menu and select Spider. Once the Spider’s Scope window opens, add your Challenge Machine IP to the starting point field, tick the recurse option, and press Start Scan.

ZAP: Configuring the Spider

Once the enumeration finishes, we’ll be able to see all the discovered resources in the left-hand column. Since we’re looking specifically for logs, expand the logs node. Notice the .txt file? This is the file containing the email dumps that we’re searching for.

By using ZAP’s Spider capability, we’ve quickly identified this file.

ZAP: Reviewing the Spider results

Question 4: The logs folder contains email logs and has a message for the software team lead. What is the name of the directory that Bob has created?

Now that we’ve discovered the URL of the email logs, we can right-click the entry from ZAP and select “Open URL in Browser.” This will open the resource in your web browser so we can read the contents.

Browser: The contents of email_dump.txt

Inside email_dump.txt, we’ll find a message from Bob sent to Mark, the software team lead. It contains a clue pointing to the location of a directory Bob created. He mentions: “I named the API folder under the name of the first phase of the SSDLC.“So, what is the first phase of the SSDLC? This was covered in the SSDLC room of the TryHackMe Software Security module. We just need to refer back to the Phases of Secure Software Development Life Cycle diagram to determine the name of the folder Bob created, containing the API documentation.

Image Credit: https://tryhackme.com/room/securesdlc

Question 5: What is the key file for opening the directory that Bob has created for Mark?

Another handy clue that Bob left for Mark in his email is the key to accessing the page contents — thanks, Bob!

Browser: Identifying the password in email_dump.txt

Our next task is to use this password to access the API documentation. Let’s check it out!

Question 6: What is the email address for ID 5 using the leaked API endpoint?

Now that we’ve identified the URL and key to access the API documentation in the last two questions, let’s navigate to it in the browser:

http:///<QUESTION 4 ANSWER>

Upon accessing the page, we’ll be challenged for a password — this is where we can use the credential we found in Question 5.

Browser: Accessing the API Documentation

Now that we’ve accessed the page, we can check out the API documentation, which gives us detailed instructions on how to query specific customers by ID — awesome!

Browser: Accessing the API documentation

So, we have API documentation, but how do we actually query these customer IDs? For this task, we’ll switch to the application Postman, an all-in-one API platform. Postman is pre-installed on the THM AttackBox, with a shortcut located in /root/Desktop/Tools/Web.

Go ahead and open Postman. Here’s how we’ll build our query using Bob’s API documentation as a reference:

Set the HTTP Method to GET
Input the URL of your challenge machine: http://<YOUR CHALLENGE IP>/api
Set the Query Parameters:

KEY = customer_id
VALUE = 5

Press Send

Postman: Building the API query

This will create a request that matches the requirements of the API documentation and allows us to query the web app for a customer ID of 5. Press Send to send the request.

Postman: Identifying the email address of user ID 5

This will return the data for the user with ID 5, John, including his email address, which we need to answer Question 6.

Questions 7 & 8:

What is the ID for the user with admin privileges?

What is the endpoint for logging in as the admin? Mention the last endpoint instead of the URL. For example, if the answer is URL is tryhackme.com/admin — Just write /admin.

To answer Questions 7 & 8, we’ll need to first identify a user with the admin role, and then locate the login endpoint used to access administrative functions. We already know that John (a regular user) is ID 5, so we’ll start by changing the query VALUE and checking lower numbers like 1, 2, 3, 4, etc.

Eventually, our manual enumeration efforts pay off and we stumble upon the ID related to the admin role.

Postman: Identifying the admin user

Not only did we discover the admin user with our query, but we also uncovered the login endpoint used to access the administrative functions of the web app.

These are good reminders of how easily sensitive information can be disclosed without proper access controls. Lock it down!

Questions 9 & 10:

The attacker uploaded a web shell and renamed a file used for managing the server. Can you find the name of the web shell that the attacker has uploaded?

What is the name of the file renamed by the attacker for managing the web server?

For our next two tasks, we’re going to leverage the exposed credentials and login endpoint we found in Questions 7 & 8 to access the admin page through the browser.

Use your browser to connect to the endpoint and input the credentials when prompted.

Browser: Accessing the admin login endpoint

Once we’ve gained access to the Admin Page, we’ll see that we have the ability to execute commands on the underlying server. For example, we have the Current Directory and System Owner commands. Executing each of them seems to trigger different system-level commands: pwd lists the current directory, and whoami lists the current user.

But what if there’s a way to execute additional commands from this same admin page?

Browser: The Admin Page command execution interface

Let’s press F12 to open the browser’s developer tools again. This time, we’ll inspect the command input field. Notice anything interesting?

Browser: Inspecting the command execution elements

We can see that our theory was correct. The two available commands are simply executing whoami and pwd on the web server’s operating system. Let’s test if this field is vulnerable to command injection by adding an additional command.

To do this, right-click the <select name="commands"> tag and edit the HTML to add another command to list the contents of the current directory. For this example, we’ll use ls -la — who knows, maybe we’ll find the web shell.

Browser: HTML Manipulation

Now that we’ve edited the HTML on the client side, let’s execute our new List Contents command.

Bingo! By executing this command, we’ve successfully revealed the web server’s directory contents and uncovered some very valuable information, including the two file names we need to answer Questions 9 & 10. This confirms that the web application is vulnerable to command injection.

For additional context on this technique, check out the OWASP Top 10:2021 page. Here’s a quote from the TryHackMe OWASP Top 10–2021 room:

OWASP Top 10: 2021 — A04 — Command Injection: This occurs when user input is passed to system commands. As a result, an attacker can execute arbitrary system commands on application servers, potentially allowing them to access users’ systems.

Question 11: Can you use the file manager to restore the original website by removing the “FINALLY HACKED” message? What is the flag value after restoring the main website?

We’ve made it to our final objective — restoring the website to its original state before the hack. The cool part is that this task builds directly off the information we uncovered in Question 10 — specifically, the filename of the original file manager for this web app.

Navigate to the renamed URL from Question 10 to access the file manager. We’ll also need the password, which we also discovered after listing the web server contents with our ls -la command. This will allow us to log in and begin restoring the site.

Browser: The Admin File Manager login page

Once inside the file manager, locate and open the index.php file with the Edit action.

File Manager: Identifying the index.php file

Inside the editor, we’ll see the message header “FINALLY HACKED.” Looking further down the PHP code, there’s a condition: if the $message variable does not equal “FINALLY HACKED”, the final flag will be displayed.

Let’s go ahead and remove the $message variable, save the file, and reload the web app’s home page.

With the defacement removed, we’re rewarded with the final flag on the restored website. Great job! Now let’s wrap up this challenge.

Conclusion:

How fun was that! A big thank you to TryHackMe for another awesome challenge.

This challenge was a great capstone for the Software Security module and tied together so many concepts covered in the content. It offered a realistic example of how layered vulnerabilities like exposed credentials, weak access controls, and command injection can compound into full web server compromise.

As we moved through the investigation, we not only followed the attacker’s trail but also restored the integrity of the web application. Of course, this is only a short-term fix, and Bob definitely has his work cut out for him to get this app properly locked down.

I chose this week’s challenge to start wrapping up the Security Engineer path and get some hands-on practice investigating compromised web applications while testing my knowledge of the Software Security modules. It was a rewarding experience as each question segued perfectly into the next, and the investigation felt linear and logical. As an added bonus, I’ve been using Postman more in my day job, so getting extra reps in was a real plus. Great stuff!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

Challenge Link: https://tryhackme.com/room/traverse

CyberChef: https://gchq.github.io/CyberChef/

ZAP Proxy Documentation — Spider: https://www.zaproxy.org/docs/desktop/addons/spider/

Postman: https://www.postman.com/

OWASP Top 10 — A03 — Injection: https://owasp.org/Top10/A03_2021-Injection/

TryHackMe — Warzone 1 Room Walkthrough

Sun, 01 Jun 2025 00:00:00 +0000

TryHackMe — Warzone 1 Room Walkthrough

A Network Packet Capture Investigation Using Brim/Zui, Wireshark, and VirusTotal.

Image Credit: https://tryhackme.com/room/warzoneone

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Warzone 1 room from TryHackMe, you’re in the right place. This challenge is a fantastic introduction to forensic network packet analysis — let’s check out the scenario below.

Challenge Scenario:

You work as a Tier 1 Security Analyst L1 for a Managed Security Service Provider (MSSP). Today you’re tasked with monitoring network alerts.

A few minutes into your shift, you get your first network case: Potentially Bad Traffic and Malware Command and Control Activity detected. Your race against the clock starts. Inspect the PCAP and retrieve the artifacts to confirm this alert is a true positive.

In this challenge, we’re stepping into the shoes of a Security Analyst at an MSSP, monitoring network traffic alerts for one of our customers when suddenly, an alert fires from their IDS/IPS — Uh-Oh! We collect a network packet capture file, or PCAP, and need to quickly determine if this is a true positive alert by analyzing the artifacts within the traffic.

Okay, deep breaths — what’s in our toolkit for this investigation? We’ll be busting out a couple of essential network packet analysis tools including Brim (now called ZUI) to process, search, and analyze the PCAP, and then pivoting to Wireshark for deep packet inspection. We’ll also enrich our findings by consulting VirusTotal to add context to any indicators of compromise (IOCs) we discover.

Sounds like fun, right? Let’s get into it!

In the spirit of learning, this walkthrough will be spoiler-free. But if you find it helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.

Thanks for reading and going on this investigation with me!

Question 1: What was the alert signature for Malware Command and Control Activity Detected?

Once in our analysis environment, let’s get acquainted with our toolset so we can start forming a plan. You’ll find everything we need in the Tools folder on the Desktop.

Contents of the Tools folder

Go ahead and launch it — and speaking of packet captures, once Brim is open, load the challenge file Zone1.pcap , and wait for it to process the capture file.

Once the file is loaded, let’s get an overview of the Suricata rule hits detected in the network traffic. Select the Zone1.pcap file, click Suricata Alerts by Category under the Queries header, and review the displayed alert categories.

Brim: Overview of Suricata Alerts by Category

We’re going to focus on Malware Command and Control Activity Detected since that’s what the question is asking about. Our next step is to find the alert signature for this category.

To do this, right-click the Malware Command and Control Activity Detected row and select New search with this value.

Brim: Selecting New search with the Malware Command and Control value.

This selection adjusts the query to display packets matching the Suricata rule — and more importantly, it reveals the details we need to answer Question 1 under the alert.signature column.

Brim: Identifying the alert signature.

Question 2: What is the source IP address? Enter your answer in a defanged format.

To answer Question 2, we need to determine the source IP address of the malware traffic. Fortunately, we can continue working in the same view we used in Question 1, this time focusing on the src_ip column, which contains — you guessed it, the source IP address.

Brim: Identifying the source IP address of the malicious traffic

But before we can submit the answer, we need to defang the IP address. This is a common practice to ensure that malicious IPs and URLs aren’t accidentally clicked. While this is easy to do manually, let’s work a little smarter and use CyberChef for the task.

The offline version of CyberChef is included in the Tools folder, but the online version works just as well. To defang the source IP address:

Open CyberChef.
Select the Defang IP Addresses operation.
Paste the source IP address into the Input field.

And voilà — we have the defanged IP address.

CyberChef: Defanging an IP address

Question 3: What IP address was the destination IP in the alert? Enter your answer in a defanged format.

To answer Question 3, we need to identify and defang the destination IP address of the malicious traffic. This process is exactly the same as in Question 2, except this time we’ll focus on the dest_ip column.

Once you’ve located the destination IP, open CyberChef, select the Defang IP Addresses operation, and paste the IP into the Input field to generate the defanged version.

Brim: Identifying the destination IP address of the malicious traffic

Question 4: Still in VirusTotal, under Community, what threat group is attributed to this IP address?

The phrasing for Question 4 is a bit misleading. To uncover what threat group is attributed to the destination IP address we found in Question 3, we need to pivot out to VirusTotal, an online threat analysis and sharing platform, to look up more information from the community.

Brim: Performing a VirusTotal lookup

In a real-world scenario, some versions of Brim support right-click context menu integrations that allow you to pivot directly to VirusTotal for IP lookups. Since the THM analysis environment doesn’t have open web access, we can’t get to VirusTotal this way. Instead, we’ll copy the destination IP and navigate to VirusTotal in another web browser. Then, paste the IP into the search field.

Once we’ve input the IP address, we’ll see that several providers flag it as malicious. Let’s turn to the Community tab to see if we can learn anything about the threat group attributed to this IP.

VirusTotal: Searching the malicious destination IP address

We’ll find that several community graphs include this IP address, and some mention a specific threat actor. Look for the tag with the TA prefix—this is the group we’re looking for. If you want more information about this threat group, check out the corresponding entry on MITRE ATT&CK: https://attack.mitre.org/groups/G0092/

Question 5: What is the malware family?

To answer Question 5, we now need to identify the name of the malware leveraged by the threat group. You may have already noticed the malware name in the alert.signature field from the Suricata alert in Brim, but we can cross-reference this by reviewing and confirming the VirusTotal community graph tags—nice!

VirusTotal: Identifying the malware family

Question 6: Do a search in VirusTotal for the domain from question 4. What was the majority file type listed under Communicating Files?

Question 6 is a bit confusing, since it seems like there is a missing step in the challenge. So far, we haven’t located a domain — only an IP address. That’s okay, though, we’ll adapt and try another approach.

Within our VirusTotal search page for the malicious IP address, navigate to the Relations tab and look at the Communicating Files section.

The question is tricky because the majority file type is Win32 EXE, but the expected answer format seems to match another communicating file type — this is the one we’re looking for. Not the most precise way of answering this, but it got the job done!

VirusTotal: Identifying communicating file types

Question 7: Inspect the web traffic for the flagged IP address; what is the user-agent in the traffic?

Okay, let’s return to Brim. Our next task is to search for the malicious destination IP we’ve been examining. To do this, enter the IP address into the search box and press ENTER.

There’s a lot of information to sift through, but let’s focus on the first three events — they contain all the data we’ll need.

Brim: Identifying a suspicious user agent in the traffic

Notice the second alert type for Suspicious User-Agent (REBOL)? Take a closer look at the following http event (the third entry)—we’ll find that this packet contains the suspicious user_agent string.

For reference, user agent strings are used to identify the client connecting to a web server and can help determine more information about the source of the traffic.

Question 8: Retrace the attack; there were multiple IP addresses associated with this attack. What were two other IP addresses? Enter the IP addressed defanged and in numerical order. (format: IPADDR,IPADDR)

For our next task, we’ll need to identify additional IP addresses associated with the attack, defang them, and submit them in numerical order. No problem!

The first step is to leverage Brim’s built-in HTTP Requests query from the Queries pane on the left-hand side of the window. This will filter individual http requests. From there, we’ll focus on the id.resp_h column, which represents the IP address of the external server that responded to each request. While the majority of the traffic is directed to the IP address we previously identified, a closer look toward the bottom of the list reveals a few new entries for us to analyze.

Brim: Identifying the additional IOCs

Searching each of these IPs on VirusTotal, and checking the Community tab again, we’ll discover that some of them are linked to the same malware family we identified back in Question 5. Give it a try! If you get stuck, I’ve included some spoiler links below.

VirusTotal VirusTotalwww.virustotal.com

Once we’ve confirmed the related IPs, we can jump over to CyberChef to defang them. Just remember when submitting your answer, the IPs must be in numerical order, with the lowest value first.

Question 9: What were the file names of the downloaded files? Enter the answer in the order to the IP addresses from the previous question. (format: file.xyz,file.xyz)

Keeping with our currently filtered HTTP Requests view in Brim, we can already identify the URI associated with the downloaded MSI file from the second IP address — jot this down, since it’ll be the second one listed in the answer format.

Brim: Identifying the file downloaded from the second IP address

To identify the “first” file, let’s pivot to another built-in Brim query: the File Activity query. This gives us a broader view of file-related events and helps us spot another MSI file downloaded from the first IP address we found in Question 8.

Brim: Identifying the downloaded file from the first IP address

Now that we’ve located both files, we can combine them to form our answer — just make sure to list them in the same order as the IPs from the previous question.

Question 10: Inspect the traffic for the first downloaded file from the previous question. Two files will be saved to the same directory. What is the full file path of the directory and the name of the two files? (format: C:\path\file.xyz,C:\path\file.xyz)

Now that we’ve identified two suspicious downloaded files, we need to determine where the artifacts were saved on disk. The question tells us there are two additional files saved in the same directory — but how do we discover this?

For this task, stick with our current Brim filter, then click the Packets button just above the search box to open the associated pcap in Wireshark. This will load the packets related to the file download from the first IP address — the one listed first in the answer to Question 9. Our goal is to review the TCP stream and look for clues about the download path and any other files written to the same location.

Brim: Pivoting from Brim to Wireshark

Once Wireshark is open, right-click the first packet in the list and select Follow > TCP Stream.

Wireshark: Opening the TCP Stream

While there’s a lot of data to sift through, we can work a little smarter by using the find box to search for the common Windows drive letter C:\. This quickly reveals a file path.

Looking just next to that path, we’ll also spot a second .exe file. Since the question specifies that both files are saved in the same directory as the downloaded file, we can reasonably conclude these are the two files we’re after.

Wireshark: Identifying

Question 11: Now do the same and inspect the traffic from the second downloaded file. Two files will be saved to the same directory. What is the full file path of the directory and the name of the two files? (format: C:\path\file.xyz,C:\path\file.xyz)

For our last task, we’ll repeat the same process, this time inspecting the TCP stream for the MSI file downloaded from the second IP address we identified in Question 9.

Start by using Brim to search for the second file name. Once you have the result, click the Packets button to open the capture in Wireshark.

Brim: Searching the 2nd MSI file name

As before, right-click the first packet in the list and select Follow > TCP Stream to view the assembled data.

Wireshark: Opening the TCP Stream

With the stream open, use the find box to search for the C:\ drive letter again. This will help us quickly identify the full file path and the names of the two additional files stored in the same directory.

Now that we’ve identified the directories associated with both suspicious downloads, let’s submit our answers and wrap up this challenge!

Conclusion:

Done and done! By analyzing the PCAP file containing the suspicious network traffic using Brim and Wireshark, and enriching our findings with VirusTotal, we successfully identified several malicious IP addresses associated with a threat actor. Then we determined what files were downloaded from the malicious infrastructure and where they were saved on disk. Putting all of the evidence together, we can confirm the alert as a true positive and move on to the containment phase.

Now that we’ve uncovered the nature of the alert and completed our objectives, let’s close out this walkthrough of Warzone 1!

A big thank you to TryHackMe for another thrilling and realistic challenge. I chose this weekly challenge to spend more hands-on time with Brim/ZUI and the awesome Suricata rules built in. While Brim/ZUI doesn’t quite have the ubiquity of Wireshark, it’s an extremely impressive tool that’s beneficial to learn and get some practice with. In the real world, I’ve used this tool numerous times to visualize data in a PCAP and uncover information that was time-consuming and difficult to find using other tools — it’s worth keeping in the kit. Awesome stuff!

If you liked this challenge and want to take on the second challenge, Warzone 2, I’ve got you covered with another walkthrough if you want to continue our investigation together.

TryHackMe | Warzone 2 | Room Walkthrough

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

Challenge Link: https://tryhackme.com/room/warzoneone

Wireshark: https://www.wireshark.org/

Brim/ZUI: https://zui.brimdata.io/

Brim Data — “We’re renaming Brim to Zui”: https://www.brimdata.io/blog/brim-app-will-be-zui/

ZUI Docs — “Packet Captures”: https://zui.brimdata.io/docs/features/Packet-Captures#local-suricata-rules-folder

CyberChef: https://gchq.github.io/CyberChef/

VirusTotal: https://www.virustotal.com/

VirusTotal — Malicious Destination IP: https://www.virustotal.com/gui/ip-address/169.239.128.11

MITRE ATT&CK — TA505 (GA0092): https://attack.mitre.org/groups/G0092/

VirusTotal — Additional Malicious IP 1/2: https://www.virustotal.com/gui/ip-address/185.10.68.235/community

VirusTotal — Additional Malicious IP 2/2: https://www.virustotal.com/gui/ip-address/192.36.27.92/community

TryHackMe — Investigating Windows Challenge Walkthrough

Sun, 30 Mar 2025 00:00:00 +0000

TryHackMe — Investigating Windows Challenge Walkthrough

A Windows endpoint forensic investigation using Event Viewer, PowerShell, and VirusTotal

Image Credit: https://tryhackme.com/room/investigatingwindows

Introduction:

If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Investigating Windows challenge from TryHackMe, you’re in the right place. Welcome to my weekly walkthrough!

Investigating Windows is the first in a series of rooms within TryHackMe’s Investigating Windows module, and completing all three earns you a fancy badge on the platform. In the spirit of learning, this walk through will avoid spoilers. Since this is a FREE room, anyone can test their skills with Investigating Windows, perform the investigation along with me, and find the answers on their own as an entry point to Windows forensics.

In this scenario, we’re turned loose to investigate a compromised Windows endpoint and need to sleuth out how the attack unfolded. The tricky part? We’ll have no tools available to us, so we’ll hunt for the artifacts manually using the Windows Event Logs, Task Scheduler, Registry, and File Explorer. This is a great “back to basics” jumping-off point into digital forensics and incident response (DFIR) in the Windows world, with something interesting for all skill levels.

As we collect evidence, we’ll enrich our findings using MITRE ATT&CK, Microsoft Learn, and VirusTotal to add additional context and learn more about the attacker’s tactics and techniques. Sounds like fun, right? Let’s get into it!

And if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.

Thanks for reading and going on this investigation with me!

Challenge Scenario:

A windows machine has been hacked, its your job to go investigate this windows machine and find clues to what the hacker might have done.

This is a challenge that is exactly what is says on the tin, there are a few challenges around investigating a windows machine that has been previously compromised.

Question 1: Whats the version and year of the windows machine?

To kick off our investigation, we need to identify the operating system details of the compromised device. Specifically, we need to determine the Windows version. One approach is to use the winver command. This can be executed from the “Run” box, or the Command Prompt.

Using the Run dialog box:

Press Win + R to open the Run dialog box.
Type winver and press Enter.

Using the Command Prompt:

Open the Command Prompt by typing cmd in the search bar and pressing Enter.
Type winver and press Enter.

The resulting output will display the below information, where we can collect the Windows version information for the environment.

Winver Output

Question 2: Which user logged in last?

Now that we’ve identified the operating system version, we need to audit the logon activity for the system. For this walkthrough, we’ll use the Windows Event Log to query successful logon events, specifically filtering Event ID 4624 — “An account was successfully logged on.”

To do this:

Open Event Viewer:

Press the Windows Start button and type “Event Viewer.”

Navigate to Security Logs:

In the Event Viewer, expand “Windows Logs” and select “Security”.

Filter for Logon Events:

In the “Actions” pane on the right, click “Filter Current Log”.
In the “Event IDs” field, enter “4624" and click “OK”.

Filtering the Security Log for Event ID 4624

Now, the filtered log will display all successful logon events (Event ID 4624). Since the log is also capturing our Administrator login activity, scroll past the events for the current date to the previously logged date, 1/29/2021, to find the user logon activity before our session.

Identifying the last user logon session

Question 3: When did John log onto the system last?

Continuing to use our current filtering, we’ll use the “Find” function to locate the username John within the logs and determine the last date this user logged in to the system.

Identifying logon activity for the user John

Question 4: What IP does the system connect to when it first starts?

Now, let’s pivot away from the Windows Event Log and start to look for common persistence methods used by threat actors. The key to answering Question 4 is finding the IP address that the system connects to after it first starts.

With that in mind, we’ll check the Windows Registry Run Keys / Startup Folder (MITRE ATT&CK ID T1547.001). These methods allow a binary to execute on user login, creating persistence for the adversary.

According to MITRE ATT&CK, the relevant run keys can be found in the following locations:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

First, launch the Registry Editor:

Then, navigate to the keys referenced by MITRE ATT&CK. While examining HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run, you may notice the string UpdateSvc. This string indicates a suspicious command connecting to an additional IP address.

Identifying a suspicious run key in the registry

By analyzing these often-abused registry keys, we’ve found a method of persistence used by the threat actor and an IP address, or indicator of compromise (IOC).

Question 5: What two accounts had administrative privileges (other than the Administrator user)?

Next, we’ll need to determine which other accounts have local administrative permission on the system. To find out, we’ll query the local administrators group with PowerShell by executing the command below.

net localgroup administrators

After running the command, we’ll discover that three accounts are members of this group including the Administrator account that we’re using.

Question 6, 7, 8:

Whats the name of the scheduled task that is malicious.

What file was the task trying to run daily?

What port did this file listen locally for?

The next step in our investigation is to search for a malicious scheduled task. By abusing the Windows Task Scheduler, a threat actor could create persistence by setting a malicious file to run at a specific time (T1053.005)

For this walkthrough, we’ll search for the malicious task using the command line tool schtasks, but the GUI Task Scheduler will work just as well if you prefer to explore it.

From PowerShell, use the [schtasks](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks) command to query the task scheduler library. We’ll see a couple of suspicious entries listed.

Using schtasks to list tasks

To get more information about each task, use the following syntax:

schtasks /query /FO LIST /V /TN “”

Several tasks may look suspicious. For example, check the Clean file system task. Notice that its action is launch a PowerShell (.ps1) script, scheduled to run daily.

Using schtasks to query a task

Since we’re searching for a persistence technique and this specific task launches a file with a listening port, it matches the criteria of Questions 6,7, & 8. This is the malicious task we are searching for.

Question 9: When did Jenny last logon?

Now let’s return to gathering information about the other users on the system. We’ll pivot back to our PowerShell console to do this. Instead of querying a group like we did back in Question 5, we’ll query the Jenny user account directly to find the Last logon field.

To query the last logon time for Jenny, use the following command:

net user jenny

Identifying the “Last logon” for the user Jenny

By executing this command, we’ve figured out when Jenny last logged on to the system — nice!

Question 10: At what date did the compromise take place?

Based on the scheduled task trigger date, we can start to create a rough timeline of when the attack occurred. To take this a step further, let’s closely examine the directory storing the .ps1 file for the malicious task we found in Question 7: C:\TMP

Inside this directory, we’ll see a number of suspicious tools. All these files were staged in this folder on a specific date, which helps us pinpoint the date of compromise.

This information is crucial for understanding the timeline of the attack and properly scoping our investigation.

Question 11: During the compromise, at what time did Windows first assign special privileges to a new logon?

Now that we have scoped the date of the attack, we can start to narrow down our searches. To uncover the answer to Question 11, let’s return to the Windows Event Viewer searching for Event ID 4672, or “special privileges assigned to a new logon.”

According to Microsoft Learn, this event “generates for new account logons if any of the following sensitive privileges are assigned to the new logon session.”

To find these events, perform the following steps in the Event Viewer:

Select “Windows Logs” > “Security”.
Press “Filter Current Log…” in the right column.
Click the drop-down menu for “Logged” and select “Custom Range”.
In the “From” and “To” boxes, select “Events On” and select the date of the attack. Use the time ranges from 12:00:00 AM to 11:59:00 PM to display all events for the date, then press OK.
Type “4672" in the Event ID field, then press OK.

Filtering the Event Viewer for Event ID 4672 on the date of the attack

Based on the question, your immediate instinct might be to look at the first event in the list, but spoiler that is incorrect. Let’s take a quick look at the question hint to narrow this down a bit.

Armed with the clue, we can now locate the correct event and corresponding time stamp, determining when Windows first assigned special privileges to a new logon during the compromise.

Question 12: What tool was used to get Windows passwords?

You may have noticed throughout our investigation that a command prompt window keeps popping up randomly, right? You may have also seen another suspicious task in Task Scheduler or an alarming executable in the staging folder C:\TMP.

If not, let’s take a closer look at the window where we’ll observe a familiar file path: C:\TMP\mim.exe

To determine the nature of this file, we can collect the file hash and check it against external threat services. Use the following PowerShell command to gather the file hash:

get-filehash C:\TMP\mim.exe

Then, we can take this hash and submit it to a service like VirusTotal to evaluate the sample.

https://www.virustotal.com/gui/file/f8f1c210a8c863efc0f6b8ac3553030a14a702ce8cf573cb5e9cd58f70c7c622

After confirming that the file is malicious, check the “Family labels” to determine what tool the sample is. If you’d prefer a simpler approach, another option is to open the tool’s output text file, mim-out from the directory. This will reveal which tool created the output and allows us to see what password hashes were exposed.

https://attack.mitre.org/software/S0002/

By following these steps, we’ve identified the tool used to dump the Windows credentials and gathered more information about the attack.

Question 13: What was the attackers external control and command servers IP?

Now that we understand what method the attacker used for credential access, we’ll need to learn more about their infrastructure and discover the IP of their command and control server. I’ll admit that I spent far too much time digging through the scripts, event logs, and other artifacts on the system, so I’ll give you the short version of what worked.

Since the victim device does not have a live internet connection, we’ll have to rely on artifacts on the system to piece together this information. One place we can check is the Windows hosts file, which performs manual IP address to hostname mappings, even overriding a DNS server. The file can be located at:

C:\Windows\System32\drivers\etc\hosts

After examining the hosts file, we notice some strange entries, indicating that the attacker attempted to prevent the victim’s device from navigating to VirusTotal (whoops!), updating Sophos anti-malware products, and reaching Microsoft Update. Something sticks out here though. Most of these entries are for the local loopback IP address or a private IP address, but two entries are mapped to a public IP address. This anomaly is enough to warrant further investigation.

For the purposes of this walkthrough, we’ve found the answer — the public IP addresses in the hosts file likely belongs to the attacker’s command and control infrastructure.

Question 14: What was the extension name of the shell uploaded via the servers website?

To discover the answer to Question 14, let’s focus on a clue in the question itself: “shell uploaded via the servers website.” This tells us that the compromised device is also acting as a web server. In Windows, the IIS service typically stores the web server assets in the folder C:\inetpub\wwwroot.

By examining this directory on the compromised system, we’ll discover three potentially malicious files.

Capturing the file hashes, we’ll pivot back over to VirusTotal to gather some additional intelligence to determine if we’ve identified WebShells (T1505.003) uploaded by the attacker for persistence.

https://www.virustotal.com/gui/file/322e0bd2c20a01039fc235ba426d9d32b4960655609d0199066f828fb4904be4/detection

https://www.virustotal.com/gui/file/85053b9b54db5ff616b40521670080139459655ac6162bdb839fcfb9574166ca

Using VirusTotal, we can analyze the file hashes to confirm if these files are indeed malicious WebShells. The file extension of the shell uploaded via the server’s website will be revealed through this analysis.

Question 15: What was the last port the attacker opened?

To determine the last port the attacker opened, we’ll turn our focus to searching for activity related to network ports. Specifically, we’ll assess the Windows Firewall rules to check if the attacker made any modifications to grant access through the firewall.

Instead of blindly reviewing the firewall rules, let’s work a little smarter by auditing the event log again to check for any changes during the time of the attack.

To find Windows Firewall rule changes in the event log, follow these steps:

Navigate to Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Firewall with Advanced Security > Firewall.
Filter for “Events On” the date of the attack so that we can review the changes.

While there many events captured, most look benign and expected for a Windows system — except one that sticks out due to the rule name and the user account that modified the rule.

Identifying a new Windows Firewall rule with the Event Viewer

Next, let’s locate this rule in Windows Firewall with Advanced Security options by navigating to Inbound Rules. This console can be accessed by pressing the Windows “start” button and typing in “firewall.”

Validating the new firewall rule in the Windows Firewall interface

Once we’ve located the rule that we discovered in the event logs, we can check the local port that was opened on the firewall by the attacker and identify the last port they opened.

Question 16: Check for DNS poisoning, what site was targeted?

We’ve made it to the last question for our investigation — great job! Fortunately, we’ve already stumbled across the answer for Question 16 during our analysis of the hosts file back in Question 13.

The answer we’re looking for is the host name entry associated with the command and control IP address we discovered. This entry indicates the site targeted by DNS poisoning.

By reviewing the hosts file again, we can confirm the targeted site and understand how the attacker manipulated DNS settings to redirect traffic to their command and control server. Now let’s wrap up this investigation!

Conclusion:

Mission accomplished! Throughout this investigation, we combed through the Windows Event Logs to determine what users accessed the system and correlated event data during the timeframe of the attack. Using Registry Editor and Task Scheduler, we discovered the attacker’s methods of persistence and found evidence of payloads executing on logon and at scheduled intervals. Finally, we uncovered further evidence of the attack in the Windows Hosts File and File Explorer which we enriched using threat intelligence from VirusTotal.

Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Investigating Windows!

A big thank you to TryHackMe, for the fun and realistic challenge! This was an excellent opportunity for me to practice hands-on-keyboard analysis of a Windows environment to manually perform the investigation. It was a great lesson in the fundamentals of DFIR and promoted a creative analysis of the available artifacts to discover the answers to the questions. Awesome stuff!

Thanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable and it pumps me up to support your security journey. Cybersecurity is a team sport and we’re in this together!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

-Challenge Link: https://tryhackme.com/room/investigatingwindows

-MITRE ATT&CK — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001): https://attack.mitre.org/techniques/T1105/

-MITRE ATT&CK — Scheduled Task/Job: Scheduled Task (T1053.005): https://attack.mitre.org/techniques/T1053/005/

-Microsoft Learn — schtasks commands: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks

-Microsoft Learn — 4624(S): An account was successfully logged on: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624

-VirusTotal — f8f1c210a8c863efc0f6b8ac3553030a14a702ce8cf573cb5e9cd58f70c7c622: https://www.virustotal.com/gui/file/f8f1c210a8c863efc0f6b8ac3553030a14a702ce8cf573cb5e9cd58f70c7c622

-MITRE ATT&CK — Mimikatz (S0002): https://attack.mitre.org/software/S0002/

-MITRE ATT&CK — Server Software Component: Web Shell (T1505.003): https://attack.mitre.org/techniques/T1505/003/

-VirusTotal — 322e0bd2c20a01039fc235ba426d9d32b4960655609d0199066f828fb4904be: https://www.virustotal.com/gui/file/322e0bd2c20a01039fc235ba426d9d32b4960655609d0199066f828fb4904be4

-VirusTotal — 85053b9b54db5ff616b40521670080139459655ac6162bdb839fcfb9574166ca: https://www.virustotal.com/gui/file/85053b9b54db5ff616b40521670080139459655ac6162bdb839fcfb9574166ca

TryHackMe — Boogeyman 3 Challenge Walkthrough

Mon, 06 Jan 2025 00:00:00 +0000

TryHackMe — Boogeyman 3 Challenge Walkthrough

A Domain Forensic Investigation using Kibana

Image Credit: https://tryhackme.com/r/room/boogeyman3

Introduction:

Have you feared the return of the Boogeyman?

If not, you’ve stumbled on the right blog! Welcome to my weekly walkthrough. This is a comprehensive walkthrough of the Boogeyman 3 challenge from TryHackMe, the third in a series of capstone challenges for their SOC Level 1 learning path. This challenge is a digital forensics and incident response (DFIR) engagement for the final showdown with a fictional threat actor called the Boogeyman.

If you want to catch up on how we got here, check out my walkthroughs of Boogeyman 1 & Boogeyman 2 first.

TryHackMe — Boogeyman 1 Challenge Walkthrough

TryHackMe — Boogeyman 2 Challenge Walkthrough

To unmask the Boogeyman this time_,_ we’re all about hunting through logs within Kibana, part of the Elastic Stack, to figure out how the latest attack unfolded against an organization compromised by this persistent, shadowy threat actor. Doesn’t sound so scary, right?

Now let’s grab our flashlights and shine a light on the Boogeyman’s latest tactics, techniques, and procedures. I don’t want to ruin any of the surprises, so this walkthrough is spoiler-free, but please use it as a reference and enjoy! Thanks for reading along!

Challenge Link: https://tryhackme.com/r/room/boogeyman3

Challenge Scenario:

Due to the previous attacks of Boogeyman, Quick Logistics LLC hired a managed security service provider to handle its Security Operations Center. Little did they know, the Boogeyman was still lurking and waiting for the right moment to return.

In this room, you will be tasked to analyse the new tactics, techniques, and procedures (TTPs) of the threat group named Boogeyman.

Without tripping any security defences of Quick Logistics LLC, the Boogeyman was able to compromise one of the employees and stayed in the dark, waiting for the right moment to continue the attack. Using this initial email access, the threat actors attempted to expand the impact by targeting the CEO, Evan Hutchinson.

Question 1: What is the PID of the process that executed the initial stage 1 payload?

First things first. After starting the lab environment, enter the Elastic web console and navigate to the Analytics > Discover module. This dashboard is where we’ll be exploring the logs within the winlogbeat index_._

Once we get into our dashboard, we’ll have to adjust the time filters to view the logged events during the time of the incident. Fortunately, the security team reported to us that “the incident occurred between August 29 and August 30, 2023” so we can narrow the scope by modifying the dates in the time selection field.

We’ll filter the first date/time, selecting Absolute and setting the start date to August 29th, 2023, at 0:00 and the end date of August 30th, 2023, at 23:30. This selection gives us all the logs ingested during the incident.

Now that we have the time period set, where do we start? Well, remember from the scenario that the initial access method was a spear phishing email that had an attachment executed by the CEO, Evan Hutchinson. The security team discovered that the attachment was an ISO file containing a “PDF” file — ProjectFinancialSummary_Q3.pdf.

We saw from the triage that Windows Explorer displayed this is an HTML application (HTA), not a PDF. So, we’re potentially looking for malicious Mshta code execution activity. But let’s start broadly and simply search for the file name by entering it into the search bar at the top of the window.

This will produce 4 events for us to review. Let’s start with the first event with the oldest time stamp. As we suspected, we see our parent file spawning mshta.exe to handle the file along with the corresponding ProcessId that we’ll need to answer Question 1.

Before we submit our answer, note the hostname, host IP address, and username of the CEO’s compromised workstation. This will help us stay organized as we follow the attack.

WKSTN-0051 / 10.10.155.159 / evan.hutchinson

Question 2: The stage 1 payload attempted to implant a file to another location. What is the full command-line value of this execution?

Now, let’s focus on the next event in the list. We see evidence of [xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy) activity which can be used to move files around the system.

Since we’re interested in the full command to understand what file was copied and to which destination, let’s make some adjustments to our dashboard and toggle some columns within our table instead of expanding the event. This will allow us to see the full process.command_line field easily and have a cleaner view moving forward.

To do this, search the Available fields column on the left-hand side and press the + button to add the process.command_line field as a column.

You’ll notice in the screenshots below that I also added the process.parent.executable and host.hostname fields as columns too, making it far easier to see the sequence of events at a glance.

Now, revisiting the second event with this view, we’ll see the full command-line value for the [xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy) activity, revealing that the attacker moved a file from the ISO to a temporary directory on WKSTN-0051.

Question 3: The implanted file was eventually used and executed by the stage 1 payload. What is the full command-line value of this execution?

Continuing through the timeline, let’s look at the third event. Analyzing the command line, we see [rundll32](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rundll32) executed to register a DLL within the ISO.

Question 4: The stage 1 payload established a persistence mechanism. What is the name of the scheduled task created by the malicious script?

Next, examine the last of the four events. By focusing on the process.command_line column, we can see that PowerShell is used to create a new Scheduled Task for persistence. This task executes [rundll32](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rundll32) to register the file transferred to WKSTN-0051 via [xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy) from Question 2.

Examining the Register-ScheduledTask parameter, we’ll find the name of the task in the command:

Question 5: The execution of the implanted file inside the machine has initiated a potential C2 connection. What is the IP and port used by this connection? (format: IP:port)

Since we’re out of events to analyze in the current search, we need to pivot and expand our scope. Since we know from the last question that the attacker is leveraging PowerShell, let’s try narrowing our search for that. Fortunately for us, Quick Logistics LLC, had deployed Sysmon on the CEO’s workstation which gives us an advantage.

Searching for PowerShell.exe and querying Sysmon Event ID 3 for “t_he network connection event logs TCP/UDP connections on the machine_” might help find some clues leading us to uncover the command and control (C2) connection.

First, we’ll input the search.

powershell.exe and event.provider : “Microsoft-Windows-Sysmon” and event.code : “3”

Then, enter destination.ip into the search field names box and click the field name. This will show us the top 5 values across the logs. Notice that there are three IP addresses: One is the CEO’s workstation, another is the IPv6 local loopback, and the top result is an external IP. The external IP is present in the overwhelming majority of the searched PowerShell logs. It’s suspicious that a compromised workstation would connect to an external IP address over PowerShell.

For the second half of the question, we can check the destination.port field to find the port number. Since there is only one entry, we don’t need to look any further. Now we have both the IP Address and Port of the C2 connection.

Question 6: The attacker has discovered that the current access is a local administrator. What is the name of the process used by the attacker to execute a UAC bypass?

Now that we’ve identified the C2 server, we need to understand how the attacker escalated privileges and bypassed user account control (UAC). Recall from Question 2 that the stage 1 payload leveraged xcopy to implant a file onto the CEO’s workstation?

Let’s search for the implanted file, review.dat, to understand what other actions were performed. Right away we’ll see some discovery activity including whoami and net.exe commands used to enumerate local group membership and the associated permissions. But that’s not what we’re interested in. Notice another odd executable in the list for the Windows Features on Demand Helper. This seems out of place, doesn’t it?

Let’s research on MITRE ATT&CK to understand if this executable can be abused to bypass UAC. With a quick search, we’ll land on the page for the technique Abuse Elevation Control Mechanism: Bypass User Account Control (T1548.002) where we find the note below with a reference link:

MITRE ATT&CK: https://attack.mitre.org/techniques/T1548/002/

For additional intelligence, let’s explore the reference link from Red Canary where we’ll learn that the executable can be abused to achieve a UAC bypass:

Processes launched by [REDACTED].exe run with elevated administrative privileges without requiring a User Account Control prompt.

This means the attacker abused the legitimate binary to execute processes as an administrator without the user account control dialogue to interfere.

Since we have discovered a known method of abusing the Features on Demand Helper binary to bypass UAC combined with the evidence that this technique was used on compromised device, we’ve found the answer to Question 6.

Question 7: Having a high privilege machine access, the attacker attempted to dump the credentials inside the machine. What is the GitHub link used by the attacker to download a tool for credential dumping?

Now, we’ll need to discover what tool the attacker downloaded onto the victim’s device from GitHub. Jumping back to the search bar, let’s search for something broad like github.com, then refine our scope, filtering the host.ip field for the CEO’s workstation (10.10.155.159 / WKSTN-0051).

The search reveals that the attacker downloaded the very famous credential dumping tool, Mimikatz — not good! Let’s press forward to determine what the attacker was able to access.

Question 8: After successfully dumping the credentials inside the machine, the attacker used the credentials to gain access to another machine. What is the username and hash of the new credential pair? (format: username:hash)

Now that we’ve discovered the attacker downloaded Mimikatz, let’s continue analyzing the logs from the CEO’s workstation focusing on the executable name of the tool inside the mimi.zip archive — mimikatz.exe.

Mimikatz activity on WKSTN-0051

Here we’ll observe that Mimikatz dumps the credentials for users recently logged-on to the workstation (sekurlsa::logonpasswords) exposing their password hashes. Next, the attacker performs a Pass the Hash (sekurlsa::pth ) using the NTLM hash of one of the exposed administrative users — itadmin .

Question 9: Using the new credentials, the attacker attempted to enumerate accessible file shares. What is the name of the file accessed by the attacker from a remote share?

So, let’s do a quick recap. We know that the attacker compromised Evan, the CEO’s, workstation with a spear-phishing attachment. Then, the stage 1 payload performed a variety of activities to establish a foothold including using PowerShell to create persistence mechanisms, abusing living off the land binaries to elevate privileges, and dumping privileged OS credentials after downloading Mimikatz from GitHub. Now we’ll need to find what file shares the attacker found and accessed.

Based on what we know about the attacker’s tactics, techniques, and procedures (TTPs) it’s likely that they would need to download additional tools to perform file sharing enumeration in the environment.

Let’s test this theory by first filtering all events from the CEO, Evan’s, device — WKSTN-0051.quicklogistics.org. Then, we’ll narrow the search further starting with the attacker’s known technique of using PowerShell to download tools from GitHub. For this, we’ll format a query that specifies the CEO’s workstation in the host.name field and matches all fields for the term PowerShell and a wildcard search for GitHub.

host.name : “WKSTN-0051.quicklogistics.org” and powershell.exe and github

Right away, there’s something interesting. We’ll see that PowerShell downloaded PowerView.ps1 , a network reconnaissance tool**,** then runs the [Invoke-ShareFinder](https://attack.mitre.org/techniques/T1018/) cmdlet to discover accessible file shares within the domain.

This discovery brings us one step closer by answering the how, but we still need to determine what was accessed. Let’s modify the original query, removing the GitHub wildcard, and zoom-out to all PowerShell activities from this workstation.

host.name : “WKSTN-0051.quicklogistics.org” and powershell.exe

Bingo! We see that the attacker discovered a file share on WKSTN-1327 hosting an automation script where credentials are potentially stored to enable automation. Then, using the cat command, the attacker prints the output of this script to the console giving them access to the password within.

Question 10: After getting the contents of the remote file, the attacker used the new credentials to move laterally. What is the new set of credentials discovered by the attacker? (format: username:password)

Sticking with our current search parameters, scroll up through the newer events in the timeline. Shortly, we’ll stumble upon the series of events below showing that the attacker remotely used the newly discovered credentials for allan.smith to move laterally, executing code on a second workstation.

Question 11: What is the hostname of the attacker’s target machine for its lateral movement attempt?

From the previous two steps in the analysis, we’ve already determined the hostname and user account targeted for lateral movement. Let’s check our work and move forward with the investigation.

Question 12: Using the malicious command executed by the attacker from the first machine to move laterally, what is the parent process name of the malicious command executed on the second compromised machine?

Now we’ll switch our scope to the workstation targeted for lateral movement from the last question. To do this, we’ll zoom out focusing on the Microsoft-Windows-Sysmon events again and searching Sysmon Event ID 1 or process creation events. Since we are looking for a parent/child process used for lateral movement, let’s start here and see what we find.

host.hostname : “WKSTN-1327” and event.provider : “Microsoft-Windows-Sysmon” and event.code : “1”

Excellent! Notice the encoded PowerShell command and that the timestamp follows directly after the use of the credentials from WKSTN-0051 ? The process.parent.executable of the PowerShell process is what we’ll need to answer Question 12.

Question 13: The attacker then dumped the hashes in this second machine. What is the username and hash of the newly dumped credentials? (format: username:hash)

Staying within our current filters, we’ll see that once the attacker is connected, they perform the same patterns of system discovery as on the first workstation, including downloading Mimikatz to dump credentials on the second compromised workstation.

In addition to exposing the previous credentials we found back in Question 8 again, the attacker also discovers another set of administrative credentials, which may include Domain Admin privileges.

Question 14: After gaining access to the domain controller, the attacker attempted to dump the hashes via a DCSync attack. Aside from the administrator account, what account did the attacker dump?

Keep scrolling to the newer events following the administrator account credential dump, we see the attacker performed a Pass the Hash again using the new domain admin NTLM hash to access environment’s domain controller, following-up with a DCSync attack.

This gives us a good idea of where to look next. To confirm, let’s adjust our query again focusing on events from DC01 to see the full story.

host.hostname : “DC01” and event.provider : “Microsoft-Windows-Sysmon” and event.code : “1”

Once again, we’ll see familiar TTPs including system/user discovery and downloading Mimikatz. By performing a DCSync attack the attacker accesses the account credentials from the previous question and another new set of credentials.

Question 15: After dumping the hashes, the attacker attempted to download another remote file to execute ransomware. What is the link used by the attacker to download the ransomware binary?

Now that the attacker has achieved domain dominance, we can see that a few minutes later, the attacker downloads a ransomware binary from a remote server. This is the URL needed to answer Question 15.

To be thorough and fully scope the impact of the incident, let’s make a quick adjustment to our filters to understand if the ransomware binary was also executed after download.

In the search bar, we’ll enter the name of the executable, ransomboogey.exe. But we also want to understand what user accounts were used for execution and the winlog.event_id to understand if the file was executed. For this just select the user.name and winlog.event_id fields to add them to our dashboard.

First, we’ll see that the binary is executed (Sysmon Event ID 1) on DCO1 by Administrator.

Shortly after, we see that the ransomware is created (Sysmon Event ID 11), but not executed on the CEO’s workstation, WKSTN-0051.

Finally, we’ll determine that the ransomware binary was executed on WKSTN-1327 by itadmin.

Whew! Now that we have fully answered all the questions and have built a solid understanding of how the latest Boogeyman attack unfolded, let’s wrap up this investigation!

Conclusion:

The third time’s the charm! We’ve come to the end of our frighteningly fun investigation of Boogeyman 3, facing the Boogeyman for the final time. Using our forensic skills in ELK, we learned that the Boogeyman infected CEO’s device through a spear phishing email with a malicious attachment. Then, they performed a variety of activities to establish a foothold including leveraging PowerShell to create persistence and command and control, abusing living off the land binaries to elevate privileges, dumping privileged credentials with Mimikatz, performing discovery in the environment, moving laterally, and achieving domain dominance before finally deploying ransomware. While it was a scary incident, we successfully traced the Boogeyman’s activities and now, let’s wrap this investigation — Quick Logistics LLC’s nightmare is over!

A huge thank you to TryHackMe for the excellent part III of the Boogeyman series. This challenge was the perfect way to end the year and the awesome SOC Level 1 learning path! As usual for this series, I was truly impressed with the details and narrative of this room. This one felt closer to a real-world simulation exercise than others I have completed and it really pushed me to level-up my skills in Elastic. It was really engaging to see how the Boogeyman changed tactics, techniques, and procedures between the three rooms and the stakes felt real for the fictional organization! Let’s hope we never have to deal with Boogeyman again.

Thanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

MITRE ATT&CK: System Binary Proxy Execution: Mshta (T1218.005): https://attack.mitre.org/techniques/T1218/005/

Microsoft Learn — xcopy: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy

Microsoft Learn — rundll32: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rundll32

MITRE ATT&CK: Scheduled Task/Job: Scheduled Task (T1053.005): https://attack.mitre.org/techniques/T1053/005/

Microsoft Learn — Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

MITRE ATT&CK: https://attack.mitre.org/

MITRE ATT&CK: Abuse Elevation Control Mechanism: Bypass User Account Control (T1548.002): https://attack.mitre.org/techniques/T1548/002/

MITRE ATT&CK: OS Credential Dumping (T1003): https://attack.mitre.org/techniques/T1003/

MITRE ATT&CK: Mimikatz (S0002): https://attack.mitre.org/software/S0002/

MITRE ATT&CK: Remote System Discovery (T1018): https://attack.mitre.org/techniques/T1018/

MITRE ATT&CK: Use Alternate Authentication Material: Pass the Hash ( T1550): https://attack.mitre.org/techniques/T1550/002/

MITRE ATT&CK: OS Credential Dumping: DCSync (T1003.006): https://attack.mitre.org/techniques/T1003/006/

TryHackMe — Friday Overtime Challenge Walkthrough

Mon, 09 Dec 2024 00:00:00 +0000

TryHackMe — Friday Overtime Challenge Walkthrough

A Cyber Threat Intelligence Challenge Using DocIntel, Virus Total, MITRE ATT&CK, CyberChef, and Google

Image Credit: https://tryhackme.com/r/room/fridayovertime

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive write-up of the Friday Overtime challenge from TryHackMe, you’re in the right place.

In this scenario, we’re stepping into the world of Cyber Threat Intelligence to analyze a malware sample submission that we received through the DocIntel threat intelligence platform. Our objective is to gather intelligence on this sample, identify what malware family it’s a part of, understand its functionality, and determine what external destinations it contacts. This information will help us create a detailed report for our fictional customer so that we can head into the weekend. To achieve this, we’ll explore resources like VirusTotal, MITRE ATT&CK, and external reports from Google to fully grasp the malware’s capabilities.

The real value of this challenge comes from the research process and becoming adept at collecting threat intelligence from existing reports. With that in mind, I won’t be revealing the answers to the questions in this writeup. Don’t let that deter you — the approach I took isn’t the only one. You’ve got this. Happy hunting!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap! Thanks for reading and going on this investigation with me!

Challenge Link: https://tryhackme.com/r/room/fridayovertime

Challenge Scenario:

Hello Busy Weekend. . .

It’s a Friday evening at PandaProbe Intelligence when a notification appears on your CTI platform. While most are already looking forward to the weekend, you realise you must pull overtime because SwiftSpend Finance has opened a new ticket, raising concerns about potential malware threats. The finance company, known for its meticulous security measures, stumbled upon something suspicious and wanted immediate expert analysis.

As the only remaining CTI Analyst on shift at PandaProbe Intelligence, you quickly took charge of the situation, realising the gravity of a potential breach at a financial institution. The ticket contained multiple file attachments, presumed to be malware samples.

With a deep breath, a focused mind, and the longing desire to go home, you began the process of:

Downloading the malware samples provided in the ticket, ensuring they were contained in a secure environment.

Running the samples through preliminary automated malware analysis tools to get a quick overview.

Deep diving into a manual analysis, understanding the malware’s behaviour, and identifying its communication patterns.

Correlating findings with global threat intelligence databases to identify known signatures or behaviours.

Compiling a comprehensive report with mitigation and recovery steps, ensuring SwiftSpend Finance could swiftly address potential threats.

Question 1: Who shared the malware samples?

First thing’s first, let’s login to the DocIntel portal using the credentials supplied in the challenge’s instructions. DocIntel is an open-source threat intelligence platform for information sharing where we’ll find the request ticket and download the included malware samples.

To answer Question 1, we’ll just need to open the ticket, read the request, and check the sign-off signature to find who sent it in.

Question 2: What is the SHA1 hash of the file “pRsm.dll” inside samples.zip?

Next, let’s download the attachment, samples.zip, from the files section on the right side of ticket and extract the files within the archive. To do this, we’ll need the password provided in the ticket details. Once the files are extracted, we can get the SHA1 hash of pRsm.dll directly from the terminal using the below command:

sha1sum /home/ericatracy/Downloads/pRsm.dll

Question 3: Which malware framework utilizes these DLLs as add-on modules?

Now that we have a file hash to work with, let’s pivot over to VirusTotal and check if this sample has been analyzed on the platform before and see what additional intelligence we can collect about it.

Fortunately for us, this sample has been seen before and there are a high number of hits. To answer Question 3, we’ll focus on the threat / family labels to find the answer.

Question 4: Which MITRE ATT&CK Technique is linked to using pRsm.dll in this malware framework?

If you’re unfamiliar, MITRE ATT&CK is an expansive knowledge base that documents known adversary tactics, techniques, and procedures as observed in world-world attacks. Since Question 4 mentions MITRE ATT&CK, let’s navigate there and search for the family name we found in the last question to gather more information.

MgBot _MgBot is a modular malware framework exclusively associated with Daggerfly operations since at least 2012. MgBot was…_attack.mitre.org

Since there are so many techniques listed on MITRE ATT&CK and in VirusTotal for the malware, we’ll need to pivot out to some external research to narrow it down. From the MITRE ATT&CK page, there are several reference links listed at the bottom.

Let’s select the second link from ESET to read more about the malware framework and pRsm.dll.

Evasive Panda APT group delivers malware via updates for popular Chinese software _ESET Research uncovers a campaign by the APT group known as Evasive Panda targeting an international NGO in China with…_www.welivesecurity.com

There’s a treasure trove of excellent research content in this blog but for Question 4, we’re most interested in the documented MITRE ATT&CK techniques where we’ll learn that pRsm.dll is used to capture audio streams and the corresponding technique ID.

From: https://www.welivesecurity.com/2023/04/26/evasive-panda-apt-group-malware-updates-popular-chinese-software/

Question 5: What is the CyberChef defanged URL of the malicious download location first seen on 2020–11–02?

Continuing with our review of the ESET report, we’ll also discover some additional details about the malware including the origin of the malicious download.

We’re halfway there! While the URL is already defanged within the report, the key detail is that we need to submit the URL after it’s been defanged with CyberChef specifically — Easy enough!

Let’s open CyberChef, input the URL from the ESET report, and apply the Defang URL option to the recipe to get our newly defanged output.

Defanging the Download URL in CyberChef

Question 6: What is the CyberChef defanged IP address of the C&C server first detected on 2020–09–14 using these modules?

We’ll approach Question 6 like we did the last one. We’ll find the malware’s command and control (C&C) server addresses listed in the ESET report’s IOC section under Network.

Pick the IP address that matches the date from the question and jump back over to CyberChef. It can be a little picky, but manually enter the raw IP address into the input box then apply Defang IP Address to the recipe.

Defanging C&C IP Address in CyberChef

Question 7: What is the SHA1 hash of the spyagent family spyware hosted on the same IP targeting Android devices on November 16, 2022?

Finally, we’re going to take what we’ve learned during our intelligence collection and expand our scope by searching for any other malware families hosted on the IP Address from Question 6.

Head back over to VirusTotal. Once we input the IP, navigate to the Relations > Communicating Files tab where we’ll find an Android type file communicating with this IP address.

While the date doesn’t match what the question is looking for, let’s click the entry anyway to see if we can find any leads. Looking at the family label, it matches the spyagent tag referenced in the question, so it seems that we’re on the right track.

Let’s try the SHA-1 hash from the Details tab to verify.

Fantastic! We’ve found the correct sample! Now that we’ve completed Question 7, let’s recap our findings and wrap up this investigation.

Conclusion:

There we have it — sample analyzed! During our investigation, we calculated the SHA1 hash value of a DLL within the sample**.** We then searched VirusTotal for this file hash, which helped us identify the malware family the DLL belongs to. Next, we pivoted to MITRE ATT&CK to understand the malware’s capabilities and searched for external references, where we discovered a detailed analysis from ESET. With the ESET report in hand, we identified indicators of compromise (IOCs), including the initial access download URL and the command and control IP addresses. All this information equips us with what we’ll need to create a comprehensive report for the requestor. Let’s wrap up this investigation and conclude our Friday Overtime.

A big thank you to TryHackMe for the engaging challenge. This was a really fun challenge because the scenario felt realistic and led me down a research rabbit hole. It was cool to learn about DocIntel and get a glimpse into the CTI world. I find it extremely rewarding to start with something as simple as a file hash and continue to unravel the mystery by adding more context through threat intelligence with each new piece of information. It never hurts to continuously practice your research skills and leverage any available reporting when collecting intelligence on a threat — this happens all the time in the field!

Thanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps keep me motivated to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

DocIntel: https://docintel.org/

VirusTotal: https://www.virustotal.com/

MITRE ATT&CK — MgBot (S1146): https://attack.mitre.org/software/S1146/

ESET WeLiveSecurity Blog — Evasive Panda APT group delivers malware via updates for popular Chinese software: https://www.welivesecurity.com/2023/04/26/evasive-panda-apt-group-malware-updates-popular-chinese-software/

TryHackMe — Boogeyman 2 Challenge Walkthrough

Sun, 27 Oct 2024 00:00:00 +0000

TryHackMe — Boogeyman 2 Challenge Walkthrough

Email & Endpoint Forensic Investigation using olevba, strings, & Volatility 3

Image Credit: https://tryhackme.com/r/room/boogeyman2

Introduction:

Are you still afraid of the Boogeyman?

If not, you’ve stumbled on the right blog and welcome to my weekly walkthrough! This blog is a walkthrough of the Boogeyman 2 challenge from TryHackMe which is the second in a series of capstone challenges for the SOC Level 1 path. This challenge is a multi-part digital forensics and incident response (DFIR) investigation focusing on a fictional threat actor called the Boogeyman.

If you want to catch up on how we got here, check out my walkthrough of Boogeyman 1 first.

TryHackMe — Boogeyman 1 Challenge Walkthrough

In this challenge, we will investigate an email, and an endpoint memory dump collected from a victim compromised by this returning, shadowy threat actor. It is our job as security analysts to determine how the Boogeyman got in this time. To unmask the Boogeyman, we’ll utilize a few tools to aid in our investigation including olevba, part of the oletools package, and Volatility for analyzing a memory dump of the compromised workstation.

Doesn’t sound so scary, right?

Now let’s grab our flashlights and shine a light on the Boogeyman’s updated tactics, techniques, and procedures. I don’t want to ruin any of the surprises, so this walkthrough is spoiler-free, but please use it as a reference and enjoy! Thanks for reading along!

Challenge Link: https://tryhackme.com/r/room/boogeyman2

Challenge Scenario:

After having a severe attack from the Boogeyman, Quick Logistics LLC improved its security defences. However, the Boogeyman returns with new and improved tactics, techniques and procedures.

In this room, you will be tasked to analyse the new tactics, techniques, and procedures (TTPs) of the threat group named Boogeyman.

Maxine, a Human Resource Specialist working for Quick Logistics LLC, received an application from one of the open positions in the company. Unbeknownst to her, the attached resume was malicious and compromised her workstation.

The security team was able to flag some suspicious commands executed on the workstation of Maxine, which prompted the investigation. Given this, you are tasked to analyse and assess the impact of the compromise.

Question 1: What email was used to send the phishing email?

Jumping right into our environment let’s start with the email, “Resume — Application for Junior IT Analyst Role.eml,” from within the Artefacts folder.

While there are a number of ways that we can approach the header analysis of this message, let’s just open it with the default text editor and do manual header analysis for the first few questions.

We’ll start out with a simple one; all we’re looking for is the From field in the email to find the sender’s address. Once we’ve found it, we can answer Question 1.

Question 2: What is the email of the victim employee?

By finding the From field in the email header, we’ve also discovered the To field right below it which has the victim, Maxine’s, email address.

Question 3: What is the name of the attached malicious document?

We can discover the attachment’s filename by simply searching for “attachment” within the text file. This will take us to the Content-Description/Disposition fields where we can see the name of the attached malicious document.

Question 4: What is the MD5 hash of the malicious attachment?

While we have a couple of ways of approaching this, let’s take the path of least resistance and simply download the attachment by opening the .eml file with the default email client installed in the analysis environment.

Once downloaded, we can use the md5sum command from the terminal to compute the MD5 hash of the attachment.

md5sum NAME-OF-ATTACHMENT-Q3.doc

Question 5: What URL is used to download the stage 2 payload based on the document’s macro?

Okay, now it’s time to perform some static analysis of the malicious attachment. Since the question mentions macros and the attachment type is .doc, let’s check out the tool mentioned in the tutorial for this challenge— olevba, part of the oletools suite by Philippe Lagadec (decalage2).

According to the project’s GitHub repository:

olevba is a script to parse OLE and OpenXML files such as MS Office documents (e.g. Word, Excel), to detect VBA Macros, extract their source code in clear text, decode malware obfuscation (Hex/Base64/StrReverse/Dridex) and detect security-related patterns such as auto-executable macros, suspicious VBA keywords used by malware, and potential IOCs (IP addresses, URLs, executable filenames, etc).

Sounds useful! Let’s put olevba to work and parse the attachment to see if it discovers anything that could help us answer Question 2 by using the command below:

olevba

At the bottom of the output, we’ll find a handy summary of what the tool uncovered. Items marked with IOC are indicators of compromise, or items that can potentially help with our investigation like IP Addresses, URLs, or file names. Here we’ll see that olevba extracted a suspicious URL that might be related to the threat actor…

olevba summary table

Question 6: What is the name of the process that executed the newly downloaded stage 2 payload?

Now, instead of focusing on the summary results, let’s look a little more closely at the macro details where the IOC is located. Scroll back toward the top of the olevba output right above the summary table and look for the stream ‘Macros/VBA/NewMacros’

Looking at the macro it seems that once the stage 2 payload is downloaded from the URL (Question 5), it is saved as a JavaScript (.js) file and then executed with a specific process — this is what we need to answer Question 6.

Question 7: What is the full file path of the malicious stage 2 payload?

Because we already found the process that executed the payload in the last question, we also discovered the file path where the JavaScript payload was executed from.

Question 8: What is the PID of the process that executed the stage 2 payload?

All right, now we’re going to pivot to performing memory forensics using Volatility 3.

If you aren’t familiar with Volatility, it’s a “widely used framework for extracting digital artifacts from volatile memory (RAM) samples.” In other words, we can use it to analyze the raw memory dump artifact WKSTN-2961.raw!

But how do we get started looking for the answer to Question 8? A pro tip is to leverage Volatility’s help function to see what plugins are available:

vol.py -h

After reviewing the available plugins, we’ll start by getting an overview of all the processes running at the time the memory dump was taken on the victim’s system and see the process IDs (PID) listed in the PID column on the far left.

vol -f WKSTN-2961.raw windows.psscan

Then, we can search the output manually for the process name that we found in Question 6.

Alternatively, we can work a little bit smarter and use grep to show us only the results that match the process name.

vol -f WKSTN-2961.raw windows.psscan | grep “PROCESS-NAME-FROM-QUESTION-6”

It’s your choice! Either way, the PID column is the answer we need.

Question 9: What is the parent PID of the process that executed the stage 2 payload?

Fortunately, by finding the answer to Question 8, we also found the answer to Question 9 already. We just need to input the value in the parent process ID (PPID) column!

Question 10: What URL is used to download the malicious binary executed by the stage 2 payload?

All right, we’ve gotten a good start with Volatility but to answer Question 10 we need to go a step further and see if the processes that executed the stage 2 payload (Question 8) also has any child processes_._ The idea here is that by looking for processes spawned by the binary that launched the stage 2 payload, we can analyze the payload and find any additional URLS.

To accomplish this, we’ll leverage Volatility’s [windows.pstree](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pstree) to list the process tree and view the relationships between the processes. To keep it simple, let’s use grep again to show us only results with the PID of the process that executed the stage 2 payload that we found in Question 8.

vol -f WKSTN-2961.raw windows.pstree | grep “PID-FROM-QUESTION-8”

Okay, there is a child process! Let’s try to determine where this executable came from by dumping the process with Volatility’s [windows.memmap](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#memmap) plugin and searching for new evidence:

vol -f WKSTN-2961.raw windows.memmap –pid –dump

Running this command creates .dmp file of the process. Then, we can try running strings command to pull out any artifacts from the process dump. Since we know of the domain (Question 5) that downloaded the 2nd stage payload, let’s start there:

strings pid.REDACTED.dmp | grep “files.boogeymanisback.lol”

Unfortunately, while we see the domain, we don’t have a full URL path to the malicious binary within the process dump. So, why don’t we just try running strings against the complete raw memory dump instead to check the whole thing in one shot?

strings WKSTN-2961.raw | grep “files.boogeymanisback.lol”

There we go! Now we’ve found a second file from this domain — this is the malicious binary that we’re looking for.

Question 11: What is the PID of the malicious process used to establish the C2 connection?

Although this is a bit out of order, we already found the answer by searching for the child process in the previous question. Now, we just need to input the PID of the child process we found.

Question 12: What is the full file path of the malicious process used to establish the C2 connection?

To answer Question 12, we need to find the full file path of the malicious child process. For this task, we can use the Volatility windows.cmdline plugin.

This plugin can help us by showing not only the process command line arguments but also the executable file path of the process.

vol -f WKSTN-2961.raw windows.cmdline –pid PID-FROM-QUESTION-11

Question 13: What is the IP address and port of the C2 connection initiated by the malicious binary? (Format: IP address:port)

Now that we know the PID and file path of the malicious binary, let’s dive deeper and search for any network connections established by the process, which could lead us to the command and control (C2) server.

We’ll use the [windows.netscan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan) plugin to scan for network artifacts like IP addresses, ports, and protocols. Then, we’ll combine it with grep to filter the relevant results for the malicious process PID from Question 11.

vol -f WKSTN-2961.raw windows.netscan | grep -i “PID-FROM-QUESTION-11”

Volatility windows.netscan output for the malicious binary

Once we run the command, we’ll see the output table listing the external ForeignAddr and ForignPort columns that the malicious binary is connected to. These should be the IP address and port of the C2 connection we are looking for.

Question 14: What is the full file path of the malicious email attachment based on the memory dump?

We already identified the name of the malicious attachment in Question 3, which gets us halfway to our goal. Now, we just need to find the full file path of the downloaded email on the victim’s system.

To accomplish this, we can use Volatility’s [windows.filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin to search for file objects within the image.

Using grep to search the term “Resume,” we can uncover the path of the malicious CV sent by the Boogeyman threat actor.

vol -f WKSTN-2961.raw windows.filescan | grep “Resume”

Although there are two entries, we can see the file path in the image points to the same temporary Microsoft Outlook content storage folder.

Question 15: The attacker implanted a scheduled task right after establishing the c2 callback. What is the full command used by the attacker to maintain persistent access?

Okay, we’ve made it to the last step. To finally unmask the Boogeyman this time, we need to analyze the scheduled task that the threat actor used for persistence on the victim’s system (MITRE ATT&CK T1053.005.)

To do this, we’re going to use strings on the RAW dump file again but this time we’ll look for Windows Task Scheduler artifacts. There are two ways that this can be done, let’s take a brief look at what we will search for.

taskschd: This is the GUI version of the Task Scheduler in Windows.

schtasks: This is the CLI version of the Task Scheduler in Windows.

We’re going to try both and see if we can find any relevant artifacts starting with taskschd:

strings WKSTN-2961.raw | grep -i “taskschd”

It doesn’t seem like there is anything interesting here. Let’s try schtasks next:

strings WKSTN-2961.raw | grep -i “schtasks”

Now we’ve found something interesting, the threat actor has created a new task using schtasks. This is exactly what we need to answer the last question and wrap up this investigation!

Conclusion:

Mission accomplished! We have completed our frighteningly fun investigation of Boogeyman 2! Using our forensic skills, we discovered that this time the Boogeyman infected the victim’s device through email with a malicious attachment. Then the threat actor used living-off-the-land binaries to download a stage 2 payload, establish command and control, and maintain persistent access using schtasks. Now, let’s wrap this investigation!

A huge thank you to TryHackMe for the excellent part II of the Boogeyman series. This challenge is perfect for sharpening our security skills during the spooky Halloween season! I was really impressed with the dimensions of this room, as it had two different scopes and a complete narrative of the Boogeyman’s return. The detail and flow were much closer to a real-world simulation exercise than others I have completed. It was really engaging to see how the fictional threat actor changed tactics, techniques, and procedures between the two rooms.

If you want to brave the next Boogeyman adventure with me, please check out my walkthrough of the Boogeyman 3. Until the Boogeyman returns yet again, stay vigilant!

TryHackMe — Boogeyman 3 Challenge Walkthrough

But if this is the end of our journey together, please consider giving this walkthrough a clap if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question. Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

Tools & References:

Olevba: https://github.com/decalage2/oletools/wiki/olevba

Volatility Framework: https://github.com/volatilityfoundation/volatility3

Volatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

Microsoft Learn (schtasks): schtasks commands | Microsoft Learn

MITRE ATT&CK — Scheduled Task/Job: Scheduled Task (T1053.005): https://attack.mitre.org/techniques/T1053/005/

TryHackMe — Benign Challenge Room Walkthrough

Sun, 29 Sep 2024 00:00:00 +0000

TryHackMe — Benign Challenge Room Walkthrough

An Endpoint Forensic Investigation using Splunk

Image Credit: https://tryhackme.com/r/room/benign

Introduction:

Imagine this: You’re on the front lines of your organization’s security team when suddenly, intrusion detection alerts start firing from an endpoint, indicating discovery and persistence activity. You need to dive into your security logging platform, investigate the logs, and contain the threat. If this sounds like a thriller you want to be part of, you’ve stumbled upon the right blog!

Welcome to my weekly walkthrough! This week, we’re tackling the Benign room from TryHackMe. Using the Splunk data and logging platform, we’re going to investigate a compromised endpoint, but we only have the process execution logs (Event ID: 4688) ingested into the platform. Together, we’ll analyze the logs to find the compromised endpoint and then uncover how the malicious payload was downloaded onto the system, where it was hosted, and how it bypassed the security controls to get there. Sounds like fun, right? Let’s get to it!

In the spirit of learning, I won’t be revealing any flags in this write-up, but I hope that this guide sets you on the right track — you got this! If you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback helps me improve and continue supporting your security journey. Thanks for reading!

Challenge Link: https://tryhackme.com/r/room/benign

Challenge Scenario:

One of the client’s IDS indicated a potentially suspicious process execution indicating one of the hosts from the HR department was compromised. Some tools related to network information gathering / scheduled tasks were executed which confirmed the suspicion. Due to limited resources, we could only pull the process execution logs with Event ID: 4688 and ingested them into Splunk with the index win_eventlogs for further investigation.

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

Let’s dive right in and start by getting an overview of how many logs have been ingested by Splunk in March 2022. First, we’ll open the Search & Reporting App from the left side of the dashboard:

Once inside of the Search tab, we’ll need to select the correct index that we want to query. Remember from the challenge scenario that the captured process execution logs were ingested into the win_event_log index.

Due to limited resources, we could only pull the process execution logs with Event ID: 4688 and ingested them into Splunk with the index win_eventlogs for further investigation.

So, to answer Question 1 we’ll need to find the total number of events ingested in March 2022. To do that we’ll first input the index name we want to search, then hit the date/time button to change the search range. Let’s select a Date Range between 03/01/2022 and 03/31/2022 and then press Apply.

This will show us the total number of events during the selected date range to answer Question 1.

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

Okay, before diving into the logs again let’s pull back and review the information provided to us. We have a list of usernames and their corresponding departments which will be our point of comparison for “real” users versus “imposter” users.

About the Network Information

The network is divided into three logical segments. It will help in the investigation.

IT Department

James

Moin

Katrina

HR department

Haroon

Chris

Diana

Marketing department

Bell

Amelia

Deepak

Now that we have the correct index and date range selected already, let’s start to analyze the data.

To answer Question 2, we need to look at all the usernames captured within the ingested data. For that, we can leverage the stats command to display all the aggregated usernames from the UserName field.

win_event_log | stats count by UserName

This will show us all 11 of the UserNames in the data! After a comparison with the provided users list, we’ll find one that looks similar but not quite right…

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

Alright, to find the answer to Question 3 we’re going to search for evidence of persistence by looking for scheduled tasks activity within the HR department.

Since Splunk only has ingested logs for the process execution events we’ll need to use the name of the scheduled tasks executable in our search — schtasks.exe

win_event_log schtasks

This will return 87 scheduled task events, but we can speed up our analysis by looking at the usernames that appear in these events by selecting UserNames from the selected fields header.

This shows us four usernames appearing in the data set, so let’s just match the visible entries against the HR department list and see which user appears…

HR department

Haroon

Chris

Diana

Okay! Now we’re going to dive deeper into our analysis and look for indicators of how the actor brought the payload/tools into the environment.

The first thing to do is narrow down our search scope and only view the logging data for the HR department users. Remember, we already have a list of all HR users from the previous question so all we need to do is format our query to include only those users:

win_event_log UserName=Daina OR UserName=“Chris.fort” OR UserName=“Haroon”

But even with the tighter search scope, we still have too many logs to go through manually.

Next, we need to drill down even further by searching for activity related to living off the land binaries (LOLBINS). For some background, LOLBINS are legitimate Microsoft-signed binaries that are native to Windows which could also be abused to perform some unintended activity by an adversary.

Fortunately, we don’t have to know these off the top of our heads and we can instead refer to the living off the land binaries and scripts (LOLBAS) repository on GitHub!

LOLBAS _contribute, check out ourcontribution guide. Ourcriteria list sets out what we define as a LOLBin/Script/Lib. More…_lolbas-project.github.io

While the LOLBAS repository is a great start, we still need to find the exact tool within the list. Let’s work a little smarter and take a look at the MITRE ATT&CK knowledge base and see if we can find some specific tools in Windows that are used for Ingress Tool Transfer (MITRE ATT&CK T1105.)

According to the page for this technique:

On Windows, adversaries may use various utilities to download tools, such as copy, finger, certutil, and PowerShell commands such as IEX(New-Object Net.WebClient).downloadString() and Invoke-WebRequest.

Now if we cross-reference these utilities with the LOLBAS repository, we will find a couple of utilities to search for!

So, putting all of this together, we are going to use Splunk to search the win_event_log index containing known HR users, where the captured process command line (4688) matches one of the LOLBAS download methods that we validated with MITRE ATT&CK.

win_event_log UserName=Daina OR UserName=“Chris.fort” OR UserName=“Haroon” | search CommandLine="NAME OF LOLBIN"

And there we go — we found a hit in the logs! Look at the UserName field, this is the answer to Question 4. Keep this search result open as we are going to use it to answer the next few questions too.

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

Fortunately, we already found the answer since the lolbin name was how we discovered the answer to Question 4.

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

From the same event that we found in Question 4, enter the date from the Time column or the EventTime field from the event log — they are the same.

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

In the CommandLine field, there is a visible URL in the command. The domain name is what we are looking for to answer Question 7.

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

The file path the end of the C2 URL from the previous question points to an executable (.exe) file that is downloaded on the victim’s system.

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

Now that we have analyzed the suspicious event within Splunk, we need to start looking at the malicious content, but how do we do that? Well, the wording of this question is a bit confusing but since we do not have access to the suspicious binary within our ingested data, we’re going to pivot and gather some intelligence on the C2 URL instead.

Let’s start out by checking the C2 URL against VirusTotal to see if we can gather any information about it.

VirusTotal VirusTotalwww.virustotal.com

While the detection looks clean, let’s navigate to the Details tab to get some extra information. Navigate to the HTML Info section and check out the Meta Tags — notice anything interesting?

Is that a flag we see?

Question 10: What is the URL that the infected host connected to?

Okay, we’ve reached the last question, and it’s a straightforward one. The URL that the infected host connected to is the same one we used to answer Question 9. Simply copy, paste, and submit the final flag!

Conclusion:

A big thank you to TryHackMe for another awesome hands-on challenge! By leveraging Splunk, we’ve successfully identified the affected HR user and uncovered how a Living off the Land (LOLBIN) binary was abused to bypass security controls and download the malicious payload. Our investigation revealed that the payload was hosted on a suspicious URL, which we traced back to a compromised website with some interesting metadata.

The Benign room is a great opportunity to go hands-on with Splunk, exercise your research skills, and get familiar with the LOLBAS repository. As a defender, understanding how legitimate binaries are abused can help enrich your investigations and uncover the whole attack story. Personally, I find every opportunity to practice log analysis in a logging or SIEM platform helpful to keep my skills sharp and get the repetitions in with the tool. With the analysis of the logs completed, let’s wrap up this investigation!

Remember, if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

Splunk (Stats): https://docs.splunk.com/Documentation/Splunk/9.3.1/SearchReference/Stats

Microsoft Learn (schtasks.exe): https://learn.microsoft.com/en-us/windows/win32/taskschd/schtasks

MITRE ATT&CK — Ingress Tool Transfer — T1105: https://attack.mitre.org/techniques/T1105/

Microsoft Learn (Certutil): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil

VirusTotal: https://www.virustotal.com/gui/url/ec89f7db79c0760ecd6676a32feb5b0362526cbd491302ff3ad7bb0b640d21ce/details

TryHackMe — Boogeyman 1 Challenge Walkthrough

Sun, 04 Aug 2024 00:00:00 +0000

TryHackMe — Boogeyman 1 Challenge Walkthrough

Email, Endpoint, & Network Forensic Investigation using Thunderbird, LNKParse3, PowerShell Logs, JQ, & Wireshark

Image Credit: https://tryhackme.com/r/room/boogeyman1

Introduction:

Are you afraid of the Boogeyman?

If not, welcome to my weekly walkthrough, you’ve stumbled on the right blog! This blog is a walkthrough of the Boogeyman 1 challenge from TryHackMe and is the first in a series of capstone challenges for the SOC Level 1 path. This challenge is a multi-part digital forensics and incident response (DFIR) investigation focusing on a fictional threat actor called the Boogeyman.

In this challenge, we will investigate email, endpoint, and network artifacts collected from a victim compromised by this new, shadowy threat actor. It is our job as security analysts to determine how the Boogeyman got in, what they took, and how they did it. Doesn’t sound so scary, right?

To unmask the Boogeyman, we’ll utilize a few tools at different points in our investigation including LNKParse3, JQ to parse JSON formatted PowerShell logs, and Wireshark for deep packet capture analysis.

Now let’s grab our flashlights and shine a light on the Boogeyman’s tactics, techniques, and procedures. I don’t want to ruin any of the fun, so this walkthrough will not contain spoilers, but please use this as a reference and enjoy! Thanks for reading along!

Challenge Link: https://tryhackme.com/r/room/boogeyman1

Challenge Scenario:

Uncover the secrets of the new emerging threat, the Boogeyman.

In this room, you will be tasked to analyse the Tactics, Techniques, and Procedures (TTPs) executed by a threat group, from obtaining initial access until achieving its objective.

Task 2 — Email Analysis

Julianne, a finance employee working for Quick Logistics LLC, received a follow-up email regarding an unpaid invoice from their business partner, B Packaging Inc. Unbeknownst to her, the attached document was malicious and compromised her workstation.

The security team was able to flag the suspicious execution of the attachment, in addition to the phishing reports received from the other finance department employees, making it seem to be a targeted attack on the finance team. Upon checking the latest trends, the initial TTP used for the malicious attachment is attributed to the new threat group named Boogeyman, known for targeting the logistics sector.

You are tasked to analyse and assess the impact of the compromise.

Question 1: What is the email address used to send the phishing email?

We’ll jump right into our environment and look at the dump.eml file. There are number of ways that we can approach header analysis of this email, but let’s just open with the Mozilla Thunderbird client so that we can get the victim’s perspective.

The phishing email.

We’ll start out with a simple one and enter the From field address to answer Question 1.

Question 2: What is the email address of the victim?

We’ll follow the same process for Question 2 except this time we will enter the To field name which is the recipient address.

Question 3: What is the name of the third-party mail relay service used by the attacker based on the DKIM-Signature and List-Unsubscribe headers?

Now, we need to get more detail beyond what’s shown in the normal, visible headers by viewing the message source.

To do this in Thunderbird press More > View Source.

It might look a little scary at first, but let’s use the find function of the text editor to locate the DKIM-Signature line:

If you would like more information on what DKIM is or what the header means, refer to the excellent Email Headers list from Mailtrap.io. I refer to this list often when I need additional context for email header analysis!

Email Headers Explained: Definition, Components, Role [2024] _Email Headers contain important information and can be useful for improving email deliverability. Learn what they are…_mailtrap.io

Question 4: What is the name of the file inside the encrypted attachment?

Now, let’s download the suspicious ZIP archive file from the email message and save it to our artefacts folder. If we peek inside of the archive, we’ll see a .lnk (shortcut) file within it.

Very suspicious, indeed! Fortunately, this is enough information to answer Question 4!

Question 5: What is the password of the encrypted attachment?

Let’s jump back to Thunderbird and review the suspicious email sent to the victim. We’ll notice that the sender was kind enough to send us a handy password to open the archive.

Now that we have the password for the ZIP file, we will extract the .lnk file. In the next question, we’ll perform some analysis on this LNK file in the next question.

Question 6: Based on the result of the lnkparse tool, what is the encoded payload found in the Command Line Arguments field?

Now that we have extracted the .lnk from the archive, we’ll parse it and see if we can determine what it does. To do this, we will use the tool suggested in the challenge introduction — LnkParse3.

Within our analysis environment, open up the terminal and use the following syntax to parse the file:

lnkparse NAME-OF-FILE.lnk

Scroll through the output and we’ll see something interesting — an encoded PowerShell command. This is extremely suspicious and definitely requires further investigation.

For now, we only need to submit the encoded command to answer Question 6 before we move on to investigating the victim’s endpoint device.

Task 3 — Endpoint Security

Based on the initial findings, we discovered how the malicious attachment compromised Julianne’s workstation:

A PowerShell command was executed.

Decoding the payload reveals the starting point of endpoint activities.

Question 1: What are the domains used by the attacker for file hosting and C2? Provide the domains in alphabetical order. (e.g. a.domain.com,b.domain.com)

So, we know that a malicious PowerShell command was executed from the execution of malicious attachment we analyzed in the previous task. To determine the impact of the malicious attachment, we’re going to need to analyze the Windows PowerShell event logs.

But first, let’s decode the Base64 encoded payload that we discovered within the attachment. There are a few tools to do this, but for simplicity, I’ll just utilize the Base64 command to decode this in the terminal_:_

echo “ENCODED STRING” | base64 -d

Let’s note this URL and move on to analyzing the PowerShell logs. We have just a quick detour — remember the note from Task 1?

Note: The powershell.json file contains JSON-formatted PowerShell logs extracted from its original evtx file via the evtx2json tool.

So, rather than viewing the exported PowerShell Windows Event Log (.evtx) file, we are going to rely on JQ, which is a command-line based JSON parsing tool to parse the PowerShell.json.

We will start with the simplest option; parsing the JSON file into the beautified output using the syntax below:

cat powershell.json | jq

Right away, we will see a ton of information but it’s too much output to sift through manually. Let’s filter by events by “ScriptBlockText” so that we can focus on events with statements that we can analyze.

According to Microsoft:

In the PowerShell programming language, a script block is a collection of statements or expressions that can be used as a single unit. The collection of statements can be enclosed in braces ({}), defined as a function, or saved in a script file. A script block can return values and accept parameters and arguments.

Let’s go a step further too. We’ll re-tool our JQ filter to apply sorting by Timestamp, the ScriptBlockText field, and remove duplicate entries:

cat powershell.json | jq -s -c ‘sort_by(.Timestamp) | .[] | {ScriptBlockText}’ | sort | uniq

While this still returns a lot of output, we’ve filtered to the most relevant output for our search. In particular, there are a couple of interesting lines that are requesting data with different URLs — one uses Invoke-WebRequest and the other t_hat we already found by decoding the Base64 command uses WebClient._

These are the two command and control (C2) domains that we are looking for to answer Question 1!

Question 2: What is the name of the enumeration tool downloaded by the attacker?

We’ll keep with the same JQ output since we actually saw this earlier while looking for the C2 URLs.

The attacker downloaded a tool from a GitHub Repository, but is it an enumeration tool? Let’s do some research to find out.

See the name of the .ps1 file referenced at the end of the command? Navigate to the GitHub repository and we can locate the separate repository for referenced tool!

We’ll do some quick reading through the documentation for this project to discover that the tool does contain some enumeration function using WMI - this confirms that we discovered the correct tool!

Question 3: What is the file accessed by the attacker using the downloaded sq3.exe binary? Provide the full file path with escaped backslashes.

Okay, now we are looking for a specific executable. We’ll keep with using JQ but we need to adjust our scope. What if we grep the output to display only results containing sq3.exe?

cat powershell.json | jq ‘{ScriptBlockText}’ | grep “sq3.exe”

Hey, that’s getting us closer! We found a file that the executable accessed. Now all we need to know is the user account name to add to the front of the path. We’ll use the same command as before but revise the grep to the change directory (cd) command. This should help us understand how the attacker traversed the victim’s directories and disclose a valid profile name.

cat powershell.json | jq ‘{ScriptBlockText}’ | grep “cd”

Here, we’ll find references to a user profile name. Append this profile name to the path we found earlier accessed by sq3.exe to form our answer!

Question 4: What is the software that uses the file in Q3?

To answer this question, look at the file path from the previous question:

The file is a database that stores information for a specific application, the specific application is the answer to Question 4.

Question 5: What is the name of the exfiltrated file?

Let’s pull back and revisit the JQ output for ScriptBlockText that we used in Question 1 and browse through the output again. We’ll stumble across the following line where we can see some evidence of a file being exfiltrated to an external IP address:

Submit the IP address as the answer but also add it to your notes as we may need it again later!

Question 6: What type of file uses the .kdbx file extension?

If you aren’t familiar with this file type, do some quick Google research to determine what application uses it. There is a help center for the application that has a detailed specification page about the file extension.

Question 7: What is the encoding used during the exfiltration attempt of the sensitive file?

Continue reviewing the JQ parsed command output. Following the line we discovered to answer Question 5, we’ll see another interesting item that contains the file encoding used during the exfiltration:

Question 8: What is the tool used for exfiltration?

To answer Question 8, refer back to the previous question’s output that contains the encoding method and look further down the command.

After the data is encoded, we’ll see another command which appears to be using DNS to query the A record of attacker-controlled infrastructure at the $destination variable. Remember that the IP address we found in Question 5 was defined as $destination?

This looks like it might be a living off the land exfiltration technique where targeted data is encoded, split to a character limit, and then exfiltrated though DNS queries to the adversary’s infrastructure by appending the data (the $line variable) to a domain name where it can be reassembled or interpreted by the adversary.

Maybe we will get more information when we move into the network packet capture analysis…

Task 4 — Network Traffic Analysis

Based on the PowerShell logs investigation, we have seen the full impact of the attack:

The threat actor was able to read and exfiltrate two potentially sensitive files.

The domains and ports used for the network activity were discovered, including the tool used by the threat actor for exfiltration.

Question 1: What software is used by the attacker to host its presumed file/payload server?

Now, we are moving into the next phase of our investigation, the network traffic analysis. From the artefact folder, double-click capture.pcapng to open it with Wireshark.

Once we’re in Wireshark, we need a starting point for the next phase of our investigation. Let’s begin by inputting the attacker’s infrastructure IP address that we located in Question 5 of the Endpoint Security section into Wireshark’s filter:

ip.addr==167.71.211.113

That’s a lot of output, so let’s make this a bit more manageable and focus on the HTTP protocol traffic by further adjusting our filter.

http && ip.addr==167.71.211.113

Much more manageable! Let’s focus in on the first HTTP response (33256.) Right click the packet row > Follow > HTTP Stream.

Once the HTTP Stream window opens, we can check out the Server field to determine what application is hosting the web server:

Question 2: What HTTP method is used by the C2 for the output of the commands executed by the attacker?

We found this information when analyzing the PowerShell logs in Endpoint Security Question 1, remember? If not, here’s a refresher:

Since, we know the attacker is exfiltrating the data out and not requesting it in, the method would NOT be GET…

Question 3: What is the protocol used during the exfiltration activity?

Remember back in Question 8 of the Endpoint Security Section (Task 3) we discovered that the exfiltration tool used a specific protocol? This is the answer to Question 3.

Question 4: What is the password of the exfiltrated file?

Since this gets a little complicated, let’s lean on the question hint:

Thanks, THM! So, the working theory here is that we need to locate a password that the victim stored in the file that accessed by sq3.exe in the Endpoint Investigation (Question 3) to “unlock” the exfiltrated file.

So, let’s leverage Wireshark’s search function to search the packets for a keyword. First, press CTRL + F to bring up the find/search bar, then select String, and finally select Packet details so we can search within middle “packet details” window. Now enter sq3.exe into the search box.

Here, we will locate an HTTP GET request packet (42700), but since the attacker took the data and sent it out, we’re looking for a POST request.

If we continue with the find function, there are four hits for sq3.exe. The last one has the same PowerShell command in the text data that we found in the Endpoint Analysis section for Question 3. It feels like we are getting closer!

So, we’ll use 44459 as our starting point for searching POST requests. We’ll need to cut down the noise by filtering HTTP POST methods since we can’t simply just keep searching sq3.exe. We can further narrow our scope by also filtering anything below our starting point frame number.

http.request.method==POST && frame.number > 44459

This gets us down to nine entries. Let’s start analyzing the first entry (44467) and Follow > HTTP Stream:

Well, that’s a big blob of something! Let’s drop it into CyberChef so that we can do some decoding operations and see if we can get something readable. To start, we can go lazy mode and see if the Magic function can do anything for us:

It looks like CyberChef can do some decoding if we apply the From Decimal recipe. Let’s apply it and see what we can find…

Bingo! We found the “Master Password” that the victim stored in plain text— not good!

Question 5: What is the credit card number stored inside the exfiltrated file?

Alright, we made it to the last question! Now that we have a “Master Password” we need to unlock something with it…

Let’s recap what we know so far:

The exfiltrated file is a type of database that would require a master password. We know what application it is from Task 3 — Question 6.
From Question 8 of the previous task, we also know that this database was being converted to Hexadecimal in blocks, and exfiltrated over DNS A record queries to the destination IP address of 167[.]71[.]211[.]113
Each DNS query is sent in the format of an encoded string ($line) appended to bpakcaging[.]xyz.

Below is the evidence from that question for our reference:

PowerShell Reference of the KDBX Exfiltration

So, we know the file, protocol, domain, and IP address. Let’s try to leverage Wireshark to filter out just the packets relevant to this information. To do this, we need to adjust our filter again.

First, I went to Wikipedia to find out the type id for the DNS A Record which is 1. This helps us build our Wireshark query to only look at DNS A records. Then we also input the IP address that the data is exfiltrated to.

dns.qry.type==1 && ip.dst==167.71.211.113

Now, we will see a ton of rows returned but the data matches the format that we expected based on what we learned about the exfiltration method. But it isn’t readable just yet.

So, now we need to figure out how to reassemble this data. We’re going to move it out of Wireshark so we’ll first export this data by selecting all the filtered packets and pressing File > Export Packet Dissections > As Plain Text.

For the purposes of this walkthrough, my output file is called AQuery.txt. When we open AQuery.txt in a text editor, it looks like this:

While helpful, we still need to clean up this data to carve out only the Hex encoded strings that we need. I’m certain there is a better way to do this (alluded to in the question hint) but my approach is to try to transform this data from within the terminal.

To save you some time, I freely admit that there was a lot of stumbling, trial and error, and time spent researching with Google and Microsoft Copilot to come up with command using grep and sed that would work to clean up the data, until at long last, I landed on the below version:

grep -Eo ‘[0-9a-fA-F]{8,}.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}’ AQuery.txt | sed ’s/.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}.*//’ | uniq | tr -d ' '

Here’s the long story short(ish) — The grep command is performing some pattern matching to display only the Hex strings followed by a “domain.tld” and trailing text from our Wireshark output file. Then, sed removes the domain and any trailing text, removes duplicate entries, and concatenates the results into a single line without any delimiters so it’s a long, single line combining all the Hex strings we found being sent to the C2 domain.

But now that we have the required data, we still need to output the file so that we can convert it from Hex into a working database file.

grep -Eo ‘[0-9a-fA-F]{8,}.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}’ AQuery.txt | sed ’s/.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}.*//’ | uniq | tr -d ' ’ > hexdump.txt

We’re almost there! Now we’ll convert the Hex data to ASCII and save the database as a new output. We’ll achieve this by processing it with xxd.

xxd creates a hex dump of a given file or standard input. It can also convert a hex dump back to its original binary form. Like uuencode(1) and uudecode(1) it allows the transmission of binary data in a ‘mail-safe’ ASCII representation, but has the advantage of decoding to standard output. Moreover, it can be used to perform binary file patching.

xxd -r -p hexdump.txt > database.kdbx

Finally, we can open the reassembled KDBX file! The TryHackMe analysis environment already has the correct application to open this file type and it should automatically be associated.

Once it opens, we are prompted for the Master Password that we recovered in the previous question. Inputting the password unlocks the database and allows us to retrieve the credit card number that the victim stored in their password manager which is now in the hands of the adversary! Time to call the bank, indeed!

Go ahead and input the victim’s credit card number and let’s wrap up this investigation.

Conclusion:

Mission accomplished — We have completed our frighteningly fun investigation of the Boogeyman 1! Using our forensic skills, we learned how the Boogeyman infected the victim’s device with a malicious attachment, collected and exfiltrated data with PowerShell and DNS, and stole credit card data stored in KeePass. Now, let’s wrap this investigation!

A huge thank you to TryHackMe for the seriously fun challenge! I was really impressed with the dimensions of this room as it had three different scopes and a complete narrative. The detail and flow were much closer to a real-world simulation exercise than others I have completed. The escalating difficulty was also really engaging as it started out easy and ramped up as the room went on. This really pushed me out of my comfort zone and forced creativity when it came to the later steps of the Networking Traffic Analysis. I was also excited to have the opportunity to get some hands-on time with JQ as I was familiar with the name but had not encountered it before.

If you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Until the Boogeyman returns, stay safe! If you want to continue battling the Boogeyman, be sure to check out my walkthrough of the Boogeyman 2.

TryHackMe — Boogeyman 2 Challenge Walkthrough

Tools & References:

Mailtraip.io Email Headers List: https://mailtrap.io/blog/email-headers/

LnkParse3: https://github.com/Matmaus/LnkParse3

JQ: https://jqlang.github.io/jq/

Microsoft Script Block: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_script_blocks?view=powershell-7.4

Microsoft Learn (WebClient Class): https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-8.0

Microsoft Learn (Invoke-WebRequest): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7.4

CyberChef: https://gchq.github.io/CyberChef/

Wikipedia DNS Types: List of DNS record types — Wikipedia

Linux Man Pages (XXD): https://linux.die.net/man/1/xxd

TryHackMe — ItsyBitsy Challenge Walkthrough

Sun, 23 Jun 2024 00:00:00 +0000

TryHackMe — ItsyBitsy Challenge Walkthrough

Incident Response Challenge using the Elastic Stack

Image Credit: https://tryhackme.com/r/room/itsybitsy

Introduction:

Welcome to my weekly walkthrough!

Are you curious about investigating incidents using the Elastic (ELK) stack? Well you’re in luck — we’re about to tackle the ItsyBitsy challenge from TryHackMe!

ItsyBitsy is a DFIR challenge where we will analyze the HTTP network connection logs captured from a device. The not great news is that this device was making some suspicious network calls to a potential command and control server. To figure out what happened, we’ll use the Kibana module within the Elastic Stack to search the through logs, visualize the data, and determine what was downloaded.

But first, a high-level infographic of where Kibana fits into the Elastic Stack:

Image Credit: https://tryhackme.com/r/room/investigatingwithelk101

Want more? Go check out the full Investigating with ELK 101 room on TryHackMe which covers the ELK stack fundamentals in much more detail.

So, whether you’re here to learn more about investigating with Elastic, or are just looking for a reference walkthrough for the ItsyBitsy challenge, you’ve stumbled on the right blog. In the spirit of learning, I am not going to be revealing any flags in this write-up, so I encourage you to go hands-on and try it for yourself — you got this!

Now let’s put on our detective hats and have some fun with forensics!

Thanks for reading along!

Challenge Link: https://tryhackme.com/r/room/itsybitsy

Challenge Scenario:

During normal SOC monitoring, Analyst John observed an alert on an IDS solution indicating a potential C2 communication from a user Browne from the HR department. A suspicious file was accessed containing a malicious pattern THM:{ ________ }. A week-long HTTP connection logs have been pulled to investigate. Due to limited resources, only the connection logs could be pulled out and are ingested into the connection_logs index in Kibana.

Our task in this room will be to examine the network connection logs of this user, find the link and the content of the file, and answer the questions.

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

First things first, we’ll enter the Elastic web console and then navigate to the Kibana > Discover Analytics module. Kibana is used to search logs and visualize them, so using the Discover module will enable us to query and explore the provided network connection_logs index_._

To access the Discover tab, we can either input “discover” into the search box at the top of the dashboard or use the menu on the left-hand sidebar.

For Question 1, our objective is to narrow the search scope to a single month. To do this, we will need to adjust the time filter so that we can focus only on the events that occurred in March of 2022. Let’s modify the dates in the time selection field.

We’ll filter the first date/time to Absolute and set the start date to March 1, 2022, at 0:00 and then the end date to March 31, 2022, at 23:30. This selection should give us the entire month of March 2022.

Once we apply the date/time filter, we’ll see our results displayed as a total number of hits and now we have some data to analyze and the answer to Question 1.

Total Hits

Question 2: What is the IP associated with the suspected user in the logs?

Since we have so many log entries, we’ll want to filter this to a manageable level. To do this, let’s check out the source_ip field filter which will help us to determine how many source hosts we have captured in our logs.

On the fly-out menu, we will have some analytics about the top 5 values that appear in the logs. Fortunately for us, there are only two entries.

One IP accounts for 99.6% of the traffic, and the second only accounts for 0.4%.

Before we go too crazy wading through a massive number of records, let’s check the IP address with the fewest number of hits by adding the source IP to the filter. I searched it manually in the query box, but you can also simply hit the + next to the value to add it to the filter.

This IP address only has two logged events which makes it a bit easier for us to analyze. Right away, there are a few suspicious indicators but let’s do some reconnaissance on the destination IP address to see if we can locate any intelligence.

We’ll start with VirusTotal to get an overview and see if there are any hits for malicious activity associated with this IP address:

Interestingly, there are no hits for malware, however the banner shows that there are “10+ detected files communicating with this IP address” — that’s odd, let’s take a closer look at that.

The files communicating with this domain seem to have a high number of hits for malicious activity. This is giving us some confidence that we have found the host IP address of the infected user. But let’s double-check with another service as well, Hybrid Analysis.

Hybrid Analysis also assesses that this IP has been associated with some malicious activity. So, would have enough information to say that we found the correct local IP address for the victim. Let’s enter our answer to check our work.

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

Now that we know the victim’s local IP address and have an idea of what IP address the infected device was communicating with for command and control (C2), we need to determine what application or service was being used for the connection. Let’s focus on the user_agent field to answer Question 3.

If you aren’t familiar, user-agents are request headers that servers use to identify requesting client details like the operating system, web browser version, or application.

In this log, we have an unusual user_agent that isn’t something typical like a web browser, for example. This indicates that the malware might be living off the land and using a legitimate Microsoft command-line tool.

I don’t want to spoil the fun but if we do a little research about this user agent, we’ll stumble on some helpful information from Microsoft Learn — this particular tool can be leveraged to:

create, download or upload jobs, and to monitor their progress.

In other words, this information confirms that this utility can be used to download files. Let’s submit our findings and move on to the next question.

Question 4: 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?

In Question 2, we found evidence that the victim’s device communicated with a destination IP address that resolves to a web-based file sharing service. According to MITRE ATT&CK (T1102), this site has been used for command and control by some threat actors and malware families.

Let’s confirm that our IP intelligence is correct by looking at the host field.

Since the host matches the intelligence that we found about the IP address, we have our answer.

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

Okay, to answer Question 5, we have the simple task of combining the host domain from Question 4 with the uri field of the event. This will form the hostname/path combination of the URL that we are looking for to answer this question!

Questions 6 & 7:

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

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

All right, we made it to the last two questions! So far, we have determined the IP address, application, domain, and URL that the victim’s infected device accessed. The last step for this challenge is to determine the name and content of the file hosted on this file sharing site.

Unfortunately, the connection_logs index does not seem to contain any of the file data that we are looking for, so we have to pivot. What if we navigate to the URL that we assembled in Question 5 to view the public site directly?

Once there, it looks like our research paid off! We found both the file that was accessed and can view the contents. Let’s submit our answers and wrap up this investigation!

Conclusion:

Hey, nice job with the investigation! We successfully completed the listed objectives and analyzed the HTTP connection log file, found the required evidence, and have an understanding of the payload to complete the ItsyBitsy challenge! It’s time to close the case.

A big thank you to TryHackMe for hosting this awesome challenge! I haven’t had an opportunity to jump into Elastic so this was a fantastic challenge to learn about the tool and get a high-level overview of how it can be leveraged to analyze large data sets and apply that to incident response. While I’m sure this barely scratches the surface of what the tool is capable of, I gained plenty of valuable hands-on experience with Kibana and am looking forward to the next time I’ll get to practice with Elastic!

I hope that you had as much fun as I did and learned something new, too!

Thank you so much for reading along and working through this investigation with me. Until next week — stay curious!

Tools & References:

VirusTotal: https://www.virustotal.com/

Hybrid Analysis: https://www.hybrid-analysis.com/

MITRE ATT&CK — Command and Control: https://attack.mitre.org/tactics/TA0011/

Mozilla Developer (User Agent): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent

Microsoft bitsadmin: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin

MITRE ATT&CK — Web Service: https://attack.mitre.org/techniques/T1102/

TryHackMe — Basic Malware RE Walkthrough

Sun, 21 Apr 2024 00:00:00 +0000

TryHackMe — Basic Malware RE Walkthrough

Basic malware reverse engineering with Ghidra

Image Credit: https://tryhackme.com/r/room/basicmalwarere

Introduction:

Have you ever wondered how malware reverse engineering works when using Ghidra? We’re about to find out together!

Welcome to my weekly walkthrough where we’ll tackle the Basic Malware RE room on TryHackMe. This is a follow-up to the MAL: Strings room on the Cyber Defense learning path that I explored last week.

TryHackMe — MAL: Strings Room Walkthrough

As a beginner with reverse engineering, I’m confident that this room will challenge me with the basics and help me to fill in some knowledge gaps. So, while I’m still learning and won’t have many real-world application tips this time around, the hands-on experience will be a lot of fun.

So, whether you’re here to learn with me or looking for a reference walkthrough for the TryHackMe Basic Malware RE room, you’re in the right spot. In the spirit of learning, I will not be revealing any flags but I encourage you to follow along on your own. Thanks for reading along, hope it helps!

Challenge Link: https://tryhackme.com/r/room/basicmalwarere

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first — It’s always a good idea when working with lab/challenge files from TryHackMe (or any lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine. For example, I’m using REMnux for this challenge and walkthrough .

Second, I want to make a note that I’ll be referencing the excellent REMnux Documentation in this post. This is a great resource to discover the tools available within the environment.

https://docs.remnux.org/

Third, to keep this write-up focused I’m going to skip a step-by-step setup guide of REMnux. Instead, if you want to set up your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:

https://docs.remnux.org/install-distro/get-virtual-appliance

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started! For this one, we have three tasks, and the extraction process is the same:

Strings :: Challenge 1

This executable prints an MD5 Hash on the screen when executed. Can you grab the exact flag?

Building on my write-up for the previous room in the series, MAL:Strings, we’ll start simple and utilize the strings command to see if there is anything obvious that we can find.

Snippet from the strings output

Woah! There are hundreds of FLAG strings. This looks like it might be a bit more complicated to analyze so we’ll need to pivot from simply using the strings command. The challenge states that dynamic analysis is out of the question, so we can’t execute the binary or use a debugger. Maybe we can use something like Ghidra, which is built in to REMnux, so that we can perform static analysis on the code? Now, full disclosure I have little experience with Ghidra outside of a lab or two. So, let’s get some background on what Ghidra is from the project’s GitHub before we stumble through this together.

Ghidra is a software reverse engineering (SRE) framework created and maintained by the National Security Agency Research Directorate. This framework includes a suite of full-featured, high-end software analysis tools that enable users to analyze compiled code on a variety of platforms including Windows, macOS, and Linux. Capabilities include disassembly, assembly, decompilation, graphing, and scripting, along with hundreds of other features.

Now, let’s launch Ghidra. When it starts up_,_ we’ll create a project, drop in the strings1.exe, and let Ghidra perform the initial analysis. Once that is completed, we’ll have the symbol tree displayed on the left, the listing contents in the center, and the decompile window on the right.

Let’s start by looking at the functions. Based on what we know about this binary already, when the application is executed, it prints an MD5 hash of the flag string. So, put another way we need to find the MD5 hashing function and then locate the string within the code that is being hashed — this will be the flag we are looking for.

After doing some research, we’ll start by examining the entry function. We’ll enlist help from Microsoft Co-Pilot to explain this better for us and fill in some knowledge gaps. As a side note, remember to always verify the sources and information given by generative AI for accuracy.

The “entry function” in Ghidra refers to the initial function that is called when a program starts running. It’s the point where the control is transferred from the operating system to the program. In the context of reverse engineering, when you load a binary into Ghidra, it tries to identify this entry point so that analysts can begin tracing the program’s execution from the very start.

Great, this sounds like a good place to start! Right away, we see some evidence of a flag. While this seems promising, let’s dig in and try to understand what we are seeing.

Let’s focus on the decompile window. We see a character pointer, which is typically used to point to a memory location that stores a string: char *lpText;

It looks like this points to a string transformed by an MD5 hashing function. Messy explanation, I know, but stick with me and let’s double- click on the string that ends in “_00432294”.

This takes us to the below location in the code:

The top line matches the hash function string we found. Now let’s click the 00424828 entry…

There we go! We saw the complete flag string and managed to find our first flag! Awesome job!

Strings :: Challenge 2

This executable prints an MD5 Hash on the screen when executed. Can you grab the exact flag?

We’ll start this task the same way we did with the first one — we’ll create a new project in Ghidra, drop in the strings2.exe, and let Ghidra perform the initial analysis. Once that is complete, we’ll again start with the entry function and focus on the decompile window:

This time, as we scroll through the entry, we’ll see a different character pointer than we did in Task 1: char *local_8;

It seems like this points to another MD5 hashed string. This time instead of a fully defined string like we saw in Task 1, it appears that we have different variables in a stack represented as hexadecimal (hex) values that are hashed in sequence to form the full string. Lower address variables in the stack will be added first, so local_2c = “F”; would be added before local_2b = 0x4c; — maybe the F is the first character in “Flag”?

Let’s test the theory and focus on converting the hex values to ASCII and see if this reveals a flag.

To do this, I am going to copy out the code with the hex values and add them to CyberChef so that we can perform the cleanup and conversion_._ The first goal is to strip out all the code other than the hex values. For this we can add a Find/Replace operation to the recipe and apply the following regular expression (REGEX) to the find operation: ^[^,]*,

This should match everything from the start of each line up to the first comma.

Now all we should have to do is add the “From Hex” operation to the recipe to convert the hex to ASCII to reveal the flag!

Let’s submit and check if we stumbled through this one correctly!

Strings :: Challenge 3

This executable prints an MD5 Hash on the screen when executed. Can you grab the exact flag?

Once again, we’ll start this task the same way we did with the last two tasks — we’ll create a new project in Ghidra, drop in the strings3.exe, and let Ghidra perform the initial analysis. Once that completes, we’ll again start with the entry function and focus on the decompile window:

For this task, the code looks a little different than we saw in the previous two tasks. As this is a strings challenge, something sticks out to me, the LoadStringA function. I’ll lean on the documentation Microsoft Learn to help me out with some context for this function:

Loads a string resource from the executable file associated with a specified module and either copies the string into a buffer with a terminating null character or returns a read-only pointer to the string resource itself.

So, it looks like maybe strings3.exe is loading a string with the ID of 0x110 and then copies it into the memory buffer local_4a4 .

So, we’ll chase this theory and click the 0x110 ID in the decompile window.

Right away, we’ve stumbled upon some evidence of the flag we are looking for in the code! Let’s examine the function call by clicking on CALL which takes us to the below strings table which contains several flags.

The top string matches the flag we found earlier, but let’s double verify before we try to submit. Remember that we click the 0x110 that we thought may be the identifier of the flag?

In the strings table we don’t see this value, but we do have a column of String IDs. In Task 2 we performed a hex to ASCII conversion, this time we can try a hex to decimal conversion. Fortunately, Ghidra has already taken care of this for us — we simply need to mouse over the 0x110 ID to get the decimal value of 272.

This confirms our findings and now we know for certain that String ID 272 is the flag string we are searching for. We managed to find our third and final flag!

Conclusion:

Awesome job! We might have stumbled a bit, but we made it through the Basic Malware RE room using Ghidra!

To wrap this up, thank you to TryHackMe for the challenging room and the valuable exposure to reverse engineering as I close in on the end of the Cyber Defense learning path.

This room was tougher than usual for me as I started out as a novice in reverse engineering and using Ghidra. But the experience was incredibly helpful to highlight my own gaps in reverse engineering knowledge and to help get me some hands-on practice. It was fun to think creatively and test how one might leverage generative AI solutions to help a newbie with static code analysis. In the real world, I might have skipped right to dynamic analysis in a sandbox but that isn’t always an option and understanding what is going on “under the hood” can be far more beneficial for deep analysis.

Thank you so much for reading along, too! I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!

Tools & References:

TryHackMe: https://tryhackme.com/r/room/basicmalwarere

REMnux: https://docs.remnux.org/discover-the-tools/statically+analyze+code/general#ghidra

Ghidra: https://ghidra-sre.org/

Microsoft Copilot: https://www.microsoft.com/en-us/windows/copilot-ai-features?r=1

CyberChef: https://gchq.github.io/CyberChef/

Microsoft Learn: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadstringa

TryHackMe — MAL Strings Room Walkthrough

Sun, 14 Apr 2024 00:00:00 +0000

TryHackMe — MAL: Strings Room Walkthrough

Investigating strings within an application

Image Credit: https://tryhackme.com/r/room/malstrings

Introduction:

Hello! Welcome and thanks for joining me for this weekly walkthrough!

This week, I am doing something a little different. Rather than a challenge, I am going through the MAL: Strings room over on TryHackMe. This room is part of their Cyber Defense learning path. I’ve been putting off finishing this path for a while, but I thought it might be a good time to tackle this room and do a write up, too! This is a brief room but touches on some really valuable resources like researching CVEs, OWASP, crypto wallet address lookups, and Sysinternals Strings, so stick around!

As always, this write-up serves as a learning journey notebook for me and a TryHackMe room reference walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!

Challenge Link: https://tryhackme.com/r/room/malstrings

What are “strings”?

While this information is covered very well in the room’s learning content, I want to put an excerpt here for reference that will help frame the tasks as we move forward about what exactly strings are.

Background on strings from Task 1:

From a programming perspective, “strings” is the term given for data handled by an application. At a broader view, these pieces of data are used to store information such as text to numerical values.

For example, let’s say we have an application such as a calculator. A user will have to input two numerical values (e.g. 1 and 5) combined with an operator (e.g. + or plus) addition in this case. These values will be stored as “strings”.

However “strings” can be stored within the application itself — where no input is necessary from the user. For example, using the example of usernames and passwords is a great representation of the many types of information that may be stored as a “string”.

So put another way, if we are analyzing an application or some code, being able to extract strings can help us as analysts to understand a program’s intent or functionality and could reveal interesting artifacts like IP addresses, URLs, commands, credentials, etc. With that in mind, let’s start working through the room!

Task 1

What is the name of the account that had the passcode of “12345678” in the intellian example discussed above?

Jumping right in, we’re looking at examples of software vulnerabilities caused by storing sensitive information like passwords within the application which might lead to unintended access or information disclosure.

The task states that:

Intellian, a satellite-communications focused company had the disclosure of their “Aptus Web 1.24” application retaining a default passcode of “12345678”

So, we need to do some research to discover what the account name associated with the default password is. We’ll start by visiting the CVEdetails website so that we can search the vendor and product name from the question. Let’s input the information and see what we can find.

Once we get to the product page for the vulnerable version listed in the task content, we find two vulnerabilities. If we look at the descriptions, we see that the first one, CVE-2020–8000, has a hard coded password that matches what we are looking for. From there, we have the username as well!

Intellian Aptus Web 1.24 has a hardcoded password of 12345678 for the intellian account.

What is the CVE entry disclosed by the company “Teradata” in their “Viewpoint” Application that has a password within a string?

We’ll follow the same process that we did for the last question. Let’s search the CVEdetails and see if we can discover the CVE entry assigned to the vulnerability in the Teradata Viewpoint application.

According to OWASP’s list of “Top Ten IoT” vulnerabilities, name the ranking this vulnerability would fall within, represented as text.

For those who are unfamiliar, the Open Worldwide Application Security Project (OWASP) is a foundation that publishes guidance to help developers create secure software projects. The OWASP Top 10 documents are like “what not to do” lists so developers can avoid the most commonly exploited security mistakes for a particular category of software or application. For our purposes, we want to review the OWASP Internet of Things (IoT) Top 10.

OWASP IOT Top 10:

OWASP Internet of Things Project _Oxford defines the Internet of Things as: “A proposed development of the Internet in which everyday objects have…_wiki.owasp.org

Let’s take a look at the IoT guidance. The previous two questions have been about vulnerabilities due to Hardcoded Passwords. According to OWASP, this the number one vulnerability facing IoT projects.

Task 2

What is the correct username required by the “LoginForm”?

What is the required password to authenticate with?

What is the “hidden” THM{} flag?

Now we get a little bit of hands-on time! The task files contain an executable called LoginForm.exe — for strings analysis we can use the built-in strings command in Linux. For the purposes of this task, I am using my own REMnux virtual machine but you can use any distro of your choice including the Kali Linux box on TryHackMe.

So, now that we have the file in our analysis environment, let’s just run the strings command and let it print to the console and see what we find!

Strings output.

Okay, there is a lot of data here. Maybe it will be easier to search if we output to a txt file instead? For this example, I am going to write to an output file called stringsdump.txt but you can use whatever you’d like.

strings LoginForm_1586175647590.exe > stringsdump.txt

Strings output to txt file

There we go! If we scroll through the list, we’ll stumble on a few strings that look like a username, password, and a flag. Great find!

Task 3

What is the key term to describe a server that Botnets recieve instructions from?

Moving right along, there isn’t much that we need to do here. If we read through Task 3, we are able to answer this question from the learning content:

malware types such as botnets and ransomware rely upon information being stored within strings I.e. IP Addresses so that they are able to “call home” and connect to their “Command and Control” (C&C) server.

Below, I’ve added some additional context about the Command and Control tactic from MITRE ATT&ACK (TA0011).

Command and Control _The adversary is trying to communicate with compromised systems to control them. Command and Control consists of…_attack.mitre.org

Name the discussed example malware that uses “strings” to store the bitcoin wallet addresses for payment

Same thing as the previous question — Let’s read through the task content to find the answer:

A famous example is the “Wannacry” ransomware. The “killswitch” was a domain that was discovered as a value contained within a string.

Task 4

List the number of total transactions that the Bitcoin wallet used by the “Wannacry” author(s)

For this task, we’ll go and gather some intelligence on the Bitcoin wallet used by this threat actor to see how many transactions have occurred. There are a few sites we can do this on but let’s first check out the suggested website, BlockCypher.

Once we look up the Bitcoin address on the site, we’ll see the number of received Bitcoins and the total number of transactions for the address.

Bitcoin address lookup on BlockCypher

For fun, let’s check another source, ScamAlert. This website tracks Bitcoin wallet fraud and scams and can be used to check a Bitcoin addresses — very handy! Let’s look up the wallet address from the task here, too. We’ll find that the website has flagged it as a ransomware address. But what if we want more detail?

Bitcoin address lookup on ScamAlert

If we click the source URL, we are taken to Chainabuse (which has merged with Bitcoin Abuse). This is another site that can be used to report on malicious crypto activity. Now, if we input the wallet address on this site, we get even more intelligence that confirms the association with Wannacry/Wannacrypt.

Bitcoin address lookup on Chainabuse

Let’s submit the answer of the total number of transactions that we discovered from BlockCypher and move on.

What is the Bitcoin Address stored within “ComplexCalculator.exe”

Okay, more hands-on time! This time around we will use a Windows environment instead of Linux. This is a great opportunity to try out the Strings tool which is part of the Microsoft Sysinternals suite of utilities_._

Fortunately, this task includes a virtual machine which has the Sysinternals utilities installed already. We will use strings.exe to extract the strings from within the included executable file, ComplexCalculatorv2.exe

Let’s launch the virtual machine and see what we can discover!

First, we’ll open the Command Prompt (cmd.exe) as Administrator. Then, we will change the directory to the folder on the Desktop containing the Sysinternals tools_._ Since Strings is a command-line utility, we will launch it from the command prompt and accept the license agreement.

Now, let’s go ahead and run Strings using the following syntax. We’ll use the > operator to direct the output to a file instead of the console:

strings.exe ComplexCalculatorv2.exe > strings.txt

Now that we have sent the output to a text file, let’s open it up in Notepad. Since we are searching for a Bitcoin address, let’s speed this up and use Notepad’s find function by pressing CTRL + F and typing in “bitcoin” — This should help us locate the string quickly!

Nice! It looks like we found our answer!

Task 5

What is the name of the toolset provided by Microsoft that allows you to extract the “strings” of an application?

Alright, we’re in the home stretch! Task 5 is going to focus on the theories that we just utilized in Task 4.

In the last task, we used Strings in the Windows environment. This utility is part of the Microsoft SysInternals toolset.

Strings - Sysinternals _Search for ANSI and UNICODE strings in binary images._learn.microsoft.com

What operator would you use to “pipe” or store the output of the strings command?

I believe the question is asking about redirecting output, not piping, since we aren’t sending the output of the command into the input of another command. With that, remember in Task 4 that we directed the output of Strings with the > operator to a .txt file? I think we are looking for > as the answer.

What is the name of the currency that ransomware often uses for payment?

Okay, last one! In Task 4, we were looking up the Bitcoin address for Wannacry and Bitcoin is a type of cryptocurrency, so it seems to me that we already have the answer — let’s check our work!

Conclusion:

Awesome job! We made it through the MAL: Strings room!

Thank you to TryHackMe for the interesting room as I close in on the end of the Cyber Defense learning path. While this room was pretty brief and a little light on the hands-on content, it was still a fun experience to do some research with CVEdetails and OWASP and to explore the Strings utilities available in Linux and Windows.

I also enjoyed checking out some of the c_rypto wallet_ lookup tools and see what kind of intelligence can be found about Bitcoin addresses. This will definitely be useful in the field! It never hurts to have some more experience with a new tool to keep in your kit, after all!

Thank you so much for reading along. I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!

Tools & References:

CVE Details: https://www.cvedetails.com/

OWASP: https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10

REMnux: https://remnux.org/

BlockCypher: https://live.blockcypher.com/

ScamAlert.io: https://scam-alert.io/

ChainAbuse: https://www.chainabuse.com/

Sysinternals Suite: https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

TryHackMe — REvil Corp Challenge Walkthrough

Sun, 07 Apr 2024 00:00:00 +0000

TryHackMe — REvil Corp Challenge Walkthrough

Incident Response Engagement using FireEye Redline

Image Credit: https://tryhackme.com/r/room/revilcorp

Introduction:

Hello — Thanks for joining me for this weekly walkthrough!

This week I am going to continue exploring the FireEye Redline tool by investigating the REvil Corp incident response challenge room over on TryHackMe.

In the spirit of learning, I will not be revealing the flags in this walkthrough but this is a FREE room so anyone can test their skills with Redline and perform the investigation along with me and find the answer on their own.

This challenge builds on my previous TryHackMe Redline walkthrough so I encourage you to start there first if you are just jumping in.

TryHackMe — Redline Endpoint Investigation Challenge Walkthrough

As always, this write-up will serve as a learning notebook for me and a TryHackMe challenge walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!

Challenge Link: https://tryhackme.com/r/room/revilcorp

Challenge Scenario:

Scenario: One of the employees at Lockman Group gave an IT department the call; the user is frustrated and mentioned that all of his files are renamed to a weird file extension that he has never seen before. After looking at the user’s workstation, the IT guy already knew what was going on and transferred the case to the Incident Response team for further investigation.

You are the incident responder. Let’s see if you can solve this challenge using the infamous Redline tool. Happy Hunting, my friend!

Question 1: What is the compromised employee’s full name?

Fortunately, the analysis session has already been created for this challenge, so we simply need to open the investigation (.mans) file in Redline. Once it (finally) opens, we have quite a few options to explore in our Analysis Data menu.

To kick this off, let’s take a look at the Users tab to hunt for the usernames on the system and find out who the victim is.

Users Analysis Data

Since the Administrator and Guest accounts are disabled, it looks like we only have one option. Let’s confirm our findings and keep going with the investigation.

Question 2: What is the operating system of the compromised host?

Okay, now that we know who the victim is let’s take a high-level view of the victim’s machine to better understand the environment. At the very top of the Analysis Data menu is the System Information tab. This tab is a great starting point for us and contains information about the Machine, Operating System, and User.

Questions 3 & 4:

What is the name of the malicious executable that the user opened?

What is the full URL that the user visited to download the malicious binary? (include the binary as well)

Okay now we need to determine how the malicious executable was dropped onto the system. Since Question 4 is asking about a download URL, let’s start with something obvious and check the File Download History tab to see what we can find.

The File Download History shows u_s_ two artifacts, but one of the downloads has a source URL containing an IP address — that’s a bit suspicious and requires some additional investigation.

The artifacts we discovered so far should be sufficient to answer Questions 3 & 4 but it is still unclear how or why the victim acquired this executable.

At this point in the analysis, we can start to speculate what might have happened:

-Maybe the download URL was sent to the victim with a Spearphishing Link? (MITRE ATT&CK T1566.002)

-Could the user have been searching for the legitimate application on the web and fell victim to a Malvertising link? (MITRE ATT&CK T1583.008)

-Or maybe there was a Supply Chain Compromise, and the executable was infected and distributed from the legitimate site hosting the application? (MITRE ATT&CK T1195.002)

As we go through the investigation, answering these types of questions will be important. In the real world, finding the root cause can help us form a strategy to tighten up our preventative controls and prepare us to fully eradicate the threat!

Questions 5 & 6:

What is the MD5 hash of the binary?

What is the size of the binary in kilobytes?

Now, since we have the download path from the File Download History, let’s actually navigate to this location using the File System tab. We will select the Downloads folder, locate the file, and double-click it to drill-down and get more detailed information.

This will give us the specific information we are looking for to answer Questions 5 & 6, including the file size and file hashes.

Full Detailed Information of the Malicious Binary

Okay! Now that we have the file hash, let’s take our analysis a step further and drop the hash into VirusTotal to see if we can get any hits and gather some additional intelligence on this binary:

VirusTotal shows a lot of detection on this binary and includes some threat labeling that will help us to hunt for specific indicators of compromise. Keep this page open for reference later since we will use it to help answer Question 9!

Questions 7 & 8:

What is the extension to which the user’s files got renamed?

What is the number of files that got renamed and changed to that extension?

Okay, let’s stick with the File System tab. Since we know the user account and that the victim complained that his files “are renamed to a weird file extension that he has never seen before” we can take a look at a location with high visibility and that is often used for storage — the Desktop.

Right away we can see what the victim reported, several files with an unusual extension. Let’s try to assess the impact and determine how many files were appended with this extension.

To do this, we are going to utilize the Timeline feature which records all of the file events so that we can see what has been created, accessed, modified, and changed. The question is asking about files that are renamed AND changed, so within the Timeline lets select modified and changed under Files. After that we will press the filter button on the Summary column and input the weird extension from Question 7 to search for files with this extension.

Now let’s check our results. At the bottom right of the screen we will have an item count, this should be the answer we are looking for!

Question 9: What is the full path to the wallpaper that got changed by an attacker, including the image name?

To tackle this problem, let’s pull back and recall some of the indicators we have already discovered. Remember back in Question 6 that we found some information about the threat family of the malicious executable from VirusTotal? Let’s use that information and do some research. This will save us time instead of manually sifting through the entire Timeline.

Let’s head over to Google and see what we can find by searching for the threat family label that we found on VirusTotal. While there is quite a bit of information on this malware, I stumbled across one article that had some interesting information that will help us answer Question 9 (and confirms one of our theories from Question 4).

REvil/Sodinokibi Ransomware _The REvil (also known as Sodinokibi) ransomware was used by the financially motivated GOLD SOUTHFIELD threat group…_www.secureworks.com

The article states that the malware sets a wallpaper and:

saves the finished image to the host’s %Temp% directory using a random filename consisting of lowercase letters and numbers between 3 and 13 characters in length appended with the “.bmp” extension (e.g., C:\Users__\AppData\Local\Temp\cd2sxy.bmp).

Now that we have some idea of what indicator we might be hunting for, let’s jump back into Redline and adjust our filter in the Timeline.

We will add a filter to the Summary column and specify the Temp directory for the user that we are investigating. Once we have the filter in place, we can search for the .bmp file extension in the search box.

Great! With the help of some threat intelligence, we found the answer!

Question 10: The attacker left a note for the user on the Desktop; provide the name of the note with the extension.

Now let’s go searching for the ransom note. While we could navigate back to the Desktop from the File System tab, why don’t we just keep using the Timeline with some adjustments?

Let’s change the Timeline Configuration to show Created files and then filter the summary column for the victim’s Desktop path:

Once we do that, we will see a readme file — I think that’s what we are looking for…

Question 11: The attacker created a folder “Links for United States” under C:\Users\John Coleman\Favorites\ and left a file there. Provide the name of the file.

We have all the information we need from Question 11 itself to continue searching within the Timeline. Let’s go ahead and add the file path from the question including the folder name.

Once add the information to the filter, the output leaves us with just a few choices. One file sticks out as it is not an English language word like we have seen on the rest of this system:

Let’s confirm our suspicion and check our findings.

Question 12: There is a hidden file that was created on the user’s Desktop that has 0 bytes. Provide the name of the hidden file.

For Question 12, we’ll pivot back to the File System tab and filter only John’s Desktop again.

If we look at the Size column, we can easily spot the hidden file we are looking for.

Question 13: The user downloaded a decryptor hoping to decrypt all the files, but he failed. Provide the MD5 hash of the decryptor file.

Awesome, since we are already filtering the Desktop from the File System tab, you may have also already noticed a conspicuous decryptor executable?

Let’s double-click the file to get the full detailed information, including the file hashes.

Let’s copy the MD5 Hash and submit the answer!

Question 14: In the ransomware note, the attacker provided a URL that is accessible through the normal browser in order to decrypt one of the encrypted files for free. The user attempted to visit it. Provide the full URL path.

I don’t see a straightforward way to extract an artifact from the Redline file to simply read the URL from the ransom note, so let’s get creative and utilize the Browser URL History tab and sift through the logs.

Since we are looking for a website used for decryption let’s try entering the keyword decrypt into the search box and see what we find?

Okay, it looks like we found a URL in the list with our search! While it isn’t always this easy to correlate a URL with the other malicious activity, we’ll take this one as a win and move on to the final question.

Question 15: What are some three names associated with the malware which infected this host? (enter the names in alphabetical order)

With the indicators discovered from our investigation so far, we can be pretty confident that we know which ransomware affected the victim. But, the VirusTotal intelligence from Question 6 and the Secureworks report from Question 9 only give us two names for this malware. So, we will need to collect more intelligence. For this, let’s turn to the MITRE ATT&CK knowledge base and see what additional information is available for this ransomware — we’ll input one of the names that we know already:

REvil _REvil is a ransomware family that has been linked to the GOLD SOUTHFIELD group and operated as ransomware-as-a-service…_attack.mitre.org

There we go, we have some associated software descriptions that should help us answer the last question and wrap up this investigation!

Conclusion:

Whew! We set to solve this ransomware incident using Redline and I think we now have enough information to start the eradication and recovery phase for John! Great job!

Thank you to TryHackMe for hosting another engaging challenge and building out such a huge catalog of free rooms for the community. This room was an excellent challenge to reinforce the concepts from the Redline room and provides enough hands-on time to understand it’s value in the DFIR process. It never hurts to have some more experience with a new tool to keep in your kit, after all!

Thank you so much for reading along. I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!

Tools & References:

FireEye Redline: https://fireeye.market/apps/211364

TryHackMe REvil Corp Room: https://tryhackme.com/r/room/revilcorp

MITRE ATT&CK — Spearphishing Link: https://attack.mitre.org/techniques/T1566/002/

MITRE ATT&CK — Malvertising: https://attack.mitre.org/techniques/T1583/008/

MITRE ATT&CK — Supply Chain Compromise: https://attack.mitre.org/techniques/T1195/002/

VirusTotal: https://www.virustotal.com/

Secureworks: https://www.secureworks.com/research/revil-sodinokibi-ransomware

MITRE ATT&CK — REvil: https://attack.mitre.org/software/S0496/

TryHackMe — Redline Endpoint Investigation Challenge Walkthrough

Sun, 10 Mar 2024 00:00:00 +0000

TryHackMe — Redline Endpoint Investigation Challenge Walkthrough

Endpoint Investigation with the FireEye Redline Security Tool

Image Credit: https://fireeye.market/apps/211364

Introduction:

Hello! Thanks for joining me on this walkthrough. This week I am going through the Redline room on TryHackMe. FireEye Redline (not the info stealer malware) is an endpoint security memory analysis tool with file structure browsing capabilities, similar to Volatility (see my previous TryHackMe write-up), but with a nice GUI for navigation!

As always, this write up will serve as both a learning journal for me and a TryHackMe challenge walkthrough with some added context for anyone who stumbles on this post. To keep this focused, this walkthrough is only going to cover Task 7: Endpoint Investigation. In the spirit of learning, I will not be revealing the flags in this walkthrough but this is a FREE room so anyone can learn about Redline and perform the investigation along with me and find the answer on your own. Thanks for reading — hope it helps!

Challenge Link: https://tryhackme.com/room/btredlinejoxr3d

Task 7 : Endpoint Investigation

Challenge Scenario:

A Senior Accountant, Charles, is complaining that he cannot access the spreadsheets and other files he has been working on. He also mentioned that his wallpaper got changed with the saying that his files got encrypted. This is not good news!

Are you ready to perform the memory analysis of the compromised host? You have all the data you need to do some investigation on the victim’s machine. Let’s go hunting!

Question 1: Can you identify the product name of the machine?

Okay, let’s see if we can help Charles. Fortunately, the analysis session has already been created for this challenge, so we simply need to open the investigation (.mans) file in Redline.

Once it (finally) opens, we have quite a few options explore in our Analysis Data menu. Let’s start with a high-level view of the victim machine to better understand the environment at the time of the data collection. The System Information tab has some great information including information about the Machine, OS, and User.

If we read through the information, I think we can find the answer to Question 1…

Question 2: Can you find the name of the note left on the Desktop for the “Charles”?

Okay, now that we have a better idea of the environment we are analyzing, we need to look for a “note” left for Charles. Since Charles complained that there was a message that his files were encrypted, we’re probably looking for a ransom note?

There are a couple of ways I think we can find it. Let’s try the path of least resistance first. We can simply try navigating to Charles’ Desktop through the File System tab and seeing what we find:

File System > Charles > Desktop

Okay, this seems promising! We have a .txt file which is a standard plaintext document typically created by Notepad in a Windows environment. Let’s approach this another way and confirm that we have the correct file.

If we navigate to Processes on the Analysis Data panel, let’s look for Notepad. We can use the filter but in this case, it’s pretty easy to spot in the process list.

Let’s double click the NOTEPAD.EXE process and see what additional information we can get.

Okay, there we go! I think we found the answer we are looking for. It looks like some process spawned Notepad.exe to generate the note and drop it on Charles’ desktop.

Question 3: Find the Windows Defender service; what is the name of its service DLL?

Alright, moving right along. We need to locate a DLL for the Windows Defender service, so let’s go check out the Windows Services section of the analysis panel.

We have a couple of ways of locating this. We can filter all fields for Windows Defender or we can filter the Service DLL tab specifically.

This time around, let’s use the Service DLL column and filter for Windows Defender. This should get us the information we need.

Filtering the Service DLL column.

Let’s submit the answer and confirm:

Question 4: The user manually downloaded a zip file from the web. Can you find the filename?

Moving along, let’s see if we can determine the source of the ransomware infection. Let’s start with something obvious, like supposing that the user downloaded a file.

We can approach this in a similar way to Question 2. We will start by manually evaluating the artifacts in Charles’ download folder and then use the File Download History tab in the Analysis Data pane to confirm.

Let’s use the File System tab and select the Downloads folder for Charles. If we quickly scan the folder we mostly see some forensic tools like FTK Imager, Wireshark, and Redline itself along with some incomplete downloads(the unconfirmed downloads), and Microsoft update files. There is one file that looks a little strange though…

Now, let’s utilize the File Download History tab_._ We can search by the file extension .zip to search for the file we found during our manual review of the Downloads folder.

Look at the first result. There is a manual download entry with an intriguing URL — Malware Bazaar. It appears Charles may have downloaded a malware sample.

According to the Malware Bazaar website:

MalwareBazaar is a project from abuse.ch with the goal of sharing malware samples with the infosec community, AV vendors and threat intelligence providers.

Very interesting but for the purposes of this challenge, the file name column confirms our finding from the Downloads folder — we can go ahead and submit Question 4

Side Note: Before we move onto the next question, let’s try to add some context by checking out the timeline to get a better idea of the series of events leading up to the download of the malware sample. I had previously combed through the timeline and tagged relevant (the orange tag) events to get a focused view of the incident.

While this isn’t relevant for this challenge, this would be very interesting in a real world scenario. It’s possible that this sample was simply downloaded to create this challenge scenario but in the real world, we can’t rule out an insider threat since we have evidence of a Google search for a piece of malware under the user’s profile.

Question 5: Provide the filename of the malicious executable that got dropped on the user’s Desktop.

Let’s navigate back to Charles’ Desktop through the file system tree view where we found the ransom note. On the Desktop, we see two executable (.exe) files. One appears to be the Microsoft Office setup and the other seems a bit more suspicious…

In Question 6 we will do a bit more analysis on this executable but for now, let’s submit our answer:

Question 6: Provide the MD5 hash for the dropped malicious executable.

Now for the easy part! Simply double-click the file within the tree view to drill down into the Full Detailed Information for the file. Once the window loads, we will have some additional information about the file including a section for file hashes.

We can go ahead and submit the answer but keep that MD5 hash handy, as we will use it for some further IOC investigation in the next question.

Question 7: What is the name of the ransomware?

Okay, to fully determine the impact and remediate the incident, we need to identify exactly what malware we are investigating. Let’s start by taking the file hash of the malicious executable that we found in Question 6 and checking it against VirusTotal & _Hybrid Analysis t_o see if we get any hits that can help us:

VirusTotal Result

Hybrid Analysis Result

Fortunately, we have a lot of detection for this particular executable. If we look through the labels and the details tab on these two services, we see a frequent name which identifies this malware family. I have a suspicion that this is the correct name for the ransomware but we can do a bit of Google reconnaissance to see if we can find any technical reports to provide further intelligence and confirm our findings.

Once we do that, we have enough information to answer Question 7 and conclude this investigation!

Conclusion:

I think we now have enough information now to start the eradication and recovery phase for Charles! Great job!

Thank you to TryHackMe for hosting another awesome challenge and building out such a huge catalog of free rooms for the community. This room, while brief, was a thorough introduction to the Redline tool and gives you just enough hands-on time to understand it’s value in the DFIR process when comparing to Volatility for memory analysis. It never hurts to have some experience with a new tool to keep in your kit, after all!

Thank you so much for reading along and learning with me! I hope that you had as much fun as I did and learned something new, too. Stay curious!

Tools & References:

Redline: https://fireeye.market/apps/211364

TryHackMe: https://tryhackme.com/room/btredlinejoxr3d

Malware Bazaar: https://bazaar.abuse.ch/

Hybrid Analysis: https://www.hybrid-analysis.com/search?query=Fe1bc60a95b2c2d77cd5d232296a7fa4

VirusTotal: https://www.virustotal.com/gui/file/b3e1e9d97d74c416c2a30dd11858789af5554cf2de62f577c13944a19623777d

TryHackMe — Volatility Room Practical Challenge Walkthrough

Sun, 25 Feb 2024 00:00:00 +0000

TryHackMe— Volatility Room Practical Challenge Walkthrough

Endpoint Investigation with Volatility 3

Image Credit: https://github.com/volatilityfoundation

Introduction:

Hello! Last week’s write-up was for the LetsDefend Memory Analysis room which was my introduction to the Volatility framework. This week, I am going to build on my knowledge and am writing up my learning with the excellent Volatility room on TryHackMe. The capstone of the room is a practical challenge with two cases.

TryHackMe makes challenges like these very beginner-friendly and the coursework modules prior to the challenge will have you well-prepared. This challenge does require some additional, external research but it definitely helps to add context and spend more time on the DFIR process. In the spirit of learning and research I am not going to reveal the flags this time around but I will walk you through my process so you can recreate it yourself.

I used Volatility 3 to complete this room but _g_oing forward I will use the terms Volatility 3 and Volatility interchangeably. This is a longer one, so get comfortable. Thanks for reading!

Challenge Link: https://tryhackme.com/room/volatility

Challenge Scenarios:

Case 001 — BOB! THIS ISN’T A HORSE!

Your SOC has informed you that they have gathered a memory dump from a quarantined endpoint thought to have been compromised by a banking trojan masquerading as an Adobe document. Your job is to use your knowledge of threat intelligence and reverse engineering to perform memory forensics on the infected host.

You have been informed of a suspicious IP in connection to the file that could be helpful. 41[.]168[.]5[.]140

The memory file is located in /Scenarios/Investigations/Investigation-1.vmem

Case 002 — That Kind of Hurt my Feelings

You have been informed that your corporation has been hit with a chain of ransomware that has been hitting corporations internationally. Your team has already retrieved the decryption key and recovered from the attack. Still, your job is to perform post-incident analysis and identify what actors were at play and what occurred on your systems. You have been provided with a raw memory dump from your team to begin your analysis.

The memory file is located in /Scenarios/Investigations/Investigation-2.raw

Case 001 — BOB! THIS ISN’T A HORSE!

Questions 1 & 2:

What is the build version of the host machine in Case 001?

At what time was the memory file acquired in Case 001?

Before we get started, I want to call out the Volatility 3 help command built into the tool. We’re going to lean on this a lot. This is a great way to explore what plugins are available and get a brief description of their functions. In some cases, the plugin itself may have its own set of help for optional arguments! Don’t worry, we will utilize these further in the challenge. For now, I will leave the help command here as a starting point if you’d prefer to navigate the challenge on your own.

python3 vol.py -h

Okay, let’s get started! While the challenge doesn’t specify it, I am going to assume that we are analyzing a memory dump from a Windows endpoint. If you have completed the preceding tasks already in the TryHackMe Volatility room, you will have come across a module that will help us get started with scoping the challenge and working through the case: windows.info

As a refresher, Task 6 states:

If we are still looking to get information about what the host is running from the memory dump, we can use the following three plugins _windows.info_ _linux.info_ _mac.info_. This plugin will provide information about the host from the memory dump.

This plugin is a good starting point for our investigation so that we can get some high-level details from the dump file and better understand our victim environment. When we run Volatility we’ll point to the challenge file path with the -f parameter and have it use the windows.info plugin.

python3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem windows.info

Once Volatility does its magic, we get the following output with some details of the memory dump.

I think the NTBuildLab & SystemTime fields should answer questions 1 & 2 — let’s submit to confirm that we have the right answers:

Question 3:

What process can be considered suspicious in Case 001?

Okay, now let’s get into the analysis and use Volatility to dig a bit deeper and understand the running processes on the victim system at the time the memory dump was taken. If we refer to the Volatility help again we have several process identification options.

The windows.pslist help file entry.

Let’s go with the light-touch option first and simply list out the processes list using the windows.pslist plugin. We’ll see if we can find anything suspicious within our case file.

python3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem windows.pslist

Okay, now we have our output, see anything odd? I mentioned this in my previous Volatility post, but typically when looking at a Windows process list, I like to refer to the SANS Hunt Evil reference poster to understand normal Windows processes which helps tremendously during analysis.

Fortunately, this is a pretty short list and one of these process sticks out to me. Let’s confirm our suspicion and submit the answer but before we do, pay attention to the note on the submissions page…

Note: Certain special characters may not be visible on the provided VM. When doing a copy-and-paste, it will still copy all characters.

While we are here, let’s make a special note to grab the process ID (PID) of the suspicious process as well, we will need this to answer Question 5. So now we have the PID as well, let’s copy directly from the virtual machine, and paste our answer!

Questions 4, 5, 6:

What is the parent process of the suspicious process in Case 001?

What is the PID of the suspicious process in Case 001?

What is the parent process PID in Case 001?

Good work! Now that we have located the suspicious process, these next few questions will be straightforward. We just need to look at the output of pslist and look at the information presented. These questions seem out of order to me but we’ll figure it out.

Look at the columns in the output. We are going to focus on Process ID (PID), Parent Process ID (PPID), and ImageFileName. Using the information in these columns, we can determine the answers.

Question 4 is looking for the ImageFileName of the parent process of the suspicious child process we located. To find it, search the pslist output and look at the PPID of the suspicious process (this could also answer Question 6…) Then, locate the process with the matching PID — this is the parent process and we can use the ImageFileName as our answer_._ Once you find it, make a note of the PID as well so we can have it ready for Question 6!

Remember in Question 3 we made a note of the PID of the suspicious process? Now we can utilize it! Question 5 is asking for the PID of the suspicious process — easy enough, we will simply use the PID value of the suspicious process for our answer.

Whew! We got them — let’s move on.

Questions 7 & 8:

What user-agent was employed by the adversary in Case 001?

Question 8: Was Chase Bank one of the suspicious bank domains found in Case 001? (Y/N)

Cool, I haven’t had a chance to look at the networking modules in Volatility 3 yet. We’ll start with the information given in the challenge scenario:

You have been informed of a suspicious IP in connection to the file that could be helpful. _41.168.5.140_

We have an IP, let’s see if we can get any networking info with windows.netstat & windows.netscan. Hmmm, the version of Windows our memory dump was taken from doesn’t seem to be supported…

Let’s pivot and try something else. If we scan through the help files again, there isn’t an obvious plugin that can work to search for this suspicious IP address though…

What if we could dump out the suspicious processes’ memory map? Maybe we can get some additional information or perform further analysis about the contents of files opened by this process that are mapped to the memory address space…

Remember that before we started the investigation, I mentioned that some plugins have optional arguments? Here is a good example.

We see that the memmap plugin has some additional options that will help us here. We can try dumping the suspicious process that we identified earlier. This time we are going to set an output directory with the -o parameter:

python3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem -o windows.memmap –pid –dump

This creates a dump file which contains way too much information for us to manually sift through. Let’s try to utilize the strings command in Ubuntu and grep our output to be a bit more focused.

Strings is a command that searches the contents of a file for printable strings so it can help us pull out something human readable from the process dump.

So what are we going to grep? Well, if we read the question back, it asks for a user-agent so let’s just try that? If you aren’t familiar a user-agent headers are strings that servers use to identify requesting client details like the operating system or the web browser version. In this case, let’s use the -i argument to ignore case and just search for user-agent.

Awesome! It looks like we found something useful for our investigation that should answer Question 7.

Now let’s tackle Question 8 and wrap Case 001 up. Since we already have the memory map for the suspicious process, maybe we can try the same logic as we did for Question 7 and just grep out “Chase” — could that work? Try it and find out!

sudo strings /home/thmanalyst/evidence/pid..dmp | grep -i “Chase”

Great! Now we can submit, and close the case before moving on to our next set of challenges in Case 002!

Case 002 — That Kind of Hurt my Feelings

Question 9: What suspicious process is running at PID 740 in Case 002?

Okay! Case 002 is an analysis of a ransomware strain. Since we have the PID of the suspicious process already, let’s use the pslist plugin again and this time let’s grep only the suspicious PID:

python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw wind ows.pslist | grep 740

Interesting. This file name seems like it might be related to a famous ransomware from a few years ago. Let’s keep that in mind as we move through the investigation. While we’re at it, let’s also make a note of the parent process ID (PPID) too we’ll need it in Question 12.

Question 10: What is the full path of the suspicious binary in PID 740 in Case 002?

Let’s try to locate the file path of the suspicious binary. We’ll first try to lean on our process plugs (pslist, psscan, & pstree) to see if we can find any information. Unfortunately, these commands aren’t giving us much additional information so we will go back to the Volatility 3 help and see if we can find a plugin that could help us.

From the THM Task 7 Module:

This plugin will list all DLLs associated with processes at the time of extraction. This can be especially useful once you have done further analysis and can filter output to a specific DLL that might be an indicator for a specific type of malware you believe to be present on the system.

This could be useful to us from an investigative perspective but we also might get the file path of the binary that is loading the DLLs as well.

As a refresher, DLLs (Dynamic Link Library) are binary files that provide shared functionality for executables that can be called when required.

For the Windows operating systems, much of the functionality of the operating system is provided by DLL. Additionally, when you run a program on one of these Windows operating systems, much of the functionality of the program may be provided by DLLs. For example, some programs may contain many different modules, and each module of the program is contained and distributed in DLLs.

Let’s give it a try and see what we can find.

python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw windows.dlllist | grep 740

Awesome — this is exactly what we were looking for!

Questions 11 & 12:

What is the parent process of PID 740 in Case 002?

What is the suspicious parent process PID connected to the decryptor in Case 002?

Alright, one step forward and two steps back. If you haven’t cleared your terminal yet, lets scroll back up to your pslist output from Question 9.

Take a look at the PPID column for PID 740. Remember in Question 9 where I mentioned we might want to make a note of the PPID of the suspicious process? That’s what we need for Question 12.

We will use pslist again and grep the parent process ID. After that, this becomes a simple matching game like we saw in Case 001.

python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw wind ows.pslist | grep

When reviewing the output, Question 11 is looking for the ImageFileName of the process_._ Have fun!

Question 13: From our current information, what malware is present on the system in Case 002?

Let’s get to Google for some research of the artifacts we’ve found so far. We’ll start by searching for something broad, like the specific name of the executable that we discovered in Question 9.

We’ll stumble across a few links, but I chose the threat report from Mandiant for this write-up.

Based on the report — we have already discovered some of these indicators of compromise (IOCs) on our victim system. I think that we have determined the malware strain that infected the victim system:

Question 14: What DLL is loaded by the decryptor used for socket creation in Case 002?

Reading through the Mandiant report linked in Question 13, there are some mentions of socket functions but not necessarily what DLL is loaded specifically for socket creation. Let’s do a little more manual work with Volatility and perform our own analysis.

First, we will dump the process to see if I can learn anything on VirusTotal about any loaded DLLs by this executable. We’re going to dump this to an output directory and then retrieve the file hash for comparison.

python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw -o /home/thmanalyst/evidence windows.pslist –pid 740 –dump

sha256sum /home/thmanalyst/evidence/pid.740.0x400000.dmp

On the details tab, we’ll scroll down to the imports and take a look at the list of DLLs. It might not be the most efficient way, but we can quickly expand on all of the imports and see if we can spot any network or socket functions specifically. Let’s review the details; there is one that sticks out and looks like it could be relevant.

Now, let’s return to the DLL list in our analysis environment and look at the output for this process again and see all of the DLLs loaded by this specific sample and verify we see the DLL here as well:

Okay, I am thinking we may have found the answer but let’s do some additional research. I’m going to try get a quick AI brief on this DLL from the Microsoft Copilot for Edge to before we validate the accuracy of the information through the reference links — it’s always important to verify the accuracy of AI output.

The .dll, also known as the Winsock2 DLL, is a dynamic link library file that provides essential functions for network communication in Windows operating systems

.dll plays a crucial role in managing network communication, ensuring compatibility, and facilitating efficient interactions between applications and service providers in the Windows environment

Okay, confirmed! This seems like we can say with high confidence that the Winsock2 DLL is what is used for socket creation.

Question 15: What mutex can be found that is a known indicator of the malware in question in Case 002?

This is an interesting question and is a new one for me! Let’s do a quick Google refresher on a mutex for context.

Below is an excerpt from the SANS Blog:

Programs use mutex (“mutual exclusion”) objects as a locking mechanism to serialize access to a resource on the system. Consider the following explanation by Microsoft: “For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object.”

Now, let’s check out the Mandiant report again and see if any of the heavy lifting has been done for us already. If we check out the file artifacts listed in the report, we see a mutex listed out.

Okay, so in theory this is information that should be captured in the memory image and we should be able to find a mutex used by the malware. Let’s check out the Volatility help and see if we can find any plugins that could help us validate this.

I’m sure there is a better way to utilize this plugin but in this case, let’s simply use the Volatility 3 windows.mutantscan plugin to validate the presence of the mutex in our analysis sample against the report:

Great, we stumbled through this one! Let’s submit and confirm our suspicion.

Question 16: What plugin could be used to identify all files loaded from the malware working directory in Case 002?

For the last question, we will return for the last time to our Volatility 3 help file. Let’s see if there are any other plugins we can utilize for further analysis of the malware and search for the files loaded from the malware directory?

This plugin could be useful for further analysis especially if we run it against the malware directory that we found in Question 10. While not required for the challenge, let’s go ahead and run the command and grep the working directory:

python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw windows.filescan | grep -i “\ivecuqmanpnirkt615”

Wow! This gives us even more IOCs that we can use to validate our findings. For now, though — let’s submit the answer to Question 16 and wrap up these cases.

Conclusion:

There we have it — mission completed! Thank you to TryHackMe for the impressive room and challenge. This was a really great challenge to help me further explore Volatility 3 and learn some new skills along the way and I hope that you learned something as well between the two cases. Personally, I especially appreciated the need to do external research and use some brain power on DFIR. Thank you for your time in checking out this (long) walkthrough and stumbling through the challenge with me. Stay curious!

TryHackMe on Drew Arpino (Stumblesec)

TryHackMe — Monday Monitor Challenge Room Walkthrough

TryHackMe: Monday Monitor Challenge Room Walkthrough

Wazuh SIEM Forensics: Investigating Persistence, Credential Dumping, and Exfiltration with Atomic Red Team.

Introduction:

Challenge Scenario:

Question 1: Initial access was established using a downloaded file. What is the file name saved on the host?

Questions 2 & 3:

What is the full command run to create a scheduled task?

What time is the scheduled task meant to run?

Question 4: What was encoded?

Question 5: What password was set for the new user account?

Question 6: What is the name of the .exe that was used to dump credentials?

Question 7: Data was exfiltrated from the host. What was the flag that was part of the data?

Conclusion:

Tools & References:

TryHackMe — Tempest Challenge Walkthrough

TryHackMe | Tempest | Challenge Walkthrough

An Endpoint Forensic Investigation Challenge Using SysmonView, EvtxECmd, Brim, & CyberChef.

Introduction:

Challenge Scenario:

Task 3: Preparation — Tools and Artifacts

Questions 1, 2, & 3:

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

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

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

Task 4: Initial Access — Malicious Document

Investigation Guide:

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

Questions 2 & 3:

What is the name of the compromised user and machine?

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

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

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

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

Task 5: Initial Access — Stage 2 execution

Investigation Guide:

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

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

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

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

Task 6: Initial Access — Malicious Document Traffic

Investigation Guide:

Question 1: What is the URL of the malicious payload embedded in the document?

Question 2: What is the encoding used by the attacker on the c2 connection?

Questions 3 & 4:

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

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

Question 5: What is the HTTP method used by the binary?

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

Task 7: Discovery — Internal Reconnaissance

Investigation Guide:

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

Question 2: 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?

Question 3 & 4:

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?

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

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

Question 6: 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?

Task 8: Privilege Escalation — Exploiting Privileges

Investigation Guide:

Question 1: 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?

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

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

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

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

Task 9: Actions on Objective — Fully-owned Machine

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

Question 2: 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?

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

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

Question 5: 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?

Question 6: 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?

Conclusion:

Tools & References:

TryHackMe — Warzone 2 Room Walkthrough

TryHackMe — Warzone 2 Room Walkthrough

A Second Network Packet Capture Investigation Using Brim/Zui, Network Miner, and VirusTotal.

Introduction:

Challenge Scenario: