CyberDefenders on Drew Arpino (Stumblesec)

CyberDefenders — BRabbit Lab Walkthrough

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

CyberDefenders: BRabbit Lab Walkthrough

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

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

Introduction:

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

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

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

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

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

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

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

Challenge Scenario:

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

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

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

What is the suspicious email address that sent the attachment?

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

Overview of the Challenge File

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

Heed the warning

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

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

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

And almost immediately, something stands out.

CyberChef: Identifying the suspicious sender address

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

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

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

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

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

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

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

CyberChef: Identifying the attachment as Base64

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

CyberChef: Decoding and extracting the attachment

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

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

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

sha256sum extracted_at_0x0.exe

Calculating the SHA256 hash of the ransomware binary

Which produces:

630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da

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

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

VirusTotal: Identifying the ransomware family

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

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

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

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

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

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

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

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

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

Tria.ge: Behavioral report > Processes snippet

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

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

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

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

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

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

VirusTotal: Identifying the hash of infpub.dat

579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648

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

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

VirusTotal: Finding external reporting through the community comments

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

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

" # "

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

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

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

Identifying the username through the ESET report

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

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

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

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

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

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

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

Any.Run: Identifying potentially malicious WebDAV traffic

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

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

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

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

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

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

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

Tria.ge: highlighting scheduled task creation for persistence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0f815e2944f12b847e1165517daaab6be67ff4c1daee73b09e8fb3733b974c9f

VirusTotal: Identifying the file hash of dispci.exe

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

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

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

VirusTotal: Opening the Zenbox sandbox report

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

Zenbox: Reviewing execution screenshots

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

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

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

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

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

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

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

VirusTotal: Looking for driver clues on the behaviors tab

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

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

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

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

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

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

Malpedia: Identifying actors associated with Bad Rabbit

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

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

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

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

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

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

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

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

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

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

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

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

MITRE ATT&CK: Identifying Bad Rabbit destructive impact techniques

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

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

Conclusion:

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

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

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

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

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

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/brabbit/

REMnux: https://remnux.org/

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

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

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

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

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

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

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

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

Disk Cryptor: https://diskcryptor.org/

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

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

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

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

CyberDefenders — RedLine Lab Walkthrough

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

CyberDefenders: RedLine Lab Walkthrough

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

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

Introduction:

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

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

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

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

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

Thanks for reading and going on this investigation with me!

Challenge Scenario:

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

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

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

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

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

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

vol3 -h

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

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

Let’s give it a try:

vol3 -f MemoryDump.mem windows.pslist

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

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

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

Volatility 3: Identifying a suspicious process with windows.pslist

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

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

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

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

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

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

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

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

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

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

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

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

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

Volatility 3: Identifying memory protection using windows.malfind

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

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

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

Volatility 3: Identifying a potential tunneling process

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

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

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

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

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

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

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

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

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

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

Here’s the combined command:

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

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

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

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

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

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

From the terminal, we can use the strings utility and pipe the results through grep to isolate only the results that contain the attacker’s IP address:

strings MemoryDump.mem | grep “77.91.124.20”

Using strings & grep to identify URLs

From the output, we’ll notice several interesting artifacts, including a full URL that points to index.php. That’s exactly what we need to answer this question!

Question 7: What is the full path of the malicious executable?

Our last objective is to determine the full file path of the malicious oneetx.exe executable on disk. We can approach this question the same way we handled the previous one: by running a strings search against the memory dump. This time, instead of looking for an IP address, we’ll use strings and pipe the results through two grep filters. One looks for the name of the malicious binary (oneetx.exe) and the other searches for the drive label C: since we know we’re working with a Windows system.

strings MemoryDump.mem | grep “oneetx.exe” | grep C:

Using strings to identify the malware file path

Nice. The output gives us a clean file path for the oneetx.exe binary, and it points to the AppData\Local\Temp directory. This location often shows up during malware investigations, since it’s a common staging area that attackers abuse for downloading, unpacking, or executing payloads. Now that we’ve double-grepped our way through the last question and solved the full set, it’s time to wrap up this investigation.

Conclusion:

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

This one was another fantastic addition to their catalog, with a tight focus on volatile memory analysis and a beginner-friendly opportunity to get comfortable with the Volatility modules that help uncover meaningful artifacts. Piece by piece, we worked through the investigation, identified and researched a suspicious process, enriched it with threat intelligence, and built a clear picture of the attacker’s command-and-control activity and the malware involved.

I picked this week’s challenge because I wanted to brush up on Volatility. It’s not a tool I use every single day, but it’s always worth staying sharp and adding a few new tricks to your notebook. You never know when you’ll need them. And honestly, there’s something really rewarding about reconstructing an attack from a single forensic artifact. It’s a great reminder of just how powerful memory analysis can be when it comes to uncovering malicious behavior. Fun times!

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

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/redline/

REMnux: https://remnux.org/

Volatility Foundation: https://volatilityfoundation.org/

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

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

Stormshield — " # “RedLine malware: from a Chrome extension to a large-scale malware campaign”: https://www.stormshield.com/news/malware-redline-chrome-extension-large-scale-malware-campaign/

Volatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/command-reference

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

GitHub — Tun2Socks: https://github.com/xjasonlyu/tun2socks

VirusTotal — C2 IP: https://www.virustotal.com/gui/ip-address/77.91.124.20

CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough

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

CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough

A Threat Intelligence Challenge Using VirusTotal and Securelist.

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

Introduction:

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

Challenge Scenario:

A blockchain development company detected unusual activity when an employee was redirected to an unfamiliar website while accessing a DAO management platform. Soon after, multiple cryptocurrency wallets linked to the organization were drained. Investigators suspect a malicious tool was used to steal credentials and exfiltrate funds.

Your task is to analyze the provided intelligence to uncover the attack methods, identify indicators of compromise, and track the threat actor’s infrastructure.

This challenge is extremely beginner-friendly and a great exercise in pivoting from a simple file hash to finding relevant reporting and leaning on the broader security community to add context to an investigation. It’s really cool to go from a single hash to fully understanding an entire malware campaign tied to that sample.

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

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!

Question 1: In KB, what is the size of the malicious file?

First things first! Extract the challenge file using the password provided in the challenge. This leaves a simple .txt file named hash.txt.

Contents of the Challenge File

Inside this file is the MD5 hash of a malware sample suspected of being linked to a recent cryptocurrency funds exfiltration:

E5B8B2CF5B244500B22B665C87C11767

With this file hash in our possession, we can pivot to checking it against threat intelligence and sample-sharing communities to search for known activity related to this exact file.

Our first stop is VirusTotal. Once on the site, submit the file hash to check if this sample has been uploaded before. If it has, we can leverage existing intelligence to learn more about the malware.

VirusTotal: Checking the file hash of the sample

Right away, we can confirm that our sample has been processed before, and a majority of anti-malware vendors have tagged it as malicious. That’s interesting, but to answer Question 1, we’re focused on the file size of the sample. You can find this by clicking on the Details tab and checking the File Size value under Basic Properties. We just need to grab the value listed in KB, instead of the bytes value

VirusTotal: Identifying the file size of the sample

Question 2: What word do the threat actors use in log messages to describe their victims, based on the name of an ancient hunted creature?

Well, that’s an interesting question! Let’s dig into VirusTotal and see what else we can find that might allude to an ancient hunted creature.

For this, it can be helpful to check out the Community tab. This is a valuable place to find relevant research where other members share links to additional analysis or notes about a given sample.

https://www.virustotal.com/gui/file/523d4eb71af86090d2d8a6766315a027fdec842041d668971bfbbbd1fe826722/community

Lucky for us, there’s a comment linking to an external post on Kaspersky’s Securelist blog. Let’s check it out:

Tusk campaign uses infostealers and clippers for financial gain _Kaspersky researchers discovered Tusk campaign with ongoing activity that uses Danabot and StealC infostealers and…_securelist.com

After a read-through of the introduction, we’ve already stumbled across the answer to Question 2:

We identified three active sub-campaigns (at the time of analysis) and 16 inactive sub-campaigns related to this activity. We dubbed it " # "

Tusk" , as the threat actor uses the word " # "

Mammoth" in log messages of initial downloaders — at least in the three active sub-campaigns we analyzed. " # "

Mammoth" is slang used by Russian-speaking threat actors to refer to victims. Mammoths used to be hunted by ancient people and their tusks were harvested and sold.

So, the creature is Mammoth.

Question 3: The threat actor set up a malicious website to mimic a platform designed for creating and managing decentralized autonomous organizations (DAOs) on the MultiversX blockchain (peerme.io). What is the name of the malicious website the attacker created to simulate this platform?

Let’s dive deeper into this threat intelligence report and look for any information about the look-alike website spoofing peerme.io.

Inside the report, we can see detailed information about this exact scenario — nice!

In this campaign the actor simulated peerme.io, a platform for the creation and management of decentralized autonomous organizations (DAOs) on the MultiversX blockchain. It aims to empower crypto communities and projects by providing tools for governance, funding, and collaboration within a decentralized framework. The malicious website is tidyme[.]io.

We just need to re-fang the address by removing the brackets from the top-level domain before submitting the answer.

Question 4: Which cloud storage service did the campaign operators use to host malware samples for both macOS and Windows OS versions?

Reading through the first sub-campaign details, it’s identified that “this campaign has several malware samples for macOS and Windows, both hosted on Dropbox.“This means the attacker is leveraging a trusted, common cloud storage solution to host the initial downloader component of the campaign.

As we continue through the analysis, we’ll see that this same service is abused in all three sub-campaigns.

Question 5: The malicious executable contains a configuration file that includes base64-encoded URLs and a password used for archived data decompression, enabling the download of second-stage payloads. What is the password for decompression found in this configuration file?

Following execution of the initial downloader, there’s a background routine that fetches the second-stage payloads. The Downloader routine section of the first sub-campaign details the configuration file, including the password we need to answer Question 5.

https://securelist.com/tusk-infostealers-campaign/113367/

Question 6: What is the name of the function responsible for retrieving the field archive from the configuration file?

Moving right along, we’ll find that the report also documents the function we’re looking for to answer Question 6.

The function downloadAndExtractArchive retrieves the field archive from the configuration file, which is an encoded Dropbox link, decodes it and stores the file from Dropbox

https://securelist.com/tusk-infostealers-campaign/113367/

Question 7: In the third sub-campaign carried out by the operators, the attacker mimicked an AI translator project. What is the name of the legitimate translator, and what is the name of the malicious translator created by the attackers?

Moving on from the first sub-campaign section, we’re now going to focus on the third sub-campaign. In the summary of this campaign, it’s stated that:

In this campaign, the threat actor was simulating an AI translator project named YOUS. The original website is yous.ai, while the malicious website is voico[.]io:

This is all the information we need. The only trick is that we must again remove the defang brackets from the malicious URL before submitting the answer.

Question 8: The downloader is tasked with delivering additional malware samples to the victim’s machine, primarily infostealers like StealC and Danabot. What are the IP addresses of the StealC C2 servers used in the campaign?

The next question has us assessing the reporting looking for tactical indicators of compromise (IoCs) associated with the StealC infostealer. We can locate this specific information in the report under the Network IoCs section where they are labelled StealC C2 server:

https://securelist.com/tusk-infostealers-campaign/113367/

Having these indicators readily available is really helpful so that we could hunt for matching activity against the fictional organization in the challenge and confirm the same infrastructure was used.

Question 9: What is the address of the Ethereum cryptocurrency wallet used in this campaign?

On to the final question for this threat intelligence challenge: identifying the Ethereum (ETH) cryptocurrency wallet address associated with the campaign.

While the wallet addresses are listed in each of the sub-campaign sections, we can also easily access them in the dedicated Cryptocurrency wallet addresses section of the report:

https://securelist.com/tusk-infostealers-campaign/113367/

This provides us with further tactical information we could use in additional analysis of the impact of the attack. Now that we’ve analyzed the report and collected the relevant information, let’s wrap up this case!

Conclusion:

That’s a wrap on the Tusk Infostealer challenge and the end of our investigation! A big thank you to CyberDefenders for another awesome challenge.

This challenge was a fantastic exercise in threat intelligence analysis, tying together several important concepts: pivoting from a single file hash, leveraging community resources like VirusTotal, and extracting tactical indicators such as C2 IPs and cryptocurrency wallet addresses. We also explored how attackers abuse trusted services like Dropbox and spoof legitimate platforms to build credibility.

Working through each question, we followed the trail of clues and learned how to pivot between threat intelligence reports and real-world IoCs to uncover the attacker’s infrastructure. I chose this challenge because it’s perfect for sharpening investigative skills and demonstrates how defenders can use open-source intelligence to map out an entire campaign.

It’s pretty cool that starting with just a hash, we can reveal how attackers chain techniques — from initial downloaders to second-stage payloads, and ultimately to financial exfiltration through cryptocurrency wallets. Awesome!

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

Securelist — " # “Tusk: unraveling a complex infostealer campaign”: https://securelist.com/tusk-infostealers-campaign/113367/

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/523d4eb71af86090d2d8a6766315a027fdec842041d668971bfbbbd1fe826722

CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough

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

CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough

A Windows DFIR Challenge Using Arsenal Image Mounter, FTK Imager, Detect It Easy, ProcMon, CyberChef, and Eric Zimmerman’s Tools

Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/spottedinthewild/?cta=navbar-sign-in&origin=%2Fblueteam-ctf-challenges%2Fspottedinthewild%2F

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the SpottedInTheWild blue team challenge from CyberDefenders, you’re in the right place. This challenge is rated HARD by the authors, but don’t let the difficulty rating scare you off. Whether you’re just getting started in digital forensics or you’ve been around the block a few times, this challenge has something for everyone.

Challenge Scenario:

You are part of the incident response team at FinTrust Bank. This morning, the network monitoring system flagged unusual outbound traffic patterns from several workstations. Preliminary analysis by the IT department has identified a potential compromise linked to an exploited vulnerability in WinRAR software.

For this challenge, we’re putting on our incident response hats. Several workstations in the environment are showing suspicious outbound traffic, and it’s up to us to shed some light on the situation. Fortunately, we’re given a virtual hard disk for one of the devices, so we can dig into all the forensic artifacts, reconstruct a timeline, and determine what happened.

This scenario pushes us to think creatively, pivot between tools, and piece together a full attack chain using a variety of forensic artifacts. We’ll be using a mix of Eric Zimmerman’s forensic tools, FTK Imager, CyberChef, Detect It Easy, and even a few public sandbox platforms like Any.Run and VirusTotal to validate our findings. If you’re using Flare-VM, most of these tools are already built in and ready to go.

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

Thanks for reading and going on this investigation with me!

Important: Setup a Safe Analysis Environment & Extract the Challenge File:

Safety first! It’s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is " # “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).“To keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.

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

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

Question 1: In your investigation into the FinTrust Bank breach, you found an application that was the entry point for the attack. Which application was used to download the malicious file?

Let’s kick off our investigation and start digging into the provided artifacts. First, unzip the 166-SpottedInTheWild.zip archive from CyberDefenders using the password provided on the challenge page.

Once extracted, we’ll have access to the challenge file: c125-SpottedInTheWild.vhd.

So, what do we do with this thing? There are a variety of options, some of which we’ll explore during this investigation. As a first point of entry, we’ll leverage one of the suggested tools in the challenge, Arsenal Image Mounter. Arsenal gives us the ability to mount the virtual hard disk (.VHD) file and view the contents of the file system so we can analyze the forensic artifacts contained within.

Open Arsenal and press the Mount Disk Image button at the bottom. Select c125-SpottedInTheWild.vhd and use the default mount options.

Arsenal: Selecting the default mount options

Once it’s loaded, we’ll see the file listed in the center pane. As a shortcut, we can open the mounted directory by pressing the F:\ drive letter.

Arsenal: Opening the mounted directory

Now we can start checking out the contents of the challenge file.

To answer Question 1, we need to determine which file is malicious and where it came from. A logical starting point is the Downloads folder, which we can access by opening the path C\Users\Administrator\Downloads.

Inside that directory, we’ll find a folder named Telegram Desktop, which contains a suspicious WinRAR archive: SANS SEC401.rar. Something feels off…

Identifying the suspicious download

This archive supposedly contains material from the SANS 401 Security Essentials course, but the folder name suggests it came from the Telegram Desktop app, which is unusual. Since this is the only file in any of the download directories, it’s likely the malicious file used to gain initial access to the victim’s device. We’ll confirm this later in our investigation.

For now, we can reasonably assume that Telegram is the application used to download the file. We can confirm its presence on the system by navigating to C\Users\Administrator\AppData\Roaming\Telegram Desktop.

Confirming the presence of Telegram Desktop on the victim device

Question 2: Finding out when the attack started is critical. What is the UTC timestamp for when the suspicious file was first downloaded?

Great! Now that we’ve positively identified the malicious file and its source, we need to grab the timestamp in UTC for when this file was first downloaded. This will help us start building out a timeline of the attack.

There are several ways to approach this task, but for this walkthrough we’ll leverage the Master File Table (MFT) artifact from the victim’s image. If this is a new artifact for you, here’s an excellent overview from the Magnet Forensics blog:

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

The idea here is to use the $MFT to grab the creation timestamp of the Telegram Desktop folder, and to have this artifact loaded for later in the investigation.

To analyze this artifact, we’ll use Eric Zimmerman’s MFTExplorer, a graphical parser for the $MFT that lets us explore its contents. If you’re following along using Flare-VM, this tool is already built-in.

Open MFTExplorer, then go to File > Load MFT, and select the victim’s $MFT from the C directory of the mounted file system.

The location of the $MFT artifact on the victim image

Once the $MFT is open, navigate to the C:\Users\Administrator\Downloads directory in the file tree. With the contents displayed, check the SI_Created On column to grab the time this file was created (or downloaded) onto the disk. This is the timestamp we need to answer Question 2.

MFTExplorer: Identifying the file creation time of Telegram Desktop

Question 3: Knowing which vulnerability was exploited is key to improving security. What is the CVE identifier of the vulnerability used in this attack?

Our next objective is to identify which vulnerability was used to carry out the attack. This is a great opportunity to pivot to an external threat intelligence platform so we can benefit from the research of the broader security community. But first, we need to obtain the file hash of the malicious archive.

Jump back into the file explorer and navigate to the Telegram Desktop folder.

To collect the hash of SANS SEC401.rar, we can use PowerShell’s Get-FileHash command:

PowerShell: Computing the malware archive file hash

D1A55BB98B750CE9B9D9610A857DDC408331B6AE6834C1CBCCCA4FD1C50C4FB8

Now that we’ve obtained the SHA256 file hash, head over to VirusTotal and submit the hash in the search box. We’ll discover that this sample has already been submitted to the platform, and about half of the security vendors flag the archive as malicious. However, what we’re really interested in is one of the tags: CVE-2023€“38831.

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

This CVE designation tells us that the file is potentially weaponized to exploit a vulnerability in the WinRAR archive tool. For context, let’s take a look at the National Vulnerability Database entry for this CVE:

RARLAB WinRAR before 6.23 allows attackers to execute arbitrary code when a user attempts to view a benign file within a ZIP archive. The issue occurs because a ZIP archive may include a benign file (such as an ordinary .JPG file) and also a folder that has the same name as the benign file, and the contents of the folder (which may include executable content) are processed during an attempt to access only the benign file.

