HackTheBox on Drew Arpino (Stumblesec)

HackTheBox — Campfire-2 Sherlock Walkthrough

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

HackTheBox: Campfire-2 Sherlock Walkthrough

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

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

Introduction:

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

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

HackTheBox: Campfire-1 Sherlock Walkthrough

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

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

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

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

Challenge Scenario:

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

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

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

AS-REP Primer:

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

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

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

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

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

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

MITRE describes it like this:

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

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

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

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

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

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

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

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

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

To do that:

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

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

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

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

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

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

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

Questions 2, 3, 4:

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

What was the SID of the account?

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

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

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

Event Log Explorer: Analyzing the event details

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

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

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

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

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

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

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

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

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

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

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

Event Log Explorer: Analyzing the event details

At this point, we’ve linked together:

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

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

Conclusion:

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

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

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

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

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

Remember, cybersecurity is a team sport, and we’re in this together.

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/Campfire-2?tab=play_sherlock

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

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

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

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

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

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

HackTheBox — Campfire-1 Sherlock Walkthrough

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

HackTheBox: Campfire-1 Sherlock Walkthrough

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

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

Introduction:

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

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

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

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

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

Challenge Scenario:

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

You are provided with:

1- Security Logs from the Domain Controller

2- PowerShell-Operational Logs from the affected workstation

3- Prefetch Files from the affected workstation

Setup the Analysis Environment & Extract the Challenge File:

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

Kerberoasting Primer:

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

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

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

MITRE ATT&CK describes the technique like this:

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

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

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

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

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

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

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

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

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

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

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

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

To do that:

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

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

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

Event Log Explorer: Pinpointing the matching event

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

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

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

Questions 2 & 3:

What is the Service Name that was targeted?

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

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

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

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

That gives us our answer for Question 2.

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

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

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

Questions 4 & 5:

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

When was this script executed? (UTC)

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

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

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

Event Log Explorer: Finding evidence of PowerView execution

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

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

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

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

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

Event Log Explorer: Grabbing the timestamp of PowerView execution

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

Questions 6 & 7:

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

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

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

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

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

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

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

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

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

The contents of the prefetch folder

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

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

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

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

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

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

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

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

Rubeus _Edit description_attack.mitre.org

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

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

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

Conclusion:

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

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

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

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

Remember, cybersecurity is a team sport, and we’re in this together.

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/Campfire-1?tab=play_sherlock

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

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

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

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

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

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

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

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

HackTheBox — LogJammer Sherlock Walkthrough

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

HackTheBox — LogJammer Sherlock Walkthrough

Windows Event Log Forensics: Investigating Persistence, Malware, and Log Tampering with Event Log Explorer & FLARE‑VM.

Image Credit: https://app.hackthebox.com/sherlocks/LogJammer

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the LogJammer Sherlock challenge from Hack The Box, you’re in the right place.

This is the seventh challenge in the Intro to Blue Team track, but you can jump in at any point. If you’re following along or you’re a completionist, check out my write-up of the previous free challenge — Meerkat:

HackTheBox | Meerkat | Sherlock Walkthrough

Challenge Scenario:

You have been presented with the opportunity to work as a junior DFIR consultant for a big consultancy. However, they have provided a technical assessment for you to complete. The consultancy Forela-Security would like to gauge your Windows Event Log Analysis knowledge. We believe the Cyberjunkie user logged in to his computer and may have taken malicious actions. Please analyze the given event logs and report back.

This challenge is all about Windows Event Log Analysis and leans heavily on choosing the correct log, filtering for specific event IDs, and weaving together activity across multiple logs. It’s up to us to meet the moment and show off our event log analysis skills. Don’t worry if you’re new to this topic — I’ll link plenty of helpful resources that you can use in your own investigations.

But having great references is only half the battle. We also need solid tools. For this walkthrough, we’ll rely primarily on Event Log Explorer, a tool that makes filtering, pivoting, and correlating events far faster than using the built‑in Windows Event Viewer. It’s a huge timesaver when you’re staring down thousands of log entries.

So, whether you’re new to Windows endpoint forensics or you just want to sharpen your analysis skills, this is a fantastic challenge to tackle. Let’s go!

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

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

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

Question 1: When did the cyberjunkie user first successfully log into his computer? (UTC)

Now that we’ve gotten our analysis environment all set up, let’s kick off this investigation by extracting the challenge file and taking a look at the available artifacts.

Overview of the challenge artifacts

We have five Event Logs available in this challenge, each providing different insights:

Powershell‑Operational.evtx: This event log contains “details about PowerShell operations, such as starting and stopping the engine and providers, and executing PowerShell commands.”
Security.evtx: This event log contains “logs related to logins, privileges, and other similar events.”
System.evtx: This event log contains “logs created by the operating system.”
Windows Defender‑Operational.evtx: This event log contains logs related to Microsoft Defender Antivirus operational and malware‑related events.
Windows Firewall‑Firewall.evtx: This event log contains events related to the Windows Firewall with Advanced Security, including rule additions, modifications, and deletions.

Now that we understand what we’re working with, we can identify the correct log to answer Question 1. Since we’re searching for a sign‑in event, we’ll work directly in the Security log and filter for Event ID 4624 (“An account was successfully logged on”).

You can absolutely use the built‑in Windows Event Viewer, but there’s a more efficient option: Event Log Explorer. Because Event Log Explorer is already installed in the Flare‑VM analysis environment, that’s what I’ll be using in this walkthrough. I encourage you to try it if you aren’t familiar with it — the filtering features save a surprising amount of time.

Steps in Event Log Explorer

Open Event Log Explorer and load Security.evtx.
Click the Filter button and enter 4624 into the Event ID field.
To narrow this down further, use Description params → select “New Logon\Account Name” → operator: contains → value: cyberjunkie.
This returns only the successful logons for this user. Sort by time and double‑click the earliest entry.

Event Log Explorer: Filtering for 4624 events

With the targeted filter in place, we can stumble straight into the events we need without digging through thousands of unrelated entries. Since we’re searching for the first successful login, open the earliest one. From here, there’s one more thing we need: the UTC timestamp.

Double-click to open the event.
Select the XML tab.
Expand the System node.
Look for the TimeCreated > SystemTime attribute.

The SystemTime value is always stored in UTC and is the timestamp you’ll need for the answer.

Event Log Explorer: Identifying the logon time in UTC

Now that we’ve successfully identified the cyberjunkie’s first successful logon, we can move on to the next question.

Questions 2 & 3:

The user tampered with firewall settings on the system. Analyze the firewall event logs to find out the Name of the firewall rule added?

Whats the direction of the firewall rule?

Next up, we need to figure out what firewall rule cyberjunkie tampered with. For this step, open the Windows Firewall‑Firewall.evtx artifact in Event Log Explorer. Just like before, there’s plenty of noise in this log, but we can cut through it by focusing on events that occurred after the first cyberjunkie sign‑in on 3/27/2023 at 10:37:09 AM.

Filtering by time quickly helps us identify the events we care about. Near the top of the log, we’ll find an Event ID 2004, which indicates that a rule has been added to the Windows Defender Firewall exception rules.

Event Log Explorer: Finding a suspicious firewall exception rule

Opening this event gives us everything we need. The rule name includes the name of a well‑known penetration testing tool: Metasploit. Since this is a challenge scenario, that kind of red-flag naming is intentional and makes the rule easy to spot.

Inside the same event, you’ll also find the Direction attribute, which has a value of 2. In Windows Firewall terminology, that value represents an outbound rule. Finally, we can correlate the ModifyingUser SID to confirm that cyberjunkie is indeed the account responsible for adding it.

Now that we’ve extracted both the rule name and its direction, we’re ready to move on to the next part of the investigation.

Question 4: The user changed audit policy of the computer. Whats the Subcategory of this changed policy?

Our next task is to identify a change to the computer’s audit policy and determine the subcategory that was modified. This is an event I’m not familiar with off‑hand, so this is a good time to pivot and do a little research.

One of my favorite quick‑reference resources for security event IDs is the Ultimate Windows Security Windows Security Log Events Encyclopedia. A simple search for “audit policy” points us toward Event ID 4719, which corresponds to “System audit policy was changed.”

Windows Security Log Event ID 4719 - System audit policy was changed _4719: System audit policy was changed On this page This computer’s system level audit policy was modified - either via…_www.ultimatewindowssecurity.com

Now that we’ve identified the correct event, we can return to Security.evtx in Event Log Explorer and apply a filter for Event ID 4719. This gives us a single event, which makes our job nice and straightforward. We just need to grab the Subcategory value from the event details to answer the question.

Once we extract that field, we’ll have everything we need for Question 4.

Event Log Explorer: Identifying the subcategory in Event ID 4719

Questions 5, 6, & 7:

The user “cyberjunkie” created a scheduled task. Whats the name of this task?

Whats the full path of the file which was scheduled for the task?

What are the arguments of the command?

Moving right along, Questions 5, 6, and 7 focus on identifying a scheduled task created by cyberjunkie. This is important because scheduled tasks are a classic persistence technique. An attacker can schedule recurring execution of scripts or binaries to maintain access long after their initial intrusion. This technique maps directly to MITRE ATT&CK Scheduled Task/Job: Scheduled Task (T1053.005).

To investigate this, we’ll turn again to the Ultimate Windows Security Windows Security Log Events Encyclopedia. A quick lookup shows that scheduled task creation is logged as Event ID 4698, which corresponds to “A scheduled task was created.”

