Module 7: Introduction to Threat Hunting & Hunting With Elastic

These notes cover the threat hunting fundamentals and threat intelligence theory from the module, then the full Stuxbot investigation lab in Elastic/Kibana - pivoting from one suspicious file across Sysmon, Zeek, and PowerShell logs to a confirmed lateral movement chain.

Back to Module 6: Module 6: Detecting Windows Attacks with Splunk

Module 7 Navigation

Threat Hunting Fundamentals

Threat hunting is an active, human-led, hypothesis-driven practice that systematically combs through network data to identify stealthy, advanced threats that evade existing security solutions. It’s a shift from a reactive posture to a proactive one, with the principal objective of substantially reducing dwell time - the weeks or months an attacker might spend hidden inside a network before detection. By applying cognitive empathy to understand the adversarial mindset, organizations can neutralize threats at the earliest stage of the cyber kill chain.

When to initiate a hunt: Threat hunting is a sustained, continuous operation, meaning the ideal time to hunt is always the present. That said, immediate hunting operations are required during specific events:

• New information regarding an adversary or a system vulnerability comes to light.
• New indicators of compromise are associated with a known adversary.
• Multiple network anomalies are detected concurrently, suggesting an orchestrated attack.
• An incident response activity is actively underway, which requires finding connected hidden threats.

Building the threat hunting team: Constructing a threat hunting team requires a diverse range of skills and perspectives. Key roles include:

• Core threat hunters and intelligence analysts - proactively search for indicators of compromise and gather data to predict future trends.
• Incident responders and forensics experts - manage containment, analyze malware, reverse engineer attacks, and handle recovery actions.
• Data scientists, security engineers, and SOC managers - examine large datasets, design secure infrastructure, and oversee team operations to ensure smooth coordination.

Integration with incident handling: Hunters provide value throughout the various phases of incident handling. During preparation, they help establish operational protocols and clear rules of engagement. During detection and analysis, a hunter’s acumen is indispensable for validating indicators and uncovering additional artifacts missed by automated systems. During post-incident activity, hunters offer expert recommendations to strengthen the overall security posture of the organization.

The critical role of risk assessment: Risk assessment is a key enabler for strategic threat hunting, letting teams prioritize their activities effectively. It systematically identifies the most critical assets of an organization - the “crown jewels.” By highlighting specific system vulnerabilities and the tactics of likely threat actors, risk assessments tell hunters exactly where to focus for maximum impact.

The Threat Hunting Process

This is a proactive, cyclical approach to finding hidden threats within a network, broken into four phases:

1. Preparation and Hypothesis (Setting the Stage & Formulating Hypotheses) - the planning phase. Before hunting, prepare the environment and decide what you’re looking for.

• Preparation: Understand your organization’s critical assets, research current threats and actor TTPs, and ensure your tools are ready - comprehensive logging across systems, with SIEM, EDR, and IDS correctly configured to collect the data you need.
• Hypothesis: Form an “educated guess” to guide the hunt. Not a random search - a testable theory based on threat intelligence, security alerts, or professional intuition. For example: “An APT group is using PowerShell to move laterally from workstation to workstation.” Always formulate hypotheses that are testable.

2. Execution and Analysis (Designing the Hunt & Data Gathering) - the active phase where you test the hypothesis.

• Hunt design: Identify which data sources to analyze (server logs, network traffic, endpoint data), which tools to use, and what specific IoCs or behaviors to search for.
• Data gathering and examination: Collect the required data and search for evidence that either supports or refutes the hypothesis. This phase is often iterative - you might refine the search or the hypothesis as you uncover new information.

3. Evaluation and Response (Evaluating Findings & Mitigating Threats) - once you find something, understand it and act on it.

• Evaluation: Interpret findings to confirm if a threat is real. If so, determine its behavior, which systems are affected, and the potential impact - confirming or disproving the initial hypothesis.
• Mitigation: If confirmed, take action to remove the threat and prevent further damage - isolating compromised machines, removing malware, patching the exploited vulnerability, or blocking malicious IPs at the firewall.

4. Improvement and Refinement (After the Hunt & Continuous Learning) - the hunt isn’t over once the threat is gone.

• Documentation: Document findings, methods, and outcomes. This knowledge updates threat intelligence, improves detection rules in the SIEM, and refines incident response playbooks.
• Continuous learning: Each hunt feeds lessons back into the process, letting the team continuously improve its hypotheses, tools, and techniques to stay ahead of the evolving threat landscape.