That’s scary! This vulnerability is especially dangerous because the victim thinks they’re opening a harmless archive, but it could be weaponized to execute malicious code instead.

Question 4: In examining the downloaded archive, you noticed a file in with an odd extension indicating it might be malicious. What is the name of this file?

Now that we have a better understanding of the SANS SEC401.rar file, let’s try to open it and see what’s inside. Since we mounted the image using Arsenal’s default settings, we’re in read-only mode — which means we’ll need to copy the file to our analysis file system to extract it.

Full disclosure: when I exported the file from Arsenal, I ran into some errors and couldn’t extract it. If it works for you — great! If not, join me for Plan B: mounting and extracting with FTK Imager.

FTK Imager is another popular forensic tool used to create and read forensic disk images — and it’s also installed on Flare-VM. Once you open FTK, load the image by pressing: File > Add Evidence Item > Image File > Select c125-SpottedInTheWild.vhd > Finish.

FTK Imager: Exporting the malicious RAR file

After it loads, you’ll see a familiar-looking file tree on the left-hand side. Navigate to the C:\Users\Administrator\Downloads\Telegram Desktop directory and expand it. Right-click the SANS SEC401.rar file and select Export Files…

Once it’s copied to your analysis environment, you can use a tool like 7-Zip to extract the contents and reveal the payload within.

Question 5: Uncovering the methods of payload delivery helps in understanding the attack vectors used. What is the URL used by the attacker to download the second stage of the malware?

To answer Question 5, let’s turn our attention to analyzing the SANS SEC401.pdf.cmd file we just accessed from the RAR archive. For this challenge, we’ll start with a simple strings analysis to identify plaintext strings within the file. Maybe we’ll stumble across a clue about the second-stage URL.

There are plenty of ways to approach this, but I’m going to use Detect It Easy (DiE) to parse the file. DiE is another tool preinstalled on Flare-VM, so open it up and point the file name box to the extracted SANS SEC401.pdf.cmd file. Then, tick the Advanced box and press Strings.

Detect It Easy: Loading the malicious .cmd file

While much of the output is obfuscated, we’ll get a few clues toward the bottom in the form of readable strings that can help inform the next steps of our analysis.

Detect It Easy: Analyzing the strings

For example, on line 308, we can see most of a URL — exactly what we need to answer Question 5.

Detect It Easy: Identifying a URL in the strings

Since the protocol (like HTTP or HTTPS) is obfuscated, let’s pivot to dynamic analysis in our safe sandbox environment.

For this dynamic component, we’ll actually execute the .cmd file and observe its behavior.

CMD: Executing the malware in the sandbox

Notice the error? That result makes sense since there’s no Internet connection in the sandbox. Importantly though, we can now see the URL more clearly than we could with the strings view. The second stage is attempting to download an image named amanwhogetsnorest.jpg.

Question 6: To further understand how attackers cover their tracks, identify the script they used to tamper with the event logs. What is the script name?

Okay, the next stop on our investigation is to identify the script used to tamper with the Windows Event Logs to evade detection. Let’s jump back to the DiE strings view.

At the very bottom of the output window (lines 341€“342), we’ll spot a potential clue: a file named Eventlogs.ps1 located in the \Windows\Temp directory. Let’s follow this thread and see if we can determine what this script does.

Detect It Easy: Identifying a potential log clearing script

Next, let’s head back into MFTExplorer and try to locate the file in the directory we found with DiE.

MFTExplorer: Confirming script location in the MFT

Bingo! Unfortunately, the image data doesn’t exist, so we can’t simply export the file. While we can gain some insight into the script’s function, it looks a bit daunting to decode statically — so let’s try something else.

I know we’re bouncing around between tools but bear with me. Rather than continue with the GUI tool MFTExplorer, we’re going to pivot to another pair of Eric Zimmerman’s tools: MFTECmd and Timeline Explorer.

The plan is to parse the NTFS USN Journal file. The quick version: this file has a special data stream ($J) that contains a record of all file and filename creations, modifications, and deletions. This gives us a detailed timeline of file activity. We’ll use MFTECmd to parse the Journal file and export the results to .CSV, which we can then analyze with Timeline Explorer to understand the lifecycle of Eventlogs.ps1.

Let’s put this into practice:

Export the $J file from either Arsenal or FTK Imager from the victim image’s C:\ folder.
Open PowerShell as an administrator and run the following command:

MFTECmd.exe -f ‘<path to $J>’ –csv “<path to CSV output”

PowerShell: Executing MFTEcmd.exe

Open the resulting file with Timeline Explorer. For this challenge, we’ll keep it simple and enter eventlogs.ps1 into the Name column. This will show all records with that filename, and we can refer to the Update Reasons column to understand when the file was created and deleted.

Now we know the file exists and is part of the malware — but if we can’t analyze it directly, what else can we do to confirm it tampered with the event logs?

Luckily for us, Microsoft audits event log clearing in the Security event log as Event ID 1102 — “The audit log was cleared.”1102(S) The audit log was cleared. — Windows 10 _Though you shouldn’t normally see it, this event generates every time Windows Security audit log is cleared. This is…_learn.microsoft.com

Though you shouldn’t normally see it, this event is generated every time the Windows Security audit log is cleared.

We can open the relevant Security.evtx log from the victim’s device in the C:\Windows\System32\winevt\Logs directory.

The location of the Security.evtx logs

Once the log is opened in Event Viewer, filter for the 1102 events by pressing Filter Current Log and entering 1102 in the search field.

Event Viewer: Filtering for 1102 events

This gives us one event confirming that the Windows Event Logs were cleared — but the real indictment is that the event timestamp matches what we found with Timeline Explorer.

Event Viewer: Identifying a log clear event

Question 7: Knowing when unauthorized actions happened helps in understanding the attack. What is the UTC timestamp for when the script that tampered with event logs was run?

Based on the evidence we found in Question 6, we already have two solid datapoints indicating when the eventlogs.ps1 script was run — one from Timeline Explorer and another from the Security event log (Event ID 1102). But just for fun, let’s triple-confirm this by checking the PowerShell logs.

Navigate back to the mounted C\Windows\System32\winevt\Logs directory and load up the Windows PowerShell.evtx log this time.

The location of the Windows PowerShell.evtx logs

Instead of filtering for an event ID, we’ll use the Find… function to search the log for eventlogs.ps1.

Event Viewer: Identifying Eventlogs.ps1 activity

This search surfaces the corresponding event within the PowerShell logs, showing that the script was executed at the same time we correlated the logs being cleared and the file being deleted.

Since the results from MFTECmd were already in UTC, we don’t even need to perform a conversion.

So, while we couldn’t see the script contents directly, we can infer its impact through correlation — and now we’ve got three independent sources confirming the timestamp of execution.

Question 8: We need to identify if the attacker maintained access to the machine. What is the command used by the attacker for persistence?

We’re closing in on the end of our investigation. Let’s jump back into DiE and review the strings for further clues. Down on line 335, we’ll find evidence of a suspicious task in the Tasks directory: _\Windows\System32\Tasks\whoisthebaba_

Detect It Easy: Identifying a suspicious scheduled task in strings

We’re off to a solid start, but let’s correlate this with the victim image using MFTExplorer to see if this file existed on the system by navigating to the folder within the mounted image.

MFTExplorer: Identifying the scheduled task artifact in the victim image

Great — we found it! Unfortunately, we can’t extract the file, and there’s no evidence in the registry or Security Event Log to determine what this task actually does.

Time to get creative.

Since my environment doesn’t have Internet access, the next-stage payloads can’t be downloaded, so dynamic analysis locally won’t help much. Instead, let’s pivot to another external threat analysis service. This time, instead of VirusTotal, we’ll use something more visual: Any.Run.

In your browser, navigate to Any.Run and locate the report search. In the upper-right search box, submit the hash of SANS SEC401.pdf.cmd, which we can collect from FTK Imager or PowerShell (as we did in Question 3):

5790225B1BCFA692C57A0914DD78678CEEF6E212FBE7042B7DDF5A06FD4AB70D

The search will return several reports where the platform has analyzed this file. For this walkthrough, select the report from 09 August 2025, labeled Malicious Activity.

Any.Run: Searching public submissions

Once inside, we can use the visual replay window to watch the execution of the file, just as we would have seen in our own sandbox. This is an extremely robust capability offered by Any.Run that helps visualize the dynamic analysis process.

But for Question 8, we’re most interested in the command used to create the scheduled task. We can identify this in the Command Prompt window during execution. On the right side, we’ll also see it listed in the process tree:

https://app.any.run/tasks/69a81081-12f1-4fde-bd29-596d67b44cfb

schtasks /create /sc minute /mo 3 /tn “whoisthebaba” /tr C:\Windows\Temp\run.bat /RL HIGHEST

This command creates a scheduled task named whoisthebaba that runs every 3 minutes with the highest privilege level, executing run.bat from the Temp directory.

So, while we didn’t uncover this in our own environment, this shows the value of leveraging public sandboxes for dynamic analysis to overcome local limitations to ultimately find the answer.

Question 9: To understand the attacker’s data exfiltration strategy, we need to locate where they stored their harvested data. What is the full path of the file storing the data collected by one of the attacker’s tools in preparation for data exfiltration?

We’ve made it to the final question — and now we need to determine what data the malware collected and how it was staged for exfiltration.

We’ve already identified another script set to run with the scheduled task we found in Question 8: C:\Windows\Temp\run.bat

You may have already noticed that we previously found a reference to this script during the strings analysis using DiE.

Detect It Easy: Confirming the run.bat string

Fortunately, we can return to FTK Imager and extract this file from the VHD by navigating to the C:\Windows\Temp directory, right-clicking run.bat, and selecting Export Files…

There’s something curious at the bottom of the data window — we also see a reference to run.ps1. Let’s export that file too and drop it into the exported artifacts directory of our analysis environment.

FTK Imager: Discovering run.ps1 reference in run.bat

Since run.bat references run.ps1, we’ll jump straight into analyzing the .ps1 file first. And because my sandbox is isolated and has no internet access, there’s little danger in executing run.ps1 locally.

Before executing, we’ll monitor the activity with another built-in tool from Flare-VM: Sysinternals Process Monitor (ProcMon). Open ProcMon and set the filter to: Process Name is powershell.exe.

ProcMon: Filtering the powershell.exe process

This narrows our focus to only PowerShell events, which helps us better understand what the script is doing. Since we’re looking for the full path of the file storing the data collected, we’ll start by searching for CreateFile events.

ProcMon: Discovering CreateFile events

By doing this, we’ll see that PowerShell creates a file named BL4356.txt in the analysis environment. Simultaneously, the PowerShell window appears to be listing dozens of IP addresses as offline…

PowerShell: Output of the run.ps1 script

Let’s confirm whether this BL4356.txt artifact also exists in the victim image using FTK Imager or Arsenal.

FTK Imager: Confirming activity in the victim image

Bingo! This confirms the same behavior in both environments. Between the PowerShell output and the contents of the file, it’s clear that the script is performing host discovery and saving the results.

Let’s take it a step further and analyze the contents of run.ps1 directly. For this, we’ll use CyberChef, since I suspect there’s some obfuscation involved.

With CyberChef open, click Open as File in the upper-right to load the script into the input window. As expected, there’s a blob of base64-encoded strings, but decoding it isn’t quite so straightforward. Notice the reverse operation? The script appears to convert $best64code into an array, then reverse it back into a string.

CyberChef: Analyzing the run.ps1 script

To decode it, copy the $best64code into a new CyberChef tab, then add the Reverse and From Base64 operations to your recipe — and voilÃ !

CyberChef: Decoding the run.ps1 script

We can confirm that this script performs a host discovery scan and saves the results into the following path: $env:UserProfile\AppData\Local\Temp\BL4356.txt.

We now just need to substitute the victim’s actual UserProfile path to construct the full answer.

Conclusion:

Whew! That was a tough one — but that wraps up our investigation of the SpottedInTheWild challenge! We walked through each phase of the attack, from identifying the initial malicious archive downloaded via Telegram, to uncovering the use of a WinRAR vulnerability, tracking persistence through scheduled tasks, and finally discovering how the attacker staged data for exfiltration.

A big thank you to CyberDefenders for putting together such a fun and challenging lab! There was some stumbling along the way, but this one really pushed me to think creatively and combine the strengths of static and dynamic analysis. It also highlighted how public tools like Any.Run, VirusTotal, and CyberChef can help fill in the gaps when your own environment has limitations.

I initially chose this challenge to learn more about Arsenal Image Mounter, since it was new to me — but it ended up becoming a much more sprawling example of how defenders can pivot between forensic artifacts like the $MFT, USN Journal, and event logs to reconstruct attacker behavior. Whether it was filtering for CreateFile events in ProcMon, decoding obfuscated PowerShell in CyberChef, or correlating timestamps across tools, every step helped us build a clearer picture of the compromise. Awesome stuff!

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://cyberdefenders.org/blueteam-ctf-challenges/spottedinthewild/?cta=navbar-sign-in&origin=%2Fblueteam-ctf-challenges%2Fspottedinthewild%2F

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

Arsenal Recon — Arsenal Image Mounter: https://arsenalrecon.com/

**Magnet Forensics — " # "

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

VirusTotal — SANS SEC401.rar: https://www.virustotal.com/gui/file/d1a55bb98b750ce9b9d9610a857ddc408331b6ae6834c1cbccca4fd1c50c4fb8

NIST NVD — CVE-2023€“38831: https://nvd.nist.gov/vuln/detail/cve-2023-38831

Exterro — FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager

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

Microsoft Learn — 1102(S): The audit log was cleared: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-1102

Any.Run: https://app.any.run/tasks/69a81081-12f1-4fde-bd29-596d67b44cfb

Sysinternals — Process Monitor: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

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

CyberDefenders — Insider Lab Walkthrough

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

CyberDefenders — Insider Lab Walkthrough

A Linux DFIR Challenge Using FTK Imager and Built-In Logs.

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

Introduction:

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

Let’s check out the scenario below:

Challenge Scenario:

After Karen started working for €˜TAAUSAI,’ she began doing illegal activities inside the company. €˜TAAUSAI’ hired you as a soc analyst to kick off an investigation on this case.

You acquired a disk image and found that Karen uses Linux OS on her machine. Analyze the disk image of Karen’s computer and answer the provided questions.

A case of a malicious insider? That’s not good! It’s up to us to search for evidence and uncover what actions Karen took. Fortunately, we are provided with a forensic disk image that we can use to determine exactly what happened.

To perform this investigation, we’re going to leverage FTK Imager, a popular forensics tool used to create and explore disk images of a system. Once inside, we’ll be hands-on and searching through the available artifacts manually to shed some light on what activities were perpetrated by Karen. Sounds like fun, right? Let’s get into it!

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

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

Question 1: Which Linux distribution is being used on this machine?

Once the challenge file is extracted, navigate to the c46-FirstHack directory, which contains the FirstHack.ad1 file. The AD1 file is a forensic disk image format created by FTK Imager.

Overview of the Challenge File contents

To work through this challenge, we’re going to rely on analyzing artifacts within the disk image. Our first step is to open FTK Imager within your analysis environment.

Once the application is open, go to File > Add Evidence Item > Image File, and point to the FirstHack.ad1 file.

FTK Imager: FirstHack.ad1 loaded

Now that we have the image mounted, we can search for the answer to Question 1. One log we can check to identify the Linux distribution used on the machine is the kern.log located at /var/log/kern.log. This log contains kernel-related logging data, including the OS version being loaded.

FTK Imager: Identifying the Linux version in the kern.log

This log tells us that Karen is using Kali Linux, a popular penetration testing distribution that you’re likely familiar with if you’re reading this walkthrough.

Question 2: What is the MD5 hash of the Apache access.log file?

The next step on our investigation is to determine the MD5 hash of the system’s Apache access.log file.

We’ll locate the access.log within the /var/log/apache2 directory. Once we’ve found it, we can leverage FTK Imager’s Export File Hash List feature by right-clicking the access.log entry. This will generate a CSV file containing the file hashes.

FTK Imager: Exporting the access.log file hash

For example, I opened the CSV file in Visual Studio Code, but any CSV viewer will work. Once you have it open, you’ll be able to collect both the MD5 and SHA1 file hashes.

Visual Studio Code: Reviewing the access.log file hash export

Question 3: It is suspected that a credential dumping tool was downloaded. What is the name of the downloaded file?

Our next task is to determine what credential dumping tool the user downloaded. A good starting point is to check the user’s Downloads directory at /root/Downloads.

FTK Imager: Surveying the Downloads directory

Inside the directory, we’ll discover a file named mimikatz_trunk.zip. Based on this filename, we can reasonably say that this archive contains the popular Windows credential dumping tool, Mimikatz.

Question 4: A super-secret file was created. What is the absolute path to this file?

To answer Question 4, we’ll need to dig a bit deeper to uncover a " # "

super-secret” file created on the system.

One extremely robust and common source of forensic artifacts on Linux is the .bash_history file. This file stores the commands run within the shell or terminal, making it extremely valuable for providing clues about user behavior on the system. For our purposes, we can check this log by navigating to /root/.bash_history and reviewing the output in the bottom pane.

FTK Imager: Checking the contents of .bash_history

Among many other interesting commands, we can see toward the top of the log that the touch command is used to create SuperSecretFile.txt in the /root/Desktop directory. Sneaky indeed!

Question 5: What program used the file didyouthinkwedmakeiteasy.jpg during its execution?

To answer Question 5, let’s continue analyzing the .bash_history file and see if we can stumble across any clues that point us in the right direction.

FTK Imager: Identifying didyouthinkwedmakeiteasy.jpg in .bash_history

Scroll to the bottom of the log and you’ll find a reference to the target file didyouthinkwedmakeiteasy.jpg. Notice the command binwalk next to it? According to the Kali documentation:

Binwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images.

So, in this context, it appears that cautious Karen was checking this image file for the presence of embedded executables using Binwalk.

Question 6: What is the third goal from the checklist Karen created?

To determine the third goal, we first have to locate Karen’s checklist. To do this, we’ll stumble through the usual suspects — common directories like Desktop, Documents, Downloads, Pictures, and so on.

Lucky for us, checking the /root/Desktop folder first reveals two files: mimikatz and Checklist. The first confirms that Karen downloaded the Mimikatz credential dumper we found back in Question 3, and the second contains her checklist.

Select the Checklist and check out Karen’s plans.

FTK Imager: The location of Karen’s checklist

Question 7: How many times was Apache run?

Remember back in Question 2 when we obtained the file hash of access.log? To answer Question 7, we need to check the contents of the file instead.

Let’s navigate back to /var/log/apache2/access.log. After selecting the file, we see something strange—the log is blank. No problem. This actually tells us something useful: Apache was not run on Karen’s system, so the answer is zero.

FTK Imager: The contents of the access.log

Question 8: This machine was used to launch an attack on another. Which file contains the evidence for this?

For Question 8, we need to determine which other machine Karen’s device attacked. As a starting point, let’s return to the /root/.bash_history file to search for any additional clues.

FTK Imager: Identifying victim clues in .bash_history

Toward the bottom of the log, we see a reference to the name Bob — maybe the same Bob mentioned in the Checklist? Interesting, but not entirely helpful.

But did you notice an oddly named .jpeg file in the /root directory? You can see it in the file list at the same location where we selected the .bash_history. Let’s select it to view the contents…