Windows Security Log Event ID 4698 - A scheduled task was created _4698: A scheduled task was created On this page The user indicated in Subject: just created a new scheduled task (Start…_www.ultimatewindowssecurity.com

With that information in hand, we return to Security.evtx in Event Log Explorer and adjust our filter to Event ID 4698. Just like in the previous questions, this gives us a single event to review, making the analysis easy.

Event Log Explorer: Analyzing the scheduled task

Reviewing the event description reveals everything we need to answer all three questions:

The name of the scheduled task
The full path to the PowerShell script (Automation-HTB.ps1)
The command‑line arguments used when the task was created

Once we extract those details, we’ve successfully solved Questions 5, 6, and 7 — and we’re ready to stumble into the next part of the investigation.

Questions 8, 9, & 10:

The antivirus running on the system identified a threat and performed actions on it. Which tool was identified as malware by antivirus?

Whats the full path of the malware which raised the alert?

What action was taken by the antivirus?

Questions 8, 9, and 10 all focus on malware detection activity on the compromised device. To answer them, we’ll work with the Windows Defender‑Operational.evtx artifact, which contains logs related to Microsoft Defender Antivirus operational and malware‑related events.

Load this artifact into Event Log Explorer. For this investigation, we’ll filter for Event IDs 1116 and 1117. According to Microsoft Learn, these correspond to:

1116 — MALWAREPROTECTION_STATE_MALWARE_DETECTED
1117 — MALWAREPROTECTION_STATE_MALWARE_ACTION_TAKEN

Even though this log contains a lot of noise, we can narrow things down again by focusing only on events that occurred after the first cyberjunkie login. Doing this drops us down to only four events: two detections (1116) and two actions (1117).

Event Log Explorer: Defender events after the threat actor sign-in

Looking at the 1116 events, we see that Microsoft Defender detected two components of SharpHound (SharpHound.ps1 and SharpHound.exe). SharpHound is the ingestor module for BloodHound, a well‑known Active Directory reconnaissance tool frequently used by red teams and attackers. Both files were bundled together in a single .zip archive, and the detection explicitly references that tool — which answers Question 8.

Event Log Explorer: Identifying SharpHound activity through the Windows Defender Logs

To answer Questions 9 and 10, we can check either of the 1117 events. These entries provide:

The full path where the malware files were located
The action taken by the antivirus engine

With this information, we can fully resolve all three questions!

Question 11: The user used Powershell to execute commands. What command was executed by the user?

We’re nearing the end of this investigation, but we still have a few artifacts left to analyze. This time, we’ll pivot to the Powershell‑Operational.evtx log. As before, load the log into Event Log Explorer so we can filter the entries and focus only on events from the date of the attack.

In the filter options, select the date checkbox and set both the From and To values to 3/27/2023.

Event Log Explorer: Filtering the PowerShell log for the date of the attack

Because this device has PowerShell script block logging enabled, we can home in on Event ID 4104 to collect insights into what commands were executed. Event ID 4104 records script block content, which often includes some handy forensic data like the full command line used in a PowerShell session. Check it out:

Event Log Explorer: Identifying the Script Block Contents

The second event gives us the full command. In this case, cyberjunkie executed a PowerShell command to determine the MD5 hash of the Automation-HTB.ps1 script we identified back in Question 6. It’s not the most exciting example of an attacker command, but it’s still a great demonstration of how much forensic insight script block logging can provide.

Question 12: We suspect the user deleted some event logs. Which Event log file was cleared?

And finally, we’ve made it to the end of our investigation. To answer Question 12, we’re looking for signs that the attacker attempted to cover their tracks by deleting event logs. Tampering with logs is a classic indicator removal technique and maps directly to MITRE ATT&CK — Clear Windows Event Logs (T1070.001).

There are two locations we need to check. The first is the Security.evtx log. Here, we can filter for Event ID 1102, which corresponds to “The audit log was cleared.”

Windows Security Log Event ID 1102 - The audit log was cleared _1102: The audit log was cleared On this page Event 1102 is logged whenever the Security log is cleared, REGARDLESS of…_www.ultimatewindowssecurity.com

Event Log Explorer: Event ID 1102

While this confirms that the Security log was indeed cleared, this isn’t the answer we’re looking for. The question asks which Event Log file was cleared, and 1102 only tells us the Security log was wiped, but the challenge data suggests additional tampering.

That brings us to the artifact we haven’t touched yet: the System.evtx log.

Load System.evtx into Event Log Explorer and filter for Event ID 104, which corresponds to “[Other log file cleared](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection#appendix-e--- annotated-baseline-subscription-event-query).” This event is generated when any log except the Security log is cleared.

Event Log Explorer: Identifying the cleared log file with Event ID 104

Bingo. The top event from the day of the attack shows exactly what we need. Event ID 104 reveals that the attacker cleared the Microsoft-Windows-Windows Firewall with Advanced Security/Firewall log.

With this final piece of the puzzle, we’ve wrapped up the investigation and uncovered an attempt by cyberjunkie to cover his tracks by wiping the event logs. Nice work!

Conclusion:

How fun was that! A big thank you to Hack The Box for another fantastic challenge.

This challenge was another awesome entry in the Intro to Blue Team track with a tight focus on Windows Event Log Analysis, correlating activity across multiple logs, filtering specific event IDs, and piecing together the cyberjunkie user’s actions step‑by‑step.

As we moved through the investigation, we followed the attacker’s trail across authentication events, firewall tampering, audit policy changes, scheduled task creation, malware detections, script block execution, and even attempts at covering their tracks through log clearing. Each question built naturally into the next, creating a clear and logical narrative that mirrors real‑world DFIR work. It was a great reminder of how much visibility Windows logs provide — if we know where to look.

I chose this week’s challenge to brush up on some Event IDs I don’t use every day, add a few new ones to my notebook (which I’ve added in the quick reference below), and sharpen my workflow using Event Log Explorer. It’s always a cool experience to piece together an attack using only a handful of logging artifacts. It just goes to show how powerful proper log analysis can be when it comes to uncovering malicious activity. Great stuff!

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!

Quick Reference: Event IDs we covered

4624 — Successful logon (Security.evtx). Use New Logon\Account Name in Event Log Explorer to pinpoint the user
2004 — Windows Defender Firewall rule added (Windows Firewall‑Firewall.evtx). Includes rule name, direction, and modifying user SID
4719 — System audit policy changed (Security.evtx). Look for Subcategory and related GUIDs
4698 — Scheduled task created (Security.evtx). Task XML reveals <Command> and <Arguments>
1116 — Malware detected (Windows Defender‑Operational.evtx). Threat name and often the container path
1117 — Malware action taken (Windows Defender‑Operational.evtx). Action such as Quarantined, Removed, or Blocked
4104 — PowerShell Script Block Logging (Powershell‑Operational.evtx). Captures script block contents and the full command line
1102 — Security log cleared (Security.evtx). Indicates the audit log was wiped
104 — Other Windows log cleared (System.evtx). Specifies the exact channel, e.g., Microsoft‑Windows‑Windows Firewall with Advanced Security/Firewall

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/LogJammer

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

Ultimate IT Security — Windows Security Log Events: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

Microsoft Learn — about_Logging_Windows: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.5

Microsoft Tech Community — Windows Events, how to collect them in Sentinel and which way is preferred to detect Incidents: https://techcommunity.microsoft.com/blog/fasttrackforazureblog/windows-events-how-to-collect-them-in-sentinel-and-which-way-is-preferred-to-det/3997342

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

Microsoft Learn — Configure Windows Firewall logging: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging?tabs=intune

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

MITRE ATT&CK — Scheduled Task/Job: Scheduled Task (T1053.005): Scheduled Task/Job: Scheduled Task, Sub-technique T1053.005 — Enterprise | MITRE ATT&CK®

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

MITRE ATT&CK — Indicator Removal: Clear Windows Event Logs (T1070.001): https://attack.mitre.org/techniques/T1070/001/

Microsoft Learn — Use Windows Event Forwarding to help with intrusion detection: https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection

HackTheBox — Meerkat Sherlock Walkthrough

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

HackTheBox | Meerkat | Sherlock Walkthrough

Network Packet Forensics: Investigating Credential Stuffing and Persistence with Zui, Wireshark & NetworkMiner.

Image Credit: https://app.hackthebox.com/sherlocks/552/play

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the Meerkat Sherlock challenge from Hack The Box, you’re in the right place.

This is the fifth challenge in the Intro to Blue Team track, but you can jump in at any point. If you’re following along or you’re a completionist, check out my write-up of the previous free challenge — Unit42:

HackTheBox | Unit42 | Sherlock Walkthrough

This challenge leans heavily into network forensics using a real-world inspired narrative. It’s up to us to piece together what happened using only the provided network packet capture (PCAP) file. To analyze this file, we’ll rely on three powerful tools:

Zui (formerly Brim)
Wireshark
NetworkMiner

Using a broad set of tools for different purposes is a great way to go hands-on with multiple utilities and compare their strengths and weaknesses as they apply to identifying artifacts.

So, if you’re new to network forensics or just want to sharpen your analysis skills, this is a fantastic challenge to dive into. Let’s get into it!

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

Thanks for reading and going on this investigation with me!

Challenge Scenario:

As a fast-growing startup, Forela has been utilising a business management platform. Unfortunately, our documentation is scarce, and our administrators aren’t the most security aware. As our new security provider we’d like you to have a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.

Setup the Analysis Environment & Extract the Challenge File:

“a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”

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

Question 1: We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?

First things first — let’s extract the challenge file using the provided password. Inside the archive, we’ll find two artifacts for analysis:

meerkaat.pcap: a network packet capture file containing raw network data.
meerkat-alerts.json: a JSON file with alert logs from an intrusion detection system.

We’ll start our investigation by leveraging Zui (formerly called Brim), which can display Suricata alerts already present in the challenge data.

For our purposes, this means that we don’t need to review the second artifact separately because the Suricata alert data is already embedded in the pcap and can be pulled out using Brimcap queries. This makes it much easier to focus on the relevant details we need, including the application running on the web server.

So, where to begin? The first step is to download, install, and open Zui if you don’t already have it in your analysis environment. Once that’s done, you might notice the Suricata queries aren’t readily available which was the case in my environment.

To grab the queries I used in this walkthrough, visit the Brimcap GitHub repository. While Brimcap is bundled into the Zui desktop app, I needed to follow the directions to install the Brimcap queries:

Included in this repo is a queries.json file with some helpful queries for getting started and exploring Zeek and Suricata analyzed data within the Zui app.

To import these queries:

Download the [queries.json](https://github.com/brimdata/brimcap/blob/main/queries.json?raw=1) file to your local system

In Zui, click the + menu in the upper-left corner of the app window and select Import Queries…

Open the downloaded file in the file picker utility

Zui: Importing Brimcap Queries

This gives us some extremely handy queries for analysis. If you haven’t already, load the meerkaat.pcap file into Zui so we can query the pool.

To answer Question 1, use the new Brimcap queries by selecting Suricata Alerts by Signature. This provides a high-level view of all IDS rule hits detected in the traffic. One particular web application exploit is detected with four different rule sets, which strongly suggests this is the compromised web application.

Zui: Identifying the web application through Suricata Alerts by Signature

Then, a quick Google search for Bonitasoft confirms it’s a business process automation application, consistent with the description in the scenario.

Question 2: We believe the attacker may have used a subset of the brute forcing attack category — what is the name of the attack carried out?

Next, we need to identify the brute force attack method used by the attacker. While reviewing the Suricata Alerts by Signature query in Zui, you may have noticed the alert ET INFO User-Agent (python-requests) Inbound to Webserver had a large number of hits. This likely correlates to the brute force activity.

To dive deeper, let’s pivot to Wireshark and load the meerkaat.pcap file. This will allow us to inspect packet details and better understand how the attack was carried out.

Once Wireshark is open:

Click the magnifying glass icon to open the search tool.
Select Packet details and String to narrow the search to strings within packet details.
Enter username in the search box.

Wireshark: Searching for the username string

This helps us find packets where the username form item appears. The goal is to determine the method used for these requests and filter more granularly.

Looking at the first hit, we see an HTTP POST request to the web server. Let’s apply a display filter to isolate these:

http.request.method == “POST”

Wireshark: Confirming the User-Agent for the matching packets

Now we can easily see dozens of login attempts using Forela account addresses. The user agent matches what we saw in Zui:

python-requests/2.28.1

Based on this evidence, the attacker appears to be carrying out a credential stuffing attack (MITRE ATT&CK — T1110.004) by using multiple known usernames and passwords to gain access to target accounts.

Brute Force: Credential Stuffing _Adversaries may use credentials obtained from breach dumps of unrelated accounts to gain access to target accounts…_attack.mitre.org

Question 3: Does the vulnerability exploited have a CVE assigned — and if so, which one?

Our next task is to identify the specific CVE for the exploited vulnerability. Fortunately, we already found a clue while reviewing the Suricata Alerts by Signature in Zui: CVE-2022–25237 associated with Bonitasoft.

Zui: Identifying the related CVE

Let’s drill down on the details of this CVE by looking it up on CVEdetails:

https://www.cvedetails.com/cve/CVE-2022-25237/

According to the description:

Bonita Web 2021.2 is affected by a authentication/authorization bypass vulnerability due to an overly broad exclude pattern used in the RestAPIAuthorizationFilter. By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints. This can lead to remote code execution by abusing the privileged API actions.

Keep this information in mind — it will be extremely helpful during the next few questions.

Question 4: Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit?

Now that our research uncovered how CVE-2022–25237 can be exploited, we already have the answer:

By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints.

Let’s confirm this with our own dataset in Wireshark by searching for /api within the results.

Wireshark: Identifying API endpoints

Bingo! We’ve found the same string in our traffic that’s described in the CVE details.

Question 5: How many combinations of usernames and passwords were used in the credential stuffing attack?

To answer this, we need to determine how many username/password combinations were attempted during the attack.

One approach is to use a third tool: NetworkMiner, which offers robust forensic capabilities, including easy parsing and display of credentials logged in the PCAP.

There’s just one catch — we first need to convert the Wireshark PCAPNG file to PCAP before importing it into NetworkMiner. In Wireshark:

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

Now that we have the correct file type, launch NetworkMiner and open the new PCAP file. Once it loads:

Click the Credentials tab
Uncheck Show Cookies (we only want credential stuffing attempts, not session cookies)
Focus on Forela domain email addresses with the MIME/MultiPart protocol

NetworkMiner: Identifying credential pairs

This gives us a clean list of all username/password combinations attempted in the traffic. After removing the install user and one duplicate entry for seb.broom, we’re left with 56 unique combinations.

Question 6: Which username and password combination was successful?

For illustrative purposes, let’s jump back to Wireshark and apply an http filter. This will make it easier to see HTTP requests and responses side by side. The idea is simple: look for where the status codes change from the HTTP 4XX range (failed requests) to the HTTP 2XX range (successful requests).

Wireshark: Following the HTTP response trail

Just like in the image above, you’ll notice the first successful response appears as an HTTP 204 No Content. Looking at the packets immediately below, you’ll see other 200 OK responses, so we know we’re in the right spot. At this point, all we need to do is right‑click the first of the HTTP 200 responses and select Follow > HTTP Stream.

Wireshark: Uncovering the successful login credentials

By correlating these successful responses and following the HTTP stream, we can determine that the account seb.broom was the one that successfully authenticated.

Moving right along, for Question 7 we need to determine if the attacker used any text-sharing site during the attack. For this, we’ll jump back to Zui and use the Unique DNS Queries filter.

Selecting this option provides an easy-to-read list of all unique outbound DNS lookup queries in the PCAP. Among these, we see that pastes.io was contacted. This is a text-pasting website, which fits perfectly with what we’re looking for.

Zui: Identifying text sharing site in DNS queries

In the next couple of questions, we’ll figure out how this service was leveraged in the attack.

Questions 8 & 9

Please provide the filename of the public key used by the attacker to gain persistence on our host.

Question 9: Can you confirm the file modified by the attacker to gain persistence?

Now comes the fun part! To answer these, we’ll focus on identifying the full URI in Zui, then pivot to a web browser to see what the attacker left behind.

First, from the pastes.io query in Zui’s Unique DNS Requests results, right-click the entry and select New Search from Value. This adjusts the results to search for all traffic related to pastes.io in the PCAP.

Next, locate the line with the http type and expand it. This reveals the full URI containing the domain:

Zui: Identifying the pastes.io URI

https://pastes.io/raw/bx5gcr0et8

With the URL ready, open your browser and enter it into the address bar — and voila!

The contents of the pastes.io URL from the pcap

The contents of the paste show a command using curl to download another file named:

hffgra4unv

The command saves the output into:

/home/ubuntu/.ssh/authorized_keys

This file stores SSH public keys, which means the attacker added their own key to gain persistent access to the host. Good find!

Question 10: Can you confirm the MITRE technique ID of this type of persistence mechanism?

We’ve made it to the final question! For this one, we’ll pivot to the MITRE ATT&CK knowledge base of attacker tactics, techniques, and procedures. The goal is to identify the persistence technique ID within the framework.

We already have all the pieces: Persistence + SSH authorized keys = Account Manipulation: SSH Authorized Keys (T1098.004)

Account Manipulation: SSH Authorized Keys _Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions…_attack.mitre.org

According to MITRE:

Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured.

This technique perfectly aligns with the attacker’s behavior we observed in our investigation. Now that we’ve identified their method of persistence and confirmed that Forela’s Bonitasoft server was compromised, we can wrap up this case.

Conclusion:

That’s a wrap on Meerkat and the end of our investigation! A big thank you to Hack The Box for another awesome challenge.

This challenge was a fantastic exercise in network forensics, tying together several important concepts: detecting credential stuffing attacks, identifying CVEs in real-world applications, and uncovering persistence mechanisms like SSH authorized keys.

Working through each question, we followed the trail of clues and learned how to pivot between tools like Zui, Wireshark, and NetworkMiner to extract meaningful evidence. I chose this challenge because it’s perfect for sharpening packet analysis skills and offers a realistic approach where flexibility and knowing the right tool for the job can speed up an investigation when timing is critical.

It’s pretty cool that with just a PCAP we can reveal how attackers chain techniques, starting with credential stuffing, exploiting a web vulnerability, and then maintaining access through SSH. Awesome!

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

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/552

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

Zui/Brim: https://www.brimdata.io/download/

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

CVEdetails — CVE-2022–25237: https://www.cvedetails.com/cve/CVE-2022-25237/

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

MITRE ATT&CK — Brute Force: Credential Stuffing (T1110.004): https://attack.mitre.org/techniques/T1110/004/

MITRE ATT&CK — Account Manipulation: SSH Authorized Keys (T1098.004): https://attack.mitre.org/techniques/T1098/004/

HackTheBox — Unit42 Sherlock Walkthrough

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

HackTheBox | Unit42 | Sherlock Walkthrough

Investigating Masquerading Malware Using Sysmon Logs and the Windows Event Viewer.

Image Credit: https://app.hackthebox.com/sherlocks/632

Introduction:

Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the Unit42 Sherlock challenge from Hack The Box, you’re in the right place.

This is the third challenge in the Intro to Blue Team track, but you can jump in in any order. If you’re following along or you’re a completionist, check out my write-up of the previous challenge — BFT:

HackTheBox— BFT Sherlock Walkthrough

This challenge leans heavily into endpoint forensics using a real-world inspired narrative. It’s up to us to piece together what happened using only the provided Sysmon logs. We’ll use tools like Windows Event Viewer, VirusTotal, and MITRE ATT&CK to uncover and document the infection chain.

This one’s a great opportunity to explore how attackers might abuse legitimate cloud-based delivery mechanisms to deliver trojanized installers masquerading as legitimate tools.

So, if you’re new to Sysmon or just want to sharpen your log analysis skills, this is a great challenge to put your hands on. Let’s get into it!

Thanks for reading and going on this investigation with me!

Challenge Scenario:

In this Sherlock, you will familiarize yourself with Sysmon logs and various useful EventIDs for identifying and analyzing malicious activities on a Windows system. Palo Alto’s Unit42 recently conducted research on an UltraVNC campaign, wherein attackers utilized a backdoored version of UltraVNC to maintain access to systems. This lab is inspired by that campaign and guides participants through the initial access stage of the campaign.

Setup the Analysis Environment & Extract the Challenge File:

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

Question 1: How many Event logs are there with Event ID 11?

Let’s kick off our investigation by extracting the unit42.zip archive. This leaves us with a Windows Event Log file: Microsoft-Windows-Sysmon-Operational.evtx, which we can analyze using Windows Event Viewer. Go ahead and double-click the file to launch Windows Event Viewer.

But first, before we go any further, let’s take a step back and get a quick refresher on what Sysmon is and what’s contained in its event logs.

If you haven’t heard of it before, Sysmon is a utility that’s part of the Microsoft Sysinternals Suite. It runs as a system service and monitors detailed system activity like process creation, file creation, and network connections, and logs it to the Windows Event Log. Sysmon also has its own event types that can be used to filter specific activity in the logs, which is exactly what we’ll do in this challenge.

Let’s jump back to Event Viewer and make sure we’re looking at the Microsoft-Windows-Sysmon-Operational logs under Saved Logs.

To answer Question 1, we’re looking for only Event ID 11 (FileCreate), so we need to filter the log to accurately count these events. We can do this by clicking Filter Current Log… on the right-hand column and entering 11 in the Event ID box.

Windows Event Viewer: Filtering Sysmon Event ID 11

Once the filter is applied, we can see the number of events in the filtered log above the entries:

Windows Event Viewer: Identifying the number of filtered events

This result tells us that there are 56 file creation events captured by Sysmon on the victim system.

Question 2: Whenever a process is created in memory, an event with Event ID 1 is recorded with details such as command line, hashes, process path, parent process path, etc. This information is very useful for an analyst because it allows us to see all programs executed on a system, which means we can spot any malicious processes being executed. What is the malicious process that infected the victim’s system?

For our next task, we need to determine which malicious process infected the victim’s system. To do this, we’ll filter the Sysmon logs again, this time searching for Event ID 1.

According to the Sysmon documentation, Event ID 1 details process creation events and “provides extended information about a newly created process. The full command line provides context on the process execution.”

Once we’ve filtered the process creation events, we can start analyzing them. For readability, I’ve switched to the Details tab instead of the default General tab.

Starting with the earliest events first, the second entry reveals something suspicious — an unusual executable, Preventivo24.02.14.exe.exe, located in the victim’s Downloads folder. Of all the events, this one stands out as the most likely culprit with the available data.

Windows Event Viewer: Identifying the malicious process with Sysmon Event ID 1

But we don’t have to guess! Sysmon also handily provides the file hash values under the Hashes field. We can use these hashes to pivot out to an external threat intelligence service like VirusTotal to check if this exact binary has been analyzed before and make a more informed decision.

https://www.virustotal.com/gui/file/0cb44c4f8273750fa40497fca81e850f73927e70b13c8f80cdcfee9d1478e6f3

We can see right away that this file hash is detected as malicious by most of the platforms, and there’s a ton of great information about what this executable does. Let’s proceed with our investigation and see what we can gather just by looking at the provided Sysmon logs, shall we?

Question 3: Which Cloud drive was used to distribute the malware?

Our next order of business is to determine which cloud storage drive the malicious executable was downloaded from. For this, we can identify the Referrer URL in the Zone.Identifier metadata of the file. This is part of the Mark of the Web metadata stream and can help us analysts identify the source of a file.

We can uncover this information by filtering the event log for Event ID 15. This event label is FileCreateStreamHash, and while it sounds complicated, the Sysmon documentation clarifies:

This event logs when a named file stream is created, and it generates events that log the hash of the contents of the file to which the stream is assigned (the unnamed stream), as well as the contents of the named stream. There are malware variants that drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier “mark of the web” stream.

Putting all this together, filtering for Event ID 15 returns two results. The one at the top contains the Mark of the Web stream information for the malicious binary we identified in the previous question.

Windows Event Viewer: Identifying the referrer URL using Sysmon Event ID 15

This entry shows the Zone.Identifier metadata, including the ReferrerUrl which points to Dropbox, a common and very popular cloud storage solution, as the source of malware download.

Question 4: For many of the files it wrote to disk, the initial malicious file used a defense evasion technique called Time Stomping, where the file creation date is changed to make it appear older and blend in with other files. What was the timestamp changed to for the PDF file?

Next up, to answer Question 4, we’ll need to identify a PDF file related to the attack and then determine what the manipulated timestamp of the file is.

The first step is to filter the Sysmon logs for Event ID 2: A process changed a file creation time. This event ID is helpful for detecting timestomp activity on a victim system. According to the Sysmon documentation:

The change file creation time event is registered when a file creation time is explicitly modified by a process. This event helps tracking the real creation time of a file. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system. Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.

Once we’ve applied the filter, we can use Windows Event Viewer’s built-in Find function and search for the keyword pdf to quickly pinpoint the event we’re seeking.

Windows Event Viewer: Identifying timestomp events using Sysmon Event ID 2

Take a look under the file path for ~.pdf — we can see two different timestamps, which confirms that the file was manipulated using a timestomp technique (MITRE ATT&CK T1070.006). We’re looking for the older, original timestamp to answer the question.

Question 5: The malicious file dropped a few files on disk. Where was “once.cmd” created on disk? Please answer with the full path along with the filename.

Moving on to Question 5, we need to figure out the file path of another related file: once.cmd.

The key phrase in the question is “dropped a few files on disk”, which tells us we’ll need to filter for Event ID 11 (FileCreate) again. Once we’ve applied the filter, we can use the Find function to search for the file in question — once.cmd.

Windows Event Viewer: Identifying dropped file path event using Sysmon Event ID 11

Once we’ve located the event, we’ll learn the full file path of the dropped file.

Question 6: The malicious file attempted to reach a dummy domain, most likely to check the internet connection status. What domain name did it try to connect to?

Now’s the time to start moving away from file-related events and pivot to network events within the Sysmon log. To answer Question 6, filter for Event ID 22: DNSEvent (DNS query) events to identify DNS lookups to external domains.

This event is generated when a process executes a DNS query, whether the result is successful or fails, cached or not. The telemetry for this event was added for Windows 8.1 so it is not available on Windows 7 and earlier.

Windows Event Viewer: Identifying DNS connection check event using Sysmon Event ID 22

Applying this filter returns three events, with the top event revealing a DNS lookup to a specific domain — this is the one we’re after, and it seems to be used as an internet connection check.

Question 7: Which IP address did the malicious process try to reach out to?

To answer Question 7 and continue our analysis of network-related artifacts in the Sysmon log, we’ll now need to determine the IP address that the malicious process reached out to.

For this, we’ll filter the Sysmon log for Event ID 3: Network connection. According to the Sysmon documentation:

The network connection event logs TCP/UDP connections on the machine. It is disabled by default. Each connection is linked to a process through the ProcessId and ProcessGuid fields. The event also contains the source and destination host names IP addresses, port numbers and IPv6 status.

Applying this filter yields one result. For ease of viewing, I’ve selected the Details tab. Scroll down to the DestinationIp field to find the remote IP that the malware connects to.

Windows Event Viewer: Identifying C2 IP using Sysmon Event ID 3

Question 8: The malicious process terminated itself after infecting the PC with a backdoored variant of UltraVNC. When did the process terminate itself?

For our final question, we just need to figure out when the malicious process Preventivo24.02.14.exe.exe terminated.

We can discover this information easily by filtering for Event ID 5: Process terminated events.

The process terminate event reports when a process terminates. It provides the UtcTime, ProcessGuid and ProcessId of the process.

This will return a single event, and we can grab the termination timestamp from the event details.

Windows Event Viewer: Identifying malware process termination using Sysmon Event ID 5

So, What Happened Here? Bringing it All Together and Contextualizing the Infection Chain

Before we jump down to the conclusion, let’s take a step back and look at the LinkedIn post by Palo Alto’s Unit 42 that inspired this challenge. If you’re like me, a visual reference that brings all the questions together can help you fully understand what happened, and what the artifacts we discovered actually mean.

#ultravnc #timelythreatintel #indicatorsofcompromise #unit42threatintel #wireshark… _2024-01-23 (Tuesday): #UltraVNC infection generated by EXE from Dropbox URL. Dropbox URL now offline! IOCs from an…_www.linkedin.com

Image Credit: https://www.linkedin.com/posts/unit42_ultravnc-timelythreatintel-indicatorsofcompromise-activity-7156060867678150657-ktbL/

Does this sound kind of familiar?

If we look at the visual for the infection chain, we’ll see a malicious executable downloaded from Dropbox — just like we identified in Questions 2 & 3. Then we see a decoy PDF file, which lines up with Question 4. This context gives us insight into the attack flow and reinforces how each artifact we uncovered fits into a broader narrative.

I strongly encourage you to check out the Palo Alto post, explore the research, and see what other conclusions you might draw compared to the challenge. It’s a great way to validate your analysis and expand your understanding of how threat intelligence connects to hands-on investigations.

Conclusion:

That wraps up our investigation of the Unit42 challenge! We’ve walked through each step of the infection chain: from identifying the initial malicious executable downloaded from Dropbox, to uncovering timestomping activity, DNS queries, and IP connections — all using nothing more than Sysmon logs and a bit of threat intelligence.

A big thank you to Hack The Box for another high-quality and fun Sherlock — it’s been a blast going through this track.

I chose this week’s challenge as a great example of how Sysmon bolsters forensic capabilities by collecting and contextualizing meaningful endpoint logs. With these logs, we were able to breeze through analysis, focusing on targeted events to tell a compelling story. Whether it’s filtering for specific event IDs, pivoting to external threat intel platforms like VirusTotal, or recognizing subtle evasion techniques like timestomping, every artifact adds a piece to the puzzle. Awesome stuff!

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

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/632

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

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

Microsoft — Sysinternals: https://learn.microsoft.com/en-us/sysinternals/

VirusTotal — Preventivo24.02.14.exe.exe: https://www.virustotal.com/gui/file/0cb44c4f8273750fa40497fca81e850f73927e70b13c8f80cdcfee9d1478e6f3

MITRE ATT&CK — Indicator Removal: Timestomp (T1070.006): https://attack.mitre.org/techniques/T1070/006/

LinkedIn — Palo Alto Networks Unit 42: https://www.linkedin.com/posts/unit42_ultravnc-timelythreatintel-indicatorsofcompromise-activity-7156060867678150657-ktbL/

HackTheBox — Pikaptcha Sherlock Walkthrough

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

HackTheBox — Pikaptcha Sherlock Walkthrough

Investigating a Fake CAPTCHA Attack Using Registry Explorer and NetworkMiner.

Image Credit: https://app.hackthebox.com/sherlocks/Pikaptcha

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Pikaptcha Sherlock challenge from Hack The Box, you’re in the right place. Let’s check out this week’s scenario below.

Challenge Scenario:

Happy Grunwald contacted the sysadmin, Alonzo, because of issues he had downloading the latest version of Microsoft Office. He had received an email saying he needed to update, and clicked the link to do it. He reported that he visited the website and solved a captcha, but no office download page came back. Alonzo, who himself was bombarded with phishing attacks last year and was now aware of attacker tactics, immediately notified the security team to isolate the machine as he suspected an attack. You are provided with network traffic and endpoint artifacts to answer questions about what happened.

For this challenge, our job is to analyze the provided artifacts to learn about the suspected attack. We’ll need to uncover how the victim was compromised and determine what happened. By combining our findings from the endpoint and the network, we’ll be able to figure out exactly what happened.

This challenge is a fantastic introduction to endpoint registry analysis, network traffic analysis, and fake Captcha attacks.

But what’s in the toolkit for this investigation? The fun part is — there isn’t one right or wrong approach for this challenge. For this walkthrough, I’ll be demonstrating NetworkMiner and Eric Zimmerman’s Registry Explorer for the bulk of the analysis, but there are many other tools that can accomplish the same things — so feel free to use your preferred tools!

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

Thanks for reading and going on this investigation with me!

Setup Your Analysis Environment & Extract the Challenge File:

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

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

Question 1: It is crucial to understand any payloads executed on the system for initial access. Analyzing registry hive for user happy grunwald. What is the full command that was run to download and execute the stager.

Let’s kick off this investigation by opening the Pikaptcha challenge file. Inside, we’ll find several artifacts, but the first set we’re interested in are contained in the 2024–09–23T052209_alert_mssp_action folder.

To answer Question 1, we need to search for evidence of payload execution. Within the 2024–09–23T052209_alert_mssp_action folder are, among others, the registry artifacts. While there are a couple of places we can check, a great starting point is the Most Recently Used (MRU) artifacts.

These MRU artifacts are tracked by Windows and can help determine recent interaction with files and applications executed via the Windows Run utility. We can access this information by mounting the NTUSER.DAT hive found in the happygrunwald user folder.

Now that we understand what we’re searching for, let’s look at the how. One excellent tool for searching Registry artifacts is Eric Zimmerman’s Registry Explorer. This is a GUI-based tool used to open, browse, and search the registry — very handy!

Let’s put this into practice:

Open Registry Explorer
Press File > Load Hive
Navigate to 2024–09–23T052209_alert_mssp_action\C\Users\happygrunwald
Select NTUSER.DAT

Pro Tip: Hold Shift when selecting the NTUSER.DAT — this will automatically replay the associated transaction logs. Otherwise, you’ll get a “Dirty Hive” warning.

Registry Explorer: Opening the happygrunwald NTUSERS.DAT hive

Once loaded, we’re looking for RunMRU. There are two easy ways to get there. I’ve used the search function to locate it quickly, but you can also use the built-in bookmark under Common > RunMRU (Most recently run programs).

Registry Explorer: The contents of the RunMRU key

Either way, you’ll notice a suspicious PowerShell command listed under the Executable column that appears to be reaching out to an external IP address to download a script called office2024install.ps1. Knowing that Happy attempted to download Office updates and that we’re seeking a command that downloads and executes a stager, we can reasonably determine this is the executed payload we’re looking for.

To make this easier to see, click the Values tab so you can right-click and copy the data value. You can remove the \1 at the end as it’s not part of the command.

Registry Explorer: The values tab of the RunMRU key

Let’s check our work and move on to the next question.

Question 2: At what time in UTC did the malicious payload execute?

To answer Question 2, we need to determine when the payload we identified in the last question executed. For this, simply click the RunMRU tab again within Registry Explorer and check the Opened On value. This is the time stamp we need.

Registry Explorer: Viewing the “Opened On” timestamp for the suspicious PowerShell command

Now that we’ve obtained the value for the execution time, we can start to build our timeline and pivot to searching for follow-on activities.

Question 3: The payload which was executed initially downloaded a PowerShell script and executed it in memory. What is sha256 hash of the script?

To answer Question 3, we need to determine the SHA256 hash of the office2024install.ps1 second-stage script. By obtaining the hash of the script, we can search for threat intelligence about the specific file.

With limited registry artifacts available, let’s pivot to the second artifact in the challenge file: pikaptcha.pcapng. This PCAPNG file is a network packet capture containing raw network packet data. We can use this data to gain a deep understanding of the network traffic. Typically, when the topic of packet capture comes up, Wireshark is one of the first tools that comes to mind.

For this walkthrough, however, we’re going to use NetworkMiner, “an open source network forensics tool that extracts artifacts, such as files, images, emails and passwords, from captured network traffic in PCAP files.”

While this task can be performed in Wireshark, using NetworkMiner instead is extremely beneficial for carving out the file hash of the malicious PowerShell script because NetworkMiner can automatically reassemble files from the packet capture.

But first, we need to convert the pikaptcha.pcapng file from PCAPNG to PCAP so that we can open it in NetworkMiner. This is a straightforward process: open the file in Wireshark, press File > Save As, and select the Wireshark/tcpdump/…-pcap file format.

Wireshark: Converting PCAPNG to PCAP for use in NetworkMiner

Important: Because NetworkMiner assembles files automatically by default, this might mean you’re introducing malware onto your system if there are malicious files in the PCAP. If your analysis environment has something like Microsoft Defender running, it may start triggering alerts as the potentially malicious files are assembled. This is one of the reasons it’s important to perform malware analysis in a dedicated, safe environment. Don’t put your data at risk!

For example, in my isolated Flare-VM environment, real-time protection is typically turned off, so it doesn’t interfere with analysis. For illustrative purposes, I’ve turned it on. As seen in the screenshot below, the built-in Microsoft Defender detected malware in the assembled files from this PCAP.

Microsoft Defender: Alert triggered by NetworkMiner’s file reassembly

Okay, now that we’ve made a copy of pikaptcha.pcapng in PCAP format, let’s open it with NetworkMiner. Once the application is open, use the Files tab and search for the name of the malicious PowerShell script — office2024install.ps1. This will display the file contained in the traffic.

NetworkMiner: Identifying the SHA256 hash of the PowerShell script

Finally, right-click the entry and select File Details, which provides detailed information about the file including the SHA256 hash.

579284442094e1a44bea9cfb7d8d794c8977714f827c97bcb2822a97742914de

Question 4: To which port did the reverse shell connect?

Now, you might’ve noticed something strange when we were looking at the office2024install.ps1 payload details in the previous question. Did you catch the blob of encoded strings?

NetworkMiner: Noting the Base64 blob within the script contents

This is likely a way to evade analysis by Base64 encoding the payload, but it also probably contains some interesting artifacts that’ll help us learn more about the script’s behavior.

To understand the contents of the PowerShell script, we’ve got a couple of choices:

Pivot to external threat intelligence services like VirusTotal, assuming the file has been seen before.
Manually decode the blob using CyberChef.

I’ll illustrate both methods — you can choose whichever works best for your workflow.

To check VirusTotal, copy the SHA256 hash we identified in Question 3. Then, use your browser to navigate to VirusTotal and paste the hash into the search bar. On the analysis page, head to the Behavior tab and scroll down to Network Communication under the IP Traffic header. Here, we can see the observed port used by the reverse shell:

VirusTotal: Identifying the reverse shell destination port

A second option is to use a tool like CyberChef to decode the script manually. To make it easier to copy the encoded content, open the assembled script from NetworkMiner’s output directory, then open the PowerShell script in a text editor like Notepad++ and copy it to your clipboard.

Notepad++: Opening the malicious script contents

Next, open CyberChef. This will be part of your Flare-VM environment, but if not, the online version works just as well. Paste the encoded blob into the Input field and add the “From Base64” and “Remove Null Bytes” operations to the recipe.

CyberChef: Decoding the Base64 to identify the port

Voilà! Now that we’ve decoded the script contents, we can see that it’s using the System.Net.Sockets.TCPClient class to establish a connection over port 6969 to the same IP address we identified in Question 1.

Question 5: For how many seconds was the reverse shell connection established between C2 and the victim’s workstation?

Now that we’ve uncovered the destination IP and the port used by the reverse shell, our next objective is to determine how long the connection was active. For this task, let’s return to the Hosts tab in NetworkMiner.

On the Hosts tab, input the command and control IP address we identified in the script to filter traffic for that host:

43[.]205[.]115[.]44

Next, expand the IP address and turn your attention to the Incoming Sessions header to identify the session over port 6969, including the session start and end times.

NetworkMiner: Determining the session start and end times to the C2 IP and port

Now that we have the timestamps, we’ve almost got the answer. All we need to do is calculate the duration of the connection in seconds. To work a little smarter, we can leverage an online tool like the Time Duration Calculator from Calculator.net.

Time Duration Calculator _Free calculator to get the number of hours, minutes, and seconds between two times. Also, a full version to calculate…_www.calculator.net

Simply input the times we identified in NetworkMiner to determine that the connection was active for 403 seconds.

Calculator.net: Calculating the time duration for the C2 connection in seconds

Question 6: Attacker hosted a malicious Captcha to lure in users. What is the name of the function which contains the malicious payload to be pasted in victim’s clipboard?

For our final objective, we need to find the function on the website that copies a malicious PowerShell command to the victim’s clipboard as part of a fake Captcha.

To do this, we can leverage NetworkMiner’s assembled files to view a reconstruction of the index.html page visited by Happy and used to facilitate the compromise. For example, we can identify the correct directory in the AssembledFiles by looking for the C2 IP address folder from the previous question and checking the folder for TCP-80 (HTTP), indicating web traffic.

Locating the reassembled index.html page

After locating the reassembled index.html, open it with your default web browser. My analysis machine is using Microsoft Edge, for example.

Once open, press F12 to launch the browser’s DevTools and view the page source. Select the index.html file in the Page column, then navigate to the Sources tab.

Scroll down until we stumble on the function stageClipboard. This is the function that contains the malicious PowerShell code which is automatically copied to the victim’s clipboard.

Microsoft Edge: Identifying the stageClipboard function in index.html

Notice the familiar command? It’s the same PowerShell command we found in Question 1. This means we’ve identified the source of the initial access and confirmed that our victim, Happy Grunwald, was compromised.

Based on Happy’s account of solving a Captcha challenge, and the evidence we’ve located during this investigation, we can reasonably conclude that he fell victim to a fake CAPTCHA leading to a ClickFix attack.

If you aren’t familiar, ClickFix attacks typically involve a fake Captcha page that asks the user to “verify” themselves by instructing the victim to open the Windows Run dialog and paste a malicious PowerShell command that has been automatically copied to their clipboard. This technique is known as User Execution: Malicious Copy and Paste (T1204.004) from MITRE ATT&CK.

If you’d like more information about ClickFix attacks, check out this excellent blog from Palo Alto Unit 42 linked below:

Fix the Click: Preventing the ClickFix Attack Vector _ClickFix campaigns are on the rise. We highlight three that distributed NetSupport RAT, Latrodectus, and Lumma Stealer…_unit42.paloaltonetworks.com

Now that we’ve completed all our objectives and scoped out this attack, let’s submit our answer and wrap up the investigation.

Conclusion:

There we have it! We’ve completed all our objectives and determined how the victim, Happy, was compromised. By analyzing the user’s NTUSER.DAT artifact with Registry Explorer, we identified a malicious command executed on the victim’s system. After that, we checked out their network traffic with NetworkMiner to identify second-stage payloads, command and control infrastructure, and ultimately confirmed that the user fell victim to a fake Captcha leading to a ClickFix attack.

A big thank you to Hack The Box for another high-quality and engaging Sherlock. These things are just awesome — each one presents a great hands-on opportunity to investigate realistic attacks. I chose this week’s challenge to learn more about the artifacts left behind from a ClickFix attack. These types of attacks are becoming more and more common, so I wanted an opportunity to dig deeper into how they work and what impact they can have.

While Wireshark is a core tool in any cybersecurity toolkit, I wanted the opportunity to highlight a great use case for NetworkMiner and its feature set. This challenge didn’t disappoint!

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/Pikaptcha

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

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

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

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

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

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

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

VirusTotal — Sample: https://www.virustotal.com/gui/file/579284442094e1a44bea9cfb7d8d794c8977714f827c97bcb2822a97742914de/behavior

Calculator.net: https://www.calculator.net/time-duration-calculator.html?starthour=05&startmin=07&startsec=48&startunit=a&endhour=05&endmin=15&endsec=31&endunit=p&ctype=1&x=Calculate

MITRE ATT&CK — User Execution: Malicious Copy and Paste (T1204.004): https://attack.mitre.org/techniques/T1204/004/

Palo Alto — Unit 42: Fix the Click: Preventing the ClickFix Attack Vector: https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/

HackTheBox — BFT Sherlock Walkthrough

Sun, 25 May 2025 00:00:00 +0000

HackTheBox— BFT Sherlock Walkthrough

Investigating a Compromised Endpoint Using MFTECmd and Timeline Explorer.

Image Credit: https://app.hackthebox.com/sherlocks/BFT

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the BFT Sherlock challenge from Hack The Box, you’re in the right place. This challenge is a fantastic introduction to analyzing MFT artifacts on a Windows system — let’s check out the scenario below.

Challenge Scenario:

In this Sherlock, you will become acquainted with MFT (Master File Table) forensics. You will be introduced to well-known tools and methodologies for analyzing MFT artifacts to identify malicious activity. During our analysis, you will utilize the MFTECmd tool to parse the provided MFT file, TimeLine Explorer to open and analyze the results from the parsed MFT, and a Hex editor to recover file contents from the MFT.

In this challenge, a victim’s device has been compromised with malware, and we need to investigate what happened. The twist? We’re only given access to the Master File Table from the device. Fortunately, this is a robust forensic artifact that contains an entry for every file on the system — including size, timestamps, permissions, and more!

What’s in our toolkit for this investigation? Like the challenge stated, we’re going to leverage a couple of tools from Eric Zimmerman’s forensic suite to parse and explore the $MFT, including MFTECmd to parse it and Timeline Explorer to analyze the results.

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

Thanks for reading and going on this investigation with me!

Setup the Analysis Environment & Extract the Challenge File:

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

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

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

Question 1: Simon Stark was targeted by attackers on February 13. He downloaded a ZIP file from a link received in an email. What was the name of the ZIP file he downloaded from the link?

Once we’ve downloaded the challenge file and unzipped the archive, let’s get a high-level overview of the artifacts and tools we have to work with.

Windows Explorer: The contents of the challenge file folder

Within the C folder, we find a single file: $MFT. This is the Master File Table, which on NTFS file systems contains an entry for every file on the system—including size, timestamps, and permissions. It’s a valuable forensic artifact for analyzing file activity on a system, and we’ll do exactly that.

The other two folders contain our toolset. To analyze the $MFT, we’ll use Eric Zimmerman’s MFTECmd, a CLI-based tool that parses and exports the contents. Then, we’ll leverage Timeline Explorer, another Eric Zimmerman tool—a powerful CSV viewer that lets us sort and manipulate the results.

Now that we’ve got the background out of the way, let’s jump into MFTECmd and try it out. Open Windows Command Prompt and run the tool using the syntax below:

MFTECmd.exe -f <PATH_TO_$MFT_Artifact> –csv <PATH_TO_OUTPUT_DIRECTORY>

This command generates a CSV file we can open with Timeline Explorer for analysis.

Fortunately, we won’t be searching blindly — there are some clues in the question to guide us. First, we know this is a downloaded file, so filter the Parent Path column using the keyword Downloads.

Next, filter the Extension column for .zip to isolate ZIP file downloads.

Timeline Explorer: Identifying the ZIP file

By combining these filters, we can identify the file used for initial access. To validate our findings, check the Time Created column to match the date, February 13, to determine which ZIP file was created first.

Question 2: Examine the Zone Identifier contents for the initially downloaded ZIP file. This field reveals the HostUrl from where the file was downloaded, serving as a valuable Indicator of Compromise (IOC) in our investigation/analysis. What is the full Host URL from where this ZIP file was downloaded?

Next, we need to examine the Zone Identifier for the downloaded ZIP file to identify the URL it came from.

To do this, copy the Entry Number column value,75191,for the file we located in Question 1. Then, clear the Extension filter so we’re not limiting the view to just .zip files.

Next, input the value we copied into the Entry Number column to view results tied to this specific entry in the $MFT. Once filtered, we’ll see a second entry with the .identifier extension.

Timeline Explorer: Filtering the $MFT entry number

Scroll to the Zone ID Contents column to determine the HostURL metadata of the downloaded file. In the example below, I’ve double-clicked the entry to open the full cell contents

Timeline Explorer: Identifying the HostURL metadata

Question 3: What is the full path and name of the malicious file that executed malicious code and connected to a C2 server?

Now that we’ve identified the malicious .zip file and where it was downloaded from, let’s see if we can glean anything about its contents.

Within Timeline Explorer, clear the Entry Number filter we used in the previous question. This time, we’ll search for the filename from within the Downloads folder—this helps us understand more about the archive’s structure.

Timeline Explorer: Sussing out the malicious file

Using this keyword search, we’re able to identify a second archive, invoice.zip, which contains a suspicious .bat file—invoice.bat. Copy the entry under the Parent Path column and append the typical drive letter (C:) to match the answer format.

Question 4: Analyze the $Created0x30 timestamp for the previously identified file. When was this file created on disk?

For our next task, we’ll continue analyzing the file we identified in Question 3. Scroll over to the Created0x30 column, which represents the file creation timestamp.

Timeline Explorer: Identifying the Created0x30 timestamp

This timestamp reflects when the file was created on disk. This is a helpful piece of forensic metadata, especially when trying to correlate file activity with an attack timeline.

Question 5: Finding the hex offset of an MFT record is beneficial in many investigative scenarios. Find the hex offset of the stager file from Question 3.

To tackle Question 5, we need to discover the hex offset for the malicious stager file. The hex offset is essentially the location where the entry is stored in the $MFT.

To retrieve this information, let’s determine if there is a way to use MFTECmd again by referring to the MFTECmd GitHub page for command usage. After reviewing the documentation, we’ll try the --de option, which dumps the details of an entry:

de Dump full details for entry/sequence #. Format is ‘Entry’ or ‘Entry-Seq’ as decimal or hex. Example: 5, 624-5 or 0x270-0x5.

Next, locate the Entry Number of the malicious file from the previous two questions under the Entry Number column.

Timeline Explorer: Identifying the Entry Number of the malicious stager file

Putting this together, we can use the following syntax to print the results to the console:

MFTECmd.exe -f <PATH TO $MFT Artifact> –de 23436

Command Prompt: MFTECmd command example to identify the offset

Within the results, identify the Offset value, chop off the leading padding 0x, and let’s check our work.

Question 6: Each MFT record is 1024 bytes in size. If a file on disk has smaller size than 1024 bytes, they can be stored directly on MFT File itself. These are called MFT Resident files. During Windows File system Investigation, its crucial to look for any malicious/suspicious files that may be resident in MFT. This way we can find contents of malicious files/scripts. Find the contents of The malicious stager identified in Question3 and answer with the C2 IP and port.

We’ve made it to the last question, and our final task is to examine the DATA attribute, which contains the malicious file stored directly in the $MFT as a resident file, to identify the command and control (C2) IP address and port.

Within our MFTECmd analysis results, scroll to the DATA section and focus on the ASCII portion.

Command Prompt: MFTECmd output, identifying the C2 server

Under the ASCII section, we’ll find the contents of the file — a PowerShell script used to retrieve a second-stage payload from the C2 server. For the purposes of our investigation, we just need to capture the IP address and port of the server to complete our analysis.

Conclusion:

There we have it! Using the MFT, we’ve successfully uncovered how the victim’s device was infected, gathered details about the first-stage payloads, and identified the command and control (C2) server. Now that we’ve explored the MFT and put those skills into practice to complete our objectives, let’s close out this walkthrough of the BFT Sherlock.

A big thank you to Hack The Box for another impressive Sherlock. This was a really fun challenge that let me revisit the fundamentals of MFT analysis and be reintroduced to this essential forensic artifact. Personally, learning more about MFT Resident files was a highlight. It was so cool to see that concept in action to identify the C2 server. Awesome stuff!

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/BFT

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

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

Microsoft Learn — Master File Table (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table

MFTECmd: https://github.com/EricZimmerman/MFTECmd

HackTheBox — Brutus Sherlock Walkthrough

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

HackTheBox — Brutus Sherlock Walkthrough

Investigating a Brute Force Attack Using the auth.log and wtmp log.

Image Credit: https://app.hackthebox.com/sherlocks/Brutus/play

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Brutus challenge from Hack The Box, you’re in the right place. Imagine this scenario as we step into the shoes of a digital forensics analyst:

Challenge Scenario:

In this very easy Sherlock, you will familiarize yourself with Unix auth.log and wtmp logs. We’ll explore a scenario where a Confluence server was brute-forced via its SSH service. After gaining access to the server, the attacker performed additional activities, which we can track using auth.log. Although auth.log is primarily used for brute-force analysis, we will delve into the full potential of this artifact in our investigation, including aspects of privilege escalation, persistence, and even some visibility into command execution.

The adversary has brute-forced the SSH service on a web server, gained initial access, and we need to investigate how it happened and what else they did with their access to mitigate the threat. Our objective is to analyze the server’s auth.log and wtmp logs to create a detailed timeline of the attacker’s activities, including initial access, privilege escalation, and persistence. To analyze these logs, we’re going to leverage Notepad++ and utmpdump, then enrich our findings by pivoting to MITRE ATT&CK to fully understand the adversary’s tactics and techniques.

Sounds exciting, right? Let’s get dive right into it! If you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this. Thanks for reading and going on this investigation with me!

Question 1: Analyze the auth.log. What is the IP address used by the attacker to carry out a brute force attack?

Okay — let’s jump right into this challenge by opening the first provided artifact, auth.log. For context, auth.log is the server’s authentication log which is a good starting point to identify a brute force attack as we can analyze successful and failed logins.

While there are other ways to approach the initial analysis, for this walkthrough, I’m going to simply use Notepad++ for my approach but feel free to choose any text editor you’d like!

With the artifact open, scroll through the events, and quickly we’ll observe dozens of lines returning Invalid user and Failed password from a single IP address, 65.2.161.68. The large number of failed attempts to access these accounts is indicative of brute force password guessing (MITRE ATT&CK — T1110.001).

Snippet from auth.log revealing failed username and password guessing attempts.

Question 2: The bruteforce attempts were successful and attacker gained access to an account on the server. What is the username of the account?

Now that we’ve discovered the attacker’s IP address, we’ll need to determine what account they successfully accessed. To do this, we’ll first need to understand what a successful login looks like. For example, toward the top of the log on lines 11–15, we’ll find a successful login for the root user from the IP address 203.101.190.9.

auth.log snippet showing a successful sign-in.

Having this information gives us a couple of strings that we can search for in the logs by using the “find” function to search for “accepted password,” indicating a successful login event. Let’s keep searching to see what other accounts logged in.

Notice anything suspicious on line 281? The next hit that we’ll locate is another login from the root user, but this time, the connecting IP address is the attacker’s — 65.2.161.68.

From the sign-in records in the auth.log, we’ve started to gather a rough timeline of the attack. However, we need to correlate this with the second log artifact, wtmp, which contains only the successful login/logout events on the system, for a comprehensive picture of the login activity.

The tricky part is that wtmp is a binary log file, so we can’t simply use Notepad++ to read it like we did for auth.log. Instead, we’ll need to leverage a Linux-based tool like last to read it. According to the Ubuntu manpages:

last searches back through the /var/log/wtmp file (or the file designated by the -f option) and displays a list of all users logged in (and out) since that file was created.

If you’re using a Linux-based analysis environment like I am, you’re in good shape. If you’re using a Windows-based environment, you can utilize something like the Windows Subsystem for Linux (WSL) to access this utility. For this walkthrough, I’ll post screenshots from both my REMnux environment and the WSL output for your reference. Let’s try putting this all together, adding in the full timestamps which we can access with the -F argument.

last -F -f wtmp

last command output in REMnux

last command using WSL

We’re getting closer but notice that the timestamp doesn’t quite match what we found in auth.log. While we can assume that there’s a mismatch between the system time and the local time, let’s try interpreting wtmp another way using a different utility, utmpdump. According to the manpages, utmpdump is “a simple program to dump UTMP and WTMP files in raw format, so they can be examined.” Let’s try it out and see what we can discover.

utmpdump wtmp

utmpdump in REMnux

utmpdump in WSL

Bingo! By dumping the wtmp with utmpdump we can locate the correct timestamp for the attacker’s login to the server. Now that we’ve established a firm timeline, let’s proceed with our investigation.

Now that we’ve identified the timestamp of the attacker’s login, let’s find the corresponding timestamp of the SSH session in the auth.log on line 322. Examining the nearby events more closely, we can see that on line 324, the new session is assigned the ID 37.

Identifying the attacker’s session ID in auth.log

Question 5: The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

When analyzing the wtmp in Question 3, you may have noticed another user account other than root present in the logs from the attacker’s IP address — cyberjunkie.

utmpdump in REMnux highlighting a second user account

Let’s double-verify this finding in the auth.log by searching for this username where we can confirm the activity.

Searching the auth.log for activities from the cyberjunkie account

Question 6: What is the MITRE ATT&CK sub-technique ID used for persistence by creating a new account?

Now that we understand the attacker brute-forced access to the root account and created a second account, cyberjunkie, for persistence, we need to map this technique to MITRE ATT&CK for additional intelligence.

After navigating to the MITRE ATT&CK website, we can evaluate the techniques listed under the persistence tactics. Eventually we’ll stumble across the technique “Create Account” (T1136) which seems to fit. On the page for this technique, we can evaluate the various sub-techniques, such as “Local Account” (T1136.001), leading us to the answer for Question 6.

MITRE ATT&CK — Create Account (T1136) — Sub-Techniques

Create Account: Local Account _Adversaries may create a local account to maintain access to victim systems. Local accounts are those configured by an…_attack.mitre.org

Question 7: What time did the attacker’s first SSH session end according to auth.log?

Now, let’s jump back to auth.log and analyze when the attacker’s first SSH session as the root user ended. In the log, we’ll search for “disconnect” events from the attacker’s IP, which we can find on lines 355–359.

auth.log snippet showing SSH session disconnect

For double verification, we also stumbled upon this answer when we used last to read the wtmp log back in Question 3.

Validating the session logout time in the wtmp log

Question 8: The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

For the final question of our investigation, let’s continue searching auth.log for activities performed by the cyberjunkie account, focusing specifically on events marked with sudo, or superuser, privileges.

On line 375, we’ll find something interesting: a command string leveraging curl to download a script from a GitHub repository.

auth.log snippet exposing malicious ingress tool transfer (T1105)

While out of scope for this challenge, the downloaded script seems to be a Linux persistence tool which would allow the attacker to maintain their access to the compromised server. From a defense perspective, having this knowledge gives us an idea of the attacker’s next moves.

However, for the purposes of this challenge the command we found is all we need to answer Question 8 and conclude the investigation. Great job!

Conclusion:

Case closed! Using the server’s auth.log and wtmp logs, we successfully identified the time of the attack, the attacker’s IP address, the compromised account, and their methods of persistence. During the investigation, we turned to MITRE ATT&CK to gain deeper insights into each technique, helping us better understand the adversary’s tactics and techniques. Now that we have scoped the attack and achieved our objectives, let’s close out this walkthrough of the Brutus challenge.

A big thank you to Hack The Box, for another engaging and realistic challenge. I chose this challenge as I was unfamiliar with the wtmp logs and what additional artifacts they contain compared to the auth.log. It was incredibly fun and valuable to learn about these logs and how to read them using last and utmpdump. The hands-on practice will absolutely come in handy during real-world during incident response. Awesome stuff!

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

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

Tools & References:

Challenge Link: https://app.hackthebox.com/sherlocks/Brutus

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

MITRE ATT&CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/

MITRE ATT&CK — Brute Force: Password Guessing (T1110.001): https://attack.mitre.org/techniques/T1110/001/

Ubuntu Manpages — last: https://manpages.ubuntu.com/manpages/focal/man1/last.1.html

Ubuntu Manpages - utmpdump: https://manpages.ubuntu.com/manpages/focal/man1/utmpdump.1.html

MITRE ATT&CK — Create Account: Local Account (T1136.001): https://attack.mitre.org/techniques/T1136/001/

MITRE ATT&CK — Ingress Tool Transfer (T1105): https://attack.mitre.org/techniques/T1105/

HackTheBox — CrownJewel-2 Sherlock Walkthrough

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

HackTheBox — CrownJewel-2 Sherlock Walkthrough

Investigating a Compromised Domain Controller Using Windows Event Logs

Image Credit: https://app.hackthebox.com/sherlocks/CrownJewel-2

Introduction:

Imagine this: You’re on the front lines of an organization’s security team, trying to catch your breath and recover from an attack against your domain controller just yesterday. Suddenly, another alert fires from the domain controller about a new exfiltration attempt of the NTDS.dit database which holds the domain’s secrets. Springing back to action, you must determine how the attacker got in this time by investigating the Windows Event Logs to establish a timeline, understand how the attack unfolded, and evict the attacker…again.

If this sounds exciting to you, welcome to my weekly walkthrough, you’ve stumbled on the right blog!

This week, we’re tackling the CrownJewel-2 challenge from Hack The Box, a direct follow-up to CrownJewel-1. The scenario assumes that we’re the same incident responder that investigated the first attack, so you’ll get the most out of this challenge if you complete CrownJewel-1 first. I’ll leave a link to my walkthrough for part 1 below.

HackTheBox — CrownJewel-1 Sherlock Walkthrough

CrownJewel-2 is another digital forensics and incident response (DFIR) challenge. This time, we’ll leverage the Windows Event Logs to understand how the attacker exfiltrated the NTDS.dit database. Using the Event Viewer, we’ll establish a timeline of the attack and track what activities occurred before the exfiltration.

While this challenge is geared toward beginners, it’s a fantastic lab for all skill levels to get some hands-on practice with Windows Event Log analysis. So, let’s grab our magnifying glasses again, take a deep breath, and get ready to dive back into the investigation!

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

Thanks for reading and joining me on this investigation!

Challenge Link: https://app.hackthebox.com/sherlocks/CrownJewel-2

Challenge Scenario:

Forela’s Domain environment is pure chaos. Just got another alert from the Domain controller of NTDS.dit database being exfiltrated. Just one day prior you responded to an alert on the same domain controller where an attacker dumped NTDS.dit via vssadmin utility. However, you managed to delete the dumped files kick the attacker out of the DC, and restore a clean snapshot. Now they again managed to access DC with a domain admin account with their persistent access in the environment. This time they are abusing ntdsutil to dump the database. Help Forela in these chaotic times!!

Setup the Analysis Environment & Extract the challenge file:

[GitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com](https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

– “https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

–”)[](https://github.com/mandiant/flare-vm?source=post_page--- –2efb81522f2c—

–)

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

Question 1: When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process?

Time to kick off this investigation and see what the attackers are doing this time! After unzipping the challenge file, we’ll find three Windows Event Log (.evtx) files that we’ll use to investigate the attacker’s activities.

Application: Contains application related log events.
System: Contains events related to Windows and its components like services, drivers, and hardware.
Security: Contains security-related events, including user logins, access attempts, and account enumeration.

Each of these logs will have a role to play during our investigation, but to answer Question 1, we’re searching for when the Volume Shadow Service (VSSVC.exe) last entered the running state, which might correlate with suspicious ntdsutil.exe database dumping activity.

If you joined me for the CrownJewel-1 investigation, you might remember that we learned the SYSTEM log contains the start and stop events for services, logged as Event ID 7036_._ Let’s try it out.

Open the SYSTEM log and filter it for the relevant Event ID we want by pressing Filter Current Log then entering 7036 into the Event ID field.

Filtering the SYSTEM Log for Event ID 7036

Once we’ve filtered the events, press Find and enter the keywords “volume shadow copy” — to find any instances of Volume Shadow Copy service events. Since the events are listed in descending order, the newest ones will be at the top of the log — so the first hit should be the one we need to find the most recent entry.

Now, with the event selected, we can obtain the precise system time when the service was started by clicking Details tab > XML View > TimeCreated SystemTime.

Question 2: Identify the full path of the dumped NTDS file.

To answer Question 2, let’s jump over to the APPLICATION logs. Without any further filtering, let’s try simply searching for NTDS and review the hits. It may take a few tries to find a meaningful event, but then we’ll stumble on the entry below:

Here we’ll observe that the ESENT database engine created a new NTDS.dit database which is the file for which we received the exfiltration alert. Recalling what we discovered in CrownJewel-1, dumping the NTDS.dit file is a method an attacker can use to create a copy of the “Active Directory domain database in order to steal credential information.”

Notice the suspicious file path of the dump and that the time stamp is one second after the Volume Shadow Service started? These are both clues that we are on the right path.

Question 3: When was the database dump created on the disk?

Fortunately, we already noticed the event timestamp correlation in the last question. In the same event from Question 2, let’s capture the system time by navigating to the Details tab, copying the System Time for the event, and then submitting the answer to continue building our timeline.

Question 4: When was the newly dumped database considered complete and ready for use?

Since we’ve already found the database events in the APPLICATION log, let’s manually review the entries that follow the database’s creation, starting with the event from Questions 2 & 3.

Scrolling through the logs, we’ll quickly come across the following event reporting that the database engine detached the dumped NTDS.dit database, indicating that the creation is completed.

Following the same process that we used in Questions 1 & 3, copy the System Time from the detailed view and submit the answer.

Question 5: Event logs use event sources to track events coming from different sources. Which event source provides database status data like creation and detachment?

Throughout the investigation of the APPLICATION logs, you may have noticed that both database events from Questions 3 & 4 were provided by the same event source: ESENT, a database engine that’s part of Windows. This is all we need to answer Question 5.

Extensible Storage Engine Managed Reference - Win32 apps _Learn more about: Extensible Storage Engine Managed Reference_learn.microsoft.com

Question 6: When ntdsutil.exe is used to dump the database, it enumerates certain user groups to validate the privileges of the account being used. Which two groups are enumerated by the ntdsutil.exe process? Give the groups in alphabetical order joined by comma space.

The key word to answering this question is “enumerate.” To find the answer, we’ll pivot to the SECURITY log. Once again, if you followed along during the CrownJewel-1 investigation, this next part will look very familiar.

First, filter the SECURITY log for Event ID 4799 — “A security-enabled local group membership was enumerated.” This event indicates that a local group membership was queried to check the account privileges.

[4799(S) A security-enabled local group membership was enumerated. - Windows 10 _Describes security event 4799(S) A security-enabled local group membership was enumerated._learn.microsoft.com](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

– “https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

–”)[](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

–)

Now that we’re only filtering the group membership enumeration events, we can narrow it down to the entries within the timeline we found in Question 2. During this time period, we’ll notice some events with the source process name of ntdsutil.exe where two distinct groups are enumerated.

4799 — First Enumerated Group

4799 — Second Enumerated Group

Putting the two groups in the correct alphabetized format, we can submit the answer and continue.

We’ve made it to the last question! To tackle Question 7, copy the Logon ID field (0x8DE3D) from the events that we found in the previous question. We’ll use this to correlate other events that share this ID.

For more granular searching than the built-in Event Viewer filtering options allow, we can write a custom filter within the XML tab of the Filter Current Log options. This filter will only display events with the matching Logon ID and clears the 4799 event filter we had before.

[EventData[Data[@Name=‘SubjectLogonId’]=‘0x8de3d’]]

With our custom filter in place, scroll to the bottom of the list (if you’re still in descending order) to find the oldest events. Here, we’ll find a few, non-enumeration (4799) events with the same timestamp.

For one last time, switch to the XML View for any of these events, copy the System Time value, and submit the answer. Now let’s wrap up this investigation!

Conclusion:

Let’s wrap up this investigation of CrownJewel-2 with a quick recap: Using the Windows Event logs, we discovered details about how and when ntdsutil was abused on the domain controller, including the start time, dumped file path, enumerated groups, and Logon ID. This helps us identify the attacker’s activities and create a detailed timeline to document the incident. Great job with the triage!

A big thank you to Hack The Box for the fun and realistic challenge! This is the first series of Sherlocks that I’ve done with the platform, and it was an excellent experience both times. Remember, while this challenge is geared toward beginners, the narrative and triage processes are very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!

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:

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

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

Microsoft Learn — Extensible Storage Engine Managed Reference: https://learn.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine-managed-reference

Microsoft Learn — 4799(S): A security-enabled local group membership was enumerated: [https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page— –2efb81522f2c—

–](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- –2efb81522f2c—

–)

Microsoft Learn — Ntdsutil: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc753343(v=ws.11)

HackTheBox — CrownJewel-1 Sherlock Walkthrough

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

HackTheBox — CrownJewel-1 Sherlock Walkthrough

Investigating a Compromised Domain Controller with Windows Event Logs and MFTECmd

Image Credit: https://app.hackthebox.com/sherlocks/CrownJewel-1/play

Introduction:

Imagine this: You’re on the front lines of an organization’s security team when suddenly, alerts start firing from a domain controller about suspicious use of the V_olume Shadow Copy Service_ and a potential dump of the NTDS.dit database containing the domain’s secrets. You need to dive into the artifacts, investigate the logs, and triage this incident. If this sounds exciting to you, you’ve stumbled on the right blog!

Welcome to my weekly walkthrough! This week, we’re tackling the CrownJewel-1 challenge from Hack The Box! In this digital forensics and incident response (DFIR) challenge, we defenders will explore the NTDS.dit database and how it was accessed via the Volume Shadow Copy Service. Our goal is to uncover critical details such as the start time of the service, the accounts that were enumerated, the process ID of the service, the GUID of the volume, and the path and file sizes of the dumped file on the disk through the Master File Table (MFT). To do this, we’ll leverage the domain controller’s Windows Event logs and Eric Zimmerman’s MFTECmd tool.

While this challenge is geared toward beginners, it’s a fantastic lab to get some hands-on time with MFTECmd and practice log analysis for all skill levels. So, let’s grab our magnifying glasses and get ready to investigate!

And if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback helps me improve and continue supporting your security journey.

Thanks for reading!

Challenge Link: https://app.hackthebox.com/sherlocks/CrownJewel-1

Challenge Scenario:

Forela’s domain controller is under attack. The Domain Administrator account is believed to be compromised, and it is suspected that the threat actor dumped the NTDS.dit database on the DC. We just received an alert of vssadmin being used on the DC, since this is not part of the routine schedule we have good reason to believe that the attacker abused this LOLBIN utility to get the Domain environment’s crown jewel. Perform some analysis on provided artifacts for a quick triage and if possible kick the attacker as early as possible.

Setup the Analysis Environment & Extract the challenge file:

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

Question 1: Attackers can abuse the vssadmin utility to create volume shadow snapshots and then extract sensitive files like NTDS.dit to bypass security mechanisms. Identify the time when the Volume Shadow Copy service entered a running state.

Let’s start the triage process! Personally, I find that it’s always a good practice to familiarize myself of what artifacts are available for analysis. Let’s take a quick look at what we have been provided first:

All right, we have three Windows Event Logs and the $MFT. We’ll go into each one of these in more detail as they come up during the investigation, but this gives us at least some idea of how we’ll investigate this incident.

Next, let’s gain a better understanding of what we are investigating and why. For this, let’s check out the MITRE ATT&CK knowledge base to gather some intelligence about the technique of dumping the NTDS.dit file (T1003.003.)

According to MITRE ATT&CK:

Adversaries may attempt to access or create a copy of the Active Directory domain database in order to steal credential information, as well as obtain other information about domain members such as devices, users, and access rights. By default, the NTDS file (NTDS.dit) is located in %SystemRoot% TDS tds.dit of a domain controller.1(https://en.wikipedia.org/wiki/Active_Directory)

In addition to looking for NTDS files on active Domain Controllers, adversaries may search for backups that contain the same or similar information.2(http://adsecurity.org/?p=1275)

The following tools and techniques can be used to enumerate the NTDS file and the contents of the entire Active Directory hashes.

Volume Shadow Copy

secretsdump.py

Using the in-built Windows tool, ntdsutil.exe

Invoke-NinjaCopy

Well, that’s not good! But now that we have some background, we can start to build a timeline by identifying when the attacker started the Volume Shadow Copy service. To do this, open the SYSTEM.evtx file found in Artifacts folder. The SYSTEM log includes various details, including the start and stop states of services which are logged as Windows Event 7036. If you’re in a Windows environment, this will open with the Windows Event Viewer.

Once the SYSTEM log is opened, we’ll filter it for the relevant events we want by pressing Filter Current Log and entering Event ID 7036 into the field.

With the results now filtered, press Find and enter the keyword “Volume” — this will help us to find the correct Volume Shadow Copy service event.

Finally, let’s check the event Details > XML View > TimeCreated SystemTime to get the exact time the service was started.

If that’s too much reading, here is a GIF of the process to summarize.

Question 2: When a volume shadow snapshot is created, the Volume shadow copy service validates the privileges using the Machine account and enumerates User groups. Find the User groups it enumerates, the Subject Account name, and also identify the Process ID(in decimal) of the Volume shadow copy service process

Okay, to answer Question 2, we’ll pivot over to the SECURITY.evtx log. The key word in the question is “enumerate,” which means we’ll want to filter our log by Event ID 4799 — A security-enabled local group membership was enumerated.

4799(S) A security-enabled local group membership was enumerated. - Windows 10 _Describes security event 4799(S) A security-enabled local group membership was enumerated._learn.microsoft.com

Once we’ve filtered the log, let’s look for events with the same timestamp as the service event that we found in Question 1– 8:42:16 PM.

The first event we find has the Group Name “Administrators,” and moving up to the next event in the list, the Group Name is “Backup Operators”. Both events will have the will the same subject account name, DC01$, the Domain Controller’s machine account.

Now that we’ve uncovered both groups enumerated by the Volume Shadow Copy Service (VSSVC.exe), and which machine account the service ran with, let’s submit the answer and move on to the next question.

Question 3: Identify the Process ID (in Decimal) of the volume shadow copy service process.

Looking at the same event from Question 2, let’s focus on the Process Information section. Here we see the Process ID and the Volume Shadow Copy Service Executable Process Name (VSSVC.exe) that we are looking for.

This gives us half of our answer, but we need to do some extra legwork. The Windows Event log displays Process IDs in hexadecimal, but to answer Question 3 we need the Decimal value. No problem, let’s just use a simple online calculator to convert it:

Hex to Decimal Converter (rapidtables.com)

Question 4: Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted.

Now that we’ve already looked over the SYSTEM.evtx and SECURITY.evtx, let’s move on to the third provided event log from the Artifacts folder, Microsoft-Windows-NTFS.evtx.

This event log holds the operational events of the Windows NTFS file system on the victim’s device. Once we open this log, we’ll continue with our method of looking at the first event following the timestamp of the Volume Shadow Copy service events from the previous questions.

The first event with a timestamp after the VSS service was started contains an interesting reference to VolumeShadowCopy1. Let’s click into the Details tab and gather some additional information:

Inside of the Details view_,_ we can see some additional event data including the VolumeCorrelationId GUID — this GUID is the value we need to answer Question 4!

Question 5: Identify the full path of the dumped NTDS database on disk.

To uncover the answer to Question 5, we’ll need to pivot away from the Windows Event Logs since they won’t have the artifacts that we need.

But remember the fourth piece of evidence we had, the $MFT file_?_ It’s time to use it! But first, let’s gain a foundational understanding of what the MFT is to figure out how it can help us find the path of the dumped NTDS database.

According MITRE ATT&CK:

Every New Technology File System (NTFS) formatted partition contains a Master File Table (MFT) that maintains a record for every file/directory on the partition.

Okay, very interesting! With this background, it seems promising that we could discover the NTDS file path. So how do we find the information then? One option is to use Eric Zimmerman’s MFTECmd to parse the provided MFT file and export the results to a CSV file.

Once the tool is installed in your analysis environment, we can use the below syntax to have MFTECmd to parse the file:

MFTECmd.exe -f “<Path-to-$MFT>” –csv “<Path-to-Output.csv>”

Now that we have the output from the tool, we can use any CSV application to check the results. However, for the purposes of this walkthrough, I recommend using another of Eric Zimmerman’s tools, Timeline Explorer, to easily view, search, and sort the output data. In Timeline Explorer, search for NTDS.dit.

Looking at the timestamps of the returned results, only one matches the time period (Question 1) of the incident and it has the full path of the file in the Parent Path column!

Question 6: When was newly dumped ntds.dit created on disk?

Fortunately, we already found the answer in the previous question. We just need to copy the timestamp from the Created0x10 column:

Question 7: A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes?

Okay, last question! The theory here is that a second file, a registry hive, was dumped at the same time and into the same directory as the NTDS database. So, let’s continue working with Timeline Explorer to see what else we can find within the parsed $MFT file.

To do this, we’re going to filter the results with the same Parent Entry Number as the dumped ntds.dit that we located in Question 5. This should allow us to see other files with the same parent directory or location within the NTFS volume.

On the Parent Entry Number column, you can either click the filter icon and select the corresponding number of the ntds.dit we found, or we can simply type the number into the field. In this example, the Parent Entry Number is 42.

Once we apply the filter, we will see two files: the ntds.dit and the SYSTEM registry hive. To get the file size, we just need to copy the value from the File Size column, and voilà!

Conclusion:

Let’s wrap up this investigation of CrownJewel-1 with a quick recap: Using the Windows Event logs, we determined more details about the abused service, including the start time, process ID, and the mounted volume GUID. Then, with the help of MFTECmd, we identified the file path of the dumped NTDS database and even a second file that the adversary targeted. Great job with the triage!

A big thank you to Hack The Box for the fun and realistic challenge! This was my first lab with this platform and it was an excellent experience. While this challenge is geared toward beginners, the narrative and triage process were very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!

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

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

Tools & References:

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

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

Microsoft Learn — Volume Shadow Copy Service: https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service

Microsoft Learn — Event 4799: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799

Hex Calculator: https://www.rapidtables.com/convert/number/hex-to-decimal.html

MITRE ATT&CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/

Eric Zimmerman’s Tools — MFTECMD: https://github.com/EricZimmerman/MFTECmd

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

HackTheBox on Drew Arpino (Stumblesec)

HackTheBox — Campfire-2 Sherlock Walkthrough

HackTheBox: Campfire-2 Sherlock Walkthrough

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

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

AS-REP Primer:

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

Questions 2, 3, 4:

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

What was the SID of the account?

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

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

Conclusion:

Tools & References:

HackTheBox — Campfire-1 Sherlock Walkthrough

HackTheBox: Campfire-1 Sherlock Walkthrough

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

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Kerberoasting Primer:

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

Questions 2 & 3:

What is the Service Name that was targeted?

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

Questions 4 & 5:

When was this script executed? (UTC)

Questions 6 & 7:

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

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

Conclusion:

Tools & References:

HackTheBox — LogJammer Sherlock Walkthrough

HackTheBox — LogJammer Sherlock Walkthrough

Windows Event Log Forensics: Investigating Persistence, Malware, and Log Tampering with Event Log Explorer & FLARE‑VM.

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: When did the cyberjunkie user first successfully log into his computer? (UTC)

Steps in Event Log Explorer

Questions 2 & 3:

The user tampered with firewall settings on the system. Analyze the firewall event logs to find out the Name of the firewall rule added?

Whats the direction of the firewall rule?

Question 4: The user changed audit policy of the computer. Whats the Subcategory of this changed policy?

Questions 5, 6, & 7:

The user “cyberjunkie” created a scheduled task. Whats the name of this task?

Whats the full path of the file which was scheduled for the task?

What are the arguments of the command?

Questions 8, 9, & 10:

The antivirus running on the system identified a threat and performed actions on it. Which tool was identified as malware by antivirus?

Whats the full path of the malware which raised the alert?

What action was taken by the antivirus?

Question 11: The user used Powershell to execute commands. What command was executed by the user?

Question 12: We suspect the user deleted some event logs. Which Event log file was cleared?

Conclusion:

Quick Reference: Event IDs we covered

Tools & References:

HackTheBox — Meerkat Sherlock Walkthrough

HackTheBox | Meerkat | Sherlock Walkthrough

Network Packet Forensics: Investigating Credential Stuffing and Persistence with Zui, Wireshark & NetworkMiner.

Introduction:

Challenge Scenario:

Setup the Analysis Environment & Extract the Challenge File:

Question 1: We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?

Question 2: We believe the attacker may have used a subset of the brute forcing attack category — what is the name of the attack carried out?

Question 3: Does the vulnerability exploited have a CVE assigned — and if so, which one?

Question 4: Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit?

Question 5: How many combinations of usernames and passwords were used in the credential stuffing attack?

Question 6: Which username and password combination was successful?

Question 7: If any, which text sharing site did the attacker utilise?

Questions 8 & 9

Please provide the filename of the public key used by the attacker to gain persistence on our host.

Question 9: Can you confirm the file modified by the attacker to gain persistence?

Question 10: Can you confirm the MITRE technique ID of this type of persistence mechanism?

Conclusion:

Tools & References:

HackTheBox — Unit42 Sherlock Walkthrough

HackTheBox | Unit42 | Sherlock Walkthrough