Example walked through in the module - Emotet:

• Setting the Stage: Hunters research Emotet’s specific tactics, such as malicious email attachments, and pinpoint vulnerable targets like administrative endpoints and email servers.
• Formulating Hypotheses: The team creates a testable prediction - e.g., that Emotet is distributing malicious Word macros via compromised email accounts.
• Designing the Hunt: Hunters target specific data sources, like email server and network logs, and search for known Emotet indicators such as specific subject lines or C2 server addresses.
• Evaluating Findings: The team confirms the hypothesis, e.g., by identifying active network connections to known Emotet C2 servers, and assesses the total scope of the compromise.
• Mitigating Threats: Responders isolate affected systems, remove the malware via endpoint tools, secure compromised email accounts, and block all C2 network communication.
• After the Hunt and Learning: Hunters document findings, update intelligence platforms with new IoCs, and improve future detection by incorporating machine learning designed to track Emotet’s constantly evolving techniques.

Threat Hunting Glossary

• Adversary: The entity conducting an attack - a cyber criminal, insider threat, or state-sponsored operator. Their goal is to satisfy “collection requirements” like stealing data or financial gain.
• Advanced Persistent Threat (APT): A highly organized and well-funded adversary, typically a nation-state group. “Advanced” refers to strategic planning and operational sophistication. “Persistent” highlights long-term dedication to an objective, not necessarily just technical tooling.
• Threat: Not just an actor - the combination of three critical factors:
  1. Intent: The adversary’s reason for targeting you.
  2. Capability: The resources and skills the adversary possesses to succeed.
  3. Opportunity: The vulnerability or circumstance that allows the adversary to act.

Describing attacker operations:

• Tactics, Techniques, and Procedures (TTPs): The “signature” or operational pattern of an adversary.
  • Tactics: The high-level strategic goal (the “why,” e.g., Initial Access).
  • Techniques: The general method used to achieve the tactic (the “how,” e.g., Spearphishing).
  • Procedures: The granular, step-by-step implementation of a technique (the “recipe,” e.g., a specific email template paired with a specific malware loader).
• Campaign: A collection of related intrusion incidents linked by common TTPs, infrastructure, or objectives. Analyzing campaigns helps identify a single threat actor’s broader activities.

The evidence of an attack:

• Indicator vs. IOC: Related but distinct terms.
  • An Indicator is raw data plus context. A lone IP address is just data. That same IP being a known C2 server is an indicator.
  • Indicators of Compromise (IOCs) are the concrete, forensic artifacts of an intrusion - the “signposts” like file hashes, malicious domains, IP addresses, or registry keys that confirm a compromise.

Analytical frameworks for threat intelligence:

• Pyramid of Pain: Illustrates the trade-off between the difficulty of detecting an indicator and the “pain” it causes the adversary when blocked.
  • Bottom (low pain): Blocking Hash Values or IP Addresses is easy for defenders, but trivial for attackers to change and bypass.
  • Top (high pain): Detecting and blocking an adversary’s TTPs is difficult, but forces them to change their core behavior - a significant operational cost. The goal of a mature defense is to operate at the top of the pyramid.

  The indicators that are easiest for defenders to find are also the easiest for the attacker to change. The indicators that are hardest to find are the most “painful” and difficult for the attacker to change.

• Diamond Model of Intrusion Analysis: A holistic view of an intrusion event connecting four vertices:
  1. Adversary: Who did it.
  2. Capability: What they used (tools, TTPs).
  3. Infrastructure: The resources they leveraged (servers, domains).
  4. Victim: Who/what they targeted.

  This model helps analysts understand the relationships between these elements to better track and predict adversary activity.

My take on this: I think the Pyramid of Pain is still relevant, but its real value now depends on context. Basic IOCs like hashes, IPs, and domains are useful, but attackers can change them quickly. Stronger detection comes from understanding tools, behaviors, and TTPs.

Modern SOC teams can’t just chase every alert. They need context from SIEM, SOAR, asset criticality, vulnerabilities, and business risk to understand what actually matters. For example, a malware hash on a test VM may be low priority, but the same hash on a production finance server should be treated as far more serious.

In simple terms, good detection isn’t just finding bad activity - it’s finding the bad activity that matters most, on the systems that matter most, fast enough to stop the attacker. The shift is from IOC-based alert chasing to context-aware adversary disruption.

Threat Intelligence