FTK Imager: Evidence of the attack

Bingo! This is a screenshot of Bob’s desktop, which we can determine from the user file path visible in the Windows command prompt window. This strongly implies that Karen had remote access to Bob’s device.

Question 9: It is believed that Karen was taunting a fellow computer expert through a bash script within the Documents directory. Who was the expert that Karen was taunting?

Question 9 tells us that there’s a bash script in the Documents directory that contains the information we’re looking for. Let’s check it out.

Within the directory, there are a couple of scripts, but we want to focus on firstscript_fixed.

Checking out the contents of this simple script, we see some network enumeration tasks, but the final command contains this printed line:

echo “Heck yeah! I can write bash too Young”

FTK Imager: Karen’s taunt

Based on the boasting nature of this output, we can reasonably guess that Young is the computer expert Karen was taunting.

Question 10: A user executed the su command to gain root access multiple times at 11:26. Who was the user?

For this objective, we can leverage another log — /var/log/auth.log. This file contains the system’s authentication events, including commands elevated using sudo.

Let’s use the find feature within the output window to identify the executed su commands.

FTK Imager: Finding the su events in auth.log

Now that we’ve found them in the logs and matched the timestamps to the question, we can see that the user postgres was responsible for the command execution.

Question 11: Based on the bash history, what is the current working directory?

For our final question, we’ll return one last time to the .bash_history artifact to determine the current working directory of the terminal.

FTK Imager: Finding the current working directory from .bash_history

Easy enough — we can see the bash history shows navigation to the /root/Documents/myfirsthack directory, where we previously stumbled across Karen’s attack tooling.

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

Conclusion:

There we have it! We’ve successfully analyzed the forensic disk image of Karen’s device through FTK Imager. With access to the image, we were able to move through our investigation, determining several key pieces of evidence, such as the OS distro, the presence of a common credential access tool, a possible motive, a victim, and some of Karen’s associates. Not too bad! Now let’s report our findings back to TAAUSAI and close out this Insider case.

A big thank you to CyberDefenders for a fun and engaging lab. I’ve been brushing up on my Linux forensics skills recently, so I chose this lab to run an investigation without terminal access to the system, instead relying on artifacts available from within a disk image. This was surprisingly effective, and it was interesting to see the Linux file structure from the top-down rather than being in the system directly. It really helped to solidify my working knowledge of Linux artifacts and will definitely be helpful in the field. Awesome stuff!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/insider/

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

FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager

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

Kali Documentation — Binwalk: https://www.kali.org/tools/binwalk/

CyberDefenders — Oski Lab Walkthrough

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

CyberDefenders — Oski Lab Walkthrough

A Cyber Threat Intelligence Challenge Using VirusTotal, Tria.ge, Any.Run, & MITRE ATT&CK.

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Oski Lab from CyberDefenders, you’re in the right place. This challenge is a fantastic introduction to cyber threat intelligence (CTI) and leveraging online analysis platforms to perform research and gather indicators of compromise — let’s check out the scenario below.

Challenge Scenario:

The accountant at the company received an email titled " # "

Urgent New Order" from a client late in the afternoon. When he attempted to access the attached invoice, he discovered it contained false order information. Subsequently, the SIEM solution generated an alert regarding downloading a potentially malicious file. Upon initial investigation, it was found that the PPT file might be responsible for this download. Could you please conduct a detailed examination of this file?

In this challenge, the victim received a suspicious PowerPoint file and executed it. Assuming the role of a Security Analyst, our SIEM solution fired an alert about a potentially malicious file on the victim’s workstation — not good! It’s up to us to analyze the file hash using online cyber threat intelligence (CTI) and malware analysis services to determine if the file is a known-malicious artifact and learn more about the nature of the attack.

What’s in our toolkit for this investigation? We’ll start with the popular VirusTotal as a jumping-off point. From there, we’ll explore additional sources of information by pivoting to Recorded Future’s Triage and the dynamic analysis platform Any.Run. During our investigation, we’ll enrich our findings by mapping the observed tactics, techniques, and procedures to the MITRE ATT&CK matrix.

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

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

Question 1: Determining the creation time of the malware can provide insights into its origin. What was the time of malware creation?

Let’s dive right in! Start by extracting the downloaded challenge file archive. Inside, you’ll find the directory temp_extract_dir containing hash.txt.

This file contains our target — the unique file hash of the potentially malicious " # "

PowerPoint" file that triggered the SIEM alert. Using this file hash, we can start gathering intelligence about the file from online threat analysis platforms.

12c1842c3ccafe7408c23ebf292ee3d9

For our first steps, let’s pivot out to the popular online malware analysis platform VirusTotal. Head to the VirusTotal website and paste the malware file hash into the search box. This gives us a high-level overview of the corresponding file. We can see that the sample has already been submitted to the platform and is detected as malicious by a majority of the antivirus vendors that have scanned it. Good start!

VirusTotal: Detections Tab

To answer Question 1, we need to uncover the creation time of the malware. In VirusTotal, navigate to the Details tab and locate the Creation Time value under the History section. This value reflects the time the sample was compiled and can be helpful when building a timeline of how a malware attack unfolds. It’s worth noting that this timestamp can be spoofed, so don’t rely on it for complete accuracy.

VirusTotal: Identifying the sample’s creation time within the Details tab

Question 2: Identifying the command and control (C2) server that the malware communicates with can help trace back to the attacker. Which C2 server does the malware in the PPT file communicate with?

Moving right along, we now need to determine any URLs that the malware communicates with. This could indicate a command and control (C2) channel that the malware connects to.

To locate this information, click the Relations tab in VirusTotal and focus on the Contacted URLs section. Each entry here represents a URL the malware has attempted to reach. We can click on each one to pivot to its own VirusTotal entry and dig deeper.

VirusTotal: Identifying Contacted URLs

For example, by clicking the URL ending in .php, we can enrich the data by reviewing the Crowdsourced Context section. This often includes community-contributed insights, and in this case, it tells us that this is the C2 URL.

VirusTotal: Identifying a C2 IoC

Question 3: Identifying the initial actions of the malware post-infection can provide insights into its primary objectives. What is the first library that the malware requests post-infection?

Our next task is to identify the library requested from the C2 server. Based on the Contacted URLs we identified in Question 2, we already have some idea of what it might be. But to be thorough, and to explore the data from a different angle, let’s stick with VirusTotal and check the Behavior tab, which documents the detailed results of the dynamic analysis performed by VirusTotal.

VirusTotal: Identifying the requested library

Scroll down to Network Communication > HTTP Requests. Here, we’ll see an HTTP GET request for a DLL file: sqlite3.dll, hosted on the C2 URL. Since a DLL file is a library file, and the status code is 200 (successful), this evidence strongly suggests that we’ve found the answer to Question 3.

Question 4: Upon examining the malware, it appears to utilize the RC4 key for decrypting a base64 string. What specific RC4 key does this malware use?

To answer Question 4, let’s pivot from VirusTotal and search the file hash against another threat intelligence platform — Recorded Future Tria.ge.

Leveraging another platform is a solid strategy to get a fresh perspective on the analysis. Sometimes this reveals new information that isn’t available elsewhere.

In this case, we’re looking to identify the RC4 key used to decrypt a specific base64-encoded string within the malware payload. Searching the Tria.ge reports, we can find this easily. First, navigate to the Reports section and input the malware sample file hash into the search field:

Recorded Future Triage: Searching for the malware file hash

Then, select the first report to view the results of the analysis. Inside the report, check out the Malware Config section, which provides a high-level overview of strings extracted from the malware.

stealc | a040a0af8697e30506218103074c7d6ea77a84ba3ac1ee5efae20f15530a19bb | Triage _Check this stealc report malware sample a040a0af8697e30506218103074c7d6ea77a84ba3ac1ee5efae20f15530a19bb, with a score…_tria.ge

Recorded Future Triage: Identifying the RC4 key from the report

Using this method, we can find the RC4 key and complete Question 4.

Question 5: Identifying an adversary’s techniques can aid in understanding their methods and devising countermeasures. Which MITRE ATT&CK technique are they employing to steal a user’s password?

Moving right along, we now need to identify the specific technique this malware uses to steal a victim’s password, as it relates to the MITRE ATT&CK knowledge base.

For this task, let’s explore a third service — Any.Run. This is an interactive sandbox and malware analysis tool with robust reporting capabilities. But first, if we submit the malware hash to Any.Run, you might notice that there are dozens of reports to sift through, each with varying levels of detail.

Let’s work a little smarter and try to cross-reference a report from the VirusTotal Community tab comments. This way, we can pivot from one platform to another as we collect intelligence about the malware. Jump back to VirusTotal and check out the comment posted by ANY_RUN:

VirusTotal: Comment linking to the Any.Run report: https://app.any.run/tasks/d55e2294-5377-4a45-b393-f5a8b20f7d44

Now that we’ve found a matching report from VirusTotal, we can access the corresponding report directly on Any.Run — awesome! From here, we just need to view the MITRE ATT&CK mappings for the sample by pressing the handy ATT&CK button.

Any.Run: Locating the ATT&CK button

To answer Question 5, recall that we’re looking for a password-stealing function, which falls under the Credential Access tactic. While there are a few possibilities, we can determine through process of elimination that the technique in question is Credentials from Password Stores (T1555).

Any.Run: Identifying the MITRE ATT&CK technique

Question 6: Malware may delete files left behind by the actions of its intrusion activity. Which directory does the malware target for deletion?

Let’s stick with the MITRE ATT&CK matrix from Any.Run. This time, we’re looking for the directory deleted by the malware.

First things first: we can leverage our knowledge of the attacker’s techniques to identify the specific Defense Evasion sub-technique— Indicator Removal: File Deletion (T1070.004).

Any.Run: Identifying the MITRE ATT&CK defense evasion technique

Clicking the technique brings us to the details window, which displays evidence of the technique as performed by the malware.

Analyzing the cmdline field reveals a command to delete (del) all .dll files, specifically targeting the C:\ProgramData directory. This is a good indicator that the malware is cleaning up after itself.

Question 7: Understanding the malware’s behavior post-data exfiltration can give insights into its evasion techniques. After successfully exfiltrating the user’s data, how many seconds does it take for the malware to self-delete?

For our final task in this lab, let’s take a closer look at the file deletion technique. We already identified some cleanup activity in Question 6, so now let’s examine the full command to identify the timeout period.

In this case, we’re looking for a delay which indicates how long the malware waits before deleting itself. We can see this clearly in several locations within the Any.Run report, including the Technique Details section or right on the Overview page.

Any.Run: Identifying the timeout value from the technique details

Any.Run: Identifying the timeout value from the report overview

The command includes a timeout value of 5 seconds, showing us that the malware pauses briefly before its self-deletion routine.

Now that we’ve determined the number of seconds, let’s submit the answer and wrap up this investigation!

Conclusion:

There we have it! Starting with the file hash of a suspicious file, we successfully used our threat intelligence skills to determine that the PowerPoint file is indeed malicious — time to start our remediation! By pivoting to online threat intelligence and malware analysis services, we’ve uncovered much more about the nature of this file, including how it operates and what the impact of executing it could be.

Now that we’ve completed our objectives, let’s close out this walkthrough of the Oski Lab!

A big thank you to CyberDefenders for another engaging lab. I always keep threat intelligence challenges in the rotation because regular practice and learning what tactical information is available is such a valuable real-world skill. Having hands-on time with a variety of services is a great way to start building better defenses and equipping yourself with a stronger working knowledge of threats you might encounter.

I found it incredibly engaging that there was no single source that could provide all the answers for this lab — it required pivoting to several services to paint the full picture. Awesome stuff!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/oski/

REMnux: https://remnux.org/

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

Any.Run: https://app.any.run/tasks/d55e2294-5377-4a45-b393-f5a8b20f7d44

Recorded Future Tria.ge: https://tria.ge/250509-vyp1vshq21

MITRE ATT&CK — Credentials from Password Stores (T1555): https://attack.mitre.org/techniques/T1555/

MITRE ATT&CK — Indicator Removal: File Deletion (T1070.004): https://attack.mitre.org/techniques/T1070/004/

CyberDefenders — Yellow RAT Lab Walkthrough

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

CyberDefenders — Yellow RAT Lab Walkthrough

A Cyber Threat Intelligence Challenge using Hybrid Analysis, VirusTotal, and Red Canary Intelligence.

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Yellow RAT Lab from CyberDefenders, you’re in the right place.

In this scenario, we’re jumping into the world of cyber threat intelligence (CTI) by investigating a malware sample discovered within the victim’s environment. The challenge? We’re only provided the file hash of the malware, so it’s up to us to use our research skills to collect threat intelligence and determine what the malware is, how it operates, and what it communicates with.

To perform this investigation, we’ll leverage some common threat intelligence and malware analysis platforms, like VirusTotal and Hybrid Analysis, as well as conduct additional research on Google. Performing this analysis will give us the information we need to put a stop to this incident. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

During a regular IT security check at GlobalTech Industries, abnormal network traffic was detected from multiple workstations. Upon initial investigation, it was discovered that certain employees’ search queries were being redirected to unfamiliar websites. This discovery raised concerns and prompted a more thorough investigation. Your task is to investigate this incident and gather as much information as possible.

Question 1: Understanding the adversary helps defend against attacks. What is the name of the malware family that causes abnormal network traffic?

Time to kick off this investigation! Our first task is to unzip the challenge file containing a text file, hash.txt. The content of this file is the SHA256 file hash of the malware that infected the employee workstations.

To begin, copy the file hash:

30E527E45F50D2BA82865C5679A6FA998EE0A1755361AB01673950810D071C85

Throughout this challenge we’ll leverage several threat intelligence sources but the first one we’ll use is Hybrid Analysis, an online malware analysis service, to check the unique malware file hash contained in hash.txt. This allows us to check previous reports about the sample and gather more information about the incident. To do this follow the steps below:

Use your web browser to navigate to https://www.hybrid-analysis.com/
Select the " # "

Report Search" tab. 3. Paste the file hash into the search box & press " # "

search."

Select the first report in the list with the timestamp of June 20th, 2022 (though any should work.)
Within the report, under Falcon Sandbox Reports, click the report from the Windows 7 32 bit sandbox with the threat score of 94/100.

Hybrid Analysis search result: https://www.hybrid-analysis.com/search?query=30E527E45F50D2BA82865C5679A6FA998EE0A1755361AB01673950810D071C85

Hybrid Analysis: Selecting the Falcon Sandbox Report

Now that we’re in the report, we can start collecting some intelligence about the malware. The first objective to answer Question 1 is to discover the name of the malware family. To discover this information, we’ll use the Open Source Intelligence (OSINT) section under Additional Context and select the report from Red Canary Intelligence to be redirected to their blog entry.

Hybrid Analysis: Selecting the Red Canary Report

We’ll find the malware name is featured prominently as the subject of the write up. Not only that, but we’ll discover some extremely valuable technical information about the malware that can help us to contextualize the attack. Great find! We’ll return to this blog entry later, so keep it handy for later in the investigation.

Question 2: As part of our incident response, knowing common filenames the malware uses can help scan other workstations for potential infection. What is the common filename associated with the malware discovered on our workstations?

Now that we’ve uncovered the malware family we’re investigating, let’s pivot to another source of intelligence, VirusTotal. If you’re unfamiliar with it, VirusTotal is another popular malware analysis platform with detailed detection information and analysis reporting for malware samples.

The process of checking VirusTotal is similar to our approach with Hybrid Analysis:

Use your web browser to navigate to https://virustotal.com
Paste the file hash into the search box & press " # "

search."

Once the results page has loaded, select the " # "

Details" tab.

VirusTotal VirusTotalwww.virustotal.com

On the " # "

Details" tab, we’ll see a ton of valuable data about the malware sample but to answer Question 2, we need to discover the common filename used by the malware. We can locate this information by scrolling down to the " # "

Signature info" section under the " # "

File Version Information" header:

VirusTotal: Identifying the common filename of the sample

Once we’ve identified the " # "

Original Name," copy that value and submit the answer.

Question 3: Determining the compilation timestamp of malware can reveal insights into its development and deployment timeline. What is the compilation timestamp of the malware that infected our network?

For our next task, we need to determine the timestamp for the malware’s compilation. We can continue to explore the VirusTotal report to locate this information in the " # "

Portable Executable Info" section right below the " # "

Signature Info" we used in the previous question.

Scroll down to the " # "

Header" section to location the Compilation Timestamp value that we’re searching for.

VirusTotal: Identifying the compilation timestamp of the malware sample

Question 4: Understanding when the broader cybersecurity community first identified the malware could help determine how long the malware might have been in the environment before detection. When was the malware first submitted to VirusTotal?

To answer Question 4, we’ll need to identify the date the malware sample was first submitted to VirusTotal. To locate this information, check the " # "

History" section toward the top of the " # "

Details" tab and check the First Submission timestamp.

VirusTotal: Identifying the first submission time

Question 5: To completely eradicate the threat from Industries’ systems, we need to identify all components dropped by the malware. What is the name of the .dat file that the malware dropped in the AppData folder?

Our next objective is to identify files dropped by the malware. Typically, we can locate this information on VirusTotal but in this case, we’ll need to switch gears to find the answer since the data isn’t available on VirusTotal.

Let’s refer back to the Red Canary Intelligence report we discovered in Question 1 and see if we can gather more information from the blog to find the answer.

Scroll down to the " # “Deep dive on the .NET RAT"section of the blog to view the granular technical details of the malware including the name of the .dat file we’re seeking to answer the question.

Leveraging the report from Red Canary to identify the .dat file

Question 6: It is crucial to identify the C2 servers with which the malware communicates to block its communication and prevent further data exfiltration. What is the C2 server that the malware is communicating with?

We’ve made it to the final question! Our last objective is to identify the command and control (C2) server the malware communicates with. To tie this all together, we’ll check all the previous threat intelligence sources for this information, starting with the Red Canary report.

From the report, in the same section where we located the name of the .dat file for the previous question, we can see that point #3 contains the observed C2 URL used by the sample. That’s a good start, but let’s check another source.

Leveraging the report from Red Canary to identify the C2 server

Referring back to VirusTotal, navigate to the " # "

Behavior” tab and scroll to the " # "

Network Communication" section. Here, we’ll find the same URL that we discovered in the Red Canary report as a " # "

Memory Pattern Domain/URL" indicating a string discovered in the malware sample.

VirusTotal: Identifying the C2 server

We can take this one step further by checking the URL against VirusTotal to determine the reputation of this domain.

VirusTotal: Detection of C2 URL

Finally, let’s navigate back to the Hybrid Analysis report we used back in Question 1 and locate the " # "

Suspicious Indicators" section and locate the External Systems section. Here we’ll confirm the C2 URL along with the reputation detection of the domain, confirming our findings.

Hybrid Analysis: Locating the C2 URL

With this triple-confirmation, let’s submit the answer and wrap up this investigation!

Conclusion:

There we have it! Starting with the file hash of the sample, we were able to search for detailed information about the malware on VirusTotal and Hybrid Analysis. These platforms provided comprehensive reports on the malware’s behavior, allowing us to understand when it was compiled and seen in the wild, what file it drops, and its C2 infrastructure. The reports also contained links to valuable malware research, like the blog from Red Canary, that we used to tie the investigation together.

Now that we’ve scoped the attack and completed our objectives, let’s close out this walkthrough of the Yellow RAT Lab!

A big thank you to CyberDefenders, for another exciting and realistic lab scenario. I always keep threat intelligence challenges in the rotation. Experience with tools like VirusTotal and Hybrid Analysis is a fundamental in this field. Hands-on practice with these tools and understanding what you can learn from the reports is especially beneficial when time is of the essence during incident response or when defending against a specific threat actor. Although I don’t often have the opportunity to review research done by Red Canary, every time I encounter their work, I’m really impressed with the analysis — I’ll definitely keep them bookmarked!

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

Tools & References:

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/yellow-rat/

Hybrid Analysis: https://www.hybrid-analysis.com/

Hybrid Analysis (Sample): https://www.hybrid-analysis.com/sample/30e527e45f50d2ba82865c5679a6fa998ee0a1755361ab01673950810d071c85/5fd004f2f760b679ae373bb3

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

VirusTotal (Sample): https://www.virustotal.com/gui/file/30e527e45f50d2ba82865c5679a6fa998ee0a1755361ab01673950810d071c85/community

**Red Canary Threat Intelligence — " # "

Yellow Cockatoo: Search engine redirects, in-memory remote access trojan, and more" :** https://redcanary.com/blog/yellow-cockatoo/

CyberDefenders — IcedID Lab Walkthrough

Mon, 17 Feb 2025 00:00:00 +0000

CyberDefenders —IcedID Lab Walkthrough

A Cyber Threat Intelligence Challenge using VirusTotal, MITRE ATT&CK, and Recorded Future Triage.

Image Credit: https://cyberdefenders.org/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the IcedID Lab from CyberDefenders, you’re in the right place. Prepare to dip your toes into the world of cyber threat intelligence!

In this scenario, we’re investigating a sample of the IcedID banking malware. Our goal is to understand how it operates and identify the threat actor behind it. Having this intelligence can help our team stay one step ahead of this potential threat.

To analyze the sample, we’ll leverage VirusTotal and Recorded Future Triage (tria.ge) to review previous analysis results about the malware. Then, we’ll pivot to MITRE ATT&CK, a global knowledge base of adversary tactics and techniques, to determine which threat actors are linked to the malware. Sounds like fun, right? Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/icedid/

Challenge Scenario:

A cyber threat group was identified for initiating widespread phishing campaigns to distribute further malicious payloads. The most frequently encountered payloads were IcedID. You have been given a hash of an IcedID sample to analyze and monitor the activities of this advanced persistent threat (APT) group.

Setup the REMnux Analysis Environment & Extract the challenge file:

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

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

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

Question 1: What is the name of the file associated with the given hash?

Let’s kick off this challenge by extracting the challenge file using the password linked in the challenge.

Once extracted, we’ll see the file, hash.txt, which contains a file hash of an IcedID malware sample. According to MITRE ATT&CK, this malware " # “is a modular banking malware designed to steal financial information that has been observed in the wild since at least 2017”.

With the unique file hash in our possession, we’ll to external services to gather threat intelligence and learn more about the malware. We’ll start by using VirusTotal first.

191eda0c539d284b29efe556abb05cd75a9077a0

In your web browser, navigate to the VirusTotal site and paste the file hash into the search field.

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

To answer Question 1, navigate to the " # "

**Details" ** tab and scroll to the **" # "

Names" ** section, to find the file names associated with the hash. One of them matches the format given by the question.

Question 2: Can you identify the filename of the GIF file that was deployed?

Next, to answer Question 2, we need to identify the GIF downloaded by the malware which we can locate in several places on VirusTotal.

The first spot we can check is on the " # "

Relations" tab under the " # "

**Contacted URLs" ** section. There we’ll find several URLs that point to the file, 3003.gif.

Another area that we can discover this information is on the " # "

Behavior" tab under **" # "

Network Communication**"

" # "

HTTP Requests," where network communications are documented after the file has been executed in the VirusTotal sandbox. We’ll see the same references to the GIF file that we saw before.

Question 3: How many domains does the malware look to download the additional payload file in Q2?

We’ve already stumbled on the answer in the previous question when we examined the " # "

Contacted URLs" section. Looking for URLs hosting 3003.gif, we’ll note five listed domains:

Question 4: From the domains mentioned in Q3, a DNS registrar was predominantly used by the threat actor to host their harmful content, enabling the malware’s functionality. Can you specify the Registrar INC?

Now, let’s take a closer look at the five domains we discovered in the previous question, focusing on the " # "

Contacted Domains" section. This table gives us some additional, high-level information including the domain registrars for each entry.

To answer Question 4, we need to determine the predominant registrar among the five hosting the GIF file. From the table, we’ll identify that 2/5 used NameCheap.

Question 5: Could you specify the threat actor linked to the sample provided?

Since we know the malware family name already, we now need to hunt for the threat actor group that deploys this malware. For this, we can turn back to the MITRE ATT&CK knowledge base page for IcedID, which will point us in the right direction.

IcedID _IcedID is a modular banking malware designed to steal financial information that has been observed in the wild since at…_attack.mitre.org

Scroll down to the " # "

Groups That Use This Software" section to identity the groups linked to the software. Let’s pick the first one (G0127) since it has the most references available.

Once on the page, we can see a description of TA551, also known as GOLD CABIN.

Question 6: In the Execution phase, what function does the malware employ to fetch extra payloads onto the system?

For the final question, let’s jump back to VirusTotal and hunt for execution tactics within the results. Select the " # "

Behaviors" tab, scroll down to the " # "

MITRE ATT&CK Tactics and Techniques," and expand the **" # "

Execution" ** section.

After a cursory scan, we’ll spot a potential hit for the function we are looking for, UrlDownloadToFile. Next, let’s take this a step further and check the malware’s file hash on another source, Recorded Future Triage (Tria.ge).

Reports | Triage _Edit description_tria.ge

After submitting the file hash, let’s see what we can discover by selecting any of the available reports. Then, within the report, navigate to the Malware Config section which displays the source of the file.

We’ll see within the malware’s configuration a similar function to the one we identified on VirusTotal, calling the URLs previously identified. This gives us a high degree of confidence that we’ve found the right function. Now let’s submit the answer and wrap up this investigation!

https://tria.ge/241110-ncqlyavnct

Conclusion:

Job well done! After collecting the IcedID file hash, we moved over to VirusTotal to learn more about the next stage payload downloaded by the malware and where it was hosted. Then, we leveraged MITRE ATT&CK to identify which threat actor group the malware is associated with. Finally, we reviewed the same sample on Tria.ge to gain additional indicators of how the payload is downloaded. We’ve now put the pieces together and can provide our team with context and indicators of compromise to watch out for! Having completed our objectives, let’s close out this walkthrough of the IcedID Lab.

A big thank you to CyberDefenders, for another engaging lab. I always keep a threat intelligence challenge in the rotation. I believe that experience with tools like VirusTotal, MITRE ATT&CK, and Tria.ge is a fundamental skill in this field. Hands-on practice with these tools can be especially beneficial when time is of the essence during incident response or when defending against a specific threat actor. I don’t often get the opportunity to work with Tria.ge, but every time I encounter it, I’m really impressed with the output and results — I’ll definitely turn to this tool more often in the real world!

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

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

Tools & References:

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

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

MITRE ATT&CK — Groups — TA551 (G1027): https://attack.mitre.org/groups/G0127/

Recorded Future Triage Reports: https://tria.ge/s?q=d86405130184186154daa4a5132dd1364ab05d1f14034c7f0a0cda690a91116d

CyberDefenders — PhishStrike Challenge Walkthrough

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

CyberDefenders — PhishStrike Challenge Walkthrough

A Cyber Threat Intelligence Challenge using MXToolBox, URLhaus, VirusTotal, MITRE ATT&CK, & MalwareBazaar

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

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the PhishStrike challenge from CyberDefenders, you’re in the right place. Prepare to dive into the world of Cyber Threat Intelligence!

In this scenario, a phishing email is targeting members of our institution’s faculty which includes a suspicious link. Our goal is to analyze the phishing email artifact to discover more about the sender and the link to scope the potential impact on a victim. To unravel this mystery, we’ll leverage several tools as we follow the email thread, including:

MXToolBox: This tool helps us perform a detailed analysis of the email headers. It offers easy-to-read insights about the sender and any potential anomalies that we can explore.

URLhaus: After analyzing the headers, we may uncover some suspicious URLs. URLhaus is a service where we can gather intelligence about these URLs by checking them against a database of known malicious domains, giving us valuable context about potential malware hosted on them.

Virus Total: After identifying details about the malware, we can submit the file hashes to VirusTotal to get comprehensive scan results and analysis.

MalwareBazaar: This is a repository used to share malware samples with the infosec community. Here, we can search for additional reports about the uploaded samples to understand the malware’s behavior.

The exciting part is that the deeper we go, the more details we’ll uncover about the email payload, discovering more insights about the malware’s infrastructure. Sounds like a fun mystery, right? Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and going on this investigation with me!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/phishstrike/

Challenge Scenario:

As a cybersecurity analyst for an educational institution, you receive an alert about a phishing email targeting faculty members. The email, appearing from a trusted contact, claims a $625,000 purchase and provides a link to download an invoice.

Your task is to investigate the email using Threat Intel tools. Analyze the email headers and inspect the link for malicious content. Identify any Indicators of Compromise (IOCs) and document your findings to prevent potential fraud and educate faculty on phishing recognition.

Setup the REMnux Analysis Environment & Extract the challenge file:

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

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

Question 1: Identifying the sender’s IP address with specific SPF and DKIM values helps trace the source of the phishing email. What is the sender’s IP address that has an SPF value of softfail and a DKIM value of fail?

Within the challenge file, there is a single email file — 194-PhishStrike.eml

We’ll need to start our investigation by analyzing the phishing email, starting with its headers. There are a few ways to approach header analysis of message, including opening it in an email client, a plaintext editor, or a header analysis tool. For this walkthrough, let’s start with an online header analysis tool — the MxToolBox Supertool Email Header Analyzer. This tool will allow us to copy and paste the headers and parse them in a more readable way.

But first, we need to obtain the headers. To do this, open the .eml file with any plain text editor within your analysis environment. The top section holds the message header information and the next section contains the body content which we’ll look at later.

Start of the message header.

Headers and Message Body Boundary

Once the header is pasted into the MxToolBox, we can search the formatted fields easily. We need to look for the Received-SPF mail header. If you’re unfamiliar, according to MailTrap, Sender Policy Framework (SPF) is:

An authentication method used by senders to specify hosts that are allowed to send an email on behalf of the domain.

In the case of this phishing email, the value is softfail which tells us that the email was sent from an IP address not explicitly authorized by the sending domain’s SPF record. It’s important to know that the email is still accepted and not rejected like it would be if the value was hardfail which explains why it was delivered to the victims.

Question 2: Understanding the return path of the email helps in tracing its origin. What is the return path specified in this email?

Within the MxToolBox results, simply search for the Search for the Return-Path header to find the original sender address. Additionally, any bounces would be sent back to this address.

Question 3: Identifying the source of malware is critical for effective threat mitigation and response. What is the IP address hosting the malicious file associated with malware distribution?

To answer Question 3, we need to examine the email body content for any links or attachments sent to the victim. Since this information isn’t part of the mail headers, let’s return to the plain text editor where we opened the 194-PhishStrike.eml to view the email body.

Below the header section, we’ll see the content. Notice the text " # "

VIEW INVOICE DOCUMENT HERE" holds a hyperlink to an IP address hosting an executable file. This is extremely suspicious and has all the hallmarks of a phishing link. It’s also the IP address we’re looking for to answer Question 3.

Question 4: Identifying malware that exploits system resources for cryptocurrency mining is critical for prioritizing threat mitigation efforts. The malicious URL can deliver several malware types. Which malware family is responsible for cryptocurrency mining?

We’ve identified the malicious URL within the email body, now let’s collect some threat intelligence by checking it on URLhaus, a malware URL submission platform used to track cyber threats, searching the URL hosting the executable file:

URLhaus Results

From the tags, we’ll notice that this URL is associated with several different malware types. To answer Question 4, we are interested in the tag associated with cryptocurrency mining — CoinMiner.

Question 5: Identifying the specific URLs malware requests is key to disrupting its communication channels and reducing its impact. Based on the previous analysis of the cryptocurrency malware sample, what does this malware request the URL?

Now, let’s click into the report to browse the detailed database entry. The first thing we’ll want is the SHA256 hash of the CoinMiner payload. Having the specific malware’s file hash in our possession allows us to pivot and check other threat intelligence services for hits and build a stronger malware profile.

For example, let’s navigate to VirusTotal and search the CoinMiner hash. We’ll check the Relations tab under Contacted URLs to understand what URLS the malware communicates with based on previous analysis on the service.

There are two URLs listed: One looks familiar to us from the phishing email, and the second one is new data — this is the one we’re looking for. With the additional information, we are starting to gain a better understanding of the malware’s infrastructure.

Question 6: Understanding the registry entries added to the auto-run key by malware is crucial for identifying its persistence mechanisms. Based on the BitRAT malware sample analysis, what is the executable’s name in the first value added to the registry auto-run key?

In the last question, we searched for information on the CoinMiner malware delivered by the phishing URL. This time, we’ll need to analyze the BitRAT sample downloaded from the same URL. We can accomplish this by heading back to URLhaus, copying the BitRAT payload hash this time, then submitting it to VirusTotal to view the report.

Back on VirusTotal, let’s check out the Behavior tab and scroll down to the Registry Actions > Registry Keys Set area:

VirusTotal VirusTotalwww.virustotal.com

While there are an overwhelming amount of entries listed, we can narrow the search by specifically looking for registry hives related to the persistence technique of abusing auto-run keys in the Windows registry.

To learn more about this technique and get some clues on what to look for in the report, let’s turn to MITRE ATT&CK:

Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the " # "

run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in.[1] These programs will be executed under the context of the user and will have the account’s associated permissions level.

The following run keys are created by default on Windows systems:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

Now that we have this background information, we can apply the intelligence gained from MITRE ATT&CK to search for the default run keys in the VirusTotal report, leading us to the executable.

Question 7: Identifying the SHA-256 hash of files downloaded from a malicious URL is essential for tracking and analyzing malware activity. Based on the BitRAT analysis, what is the SHA-256 hash of the file previously downloaded and added to the autorun keys?

Continuing our BitRAT analysis on VirusTotal, let’s find the SHA-256 file hash of the executable we found in the previous question. To do this, we just need to expand the Files Dropped section and search for the executable’s name. Expanding the entry will show us the hash of the file.

From: https://www.virustotal.com/gui/file/bf7628695c2df7a3020034a065397592a1f8850e59f9a448b555bc1c8c639539/behavior

Question 8: Analyzing the HTTP requests made by malware helps in identifying its communication patterns. What is the HTTP request used by the loader to retrieve the BitRAT malware?

We’ll approach this question the same we way did the previous two. This time, navigate to the Network Communication section and focus on HTTP Requests made by the malware.

Question 9: Introducing a delay in malware execution can help evade detection mechanisms. What is the delay (in seconds) caused by the PowerShell command according to the BitRAT analysis?

Moving right along, we’ll focus on analyzing any observed PowerShell commands executed by the BitRAT malware. We can find this information under the Process and service actions section under Shell Commands. After a quick analysis, we’ll locate the below PowerShell command:

There’s just one small obstacle, we can’t read the command directly yet since it has been encoded with Base64 (-enc.) Fortunately, we can easily decode this by leveraging a tool like CyberChef.

After opening the tool, paste the encoded string into the input field and then apply the From Base64 operation to the Recipe. While we could clean this up a bit further, the operation already allows us to see the deobfuscated string showing the delay in execution.

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

Question 10: Tracking the command and control (C2) domains used by malware is essential for detecting and blocking malicious activities. What is the C2 domain used by the BitRAT malware?

After reviewing the network connections on VirusTotal, we might think that we’ve already discovered the command and control (C2) URL, but none of the domains that we have uncovered so far fit the format that the question is looking for.

For our next steps, let’s check if we can find any additional information from the Community tab on the VirusTotal report. After reviewing a couple of the entries, we’ll stumble upon a solid lead from the extremely helpful comment below:

To double-confirm that this information is accurate, let’s head back over to URLhaus and click the BitRAT link to take us over to MalwareBazaar, a malware sample sharing platform for the infosec community, to see what additional threat intelligence may be available from other vendors.

On the MalwareBazaar page for the BitRAT sample, scroll down to the Vendor Threat Intelligence section and choose the Hatching Triage entry to see an overview of their findings. Notice anything interesting?

We found corroborating evidence confirming what we found on VirusTotal! Now that we’ve double-confirmed our findings, let’s submit the answer and move on to the final question of this challenge.

Question 11: Understanding the methods malware uses for exfiltrating data is crucial for detecting and preventing data breaches. According to the AsyncRAT analysis, what is the Telegram Bot ID used by the malware?

Back to URLhaus again to answer Question 11. Here we’ll apply the same process we did in the previous question, this time selecting the AsyncRAT link to view the sample on MalwareBazaar.

Since we acquired solid threat intelligence from the Hatching Triage in the last question, let’s analyze their full report to extract anything that will help us get closer to the answer.

https://tria.ge/221025-mz5tpscdf8

Inside of the report, we’ll see that the data is collected by both static analysis and behavioral analysis. Let’s review the linked behavioral2 report to see the activities in detail, specifically focusing on the Network section.

Here we’ll discover the final details that we are looking for, the Telegram Bot ID the malware used for data exfiltration.

Now that we have successfully leveraged threat intelligence to solve the mystery — let’s wrap up this investigation!

From Recorded Future Triage: https://tria.ge/221025-mz5tpscdf8/behavioral2

Conclusion:

Great job! Starting with a single email, we used MXToolBox to learn about the spoofed trusted contact and found a suspicious URL within the body of the email. Using URLhaus and Virus Total, we collected threat intelligence about the three different malware samples delivered by the malicious server to understand their behaviors. Finally, we leveraged additional, external reports about the malware to uncover how data might have been exfiltrated. With the objectives completed, we have all the information we need to help keep the institution safe from this threat. Let’s close the book on the PhishStrike challenge!

A big thank you to CyberDefenders, for another engaging and realistic lab scenario. This one was exceptionally fun. I always enjoy a challenge that starts with a single artifact and leads through a sprawling investigation that requires deep dives into external research. In the real world, when time is of the essence, it’s important to be able to obtain insights for previously observed threats using platforms like VirusTotal and URLhaus to quickly identify, understand, and remediate a threat. Practicing in a lab environment is time well spent to prepare. I hope you found this walkthrough insightful too!

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:

REMnux: https://remnux.org/

MxToolBox Supertool Email Header Analyzer: https://mxtoolbox.com/EmailHeaders.aspx

Mailtrap Email Headers: https://mailtrap.io/blog/email-headers/

URLhaus: https://urlhaus.abuse.ch/

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

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

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

MalwareBazaar: https://bazaar.abuse.ch/

Recorded Future Triage Report: https://tria.ge/221025-mz5tpscdf8

CyberDefenders — Ramnit Blue Team Lab Walkthrough

Mon, 04 Nov 2024 00:00:00 +0000

CyberDefenders— Ramnit Blue Team Lab Walkthrough

An Endpoint Forensic Investigation with Volatility 3 and VirusTotal

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

Introduction:

Imagine this scenario: You’re a cybersecurity analyst, and suddenly, you receive an alert about suspicious process behavior from a user’s workstation. You’re handed a memory dump from the infected machine to investigate the incident, analyze the artifacts on the system, and discover the malware’s actions.

If this sounds like something you’re into, welcome to my weekly walkthrough, you’ve stumbled on the right blog! This week, we’re jumping into the Ramnit Lab from CyberDefenders.

For this challenge, we’ll dissect a memory dump of a device infected with malware performing suspicious operations on the victim’s system. Using Volatility 3 and VirusTotal, we’ll locate the malicious process, uncover its file path on the system, and learn about any IP addresses and domains the malware contacts. The goal is to gather a list of indicators of compromise (IOCs) to understand the malware’s behavior and prevent any further impact on the environment. Sounds like fun, right? Let’s get into it!

If you find this walkthrough is helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!

Thanks for reading along, hope it helps!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/ramnit/

Challenge Scenario:

Scenario:

Our intrusion detection system has alerted us to suspicious behavior on a workstation, pointing to a likely malware intrusion. A memory dump of this system has been taken for analysis. Your task is to analyze this dump, trace the malware’s actions, and report key findings. This analysis is critical in understanding the breach and preventing further compromise.

Tools:

Volatility 3

Setup the REMnux Analysis Environment & Extract the challenge file:

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

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

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

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

Question 1: We need to identify the process responsible for this suspicious behavior. What is the name of the suspicious process?

Let’s kick off this investigation and start hunting for the suspicious process!

But before we dive into using Volatility, let’s quickly get familiar with the help documentation which is a handy way to see what plugins are available for use. We can bring up Volatility’s manual pages with the following command:

vol3 -h

Now, our first task is to understand what processes were running on the victim’s system when the memory dump was taken during the incident. We’ll accomplish this by leveraging Volatility’s [windows.pslist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pslist) plugin to scan the image and list the running processes on the system using the syntax below:

vol3 -f memory.dmp windows.pslist

Analyzing the processes list, we need to identify the suspicious one. If the output seems overwhelming, don’t worry — it takes practice to sift through it. A great resource to understand normal Windows behavior is the Hunt Evil poster from the SANS Institute.

At first glance, everything seems normal for virtualized Windows system, doesn’t it? The exception is one process looks a little suspicious: a ChromeSetup.exe is running when the capture was taken. Since the intrusion detection system (IDS) alerted on suspected malware execution, let’s start by investigating this process and make a note of the process ID (PID) too, we’ll need it for the next question.

Question 2: To eradicate the malware, what is the exact file path of the process executable?

Awesome! Now that we have uncovered the malicious executable, let’s find out more about it by determining its file path on the victim’s device.

Back in Volatility, we’ll use the windows.cmdline plugin this time which allows us to view not only the process command line arguments but also the executable file path of the process.

To make it easier, let’s use grep to show us only the results with the process ID (PID) of ChromeSetup.exe. We’ll find this information in the pslist output from Question 1 in the far left column.

vol3 -f memory.dmp windows.cmdline | grep 4628

There we go! The executable is in the victim’s Downloads folder. It appears that the victim was searching for the Google Chrome browser, encountered a malicious link, and inadvertently downloaded and executed the malware on their system.

Question 3:

Identifying network connections is crucial for understanding the malware’s communication strategy. What is the IP address it attempted to connect to?

Continuing with the malware analysis, we need to identify any network connections the malware made to find the second stage or command and control (C2) server.

For this part, we’ll use Volatility’s [windows.netscan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan) plugin to scan the network artifacts in the image. Using grep again, we’ll filter the results to only show those matching the malicious PID.

vol3 -f memory.dmp windows.netscan | grep 4628

The downside is that you won’t see the column names in the output, but you can refer to the screenshot below for reference.

Volatility windows.netscan output headers

Once we run the command, the table reveals that the malware is communicating with an external IP address seen in the ForeignAddr column. This is the IP address of the command and control (C2) server that we’re looking for!

Question 4: To pinpoint the geographical origin of the attack, which city is associated with the IP address the malware communicated with?

Now that we’ve discovered the malware infrastructure’s IP address, we’ll pivot and gather geolocation intelligence about it. For a higher degree of confidence, let’s check a couple of geolocation services since the location data results can vary depending on the method the database provider uses to determine the location.

Starting with VirusTotal, we can tentatively determine that the IP address is located in Hong Kong.

Geolocation data from VirusTotal

Next, we’ll check ipinfo.io for added validation:

Geolocation data from ipinfo.io

Double-confirmed! Although we could continue checking with various geolocation and threat intelligence services, we’ve already found our answer for the purposes of this challenge.

Question 5: Hashes provide a unique identifier for files, aiding in detecting similar threats across machines. What is the SHA1 hash of the malware’s executable?

Next, we need to find the SHA1 hash of the malware executable so that we can gather more intelligence and perform further analysis to understand its impact.

The first step to obtain the file hash is to extract the executable from the memory dump. For this, we can leverage Volatility’s [windows.dumpfiles](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles) plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump and the PID of the ChromeSetup.exe process we found in Question 1.

vol3 -f memory.dmp -o windows.dumpfiles –pid 4628

As the process completes, check the terminal output for the files that are being dumped to confirm that ChromeSetup.exe was extracted and note the corresponding file name on the right side (file.0xca82b85325a0… ).

Now, we can list the contents of the output directory to confirm that the extraction was successful. Finally, use the sha1sum command to calculate hash of the executable:

Awesome! Now that we have the SHA1 hash, we can answer Question 5. But, let’s take this a step further and jump over to VirusTotal to check if the sample, identified by the unique hash we extracted, has been previously analyzed:

VirusTotal VirusTotalwww.virustotal.com

Submitting the hash to VirusTotal confirms that this file is malicious and detected by most scanning engines on the platform_._ Let’s continue to the next question and learn more about the malware.

Question 6: Understanding the malware’s development timeline can offer insights into its deployment. What is the compilation UTC timestamp of the malware?

Since we already have the VirusTotal report for the malware open, we can use the existing analysis results on the platform to check the Creation Time value from the Details tab.

VirusTotal Report > Details Tab

We’ve made it to the last question! We’ll continue using the VirusTotal report to identify any domains that the malware contacts by navigating to the Relations Tab and then scroll down to Contacted Domains.

Between the IP address, SHA1 hash, and domain, we have a comprehensive list of indicators of compromise (IOCs) that we can use to hunt for the malware in the environment and block it. Let’s submit the final answer and wrap this investigation!

Conclusion:

Mission accomplished! With the help of Volatility, we successfully identified the malicious process, hunted for the malware path and file hash, and uncovered the IP addresses and domains the malware communicates with. With the objectives completed and a comprehensive list if IOCs in-hand, let’s close out this walkthrough of the Ramnit Lab!

A big thank you to CyberDefenders for another engaging and challenging lab. This lab was a great example of the importance of memory dump analysis during DFIR cases and showcased some excellent scenarios for analyzing memory artifacts. Hands-on practice with forensic tools through labs can be extremely beneficial, and every time I try a new challenge with Volatility, I discover some cool and new uses of the tool that makes it much more efficient the next time I need it. Practice makes perfect!

Remember if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, don’t forget to give it a clap. Your feedback is invaluable and helps me create content that supports your journey in cybersecurity. We’re in this together. Thanks for the support!

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

Tools & References:

REMnux: https://remnux.org/

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

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

Volatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/command-reference

ipinfo.io: https://ipinfo.io/

VirusTotal — C2 IP: https://www.virustotal.com/gui/ip-address/58.64.204.181/details

VirusTotal — Malware Sample: https://www.virustotal.com/gui/file/1ac890f5fa78c857de42a112983357b0892537b73223d7ec1e1f43f8fc6b7496/details

CyberDefenders — BlackEnergy Lab Walkthrough

Sun, 22 Sep 2024 00:00:00 +0000

CyberDefenders— BlackEnergy Lab Walkthrough

Endpoint Forensic Investigation with Volatility 2

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

Introduction:

Imagine this: an organization has suffered a cyber attack, and you’ve been handed a memory dump from an infected machine to investigate the incident. If this sounds like a thriller you want to be part of, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This week, we’ll tackle the BlackEnergy Lab from CyberDefenders. Using the Volatility framework, we’ll dissect a memory dump of a device infected with a new variant of the BlackEnergy malware. We’re going to search for suspicious processes, hunt evidence of process injection, and uncover malicious DLLs to assess the scope and impact of this malware. Sounds like fun, right? Let’s get to it!

In the spirit of learning, I won’t be revealing any flags in this write-up, but I hope that this guide sets you on the right track — you got this! If you find this walkthrough is helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/blackenergy/

Challenge Scenario:

A multinational corporation has been hit by a cyber attack that has led to the theft of sensitive data. The attack was carried out using a variant of the BlackEnergy v2 malware that has never been seen before. The company’s security team has acquired a memory dump of the infected machine, and they want you, as a soc analyst, to analyze the dump to understand the attack scope and impact.

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first! It’s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using REMnux for this challenge and walkthrough.

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

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

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!

Question 1: Which volatility profile would be best for this machine?

Let’s start out by extracting the challenge file with the password included on the challenge page.

Since the question mentions Volatility, let’s take a quick detour to get a refresher of what it is. According to the Volatility Framework website:

The Volatility Framework was developed as an open source memory forensics tool written in Python.

Meaning we will use Volatility to analyze the contents of the .raw memory dump provided to us. Now, there are a couple of versions of Volatility: Volatility 2.6 (The original, not in active development) and the latest, Volatility 3 (in active development) which are a little different.

For the purposes of this challenge, one of the key differences is that Volatility 2 uses " # "

profiles" to identify the operating system of the dump to accurately identify the locations of artifacts in memory. OS profiles like this aren’t used in Volatility 3.

Now what does this all mean? Well, Question 1 is asking about profile usage so going forward we know that the challenge will have us using Volatility 2 (which I am just going to call Volatility for the rest of the write-up).

With that background out of the way, let’s finally invoke Volatility and use the -h option to review the help file. This is a great idea to get an overview of what commands are available.

vol.py -h

We’re looking for a specific command that can help us determine which operating system profile we’ll use going forward. After reviewing the available options, we’ll find that imageinfo is the best choice.

vol.py -f CYBERDEF-567078-20230213-171333.raw imageinfo

After running the command against the memory dump, we’ll find the answer to Question 1 in the Suggested Profile(s) list.

Question 2: How many processes were running when the image was acquired?

Now that we know what profile to apply, we’ll need to analyze the memory dump and determine how many processes were running when the image was acquired. To do this, let’s review the Volatility help again to see if we can find a command that can display this data.

Let’s try the pslist command to display all the running processes and apply the profile we discovered in Question 1:

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=QUESTION-1-ANSWER pslist

Nice! The output shows the running processes so it should be a simple matter of counting them to answer Question 2, right? Well, almost. There is just one small detail to note. We are looking for running processes so the ones with a date/time in the Exit column or that have 0 threads are not actually running at the time of the capture, so we need to subtract them from the total.

Question 3: What is the process ID of cmd.exe?

Let’s continue analyzing the output generated with the pslist command. To answer Question 3, we’re going to focus on cmd.exe.

Once we locate the process name, we can check the process ID (PID) column to find the answer!

Question 4: What is the name of the most suspicious process?

To answer Question 4, we’ll continue examining the process list. Typically, some familiarity with normal Windows processes would be beneficial but fortunately for us, the suspicious process is obviously visible within the list.

Question 5: Which process shows the highest likelihood of code injection?

Okay, now we need to dig a little deeper with Volatility to locate the process with the highest likelihood of code injection.

First, let’s get some high-level background on what code injection is from MITRE ATT&CK (T1055) to better understand what we’re looking for exactly. According to MITRE, Process Injection is:

A method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process’s memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.

So, we’re looking for a process injected with malware running its memory space. Let’s see what Volatility commands are available to help us by referring to Volatility’s help file again and using grep to show us only the options with the word " # “inject"in them.

vol.py -h | grep “inject”

There are three options available! Let’s start with the m_alfind_ command at the top of the list. According to the Volatility command reference:

The malfind command helps find hidden or injected code/DLLs in user mode memory, based on characteristics such as VAD tag and page permissions.

Let’s run the command and see what we can find.

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 malfind

After going through the output, we’ll find a couple of processes but there is one that seems a little suspicious. Notice the ASCII string MZ and the corresponding hex (4D 5A)? This is the magic byte that indicates the file’s format. In this example it appears that a Windows executable is injected into this process — that’s probably not good.

But we don’t have a clear answer if this is malicious yet. Let’s do some additional research about malfind to understand if we are interpreting the results correctly.

Below is an excerpt from an excellent blog on Volatility forensics from security company Varonis:

As an incident responder when using €˜malfind’ if you see these values within a process then it is very likely you have identified a piece of malware that has injected itself into another process.

Okay, this gives us a bit more confidence that we’ve found the correct process to answer Question 5 but let’s perform one last check. We’re going to dump this process, check it against VirusTotal, and see if it is malicious or not. To dump the process, we can use the command below which specifies the PID (-p) of the malicious process and the output directory for the dump (-D).

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 malfind -p 880 -D

Now that we have a dump of the process, we can use the SHA256sum command to get the SHA256 file hash of the process.

sha256sum process.0x89aab590.0x980000.dmp

Finally, submit the hash to VirusTotal — the number of detection hits confirms that the process was injected with malicious code.

Question 6: There is an odd file referenced in the recent process. Provide the full path of that file.

Now that we have dumped the process and confirmed that it is malicious, let’s pivot and do some static analysis on the dumped file. To find the answer to Question 6, we’ll use the strings command from the terminal to pull out text inside of the file that we can analyze.

strings process.0x89aab590.0x980000.dmp

After running the strings command, scroll through the output to look for any " # "

odd” referenced files or paths.

Toward the end of the output, we’ll stumble across the highlighted path to a .sys file — this is the file we are looking for!

Question 7: What is the name of the injected dll file loaded from the recent process?

Now, let’s jump back into the Volatility help and see what options we have for analyzing DLL files. We can do the same method we did in Question 5 and _grep"dll"to see the available commands.

vol.py -h | grep -i “dll”

Let’s start with the dlllist option, focusing on the malicious process we found back in Question 5 to see if anything sticks out as suspicious.

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 dlllist -p 880

After a quick review, nothing seems obviously suspicious with the dlllist output. Let’s refer back to the Volatility Command Reference and see if we can discover more about another DLL command — ldrmodules.

There are many ways to hide a DLL. One of the ways involves unlinking the DLL from one (or all) of the linked lists in the PEB. However, when this is done, there is still information contained within the VAD (Virtual Address Descriptor) which identifies the base address of the DLL and its full path on disk. To cross-reference this information (known as memory mapped files) with the 3 PEB lists, use the ldrmodules command.

So, using the ldrmodules command might help us discover a hidden DLL which has been unlinked from all the lists in the Process Environment Block (PEB) which contains information about loaded DLLS.

Let’s try it and filter on the malicious PID:

vol.py -f CYBERDEF-567078-20230213-171333.raw –profile=WinXPSP2x86 ldrmodules -p 880

One of these DLLs is not like the others and is pretty suspicious. Notice the highlighted DLL is not present in any of the three linked PEB lists — I think we found our answer!

Question 8: What is the base address of the injected dll?

Okay, we’ve made it to the last question! How can we find the base address of the injected DLL we just uncovered? We know from the last question that the dlllist command doesn’t list the DLL. We also know that ldrmodules does list an address, but it’s too long to fit the answer format. What to do, what to do?

Well, let’s fall back to the malfind output that we used back in Question 5. Remember that there was an Address for the suspicious process listed? Let’s try that one…

Hey, that worked! Now that we have uncovered the base address of the injected dll, let’s wrap up this investigation.

Conclusion:

Mission accomplished! With the help of Volatility, we successfully identified the suspicious processes, hunted for evidence of process injection, and uncovered malicious DLLs to assess the scope and impact of this malware. With the objectives completed, let’s close out this walkthrough of the BlackEnergy Lab challenge!

A big thank you to CyberDefenders for another engaging and challenging lab. This lab was a great example of the importance of memory dump analysis during DFIR cases and showcased some excellent scenarios for analyzing memory artifacts. It’s been a while since I’ve worked with Volatility hands-on, and it’s always a fun and insightful to practice with the tool. This time was no different, especially since I had no previous experience with Volatility 2 and have only worked with Volatility 3 in the past, so there was an added learning component for me too!

Please don’t forget that if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

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

Tools & References:

REMnux: https://remnux.org/

Volatility Framework Website: https://volatilityfoundation.org/the-volatility-framework/

Volatility GitHub: https://github.com/volatilityfoundation/volatility

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

Volatility Wiki Command Reference — Mal: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal

VirusTotal: https://www.virustotal.com/gui/file/8638ab1e5f9ba4cffc66400d36d47f7805733fae828a0cace9421d0bd83eaefa

MITRE ATT&CK — Process Injection (T1055): https://attack.mitre.org/techniques/T1055/

Varonis: https://www.varonis.com/blog/how-to-use-volatility

CyberDefenders — GrabThePhisher Blue Team Lab Walkthrough

Sun, 18 Aug 2024 00:00:00 +0000

CyberDefenders — GrabThePhisher Blue Team Lab Walkthrough

Investigation of a Phishing Kit using Google, PHP, & the Telegram API

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

Introduction:

Have you ever come across a phishing website spoofing a familiar service and wanted to understand how it works? If so, welcome to another weekly walkthrough — you’ve stumbled on the right blog! This week, we’re tackling the GrabThePhisher Blue Team Lab from CyberDefenders.

Our mission this week is a Threat Intelligence exercise that has us defenders diving into a phishing kit used to impersonate a popular cryptocurrency exchange website and trick unsuspecting victims into providing their crypto wallet seed phrases. That’s not great!

Throughout this walkthrough, we’ll explore the inner workings of this phishing kit, uncovering how it operates, the methods it uses to harvest victim data, and ultimately, who is behind this campaign. Sounds like a fun time!

What are we waiting for? Let’s get started — thanks for reading along!

Challenge Link:

GrabThePhisher | Blue team challenge. _GrabThePhisher is a blue team lab that falls under the Threat Intel category, and will cover the following subjects…_cyberdefenders.org

Challenge Scenario:

Scenario:

An attacker compromised a server and impersonated https://pancakeswap.finance/, a decentralized exchange native to BNB Chain, to host a phishing kit at https://apankewk.soup.xyz/mainpage.php. The attacker set it as an open directory with the file name “pankewk.zip”.

Provided the phishing kit, you as a soc analyst are requested to analyze it and do your threat intel homework.

Question 1: Which wallet is used for asking the seed phrase?

Let’s jump right into analyzing the phishing kit! We’ll start by unzipping the challenge file and getting an overview of the contents. We already know from the scenario that the phishing kit is impersonating the PancakeSwap cryptocurrency exchange_,_ and we’ll see plenty of assets spoofing this service used in the kit.

But the first file that we’ll start analyzing is the index.html, the default landing page for the website. When we open the file, we’ll see several wallet types listed for connection:

Yikes! Does the phishing kit attempt to harvest credentials from all these wallet types? Let’s check into this by navigating back to the pankewk directory and checking for other references to any of these services_._

We’ll find only one of these wallets has its own folder — MetaMask.