The core of Cyber Threat Intelligence (CTI): CTI aims to move an organization’s defense from a reactive posture to a proactive, anticipatory strategy. To be truly valuable and avoid “alert fatigue” or wasted resources, intelligence must strictly adhere to four principles: Relevant to your specific environment, Timely to allow swift mitigation, Actionable with clear defensive direction, and Accurate so resources aren’t wasted on false leads.

Threat Intelligence vs. Threat Hunting: Closely connected, but distinct functions that create a feedback loop.

• Threat Intelligence is predictive: It anticipates the adversary’s next moves, targeting the Where, When, How, and Why of potential attacks before they happen.
• Threat Hunting is active: It uses intelligence to actively search the network to verify whether an adversary has already breached defenses and evaded automated detection. Findings from hunts feed back to improve future intelligence.

The three tiers of intelligence:

• Strategic Intelligence: For executive leadership, to align security with business risk. Outlines long-term adversary campaigns and motivations - the Who? and Why?.
• Operational Intelligence: For mid-level management. Details specific adversary campaigns - their access methods and lateral movement - answering How? and Where?.
• Tactical Intelligence: For network defenders and SOC analysts. Immediate, actionable technical details - specific IPs, file hashes, or domains (IOCs) - used to stop immediate threats.

Actioning a tactical threat report: When defenders receive a tactical report (e.g., an alert on an Emotet campaign), they follow a structured methodology to maximize its value:

1. Comprehend & Classify: Understand the attacker’s broader narrative and classify the provided IOCs into categories (Network, Host, Email).
2. Map the Lifecycle: Track the attacker’s TTPs against frameworks like MITRE ATT&CK to anticipate their next moves.
3. Validate: Cross-reference IOCs with external databases to ensure accuracy and filter out outdated indicators or false positives.
4. Integrate: Update security infrastructure (firewalls, EDR, IPS) with validated IOCs while ensuring business operations aren’t disrupted.
5. Hunt & Monitor: Proactively hunt through network logs for both the specific IOCs and broader behavioral patterns (TTPs). Continually monitor, refine defenses, and share new findings back with the security community.

Hunting Stuxbot: A Live Investigation

The lab scenario: hunt for an actor codenamed Stuxbot inside an Elastic/Kibana environment, starting from one suspicious file and pivoting outward through Sysmon, Zeek, and PowerShell logs until the full lateral movement chain is confirmed.

1. Confirming the initial download

Started from this query for the hunt:

event.code:15 AND file.name:*invoice.one

This gives the basic suspicion, but it isn’t confirmed yet, so the next step is identifying the time to look (Pivot 1): Mar 26, 2023 @ 16:05:47.791.

Extending to process.name and file.path shows the file was downloaded via msedge, with the file path in the Downloads folder of an employee named Bob.

2. Corroborating with Sysmon Event ID 11

Now checking Event ID 11 (file create) as a download indicator when no browser is involved:

event.code:11 AND file.name:invoice.one*

Event ID 11 logs any file creation. By finding the same file creation event in both log types, the analyst proves with much higher confidence that the download occurred. The Zone.Identifier tag found in the Event ID 11 log is extra proof, since Windows adds this to files downloaded from the internet.

The source IP is visible in the same event:

3. Closing the Sysmon visibility gap

The next step should be agent.hostname, then ideally a Sysmon Event ID 3 to confirm the network connection - but there’s a problem: host WS001 with IP 192.168.28.130.

1. The core problem - a data gap: As the module notes, it’s common practice to configure Sysmon to ignore network connections from web browsers (Edge, Chrome, etc.) to reduce log noise, since browsers make thousands of connections that would otherwise flood the SIEM.
2. Find the event: A Sysmon Event ID 11 log shows the file invoice.one was created.
3. Identify the host: The host.hostname field in that log identifies the computer as WS001.
4. Pivot to find the IP: Searching for a network event (Sysmon Event ID 3) from WS001 should reveal its source.ip, 192.168.28.130 - except Sysmon was told to ignore exactly this kind of browser traffic.

• What Zeek provides: Even though Sysmon was told to ignore the browser’s network activity, Zeek saw it all. Switching to the zeek* index in Kibana opens up the network data Sysmon dropped.
• The new strategy: Instead of looking for a direct connection, search Zeek’s logs for DNS queries from the compromised host’s IP (192.168.28.130) around the time of the download.

In short, Zeek matters here because it contained the critical network information that was intentionally filtered out of the Sysmon logs - it filled the visibility gap and let the investigation continue.

4. Pivoting to Zeek DNS logs

Pivot is the IP and the time range - the question is where the file actually came from:

source.ip:192.168.28.130 AND dns.question.name:*

This shows the user’s machine looked up the domain file.io, a file-hosting service, right before the download occurred - alongside Google Mail access and a Microsoft Defender SmartScreen file scan, which typically triggers when a file is downloaded via Edge.

5. Resolving the file.io hosting IP

Extending the fields to dns.answers.data gives the IP of where the file was actually hosted via file.io:

34.197.10.85, 3.213.216.16

6. Confirming the download connection

Pivot here is the hosting IP - checking for any connections to it in the same time frame:

This corroborates that the user, Bob, successfully downloaded the file invoice.one from the hosting provider file.io.

7. OneNote spawning a batch script

Going the IR route: if invoice.one was opened, OneNote must have opened too - so before drafting the next query, the hypothesis is that OneNote was involved shortly after the download:

event.code:1 AND process.command_line:*invoice.one*

This confirms OneNote was accessed roughly six seconds after the download (Mar 26, 2023 @ 16:05:53.601). Since OneNote is now in play, the next pivot is OneNote.exe itself, to see if anything was attached:

event.code:1 AND process.parent.name:"ONENOTE.EXE"

This establishes a connection between OneNote.exe, the suspicious invoice.one, and the execution of cmd.exe, which initiates invoice.bat from a temporary location - highly likely because the batch file was attached inside the OneNote file itself. Relevant events sit between Mar 26, 2023 @ 16:05:00.000 and 16:10:00.000, events outside that window can be ignored.

8. invoice.bat staging C2

The question now: has this batch script triggered anything else? Pivot is invoice.bat:

event.code:1 AND process.parent.command_line:*invoice.bat*

This looks similar to a threat intel report seen earlier - with process.name, process.args, and process.pid as columns, a closer look shows a PowerShell script pulled from Pastebin. Assuming process.pid is the pivot here, this is very rich information:

PowerShell first staged files in Bob’s Temp folder at 16:06, contacted Pastebin, then resolved and connected to an ngrok address that may represent C2. Around 16:17, PowerShell dropped default.exe and modified the registry, suggesting possible persistence. Later, at 23:23, it dropped DomainPasswordSpray.ps1, followed by internal activity toward 192.168.28.200 and DC1.eagle.local.

9. Confirming C2 persistence

18.158.249.75 as a potential C2 - checking where it goes. Interestingly, activity extended over a period of two days:

Checking for any ngrok traffic around the same timeline to confirm whether the connection continued:

The fact that the C2 IP address changed shows it’s a resilient setup that can’t be stopped by simple blocking rules - the connection likely continued until March 29th. Searching the new IP confirms activity continued after the C2 change:

10. Pivoting on default.exe

Pivoting to Windows logs for the executable found earlier, to see what it does:

process.name:"default.exe"

This shows SharpHound was also executed:

11. The hash pivot to PKI

Pulling the field process.hash.sha256:

Checking that hash elsewhere:

process.hash.sha256:018d37cbd3878258c29db3bc3f2988b6ae688843801b9abc28e6151141ab66d4

The same malicious file hash was found on both WS001 and PKI, which suggests the attacker moved beyond the initial workstation and also compromised the PKI server. A backdoor file was found under the svc-sql1 user profile, indicating that this service account may also be compromised. On PKI, the first execution of default.exe was launched by PSEXESVC, tied to Sysinternals PSExec - strongly suggesting PSExec was used for remote execution and lateral movement within the Active Directory environment.

12. Password spray attempts from WS001

Open question: how was svc-sql1 compromised in the first place? Possibly the earlier PowerShell activity included a brute-force/spray attempt. Since DomainPasswordSpray.ps1 was uploaded on WS001, the next check is any successful or failed password attempts from that machine, excluding Bob (the machine’s own user):

There’s also an attempt made against the Administrator account.

13. The VBS file on PKI

Module knowledge check: in the part where default.exe is under investigation on PKI, a VBS file is mentioned.

process.name:"default.exe"

Filtering file.path under the relevant timestamp:

14. Mimikatz DCSync

Module knowledge check: Stuxbot uploaded and executed Mimikatz - what were the process arguments?

process.name:"mimikatz.exe"

Reading process.args:

15. PowerView share enumeration

Module knowledge check: some PowerShell code was loaded into memory that scans/targets network shares - identify the tool it derives from.

First query:

event.code:4104 AND (*share* OR *shares* OR *smb* OR *admin$* OR *c$*)

Then filtering on powershell.file.script_block_text:

Invoke-ShareFinder is a PowerView cmdlet - the answer is PowerView.

Skill Assessment

Three graded hunts, building each KQL query from scratch off the Stuxbot scenario above.

Hunt 1 - hunt for Lateral Tool Transfer to C:\Users\Public. Enter the user.name field for the transferred tool that starts with “r”.

event.code:11 AND file.path:*\\Users\\Public\\*

This was the right starting query because Event ID 11 = Sysmon FileCreate, and C:\Users\Public is a classic suspicious staging location. It showed multiple tools staged there, including Rubeus.exe at C:\Users\Public\Rubeus.exe, with user.name = svc-sql1, host.name = PKI.eagle.local, process.name = svchost.exe. Since the question asked for the tool starting with “r,” the relevant file is Rubeus.exe.

From there, the pivot is confirming how this was lateral, not just local file creation:

Pivot 1 - confirm remote logon to PKI before the tool staging:

host.name:"PKI.eagle.local" AND event.code:4624 AND user.name:"svc-sql1"

This shows 192.168.28.130 logged into PKI.eagle.local as svc-sql1 with LogonType = 3 - so svc-sql1 was used remotely against PKI.

Pivot 2 - confirm remote execution context around that login:

host.name:"PKI.eagle.local" AND @timestamp >= "2023-03-27T18:37:30" AND @timestamp <= "2023-03-27T18:38:10"

This shows PSEXESVC.exe started on PKI as SYSTEM, with Event 4624 logons for svc-sql1, Event 4648 explicit-credential activity, and default.exe executed as svc-sql1.

So the realistic chain is: 192.168.28.130 authenticated to PKI as svc-sql1 → PSEXESVC.exe appeared on PKI, showing remote execution context → default.exe executed on PKI → Rubeus.exe was later created in C:\Users\Public on PKI.

Hunt 1 answer: svc-sql1

Hunt 2 - hunt for Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder. Enter the registry.value field for the first registry-based persistence action.

First pass:

event.code:13 AND registry.path:*\\CurrentVersion\\Run*

Reducing the noise:

event.code:13 AND registry.path:*\\CurrentVersion\\Run*
AND NOT registry.value:"MicrosoftEdgeAutoLaunch_4ED9772FE1E7553A8F858520D6E0108B"
AND NOT registry.value:"Application Restart #0"
AND NOT registry.value:"Application Restart #1"

The first remaining hit is the PowerShell-set registry run key:

Hunt 3 - hunt for PowerShell Remoting for Lateral Movement. Enter the winlog.user.name field for the document related to PowerShell remoting-based lateral movement toward DC1.

Network telemetry showed PowerShell-related activity from PKI.eagle.local toward another internal host, suggesting possible WinRM/PowerShell Remoting - but that didn’t directly answer the question, since it specifically asked for winlog.user.name. The hint pointed to Event ID 4104 (powershell.file.script_block_text), since that event records the actual PowerShell code executed. Pivoting from network telemetry to PowerShell script block logs:

event.code:4104 AND powershell.file.script_block_text:*PSSession* AND powershell.file.script_block_text:*dc1*

This returns the key event:

Mar 27, 2023 @ 19:17:08.058 - host.name = PKI.eagle.local, winlog.user.name = svc-sql1, powershell.file.script_block_text = Enter-PSSession dc1.

Event 4104 shows the executed PowerShell code. Enter-PSSession dc1 confirms PowerShell Remoting toward DC1, and winlog.user.name on that document is svc-sql1.

Hunt 3 answer: svc-sql1

Key Takeaway

Most of this hunt was just pivoting from one log source to the next when the current one ran out of answers.

What stuck with me:

• Sysmon was configured to ignore browser network traffic to cut noise, so the network evidence was sitting in Zeek instead. Worth knowing what your endpoint logging isn’t showing you before assuming a gap means nothing happened.
• Each pivot carried one anchor forward - a timestamp, an IP, a hash, a process name - into the next query, instead of starting over.
• The hash match across WS001 and PKI was the clearest signal in the chain, since it showed lateral movement directly instead of just suggesting it.
• The C2 IP changed over a couple of days, so blocking one address wouldn’t have held - the ngrok tunneling behavior was the more durable thing to flag.
• The TTPs (PSExec, DCSync, PowerView enumeration) ended up telling more of the story than the individual IOCs did.

References

[HTB Academy] Certified Defensive Security Analyst (CDSA) - Module 7: Introduction to Threat Hunting & Hunting With Elastic. https://academy.hackthebox.com/