Let’s explore this folder and focus on the file metamask.php and examine the code to see if we can find any requests for a seed phrase:

This looks promising! Just below the wallet name, we can see a field asking for a Phrase with some additional code_._ This confirms that we’ve found the correct wallet soliciting the seed phrase, which answers Question 1!

Question 2, 3, & 4:

What is the file name that has the code for the phishing kit?

In which language was the kit written?

What service does the kit use to retrieve the victim’s machine information?

Now that we have discovered the correct wallet let’s take a closer look at some of the other functions in the code to answer Questions 2, 3, & 4.

We already discovered that metamask.php contains the prompt to collect seed phrases, and can probably conclude that this is the file hosting the rest of the phishing code. To double-confirm this theory, we can look further down the code, and we’ll see some functions using the Telegram API. The use of an external chat application is a red flag and confirms that we are looking at the correct file that contains the phishing functions. This answers Question 2.

Next, we need to determine which language the kit was written in. Fortunately, we have determined this already. The file has the .php extension and it contains PHP tags which identify PHP code — so, we are looking at a kit written in PHP.

Finally, we also need to discover what service is being used to find the victim’s device information. Let’s turn our attention to the $request variable. Do you see the API request to a sypexgeo endpoint? Let’s do a Google search to gather more intelligence about this service.

According to their website:

Sypex Geo is a product for determining location by IP address, from the creators of Sypex Dumper. Having received the IP address, Sypex Geo provides information about the visitor’s location — country, region, city, geographic coordinates.

Interesting! It seems that the phishing kit leverages this service to gather geolocation data about its victims. This also confirms that this is the service we are looking for to answer Question 4.

Questions 5 & 6:

How many seed phrases were already collected?

Write down the seed phrase of the most recent phishing incident?

Remember in Question 2 that we located a potential exfiltration function using Telegram? Let’s take another look at this function to see if it performs any other actions:

Notice at the bottom of the function, after the victim inputs the content, it is also appended to a log file on the web server — log.txt. Let’s follow the bread crumb trail and navigate to pankewk/log/log.txt

Inside the file, we’ll see three seed phrases were already collected — not good news! But now we also have the answers to Question 5 & 6.

Questions 7, 8, 9, 10:

Which medium had been used for credential dumping?

What is the token for the channel?

What is the chat ID of the phisher’s channel?

What are the allies of the phish kit developer?

Okay, let’s return to metamask.php and search for evidence to answer the next several questions!

We can answer Question 7 already as we discovered the application/medium back in Question 2. Remember that in addition to being appended to the log.txt, the seed phrase credentials are also dumped to Telegram.

The answers to Questions 8 & 9 are straightforward and listed as the $token and $id variables within the same function!

To answer Question 10, we’ll look to the comments in the code (enclosed by the /* */ ) where we see a message with a username/signature in the closing. We can assume this the “ally” username of the attacker that deployed the phishing kit.

Question 11 & 12: What is the full name of the Phish Actor?

Now that we have thoroughly analyzed the code of the phishing kit, let’s put all the information together, gather about the Telegram channel itself, and apply some threat intelligence to get there. This should all be possible through the Telegram API since we found the channel ID and a bot token exposed in the phishing kit code.

Let’s refer to the Telgram API documentation to determine how to call the API and what methods we can try.

First, we will stumble across the proper format to make the query — awesome!

All queries to the Telegram Bot API must be served over HTTPS and need to be presented in this form: https://api.telegram.org/bot<token>/METHOD_NAME

Then, after reviewing the methods, we will find the getChat option which can be used to retrieve full information about the chat (ChatFullInfo.)

https://core.telegram.org/bots/api#getchat

So, putting all the pieces together we need to specify our bot token, getChat method, and chat ID parameter. Let’s try this in a web browser first by making a GET request using the URL below. This URL takes the information we located in Questions 8 & 9 and puts it into the format we discovered in the Telegram docs.

https://api.telegram.org/bot5457463144:AAG8t4k7e2ew3tTi0IBShcWbSia0Irvxm10/getChat?chat_id=5442785564

Using the Telegram API in a browser.

For comparison, let’s also try this same request using Curl from the terminal and then use JQ to parse the JSON output and make it pretty.

curl “https://api.telegram.org/bot5457463144:AAG8t4k7e2ew3tTi0IBShcWbSia0Irvxm10/getChat?chat_id=5442785564" | jq

Using the Telegram API from the terminal.

With either method, we’ve uncovered new information from the API including the first_name, last_name, and username fields for the members within the chat!

This is the final piece of information we needed to answer the last two questions of this investigation and get us one step closer to finding the threat actor who deployed the phishing kit.

Conclusion:

And there we have it — mission accomplished! We’ve successfully completed our analysis of the phishing kit, determined how it harvests seed phrases, where they are sent, and how many victims have been compromised. But that’s not all! With the help of the Telegram API and some exposed secrets in the phishing kit, we also uncovered more details about the threat actors themselves.

With the objectives completed, let’s close out this walkthrough of the GrabThePhisher Blue Team Lab. A big thank you to CyberDefenders for hosting another great challenge! I found this exercise particularly insightful, as I’ve often wondered how these types of phishing kits work. It was a fantastic opportunity to go hands-on and explore it myself.

My personal highlight was using the Telegram API to pivot and gather more information than was available in the kit. This unique objective provided a great learning opportunity to explore the documentation and understand what information can be found with an exposed token.

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:

Wikipedia MetaMask: https://en.wikipedia.org/wiki/MetaMask

Sypex Geo: https://sypexgeo.net/en/about/#:~:text=Sypex%20Geo%20is%20a%20product,region%2C%20city%2C%20geographic%20coordinates.

Telegram API: https://core.telegram.org/bots/api

REQBIN (Curl): https://reqbin.com/req/c-1n4ljxb9/curl-get-request-example

JQ: https://github.com/jqlang/jq

CyberDefenders — SysInternals Blue Team Lab Walkthrough

Sun, 07 Jul 2024 00:00:00 +0000

CyberDefenders — SysInternals Blue Team Lab Walkthrough

Endpoint Forensic Investigation of Masquerading Malware using Autopsy, Eric Zimmerman’s Tools, and VirusTotal

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

Introduction:

Welcome to my weekly walkthrough! Are you curious about investigating a malware incident from a forensic disk image? Well you’re in luck — we’re about to tackle the Sysinternals challenge from CyberDefenders!

Sysinternals is a digital forensics and incident response (DFIR) challenge where we will analyze the artifacts of a malware infection from a forensic disk image and gather intelligence on first and second stage executables.

You might be asking yourself " # "

wait, isn’t Sysinternals legitimate_?“and you’d be right! If you don’t know Sysinternals is a fantastic, and not malicious, suite of tools provided by Microsoft. Unfortunately, the victim in this scenario thought they were getting the legitimate tool from Microsoft but instead downloaded and executed some malware masquerading as the legitimate Sysinternals — not good!

To figure out what happened, we’re going to use quite a few utilities from Eric Zimmerman’s tools, Autopsy, and VirusTotal. So, if this sounds interesting to you, you’ve stumbled on the right blog!

In the spirit of learning, I am not going to be revealing any flags in this write-up, so I encourage you to go hands-on and try it for yourself — you got this! Now let’s put on our detective hats and have some fun with forensics!

Thanks for reading along!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/sysinternals/

Challenge Scenario:

A user thought they were downloading the SysInternals tool suite and attempted to open it, but the tools did not launch and became inaccessible. Since then, the user has observed that their system has gradually slowed down and become less responsive.

As a soc analyst, analyze the artifacts and answer the questions.

Question 1: What was the malicious executable file name that the user downloaded?

Let’s start by unzipping the challenge file; within the archive we have an Encase (E01) forensic image file. This time around, the challenge suggests a couple of tools that are available to open this file type including FTK Imager and Sleuthkit Autopsy. For this walkthrough, I chose to use Autopsy.

Let’s kick off this investigation and launch Autopsy, open a new case, load the challenge file image as the data source, and run the default ingest module options.

After the data source is processed, we’ll be able to browse through the victim’s device image.

Since the user mentioned that they tried to download the Sysinternals suite, we can start by checking out the Downloads folders in the User directory to see if it contains any artifacts that will help us answer Question 1.

After browsing the Downloads folders, we’ll stumble on an interesting binary, Sysinternals.exe, in the Public downloads folder. Based on the information provided by the user, this seems likely to be the malicious executable we are looking for masquerading as the legitimate Microsoft Sysinternals.

Question 2: When was the last time the malicious executable file was modified? 12-hour format

Since we have a changed time for the suspicious file in the listing pane, this seems like it will be straightforward, but unfortunately, it’s not that simple. Let’s get creative and approach this another way. Another tool suggested for this challenge is AppCompatCacheParser, a utility that is part of the excellent Eric Zimmerman’s tool suite.

Now for some background! The Application Compatibility Cache (AppCompatCache) is used in Windows-based systems to track compatibility with older apps in newer versions of Windows. At first glance, this doesn’t seem that interesting but, from a forensic perspective, it contains some valuable information. For example, according to this Google blog post, the AppCompatCache:

…Stores various file metadata depending on the operating system, such as:

File Full Path

File Size

$Standard_Information (SI) Last Modified time

Shimcache Last Updated time

Process Execution Flag

Okay! Now we’re getting somewhere. So now we just need to figure out how to access this cache. Fortunately, I stumbled across a helpful blog post from SANS which describes this process in some detail:

The first part of conducting ShimCache Analysis is pulling all of the SYSTEM hives from all of machines on the network.

So, putting all of this together, we just need to jump back into Autopsy, extract the SYSTEM registry hive, and parse it with AppCompatParser.

We’ll find the SYSTEM hive in Windows/System32/config — from here we can use Autopsy to extract the file.

Once the file is extracted, we can use the following syntax to parse the file with AppCompatCacheParser with the Windows command prompt.

AppCompatCacheParser.exe -f “PATH-TO-SYSTEM-HIVE” –csv “PATH-TO-OUTPUT-FILE.csv”

Finally, we can check the output and search for " # “sysinternals”— this will show us the Last Modified Time!

Note: For the purposes of this challenge, I am using Eric Zimmerman’s Timeline Explorer, but you can use any CSV viewer that you’d like.

Now before we try inputting this answer, pay special attention to the challenge question — it is looking for the 12-hour format, not the 24-hour time we got from the output.

Question 3: What is the SHA1 hash value of the malware?

Now, we need to get the SHA1 file hash of the malicious Sysinternals.exe.

The original plan was to simply extract the file from the Downloads folder, but the file hash didn’t match what the challenge was looking for — so we’ll need a new plan.

Let’s return to the SANS blog that we referenced in the previous question. Scrolling down to the bottom, there is a link describing the next article in the series which covers something relevant for what we need to tackle Question 3 — the Amcache.

Mass Triage Part 5: Processing Returned Files - Amcache _The Amcache.hve file contains information on the executables that were executed on the system. Yogesh Khatri’s blog…_www.sans.org

Let’s check out what the Amcache is all about. According to the blog entry, " # “the Amcache.hve file contains information on the executables that were executed on the system"and " # "

t_he following fields: full path and SHA1 hash.“To do this, we will use another of Eric Zimmerman’s tools, AmcacheParser. But first, we need to extract the Amcache registry hive (Amcache.hve) from the image using Autopsy.

The A_mcache.hve_ is in Windows/appcompat/Programs/Amcache.hve — let’s extract it and parse it!

AmcacheParser.exe -f “PATH-TO-SYSTEM-HIVE\Amcache.hve” –csv PATH-TO-OUTPUT-FILE.csv

In the output directory we’ll have several files, but we want to focus on Amcache_UnassociatedFileEntries.csv. Once it opens, we’ll _s_earch for " # “sysinternals"which provides us with a handy column with the SHA1 hash of the executable!

Question 4: What is the malware’s family?

Okay! Now that we have found the SHA1 hash of the malware binary, let’s gather some additional intelligence and do some research with VirusTotal so that we can better understand what we are dealing with.

To answer Question 4, we’re going to focus on the family labels for this binary. There are a couple of labels, but we are looking at the third one (at the time of this writing) to answer the question.

Hint: If the family label has changed, check the detection name from Alibaba on VirusTotal.

Question 5: What is the first mapped domain’s Fully Qualified Domain Name (FQDN)?

Now, let’s stick with VirusTotal and pivot over to the Relations tab so that we can see further details of the analysis including the contacted URLs:

After examining the list, only one of these sticks out as suspicious both in the domain name and the number of detection hits. Let’s enter the first contacted URL’s FQDN and move on to Question 6!

Question 6: The mapped domain is linked to an IP address. What is that IP address?

Well, I thought Question 6 would be simple to discover using VirusTotal or through reverse DNS lookups but neither of these options worked. So, let’s turn to the challenge hint for a thread to follow!

Interesting! The hint is pointing us to the PowerShell command history file.

about History - PowerShell _Describes how to get and run commands in the command history._learn.microsoft.com

Let’s return to our Autopsy case and see what we can discover by navigating to the file path.

Contents of the PowerShell Command History

Immediately, we see that PowerShell history shows some suspicious commands tampering with Windows Defender. At the bottom of the command history, we can also see that one IP address was added to the Windows hosts file with two different hostnames, the legitimate Sysinternals domain and the malicious one that we found in Question 5. After this modification, both URLs would resolve to the same IP address…

Let’s confirm this by checking the Windows hosts file in the image. You can navigate to it by following the path in the image below:

The victim’s Windows hosts file.

Okay, now that we have seen the information in two places let’s submit our answer and move forward with the investigation.

Question 7: What is the name of the executable dropped by the first-stage executable?

Let’s jump back over to our VirusTotal session to continue with our analysis.

This time, we are going to click the Behavior tab and scroll down to the Process and service actions section so we can focus on the Process Tree for the malware binary that we found in Question 1.

There’s something interesting here — the process tree for the malware binary spawns the Windows command prompt (cmd.exe) and runs an executable file which installs and starts a service, then sets it to automatically start.

The executable file is the " # "

dropped file” that we are looking for to answer Question 7!

Question 8: What is the name of the service installed by 2nd stage executable?

Fortunately, from our research for the previous question with VirusTotal we already discovered the installed service information.

This tactic could be used by a bad actor for Execution, Persistence, or Privilege Escalation within a victim environment. For further reading, I’m including some additional information on these techniques from MITRE ATT&CK if you’d like to know more — fun stuff!

MITRE ATT&CK — System Services: Service Execution (T1569.002)

MITRE ATT&CK — Create or Modify System Process: Windows Service (T1543.003)

Let’s review it again and check our work.

Question 9: What is the extension of files deleted by the 2nd stage executable?

Okay, we’ve made it to the last question for our investigation! Let’s go ahead with some static analysis of the 2nd stage executable that we discovered in Question 7.

From VirusTotal we learned that the binary was executed from the Windows folder. Since we know the file path now, why don’t we try to extract the file from the victim’s image using Autopsy so that we can analyze it?

Extracting the 2nd stage executable with Autopsy

Navigate to the Windows folder with Autopsy, right-click and extract the file.

Now that we have our sample, we can start at a high-level and parse the strings stored in the malware.

For some quick background if you are unfamiliar: strings are pieces of data that store information in an application. So, if we are analyzing an application or some code, being able to extract strings can help us as defenders to understand a program’s intent or functionality and could reveal interesting artifacts like IP addresses, URLs, commands, credentials, etc.

While there are a couple of ways we can approach this, we are going to serve poetic justice and leverage the legitimate Sysinternals Strings utility to perform the analysis.

Strings - Sysinternals _Search for ANSI and UNICODE strings in binary images._learn.microsoft.com

Now that we have the Sysinternals Strings downloaded, open the Windows terminal (Command Prompt or PowerShell), and run strings.exe against the 2nd stage executable that we extracted from Autopsy. For this write-up, I also directed the output to a .txt file for easier analysis.

.\strings.exe “PATH-TO-2ND-STAGE-EXPORT” > “PATH-TO-OUTPUT-FILE”

PowerShell syntax to run Strings.exe

As a starting point, let’s search the output file. We’ll use the installed service name that we found in Question 8 to get us closer to the functions that we want to analyze.

Hey, we already found something interesting — a wildcard string for a specific file extension.

This is a good lead, so let’s pivot back over to VirusTotal so that we can confirm our findings and see if we can discover any file deletion behavior. But first, we need to grab the file hash of the executable that we carved from Autopsy.

Let’s just jump into PowerShell and do a simple get-filehash to get the SHA256 hash of this file so that we can check VirusTotal again.

Navigate to the Behavior tab > File System Actions > Files Deleted.

Looking through the VirusTotal report, we see file deletion activity with the same extension that we discovered using Strings. For the purposes of this challenge, we have double-confirmation and high confidence that this is the answer Question 9.

Conclusion:

Mission complete! We successfully completed the listed objectives and analyzed the artifacts on the victim’s system to get through the SysInternals challenge! It’s time for the after postmortem report and to close this case!

A big thank you to CyberDefenders.org for hosting this awesome lab! This lab was more challenging than I expected, and the variety of tools needed to solve the challenges kept me engaged throughout. For my own knowledge gaps and practice, the questions that leveraged Eric Zimmerman’s AmcacheParser and AppCompatCacheParser were extremely valuable. These tools were new to me, but I’ll definitely be adding these to my toolbox going forward.

I hope that you had as much fun as I did and learned something new, too!

Thank you so much for reading along and working through this investigation with me. Until next week — stay curious!

Tools & References:

Microsoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/

Sleuthkit Autopsy: https://github.com/sleuthkit/autopsy

MITRE ATT&CK (T0849): https://attack.mitre.org/techniques/T0849/

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

Google Cloud Blog (AppCompatCache): https://cloud.google.com/blog/topics/threat-intelligence/caching-out-the-val

SANS AppCompatCache Blog Post: https://www.sans.org/blog/mass-triage-part-4-processing-returned-files-appcache-shimcache/

SANS Amcache Blog Post: https://www.sans.org/blog/mass-triage-part-5-processing-returned-files-amcache/

Microsoft Learn (PSReadline): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_history?view=powershell-7.4

VirusTotal (1st Stage Executable): https://www.virustotal.com/gui/file/72e6d1728a546c2f3ee32c063ed09fa6ba8c46ac33b0dd2e354087c1ad26ef48/detection

MITRE ATT&CK (T1569.002): https://attack.mitre.org/techniques/T1569/002/

MITRE ATT&CK (T1543.003): https://attack.mitre.org/techniques/T1543/003/

SysInternals — Strings: https://learn.microsoft.com/en-us/sysinternals/downloads/strings

VirusTotal (2nd Stage Executable): https://www.virustotal.com/gui/file/5b01cca415277e5fb0c454690142b9b4029a1566938875497d2f0593db555270/detection

CyberDefenders — Intel101 Blue Team Lab Walkthrough

Sun, 05 May 2024 00:00:00 +0000

CyberDefenders — Intel101 Blue Team Lab Walkthrough

OSINT investigation with WHOIS, Google, The Wayback Machine, & Wikipedia.

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

Introduction:

Welcome to my weekly walkthrough! Have you ever wondered about using passive Open-Source Intelligence (OSINT) to search the public internet for information? Well we’re about to do just that by tackling the Intel101 Blue Team Lab on CyberDefenders.

This is a threat intelligence challenge requiring us defenders to investigate a series of questions and collect information using passive open-source intelligence (OSINT) to find the answers — it’s like a digital scavenger hunt! We’ll accomplish this task using web-based tools like Google, The Wayback Machine, WhoIS, Wikipedia, and some visual image searching_._

Now what is OSINT anyway? According to the SANS Institute:

Open-Source Intelligence (OSINT) is defined as intelligence produced by collecting, evaluating and analyzing publicly available information with the purpose of answering a specific intelligence question.

So, whether you’re here to learn more about OSINT, a new tool, or are just looking for a reference walkthrough for the CyberDefenders Intel101 Blue Team Lab, you’ve stumbled on the right spot. In the spirit of learning, I will not be revealing any answers in this post, but I encourage you to follow along during your own investigation and use this post as a reference if you get stuck. This challenge is a bit tricky since it was created three years ago from the time of this writing and the data was more challenging to find.

Thanks for reading along, let’s have some fun!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/intel101/

Challenge Scenario:

Open-source intelligence (OSINT) exercise to practice mining and analyzing public data to produce meaningful intel when investigating external threats as a security blue team analyst.

Tools

Google Lens

archive.org

WhoIS

Question 1: Who is the Registrar for jameskainth.com?

For the first question, we have a variety of tools that we can use to perform a domain lookup but to keep it simple, let’s just use the DomainTools Whois website to perform a simple lookup of the domain:

Whois Record Output

From the results, we’ll find the domain registrar clearly at the top of the profile!

Question 2: You get a phone call from this number: 855€“707€“7328, they were previously known by another name? (No spaces between words)

Now, let’s pivot and use a search engine to perform a cursory scan for this phone number. For this example, we’ll use Google. Let’s input the phone number and look at the results:

One of the search results is a familiar website, the Better Business Bureau. This is a consumer trust organization that is used to review the rating of businesses in North America.

This website’s reputation gives us a high degree of confidence that the listed business is indeed tied to this phone number. Now that we have the first part, we need to do some further digging into the history of this company. For this task, we’ll use Wikipedia.

The information about the previous name for this company is conveniently listed inthe right-hand column for us!

Question 3: What is the Zoom meeting id of the British Prime Ministers Cabinet Meeting?

Let’s do a quick Google search again. We’ll find several COVID-era articles about this event. Let’s click on the link for the article from the well-known security reporter, Graham Cluley. Cluley’s article contains the story and a screenshot of the accidental information disclosure very clearly for us!

The UK Cabinet is meeting on Zoom… here’s the meeting ID _In case you’ve lost the Zoom meeting ID for today’s UK Cabinet meeting, here it is._grahamcluley.com

Question 4: What Percentage of full-time degree-seeking freshmen from the fall of 2018 re-enrolled to Champlain in the fall of 2019?

Okay, now it’s time to do some deeper investigation!

We are looking for the student retention rate from Fall 2018 to Fall 2019 at this University. We’ll start out by performing some Google searches to see if we can discover this information.

Google search

We find that Champlain College presents this information as published through the National Center for Educational Statistics:

Champlain College — Student Outcomes

Once we navigate to the page though, we find only the most current data. We’ll need to figure out a way to view the historical data for previous years, right?

Since the data is showing two years behind (this blog was written in 2024). Maybe we can utilize the Internet Archive’s Wayback Machine and see if we can view this same page as it existed in 2020?

Let’s go ahead and select the only 2020 snapshot and see what we can find:

This data gets us close to the answer, but for the challenge, we need a more precise percentage. So, let’s rewind and go back to Champlain’s Consumer Information and Disclosures page. What if we try that URL in the Wayback Machine instead?

Consumer Information and Disclosures _Links to institutional information about Champlain College_www.champlain.edu

Let’s try that URL and pick a date in 2020. Now, notice that the data was also published by a second website that is no longer present on the current page:

If we try this link and scroll down to Freshmen Returning for Sophomore Year, we get an exact percentage!

https://web.archive.org/web/20200919015651/http://members.ucan-network.org/champlain

Question 5: In 1998 specifically on February 12th, Champlain was planning on adding an exciting new building to its campus. Back then, it was called " # "

The Information Commons" . Can you find a picture of what the inside would look like? Upload the sha256 hash here.

Let’s continue using the Wayback Machine. We’ll search the website domain for Champlain College, champlain.edu, and select the snapshot from February 12th, 1998.

Notice the links at the bottom of the page? There’s one to the Information Commons Project mentioned in the question.

Once we click that, we are taken to a page that showcases a rendering of the inside and outside of the building:

Let’s download the inside view image. We can simply generate a SHA256 file hash to get the answer. I’m using a Linux environment for my analysis but you can do the same process in Powershell if are you in a Windows environment by using the Get-FileHash cmdlet.

Question 6: One of Champlain College’s Cyber Security Faculty got a bachelor’s degree in arts from this Ohioan university. Who was the other faculty member who studied there? (FirstName LastName — two words)

Let’s get back to Google searching a bit for this information. If we simply search for the Champlain university faculty, we can find the full faculty directory, but this is too overwhelming for us to click into each person.

So, let’s refine our search a bit and narrow it down to some specifics:

We can simply go down the line and check the Education section for each of the staff within the department.

Eventually, we stumble upon this profile which meets the question criteria — Ohioan University and Bachelor of Arts! Now we have a university name that we can use to further refine our Google search. Maybe we can use the URL of that full faculty site that we found earlier to search the directory?

If we click the first link and check the Education section, we can confirm that we have found another faculty member who attended the same University — great find!

Question 7: In 2019 UVM’s Ichthyology Class Had to Name their fish for class. Can you find out what the last person on the public roster named their fish?

We’ll start this challenge the same way we did with the previous one, with Google!

Quickly we discover that this search is particularly tricky since the challenge was made three years ago from the time of this blog. It doesn’t seem like search engines today have indexed anything helpful other than some quick overview information of the Ichthyology class.

Let’s try to narrow the scope a bit by learning a little more about the University and specific school the Ichthyology program is part of:

We’ve discovered that the program is part of the Rubenstein School of Environmental and Natural Resources. That’s a start, now we can check out the University’s course catalog and hopefully locate the course number of the Ichthyology class to help refine our search:

Undergraduate Catalogue _Students at the University of Vermont are responsible for knowing and complying with all requirements for their…_catalogue.uvm.edu

We’ll navigate to: The Rubenstein School of Environment and Natural Resources > Wildlife and Fisheries Biology Program and we’ll find the course information in the catalog. Of course, the catalog represents the offerings at the time of this writing (2024) and NOT 2019.

So, let’s try to get to the same information from back in 2019 and check for any differences. If we check the course catalog site using the Wayback Machine, we’ll find that the course number was different in 2019:

What does this mean? It means we know that we need to refine our search using the course number, WFB 232, to get closer to the information. Let’s check out the home page for the Rubenstein School of Environment and Natural Resources in the Wayback Machine.

This time, however, instead of viewing a site snapshot, let’s use the URLs button and see if we can locate further information about the WFB 232 program:

Okay, now we’re getting somewhere. Let’s try our luck and see if we can add some additional keywords to the filter and look for " # "

names" …

Bingo! We found the document we are searching for. Since the archive has a snapshot of this file, we can access it and view the information we are looking for!

Question 8: Can You Figure Out Which State This Picture Has Been Taken From? See attached photo

Okay, last question! First, we’ll open the evidence file and focus on the included image, UNADJUSTEDNONRAW_thumb_4859.jpg.

Let’s try using an image or visual search to see if we can locate a match. Typically, it’s a good idea to try your search on several different services like Bing visual search_,_ Google Lens, and Yandex to maximize the chances of locating a hit since each service approaches this process differently.

Unfortunately for me (and probably for you if you are reading this walkthrough) after trying this process with all three services and scrolling through hundreds upon hundreds of Dragon and Pteranodon images, it seems like there is no clear match…

I suspect what is happening here is that the image results have changed since the challenge was originally made three years ago, and the result isn’t quite as easy to locate as it was then (or no longer exists).

Stick with me though as I remain undeterred! We need to narrow this search scope down somehow. Our only lead is that the challenge question mentions " # "

State" I am making the assumption that this means the United States since the rest of the challenges have referred to American entities.

So, I will do what any normal analyst would do — search for " # "

List of dinosaur parks" on Wikipedia and scroll to the United States section.

That is a lot of parks…

https://en.wikipedia.org/wiki/List_of_dinosaur_parks

Now for some hindsight: Did I absolutely go through _Google’s s_treet view of each one of these parks in the vain hope of finding this Pterodactyl to complete this write-up? Yes, I did.

In my search, I eventually and mercifully stumbled upon this image:

Image credit: Google Maps

Red building — check. Weird rocks — also check. Potential Pterodactyl sighting — Maybe?

So, I decided to go through every single one of the Google photos for this location using the handy " # "

Dinosaur" tag filter.

Image Credit: Google

Thanks to some user content, we can finally confirm that we found the same Pterodactyl! Since I went through the Wikipedia list, we know what state this park is in already!

Conclusion:

Whew! Excellent job with the investigation! We made it through the Intel101 Blue Team Lab and successfully uncovered the public data we were looking for.

To wrap this up, thank you to CyberDefenders for the challenging (and sometimes frustrating) lab and the opportunity to practice OSINT analysis. The research process using Google and The Wayback Machine was really engaging and kept me thinking creatively while exploring the breadth of exposure that a user might have online and how difficult it is for data to truly be removed.

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:

CyberDefenders: https://cyberdefenders.org/

SANS: https://www.sans.org/blog/what-is-open-source-intelligence/

DomainTools Whois: https://whois.domaintools.com/

Google: https://www.google.com

Better Business Bureau: https://www.bbb.org/us/ga/dublin/profile/cable-tv/charter-spectrum-0743-45535

Wikipedia (Charter Communications): https://en.wikipedia.org/wiki/Charter_Communications

Graham Cluley: https://grahamcluley.com/uk-cabinet-zoom-meeting/

Champlain College: https://www.champlain.edu/about-champlain/consumer-information-and-disclosures

Internet Archive Wayback Machine: https://web.archive.org/

Bing: https://www.bing.com/

Google Lens: https://lens.google.com/

Yandex: https://yandex.com/images/

Wikipedia (Pteranodon): https://en.wikipedia.org/wiki/Pteranodon

Wikipedia (List of Dinosaur Parks): https://en.wikipedia.org/wiki/List_of_dinosaur_parks

CyberDefenders — L’espion Blue Team Lab Walkthrough

Sun, 28 Apr 2024 00:00:00 +0000

CyberDefenders.org — L’espion Blue Team Lab Walkthrough

OSINT investigation with Google and Sherlock

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

Introduction:

Welcome to my weekly walkthrough! Have you ever wondered about using passive Open-Source Intelligence (OSINT) to investigate a potentially malicious insider? Well we’re about to do just that by tackling the L’espion Blue Team Lab on CyberDefenders.

This is a threat intelligence challenge requiring us defenders to investigate and incident using passive open-source intelligence (OSINT) to determine the details of the attacker’s identity.

Now what is OSINT anyway? According to the SANS Institute:

Open-Source Intelligence (OSINT) is defined as intelligence produced by collecting, evaluating and analyzing publicly available information with the purpose of answering a specific intelligence question.

So, whether you’re here to learn about OSINT or are just looking for a reference walkthrough for the CyberDefenders L’espion Blue Team Lab , you’ve stumbled on the right spot. In the spirit of learning, I will not be revealing any flags, but I encourage you to follow along during your own investigation and reference this post if you get stuck.

Thanks for reading along, let’s have some fun!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/lespion/

Challenge Scenario:

You, as a soc analyst, have been tasked by a client whose network was compromised and brought offline to investigate the incident and determine the attacker’s identity.

Incident responders and digital forensic investigators are currently on the scene and have conducted a preliminary investigation. Their findings show that the attack originated from a single user account, probably, an insider.

Investigate the incident, find the insider, and uncover the attack actions.

Tools

Google Maps

Google Image search

sherlock

Setup the REMnux Analysis Environment & Extract the challenge file:

Safety first — It’s always a good idea when working with lab/challenge files from CyberDefenders (or any lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine. For example, I’m using REMnux for this challenge and walkthrough.

To keep this write-up focused I’m going to skip a step-by-step setup guide of REMnux. Instead, if you want to set up your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:

https://docs.remnux.org/install-distro/get-virtual-appliance

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!

Question 1: File -> Github.txt: What is the API key the insider added to his GitHub repositories?

All right let’s dive right in and extract the challenge file!

Once we extract the challenge file, we’ll have a few pieces of evidence to review. Question 1 is pointing us to the Github.txt so let’s open it up and see what’s inside!

We have a GitHub URL to examine, so let’s start there, check out the page, and then navigate to the Repositories tab.

There are quite a few forked repositories from other, well-known cybersecurity projects but the top one sticks out as a working repository.

Now that we are in the repository, we have a couple of options — we can either browse the code from our browser or examine it locally. For this challenge, let’s clone this repository so that we can examine the JavaScript (.js) files and scan them for secrets within REMnux.

git clone https://github.com/EMarseille99/Project-Build---Custom-Login-Page.git

Let’s start simple and utilize the strings command so that we can search the code without executing it. To help narrow the results, let’s grep the output and filter only for a specific string. Since we are looking for an API Key, we can just _grep"API" — we’ll use the -i to ignore case sensitivity.

Lucky for us, we found an exposed API key in the code. Let’s submit the answer to check our work:

Question 2: File -> Github.txt: What is the plaintext password the insider added to his GitHub repositories?

For Question 2, we’ll try the same approach that we did to locate the API Key. This time, we’ll _s_earch for " # "

Password" instead of " # "

API" to look for the credential.

Okay, we found a couple of strings; let’s focus on the bottom two. It looks like we have a complex password string; either the user machine-generated their password or we are looking at some sort of encoding. Fortunately, the last string says Base64, this gives us a clue that the string might be encoded with Base64.

Let’s verify this and see if we can take the password string and convert it from Base64 encoding.

To do this, we’ll just jump into CyberChef since it’s already built-in to REMnux (the online version works, too). Then, we’ll copy the string and apply the " # “From Base64"operator to the recipe:

Voila! We confirmed that the password string was Base64 encoded, and we can move forward with the investigation.

Question 3: File -> Github.txt: What cryptocurrency mining tool did the insider use?

This time, we will return to the user’s GitHub repositories to see if they have any cryptocurrency mining repositories forked. We’ll take the path of least resistance and use our browser’s find function and search " # “miner"to locate the answer.

Question 4: What university did the insider go to?

Okay, let’s pivot and move over to utilizing a search engine to find out more information about the insider. We’ll do a quick Google search for the username that we found on GitHub — EMarseille99.

Since we’re looking for professional information, let’s focus on checking LinkedIn first.

The profile picture and job title are a match, so we can be confident that we have discovered the the right profile. More importantly for the scope of this challenge, the user has their university listed!

Question 5: What gaming website the insider had an account on?

From the Google search in the previous question, I didn’t see any clear information that pointed us to a gaming website. So let’s try to expand our search scope a bit by utilizing one of the tools suggested in the challenge scenario — Sherlock.

According to the project’s GitHub page, Sherlock is a tool used to:

Hunt down social media accounts by username across social networks

After following the installation instructions, we’ll enter the username and see what open-source intelligence the tool can locate about the target:

python3 sherlock EMarseille99

The Sherlock results

Okay, let’s review the output from Sherlock. We see a couple of gaming-related websites here but none of the listed sites match what the challenge is looking for…

Side Note: For the walkthrough, we’re going to skip ahead to Question 6 for now. The process to find the answer for Question 5 is there, too.

Question 6: What is the link to the insider Instagram profile?

Since Sherlock didn’t turn up anything interesting for Instagram either, let’s double check the project’s documentation on GitHub to check if we misconfigured the scan. It turns out that there is a list of sites that have been removed from Sherlock’s scope due to false positives or errors and Instagram is one of them.

Image Credit: https://github.com/sherlock-project/sherlock/blob/master/removed_sites.md

That’s unfortunate, but no problem as we can pivot back to Google and focus our search on Instagram.

We’ll get several results, but the top result is a link to the user’s profile. If we copy the link, we will have the insider’s Instagram profile URL!

Now, let’s revisit Question 5 to discover what gaming website the user has a profile on. Let’s review our previous Google search where one of the results catches our eye and might help us to answer Question 5:

Once we click into the post, we can see that the user is inviting people to play games with them using a QR code link_._

If you follow the URL in the QR code, we are taken to the user’s gaming profile, and we now have the answer to Question 5!

Question 7: Where did the insider go on the holiday? (Country only)

Let’s continue browsing the user’s Instagram posts to see if we can find any clues. Eventually, we stumble on this post — notice the comment with the photo which mentions holiday?

Let’s take this photo and see if we can leverage Google reverse image search on https://images.google.com to determine the location the photograph was taken?

Once we drop the photo into Google, we can quickly determine what country this location is in — very cool!

Question 8: Where is the insider family live? (City only)

Sticking with Instagram, we’ll continue reviewing the posts. We’ll find one post that mentions family.

If we try the Google image search like we did for the last question however, we’ll find that the results are inconclusive. We probably need to keep looking, don’t we?

Did you notice that the post mentioned it was Photo 1/2? What if we check out the second photo? This one looks a little more distinctive. Let’s try the Google search again.

Ã‰milie Marseille on Instagram: “photo 2/2” _4 likes, 2 comments - emarseille99 on May 23, 2020: “photo 2/2”._www.instagram.com

This time the results are much more specific! Let’s confirm our findings:

Question 9: File -> office.jpg: You have been provided with a picture of the building in which the company has an office. Which city is the company located in?

Okay, we’re closing in on the end of the investigation. This time we’re going to return to the evidence files that we downloaded for the challenge and focus on the image office.jpg.

Once we open the image, we can focus on the street sign which notes some nearby landmarks.

We can search any of these landmarks on Google to discover which city this image was taken in. For example, I chose the landmarks on the left-hand sign:

Question 10: File -> Webcam.png: With the intel, you have provided, our ground surveillance unit is now overlooking the person of interest suspected address. They saw them leaving their apartment and followed them to the airport. Their plane took off and has landed in another country. Our intelligence team spotted the target with this IP camera. Which state is this camera in?

All right, we made it to the last question! Let’s determine where the target landed.

We’ll upload the evidence file, WebCam.png into the Google image search one more time.

Right away, we’ll get several results with the name of the landmark — we simply need to Google that landmark to determine what state it is in!

Conclusion:

Excellent job with the investigation! We made it through the L’espion Blue Team Lab and collected valuable intelligence on the target.

To wrap this up, thank you to CyberDefenders for the entertaining lab and the opportunity to engage with of the world of OSINT. The research process using Google and Sherlock was really interesting and got me thinking creatively while exploring just how much exposure a user might have online.

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:

SANS: https://www.sans.org/blog/what-is-open-source-intelligence/

REMnux: https://docs.remnux.org/install-distro/get-virtual-appliance

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

Sherlock: https://github.com/sherlock-project/sherlock

Google: https://images.google.com/

CyberDefenders — MalDoc101 Blue Team Lab Walkthrough

Sun, 17 Mar 2024 00:00:00 +0000

CyberDefenders.org — MalDoc101 Blue Team Lab Walkthrough

Analyzing a Malicious Document with REMnux, OLEDUMP, and OLEVBA.

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

Introduction:

Hello — Thanks for joining me for this walkthrough! This week I am going to tackle the medium difficulty MalDoc101 blue team challenge over on CyberDefenders. This challenge should be a great opportunity to expand my static analysis skills for malicious documents and learn some cool new tools for my workflow! A recommended tool for this challenge is REMnux — If you are unfamiliar, REMnux is a Linux distro built for malware analysis so we can leverage the available built-in tools to help us with the analysis.

As always, this write up will serve as a learning notebook for me and a CyberDefenders challenge walkthrough for anyone else who stumbles upon this post. In the spirit of learning, I’m not going to reveal the answers to the challenges so I encourage you to follow along or use this walkthrough as a reference if you get stuck.

Thanks for reading along, hope it helps!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/maldoc101/

Challenge Scenario:

It is common for threat actors to utilize living off the land (LOTL) techniques, such as the execution of PowerShell to further their attacks and transition from macro code. This challenge is intended to show how you can often times perform quick analysis to extract important IOCs. The focus of this exercise is on static techniques for analysis.

As a security blue team analyst, analyze the artifacts and answer the questions.

Suggested Tools:

REMnux Virtual Machine (remnux.org)

Terminal/Command prompt w/ Python installed

Oledump

Text editor

Setup the REMnux Analysis Environment & Extract the challenge file:

Image credit: CyberDefenders.org

First thing’s first — It’s always a good idea to heed the warning when downloading the lab/challenge files from CyberDefenders (or any lab/challenge/range) and keep yourself safe by performing these tasks in a dedicated, isolated virtual machine like REMnux — Safety first!

Second, I want to make a note that I’ll be referencing the excellent REMnux Documentation regularly in this post. This is a great resource to discover the tools available within the environment.

https://docs.remnux.org/

Third, to keep this write-up focused I’m going to skip a step-by-step setup guide of REMnux. Instead, if you want to setup your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:

https://docs.remnux.org/install-distro/get-virtual-appliance

Okay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!

Question 1: Multiple streams contain macros in this document. Provide the number of highest one.

We’ll start by checking out the REMnux documentation and see what Microsoft Office specific analysis tools are available.

https://docs.remnux.org/discover-the-tools/analyze+documents/pdf

There are quite a few tools we can use but before we dive in, let’s pull back a little. I want to point to an awesome quick reference poster that can help provide us some context, the SANS Analyzing Malicious Documents cheat sheet. This incredibly helpful cheat sheet provides us with some quick, actionable tips for analyzing malicious documents. Since I’m a novice with this type of malware analysis any reference or starting point will help to keep me from stumbling too much!

Let’s focus first on a suggested tool from the challenge scenario and also referenced in the SANS cheat sheet — oledump.

According to the SANS sheet:

Binary Microsoft Office document files (.doc, .xls, etc.) use the OLE2 (a.k.a. Structured Storage) format.

I have to give myself a little refresher on the structure of OLE documents for this so we’ll turn to the GitHub page of Philippe Lagadec (decalage2), whose oletools we will use later for this challenge:

[An OLE file can be seen as a mini file system or a Zip archive: It contains streams of data that look like files embedded within the OLE file. Each stream has a name. For example, the main stream of a MS Word document containing its text is named " # "

WordDocument" .](https://github.com/decalage2/olefile/blob/master/doc/OLE_Overview.rst)

An OLE file can also contain storages. A storage is a folder that contains streams or other storages. For example, a MS Word document with VBA macros has a storage called " # "

Macros" .

Okay — now that we’ve gotten a refresher, we’ll head back to the REMnux documentation which has a link over to Didier Stevens website, the author of oledump.

We can take a look at the documentation for oledump before we move forward but fortunately for us, we have an option within the tool to utilize the built-in manual — let’s use it to get an idea of the syntax. Remember, for Question 1 we simply need to figure out how to show the streams that contain macros within the suspicious document.

Let’s just try to process the challenge file with the tool and see what we get:

oledump.py

According to the oledump site_,_ The M **" # "

**indicates that the stream contains VBA macros." Very interesting, our sample contains three! For Question 1 we are looking for the highest stream number. Let’s find it and check our work.

Question 2: What event is used to begin the execution of the macros?

Okay, now it’s time to get serious and do some static analysis. We’re going to check out another tool that I mentioned earlier — olevba as part of the oletools suite by Philippe Lagadec.

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

We’ll use olevba to parse the suspicious file and see if it pulls anything out that could help us answer Question 2.

Let’s run through the command and scroll through the output.

olevba

Conveniently highlighted in yellow, there is an event that sticks out and appears like it might trigger execution — Let’s see if there is any more information in the summary to confirm…

olevba output

The summary in olevba

Okay, very interesting! The event we found earlier is an AutoExec type that runs when the document is opened. That seems kind of suspicious and I think we have found the answer to Question 2!

Question 3: What malware family was this maldoc attempting to drop?

Now let’s see what intelligence we can gather on the file. To keep this simple, let’s just calculate the file hash of the malicious binary — we can do this right from the terminal. For this example, we’ll calculate the SHA-256 hash.

sha256sum sample.bin

Let’s check first if Virus Total has any hits by submitting the hash of the file, maybe?

There we go! We’ve got a lot of detection on this file. Let’s take a look at the threat and family labels — this will provide us with the answer we’re looking for.

Question 4: What stream is responsible for the storage of the base64-encoded string?

If you haven’t cleared your terminal, let’s scroll back to the output of olevba from Question 2. Remember as we were scrolling down through the out put there was a large block of obfuscated strings?

Yeah, that one! Let’s take a closer look but this seems likely to be the stream that is storing the Base64 encoded string we need for Question 4.

We need to find the stream number though, right? Remember back in Question 1 where we used oledump? Let’s scroll back to that output (or run it again) and see if we can do some matching.

Now if we look through the list, we see the the stream number corresponds to the OLE stream name we found with olevba — let’s confirm that we have the right one and submit the answer!

Question 5: This document contains a user-form. Provide the name?

For Question 5, we are looking for a userform contained in the document — these are used to created custom dialog boxes. _S_ometimes, these are seen in malicious documents where the user will open the document and see a dialog box/prompt/button like " # "

Sign In to view this document." When the button is pressed the victim may be redirected to a phishing URL or something else malicious.

To tackle this one, we could potentially open the file in a Microsoft Office app to confirm the use and details of the userform but I think we can continue using our command-line tools for the purposes of this write-up.

Let’s scroll back through the output of olevba again we see references to VBA FORM STRING over and over with the same container name as we found in Question 4.

That could be something, but how can we confirm the form name? Let’s take to Google and see if we can find anything about VBA Macro Forms. Eventually, I stumbled across a Microsoft Answers article, Introduction to the Office Macro Editor, Part 2, where it states:

The code of a userform is saved as a *.frm file

Maybe we can olevba again and grep the output for " # "

.frm" ? Let’s try it it out.

olevba sample.bin | grep -i “.frm”

Awesome! It looks like we found the .frm file which confirms the name we found earlier. Let’s submit it and move on!

Question 6: This document contains an obfuscated base64 encoded string; what value is used to pad (or obfuscate) this string?

Fortunately, we found this Base64 encoded string back in Question 4 so we know the stream it is contained in. Let’s jump back to oledump and do a strings dump (-S) and output this to a file just to get a cleaner view.

oledump.py -s -S sample.bin > output.txt

Once open the text file and we see pretty quickly that a pattern emerges and we see a sequence of characters repeat continuously:

*2342772g3&gsfq

Text output of the strings dump

I am pretty confident this is the padding value we are looking for. Let’s confirm our suspicion and get to decoding!

Question 7: What is the program executed by the base64 encoded string?

Alright, let’s try to deobfuscate the string and break down the command. Let’s jump into CyberChef — I’m going to use the installed version in REMnux but the online version will work as well. We’ll copy the command from the output file we made from oledump and get to work!

I’m going to try a simple find/replace operation to find the padding value that we located in the previous question and replace it with blank. Hopefully there is something left after it is stripped away that we can analyze…

Woah! Now that we have removed the padding we seem to have found the answer to Question 7! But, there is still some work to do to finish decoding the command this program will execute…

Question 8: What WMI class is used to create the process to launch the trojan?

Let’s stick with CyberChef for this question and to try to decode that command. Since we know from the challenge that we are working with a Base64 encoded string, let’s start there.

We’ll copy the encoded command (not the program name from the previous question) into a new tab and apply the From Base64 operation into our recipe as a starting point:

Once we do that, it seems that we are getting closer and the script is starting to become readable but I think we can do better getting this cleaned up. Let’s add some flavor to the recipe and add remove null bytes, find/replace the ` , and to Lower case…

Voila! Our recipe:

Now that we can clearly read this payload, we can really start to analyze it! For Question 8 we are searching for a " # “WMI class is used to create the process to launch the trojan.“Look closely toward the end of the code, we see reference to a Windows Management Instrumentation (WMI) class. I believe this is answer we are looking for as this particular class can be invoked to start a new process, script, or executable.

Question 9: Multiple domains were contacted to download a trojan. Provide first FQDN as per the provided hint.

Since we are already looking through our decoded command from the previous question, you probably already noticed quite a few Fully Qualified Domain Names (FQDN) in the output? This is what we are looking for!

For Question 9, we just need to browse through the code and submit the first FQDN listed. Once we have found it — let’s submit the answer and wrap up this challenge!

Conclusion:

We made it! Great job!

Thank you to CyberDefenders.org for hosting another awesome challenge and providing an excellent opportunity to spend time to understand the OLE document structure and how a threat actor might arm an Office file. This was a really fun challenge to tackle with so much practical application to demonstrate how we as defenders can perform quick static analysis on a malicious document file with the help of some awesome tools like oledump & olevba.

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:

REMnux Office Document Analysis Documentation: https://docs.remnux.org/discover-the-tools/analyze+documents/microsoft+office

SANS Cheat Sheet for Analyzing Malicious Documents: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/

Philippe Lagadec (decalage2) GitHub: https://github.com/decalage2

Oledump: https://blog.didierstevens.com/programs/oledump-py/

Oletools: https://www.decalage.info/python/oletools

Introduction to the Office Macro Editor, Part 2 — Microsoft Community

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

CyberDefenders — KrakenKeylogger Blue Team Lab Walkthrough

Mon, 05 Feb 2024 00:00:00 +0000

CyberDefenders.org — KrakenKeylogger Blue Team Lab Walkthrough

Endpoint Investigation with DB Browser & Eric Zimmerman’s tools

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

Introduction:

Hello! I’ve recently stumbled on the practice labs over on cyberdefenders.org. This challenge room was one of the first that I tried on the site and while stumbling through the questions, I thought it would be a great opportunity to do a write-up to solidify the concepts for me and share this cool challenge with anyone who stumbles across this post. Thanks for reading!

Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/119/

Challenge Scenario:

An employee at a large company was assigned a task with a two-day deadline. Realizing that he could not complete the task in that timeframe, he sought help from someone else. After one day, he received a notification from that person who informed him that he had managed to finish the assignment and sent it to the employee as a test. However, the person also sent a message to the employee stating that if he wanted the completed assignment, he would have to pay $160.

The helper’s demand for payment revealed that he was actually a threat actor. The company’s digital forensics team was called in to investigate and identify the attacker, determine the extent of the attack, and assess potential data breaches. The team must analyze the employee’s computer and communication logs to prevent similar attacks in the future.

Question 1: What is the the web messaging app the employee used to talk to the attacker?

AND

Question 2: What is the password for the protected ZIP file sent by the attacker to the employee?

This question mentions a web-based messaging app and the scenario lists a handful of tools to solve the challenge including DB Browser for SQLite. Normally, you can view the browser history database with this tool, so I turned my attention to examining the browser databases to see what I could find.

Unfortunately, these artifacts are missing from the challenge files for Google Chrome so we have to pivot, but there is one clue in the scenario description — notification. This got me thinking about the Windows notification center toasts.

I did a quick search for Notifications in Windows and was surprised to actually stumble on some results in the directory: \Users\OMEN\AppData\Local\Microsoft\Windows otifications

Inside of this directory is a database file, wpndatabase.db, which after a little Google magic I figured out is a database for Windows Push Notifications that stores Windows notification data. I loaded up this database file with the DB Browser to see if I could find anything interesting…

Interesting, indeed! Within the notification table, it looked like I may have found the answer for Question 1 and Question 2 here. Two for the price of one!

Question 3: What domain did the attacker use to download the second stage of the malware?

The discovery in the previous questions gave me a pretty good starting point. I needed to locate the file the attacker sent to the victim and analyze it for anything suspicious. When conducting an investigation, even for lab scenarios, I typically make it a habit to do a quick manual browsing of the folder structure (AppData, Downloads, etc.) to familiarize myself with the environment. After seeing the filename for the ZIP file in the wpndatabase, I recalled seeing a similar file artifact in my earlier reconnaissance.

I took a look at the contents within the victim’s Downloads folder and noticed something suspicious — a shortcut or lnk file, called templet.

I referred to another of the scenario’s suggested tools, LECmd. This utility can be used to parse lnk files for further analysis.

Within the argument, there appeared to be an obfuscated URL and I spent way too much time in CyberChef before I could finally deobfuscate it to solve Question 3.

If you spend some time researching this malware on Google, however, there is an excellent analysis write-up that could help in scripting this process very quickly…

Question 4: What is the name of the command that the attacker injected using one of the installed LOLAPPS on the machine to achieve persistence?

AND

Question 5: What is the complete path of the malicious file that the attacker used to achieve persistence?

LOLAPPS? I was familiar with LOLBins but this was new to me. I took to Google to understand if this was the same thing or something else. Fortunately, I stumbled across a website explaining LOLAPPS, including some examples of how to leverage a few of these apps for persistence.

With that information, I remembered seeing evidence of one of these applications, Greenshot, on the victim’s system during my earlier browsing of the challenge files.

Using the linked resources available for Greenshot on the LOLAPPS project site, I was able to find evidence of persistence from abuse of the External Command Plugin within the application’s configuration file. This was very interesting because I noticed a familiar filename referenced in the command being used for persistence and used this path to answer Question 5, too!

Question 6: What is the name of the application the attacker utilized for data exfiltration?

During my earlier analysis, there was another application that stuck out to me. A common post-compromise technique for the bad guys to leverage is installing legitimate remote access software for use as an alternative command and control or exfiltration channel (MITRE ATT&CK T1219).

Knowing this, I suspected that I already had the answer from checking out the AppData of the challenge files and from browsing the Microsoft Edge browser history database.

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

Now that I knew what application was used for exfiltration, I suspected that I needed to locate the application logs to help reveal the attacker’s IP address. Based on my previous experience with a different remote access software, I felt pretty confident that a quick search of the vendor’s site would tell me where to look.

Sure enough, this application maintains a trace file that can be located in %appdata%\REDACTED\ad.trace

For this last question, I utilized the last of the scenario suggested tools, Timeline Explorer. I had not used this tool before and found that it really helped speed up the log analysis. I tried a couple of searches within the trace file looking for external access. The right one was " # "

logged in" which gave me the final answer for this lab!

Conclusion:

Thank you to cyberdefenders.org for the challenge! This was a really fun lab scenario that provided a unique set of challenges during the investigation. This challenge also provided a great introduction to some of Eric Zimmerman’s tools that I had not used before and allowed me to better understand and analyze the Windows Push Notification database, LOLAPPS, and application logs.

CyberDefenders on Drew Arpino (Stumblesec)

CyberDefenders — BRabbit Lab Walkthrough

CyberDefenders: BRabbit Lab Walkthrough

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

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: The phishing email used to deliver the malicious attachment showed several indicators of a potential social engineering attempt. Recognizing these indicators can help identify similar threats in the future.

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

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

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

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

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

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

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

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

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

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

Conclusion:

Tools & References:

CyberDefenders — RedLine Lab Walkthrough

CyberDefenders: RedLine Lab Walkthrough

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

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

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

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

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

Question 7: What is the full path of the malicious executable?

Conclusion:

Tools & References:

CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough

CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough

A Threat Intelligence Challenge Using VirusTotal and Securelist.

Introduction:

Challenge Scenario:

Question 1: In KB, what is the size of the malicious file?

Question 2: What word do the threat actors use in log messages to describe their victims, based on the name of an ancient hunted creature?

Question 3: The threat actor set up a malicious website to mimic a platform designed for creating and managing decentralized autonomous organizations (DAOs) on the MultiversX blockchain (peerme.io). What is the name of the malicious website the attacker created to simulate this platform?

Question 4: Which cloud storage service did the campaign operators use to host malware samples for both macOS and Windows OS versions?

Question 5: The malicious executable contains a configuration file that includes base64-encoded URLs and a password used for archived data decompression, enabling the download of second-stage payloads. What is the password for decompression found in this configuration file?

Question 6: What is the name of the function responsible for retrieving the field archive from the configuration file?

Question 7: In the third sub-campaign carried out by the operators, the attacker mimicked an AI translator project. What is the name of the legitimate translator, and what is the name of the malicious translator created by the attackers?

Question 8: The downloader is tasked with delivering additional malware samples to the victim’s machine, primarily infostealers like StealC and Danabot. What are the IP addresses of the StealC C2 servers used in the campaign?

Question 9: What is the address of the Ethereum cryptocurrency wallet used in this campaign?

Conclusion:

Tools & References:

CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough

CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough

A Windows DFIR Challenge Using Arsenal Image Mounter, FTK Imager, Detect It Easy, ProcMon, CyberChef, and Eric Zimmerman’s Tools

Introduction:

Challenge Scenario:

Important: Setup a Safe Analysis Environment & Extract the Challenge File:

Question 1: In your investigation into the FinTrust Bank breach, you found an application that was the entry point for the attack. Which application was used to download the malicious file?

Question 2: Finding out when the attack started is critical. What is the UTC timestamp for when the suspicious file was first downloaded?

Question 3: Knowing which vulnerability was exploited is key to improving security. What is the CVE identifier of the vulnerability used in this attack?

Question 4: In examining the downloaded archive, you noticed a file in with an odd extension indicating it might be malicious. What is the name of this file?

Question 5: Uncovering the methods of payload delivery helps in understanding the attack vectors used. What is the URL used by the attacker to download the second stage of the malware?

Question 6: To further understand how attackers cover their tracks, identify the script they used to tamper with the event logs. What is the script name?

Question 7: Knowing when unauthorized actions happened helps in understanding the attack. What is the UTC timestamp for when the script that tampered with event logs was run?

Question 8: We need to identify if the attacker maintained access to the machine. What is the command used by the attacker for persistence?

Question 9: To understand the attacker’s data exfiltration strategy, we need to locate where they stored their harvested data. What is the full path of the file storing the data collected by one of the attacker’s tools in preparation for data exfiltration?

Conclusion:

Tools & References:

CyberDefenders — Insider Lab Walkthrough

CyberDefenders — Insider Lab Walkthrough

A Linux DFIR Challenge Using FTK Imager and Built-In Logs.

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: Which Linux distribution is being used on this machine?

Question 2: What is the MD5 hash of the Apache access.log file?

Question 3: It is suspected that a credential dumping tool was downloaded. What is the name of the downloaded file?

Question 4: A super-secret file was created. What is the absolute path to this file?

Question 5: What program used the file didyouthinkwedmakeiteasy.jpg during its execution?

Question 6: What is the third goal from the checklist Karen created?

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