CH4: Threat Intelligence and Threat Hunting

Introduction

Defending a network is easier when you know who the attackers are, how they operate, and what they are targeting. This is the domain of threat intelligence: the collection, analysis, and application of information about current and emerging threats.

Threat intelligence serves two distinct purposes. First, it informs defense. If you know that a particular threat actor is targeting companies in the financial sector with a specific phishing technique, you can adjust your email filters and user training. Second, it enables active defense: threat hunting. Instead of waiting for automated alerts to fire, threat hunters proactively search the network for indicators that an attacker is present.

This chapter covers the landscape of threat actors, the frameworks and methodologies that help us understand their tactics and techniques, the sources and types of threat intelligence, and the active techniques used to search for attackers. For a SOC analyst, threat intelligence is a lens through which to view every security event. It answers the question: Is this activity consistent with a known threat actor's behavior, or is it something new?

Learning Objectives

By the end of this chapter, you will be able to:

Distinguish between different types of threat actors (nation-states, advanced persistent threats, insiders, cybercriminals) and analyze their typical motivations and capabilities.
Explain the Pyramid of Pain and how different types of indicators provide different levels of difficulty for attackers to evade.
Navigate and apply the MITRE ATT&CK framework to map observed adversary behavior to tactics, techniques, and procedures (TTPs).
Evaluate threat intelligence sources by assessing timeliness, relevance, and accuracy, and explain how these qualities affect decision-making.
Collect, analyze, and apply indicators of compromise (IoCs) including atomic and behavioral indicators.
Design threat-hunting strategies using threat modeling (STRIDE) and conduct manual hunts for evidence of compromise.

4.1 Threat Actors: Understanding the Adversary

Security defense is adversarial. The goal is to be more difficult to exploit than the attacker's next target, rather than to prevent all malicious activity universally. Understanding who is attacking, why, and what capabilities they have is essential to prioritizing defenses.

Nation-State and Advanced Persistent Threats (APTs)

A nation-state actor is a group sponsored by or operating on behalf of a government. Their motivations include espionage (stealing intellectual property or military secrets), disruption (interfering with an adversary's infrastructure), and sometimes profit (less common for state actors, who have funding from their government).

Nation-state actors have enormous resources: large teams, zero-day exploits (previously unknown vulnerabilities they keep secret), advanced malware, and the ability to sustain operations over years. They are patient. If stealing a secret takes three years of steady work, a nation-state actor will invest that time.

Advanced Persistent Threats (APTs) is the term used to describe these sophisticated, long-running campaigns. An APT is characterized by:

Advanced. Sophisticated techniques, custom malware, and exploits not publicly known.
Persistent. Attacks are sustained over months or years, even if one intrusion is discovered and shut down.
Threat. Clear intent to cause harm.

APTs are typically named by researchers: APT29 (attributed to Russia's SVR), APT28 (Russia's GRU), APT1 (China's PLA Unit 61398), APT41 (China, operates for profit), and many others. Attribution, determining which nation or group is responsible, is difficult and incomplete. However, analysts look for patterns: malware source code language, operational patterns, target selection, and tools used.

Case Study: APT29 and the SolarWinds Campaign (2020)

In 2020, a group attributed to Russia's Foreign Intelligence Service (SVR), known as APT29 or Cozy Bear, conducted one of the most significant breaches in U.S. history.

Attack vector:

APT29 compromised SolarWinds, a software company that produces Orion, a network and IT operations management platform used by thousands of organizations, including U.S. federal agencies.
The attackers injected malicious code into a legitimate software update. When organizations updated Orion, they installed a backdoor called SUNBURST.
SUNBURST did several things: it waited for 2 weeks before activating (to evade initial detection), it looked for signs it was in a security research environment, and if it seemed safe, it opened a communication channel to attacker-controlled servers.
Once a foothold was established, APT29 deployed additional tools: TEARDROP (another backdoor), Mimikatz (a credential-dumping tool), and custom malware.
They spent months moving laterally through networks, identifying high-value targets, and exfiltrating data.

Figure 4.1: A compromised vendor update distributes malicious code to customer environments. Attackers may select a subset of recipients for follow-on intrusion.

Text description for Figure 4.1

The software vendor produces an update. Malicious code is inserted into that update before distribution. Multiple customer environments receive the compromised package. Follow-on intrusion is shown as a selected subsequent action, rather than an outcome established for every recipient. This is a simplified mechanism diagram for the SolarWinds case study.

Scope of impact:

At least 18,000 SolarWinds customers were exposed to SUNBURST.
U.S. federal agencies, including the Treasury Department and the Cybersecurity and Infrastructure Security Agency (CISA), were compromised.
The exact amount of data stolen remains classified, but it was substantial.

Why this attack was significant:

Supply chain compromise. The attackers did not break into target networks directly; they compromised a trusted software vendor. This is a class of attack that is very difficult to defend against.
Nation-state sophistication. The malware was designed to avoid detection. It included anti-forensics techniques and checked for security tools before executing.
Long dwell time. Some attackers remained undetected for months after the initial compromise, allowing extensive data theft.

Detection and response:

FireEye, a major cybersecurity company, detected the breach internally while investigating unusual network traffic.
CISA and Microsoft collaborated on the response, and technical details were shared publicly to help other victims.
U.S. government issued a statement attributing the attack to the SVR.

Lessons for SOC analysts:

Trust is fragile. A trusted vendor can be a vehicle for attack. Monitor software updates, and scrutinize unusual behavior even in legitimate software.
Long dwell time requires forensics. Detecting an intrusion quickly is difficult. Once detected, extensive forensic analysis is needed to understand what was stolen and how long attackers were present.
Attribution is based on patterns, not certainty. The U.S. government attributed the attack to the SVR based on malware analysis, observed TTPs, target selection, and intelligence. Attribution is useful but not 100% certain.

Insider Threats

Not all threats come from outside the organization. Insider threats are current or former employees, contractors, or partners who have legitimate access to systems and abuse it.

Types of insider threats:

Malicious insiders. An employee steals customer data to sell to competitors, or a disgruntled employee sabotages systems before resigning.

Negligent insiders. An employee misconfigures a database, leaving it publicly accessible. Not intentional, but the result is the same: unauthorized access.

Compromised insiders. An employee's credentials or device are compromised by an external attacker. The insider is unwitting.

Figure 4.2: Insider-related risk can arise from intentional misuse, accidental exposure, or external misuse of a compromised account.

Text description for Figure 4.2

The malicious-insider scene depicts deliberate use of organizational information outside its intended purpose. The negligent-insider scene depicts an exposure caused by a sharing setting. The compromised-account scene depicts external misuse of legitimate access.

Insider threats are particularly dangerous because they have legitimate access; they don't need to bypass firewalls or exploit vulnerabilities. They can be detected through:

Unusual access patterns. An HR employee suddenly accessing the billing database.
Data exfiltration. A user downloading large amounts of data to a USB drive or uploading to a personal cloud account.
Timing anomalies. An employee accessing systems at 3 AM when they normally work 9-to-5.
Post-employment access. A former employee's account is still active and being used.

Cybercriminals and Ransomware Gangs

Cybercriminals are threat actors motivated by profit. They operate criminal enterprises: selling stolen data, conducting ransomware campaigns, phishing for credentials, and distributing malware.

Unlike nation-states, cybercriminals are not patient. They want to maximize profit quickly. This means their attacks are often less sophisticated but more widespread. A ransomware gang might compromise thousands of small businesses, demand relatively small ransoms ($50,000-$500,000), and move on.

Ransomware gangs often operate as businesses:

They develop ransomware tools.
They advertise on dark web forums.
They manage customer (victim) communications.
They operate "support channels" to help victims pay.
They sometimes publicly shame organizations that don't pay, damaging reputation.

Examples include REvil, Conti, and LockBit.

Figure 4.3: Common threat-actor patterns compare motivations and access. Individual actors may overlap these categories.

Text description for Figure 4.3

Government-sponsored actors commonly pursue espionage or disruption and may gain access through intrusion. Profit-driven criminals commonly pursue theft or extortion and may gain or purchase access. Insider-related threats involve misuse, error, or account compromise involving existing legitimate access. These are illustrative patterns rather than exhaustive categories or fixed capability rankings.

4.2 Tactics, Techniques, and Procedures (TTPs)

Tactics are the high-level objectives an attacker is trying to achieve: gaining initial access, moving laterally, stealing data, or disrupting services.

Techniques are the methods used to accomplish those tactics: spear-phishing (technique) to gain initial access (tactic), or credential dumping (technique) to extract passwords (tactic).

Procedures are specific implementations of a technique. For example, the technique is "credential dumping from the Windows Security Account Manager database," and the procedure is "execute the following Mimikatz command: sekurlsa::logonpasswords".

Understanding an attacker's TTPs is valuable because:

Prediction. If you know an attacker's typical patterns, you can anticipate their next moves and prepare defenses.
Detection. If you know an attacker uses specific tools or techniques, you can write detection rules for them.
Comparison. If you observe a technique used in your environment, you can compare it to known threat actors to identify who might be attacking.

The Pyramid of Pain

The Pyramid of Pain, developed by security researcher David Bianco, illustrates the difficulty an attacker faces when forced to adapt to a defense.

At the base of the pyramid are Hash values (file hashes, MD5, SHA-1). These are trivial for attackers to evade; they just recompile malware slightly and the hash changes. Detecting based on file hashes alone is very easy for attackers to bypass.

Moving up the pyramid:

IP addresses and domain names are harder to change but still relatively easy. An attacker can rent a new server or use a different domain.

Network and host artifacts (registry keys, file paths, process names, command-line arguments) are harder to change because they're part of the attacker's tool design. A malware family might always create a file in C:\ProgramData\ and a registry key called Software\Microsoft\Windows\CurrentVersion\Run. Changing these requires tool modification.

Tools and malware families are even harder to change. If an attacker uses Mimikatz for credential theft, switching to a different tool means learning and deploying new software, and it might not work as well.

Tactics, Techniques, and Procedures (TTPs) are at the top of the pyramid. These are the most difficult to change. An attacker's fundamental approach, how they do reconnaissance, move laterally, escalate privileges, is shaped by their skills, philosophy, and resources. Changing TTPs requires fundamental changes to operations.

Figure 4.4: The Pyramid of Pain compares the effort attackers face when defenders detect and deny different aspects of their activity.

Text description for Figure 4.4

From bottom to top, the levels are hash values; IP addresses; domain names; network and host artifacts; tools; and tactics, techniques, and procedures. The upward direction represents generally increasing adaptation effort when defenders make those indicators or behaviors unusable. The diagram does not assign a measured numeric cost or guarantee that any level is impossible to evade.

For a SOC analyst, the implication is clear: detection rules based on TTPs are most resilient to evasion. A rule that says "if a user executes PowerShell with obfuscated arguments and then calls Add-Type to load a .NET assembly, alert" is harder for an attacker to bypass than "if the file hash matches X, alert."

MITRE ATT&CK Framework

The MITRE ATT&CK framework is a comprehensive, curated database of tactics, techniques, and sub-techniques observed in real-world attacks. It's maintained by MITRE, a federally funded research center, and is freely available.

The framework is organized hierarchically:

Tactics (the "why"): What is the attacker trying to accomplish?

Reconnaissance
Resource Development
Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Command and Control
Exfiltration
Impact

Techniques (the "how"): The methods used under each tactic. For example, under "Initial Access," techniques include Phishing, Supply Chain Compromise, and Exploit Public-Facing Applications.

Sub-techniques: Refinements of techniques. Phishing has sub-techniques like Spearphishing via Email, Spearphishing via Service, and Phishing: Malicious Link.

For each technique, the framework documents:

A description and how it works.
Real-world examples of APTs that use it.
Detection opportunities: What can defenders look for?
Mitigations: How can organizations defend against it?

Example: The technique T1566.001 - Phishing: Spearphishing via Email describes spear-phishing attacks where attackers send emails tailored to individuals. It lists examples like APT1, Lazarus Group, and APT29. It notes detection opportunities like monitoring for emails with suspicious attachments or links, and mitigations like security awareness training and email filtering.

Figure 4.5: An attacker objective can be described through increasingly specific methods and an illustrative procedure.

Text description for Figure 4.5

Initial Access identifies the objective. Phishing identifies a technique for pursuing that objective. Spearphishing Attachment, T1566.001, identifies a more specific method. The procedure example illustrates delivery of a targeted email with a malicious attachment. The brackets express classification and specificity, not a chronological attack lifecycle.

ATT&CK Heatmaps for Detection Engineering

ATT&CK can also be used to build a heatmap that shows which adversary behaviors an organization can currently detect. Analysts map observed techniques or techniques relevant to a threat model against existing data sources, analytics, and response actions. Each cell can be color-coded to show coverage, such as strong detection, partial detection, planned detection, or a visibility gap.

The heatmap makes detection gaps easier to prioritize. A technique with high relevance but no reliable telemetry becomes a candidate for improved logging or sensor coverage. A technique with telemetry but no analytic becomes a candidate for a new detection rule or hunt. Teams can also record detection quality, test results, and false-positive rates in the matrix, then revisit it as controls and attacker behavior change. This turns the ATT&CK framework from a reference catalog into a coverage model that guides practical detection engineering.

Figure 4.6: An illustrative MITRE ATT&CK heatmap maps selected techniques to detection coverage. These fictional ratings show how a team can distinguish existing coverage, planned detections, and visibility gaps.

Text description for Figure 4.6

Four tactic columns each contain two techniques. Each cell states its coverage status in words. Dark navy indicates strong detection, pale blue indicates partial detection, dashed borders indicate planned detection, and white cells with solid borders indicate a visibility gap.

Initial Access: Phishing (T1566), strong detection; Exploit Public-Facing Application (T1190), partial detection.
Execution: Command and Scripting Interpreter (T1059), partial detection; User Execution (T1204), planned detection.
Credential Access: OS Credential Dumping (T1003), strong detection; Brute Force (T1110), visibility gap. OS means operating system.
Lateral Movement: Remote Services (T1021), planned detection; Exploitation of Remote Services (T1210), visibility gap.

Strong detection represents tested coverage within a defined scope; partial detection covers some behavior; planned detection awaits implementation or validation; a visibility gap lacks reliable supporting data. These categories do not guarantee detection of every implementation of a technique. The figure shows a selected portion of the matrix.

Technique names and identifiers follow MITRE ATT&CK. The ATT&CK Navigator documentation describes user-defined scoring and coloring.

Attribution: Assigning Threat Actors to Campaigns

Attribution is the process of determining who is responsible for a cyberattack. It is inherently uncertain and often incomplete. A fully confident attribution requires multiple pieces of corroborating evidence.

Figure 4.7: Attribution assesses who may be responsible by comparing multiple kinds of evidence.

Text description for Figure 4.7

Four evidence groups point toward a central assessment: malware analysis, infrastructure, observed behavior, and timing and targeting. A question mark represents uncertainty. Confidence depends on corroboration, meaning support from multiple pieces of evidence; one matching artifact does not establish responsibility.

Evidence used for attribution:

Malware and tool analysis. The malware's code, algorithms, and behavior offer clues. Does it use Russian variable names? Does it access the Windows registry in a way typical of Kazakh developers? These linguistic and technical clues can point to a threat actor's origin.

Infrastructure. What servers, domains, and IP addresses did the attacker use? Who registered the domains? What infrastructure does this threat actor typically use? Infrastructure can be reused, shared, or rented, so it is one part of the picture rather than definitive on its own.

Tactics and techniques. Does the attack use tools and techniques known to be favored by a particular group? If APT28 is known for using a specific type of C2 (command and control) server, and the same pattern appears in a new attack, it suggests APT28's involvement.

Timing and targeting. What time of day did the attack occur? What organizations were targeted? Does the targeting align with geopolitical interests or capabilities of known threat actors?

Cryptographic artifacts. Code comments, error messages, or metadata embedded in malware can reveal the developer's language or origin.

Intelligence. Law enforcement, government agencies, and private intelligence firms sometimes have informants or signals intelligence that directly identify attackers.

Critical Distinction

Attribution is a matter of confidence rather than certainty. When CISA says, "We assess with high confidence that APT29 conducted the SolarWinds attack," it means the evidence strongly supports this conclusion, but it does not rule out other possibilities. Analysts must be comfortable with uncertainty and adjust confidence levels as evidence accumulates or changes.

Analyst Perspective

A SOC analyst rarely conducts attribution themselves. That is typically handled by a threat intelligence team or external firms. However, understanding how attribution works helps analysts evaluate threat intelligence reports. If a vendor says, "This attack is from APT X," ask what evidence supports that conclusion. Is it based on malware analysis, infrastructure, timing, or intelligence? Does the evidence seem strong or circumstantial? What is the confidence level?

4.3 Threat Intelligence: Sources, Collection, and Evaluation

Threat intelligence does not exist in a vacuum. It is collected from many sources, analyzed, and evaluated before being applied to defenses.

Sources of Threat Intelligence

Open-Source Intelligence (OSINT). Publicly available information: news reports, security blogs, academic papers, CVE databases, GitHub repositories, social media. A researcher discovers a vulnerability in a routers' web interface, documents it on a security blog, and posts code to GitHub. That's OSINT.

Closed-Source Intelligence. Intelligence not publicly available: commercial threat intelligence vendors (Recorded Future, CrowdStrike, Mandiant), law enforcement tips, information shared under NDA by other organizations.

Proprietary Research. An organization's own intelligence, derived from analyzing attacks against itself or from running threat intelligence operations (like running honeypots).

Information Sharing. Government and industry groups share threat intelligence. In the U.S., ISACs (Information Sharing and Analysis Centers) exist for different sectors (Financial Services, Healthcare, Energy). CISA publishes alerts on confirmed threats. MISP (Malware Information Sharing Platform) allows organizations to share IoCs.

Figure 4.8: Public research, restricted reports, internal observations, and sharing communities contribute information for analysis.

Text description for Figure 4.8

Four equally weighted sources feed analysis: publicly available research, reports with restricted access, observations collected within the organization, and communities that exchange threat information. The connections represent inputs to analysis. They do not imply that a source is automatically reliable or that each source contributes equal amounts of evidence.

Indicators of Compromise (IoCs)

An Indicator of Compromise (IoC) is an observable piece of data that suggests a system has been compromised by a specific attacker.

Atomic indicators are indivisible, standalone artifacts:

File hash (MD5, SHA-1, SHA-256). The hash of a malware executable. If a system has a file with that hash, it has the malware.
IP address. An attacker-controlled server's IP. If systems are connecting to it, they might be compromised.
Domain name. A command-and-control (C2) server's domain. If a process is resolving this domain, the system might be infected.
Email address. An attacker's email used in phishing. If a user received an email from this address, they were targeted.
URL. A specific malicious link. If a user clicked it, their system was exposed.

Behavioral indicators describe patterns of activity:

A process launching another process with obfuscated command-line arguments, followed by a network connection to an external IP. This pattern might indicate malware execution and C2 communication.
A user account accessing files outside their normal job function, followed by copying data to a USB drive. This might indicate data theft.
Multiple failed login attempts from a single IP, followed by a successful login with a different IP. This might indicate a credential-stuffing attack followed by successful compromise.

Behavioral indicators are more resilient to evasion because they capture the attacker's objective rather than specific artifacts. If an attacker modifies malware code, the file hash changes, but the behavioral pattern remains similar.

Figure 4.9: Atomic indicators identify individual artifacts. Behavioral indicators describe related activity across events.

Text description for Figure 4.9

The upper examples illustrate individual artifacts. MD5 (Message Digest 5) is the hash algorithm shown, using the calculated hash of a file containing hello with no newline. The IP address and domain illustrate address formats. The lower row links process creation, obfuscated command inputs, and external communication as an activity pattern for investigation.

Confidence Levels and Evaluation

Threat intelligence is only useful if it is timely, relevant, and accurate.

Timeliness. Is the intelligence current? Intelligence about a vulnerability that was patched 6 months ago is less useful than intelligence about an active campaign. However, historical intelligence is valuable for understanding attacker patterns.

Relevance. Does the intelligence apply to your organization? Intelligence about attacks on transportation systems is less relevant to a healthcare provider. Intelligence about attacks on your industry and organization size is highly relevant.

Accuracy. How confident is the source? A government agency's attribution is typically high confidence. A random blog post might be speculation. Evaluate the source's track record and methodology.

When evaluating a threat intelligence report, consider:

What is the source?
What evidence supports the conclusions?
Are there alternative explanations?
What is the time window? (Is this current or historical?)
What is the specific scope? (Which organizations or industries are targeted?)
What recommendations does the source provide?

Figure 4.10: Evaluate intelligence for timeliness, relevance to the organization, and evidential support.

Text description for Figure 4.10

A clock and calendar represent timeliness. An organization and target represent relevance. Evidence documents and a magnifying glass represent accuracy. The three criteria have equal visual treatment and connect to the same report. No source or report receives an automatic approval.

Organizations benefit from sharing threat intelligence. If Company A discovers that attackers are using a new malware variant, and Company A shares that malware's hash and C2 domain with Company B, Company B can immediately block it.

However, sharing has risks. Sharing indicators might reveal sensitive information about your organization (that you were breached, which systems you use, what your network looks like). Sharing should follow a structured process:

Determine what information is safe to share (IoCs, not details of the breach itself).
Agree on how the information will be used (can the recipient share it further? with whom?).
Consider anonymizing information to protect your organization.

Figure 4.11: Preparing intelligence for sharing includes reviewing the finding, removing sensitive details from the sharing copy, and agreeing on sharing limits.

Text description for Figure 4.11

Read left to right. First review the finding. Second remove sensitive details from the copy prepared for sharing while preserving original evidence. Third agree on sharing limits, including intended recipients and permitted use. Fourth share useful indicators with the agreed recipients. Arrows show the preparation sequence.

4.4 Threat Modeling: STRIDE

Threat modeling is the process of systematically identifying potential threats to a system. The goal is to think like an attacker: What are the ways someone could attack this system?

STRIDE is a framework for threat modeling, developed by Microsoft. It categorizes threats:

S - Spoofing Identity. Can an attacker pretend to be someone else? For example, if an application accepts a username in a web form without validating it, an attacker could spoof being another user.

T - Tampering with Data. Can an attacker modify data in transit or at rest? If a message is sent over the network without integrity protection (like a cryptographic signature), an attacker could modify it.

R - Repudiation. Can an attacker deny they took an action? If there is no audit log of who deleted a record, an attacker could delete it and deny responsibility.

I - Information Disclosure. Can an attacker access information they shouldn't? If a database backup is stored on an unsecured server, an attacker could download it.

D - Denial of Service. Can an attacker disrupt service? If an application uses a lot of CPU to process a request, an attacker could send thousands of requests and overload the server.

E - Elevation of Privilege. Can an attacker gain higher privileges? If an application runs as root or administrator, and the application is exploitable, an attacker could gain root or administrator access.

Figure 4.12: STRIDE groups threats into six categories that help analysts examine how a system might be attacked.

Text description for Figure 4.12

Read left to right across each row. S, Spoofing: impersonate a user. T, Tampering: alter data, illustrated by changing an amount. R, Repudiation: deny an action, illustrated by questioning an audit record. I, Information disclosure: expose restricted data. D, Denial of service: disrupt access. E, Elevation of privilege: gain unauthorized permissions, illustrated by movement from user to administrator.

STRIDE is useful for developers designing secure applications, but it is also useful for security operations. If you understand the threat model for your systems, you know what to monitor and what defenses matter most.

For example, a web application's threat model might identify:

Spoofing risk: Users logging in without MFA. Mitigation: Implement MFA.
Tampering risk: Session cookies are not signed. Mitigation: Sign cookies cryptographically.
Elevation of privilege risk: SQL injection vulnerability allows querying the database. Mitigation: Use parameterized queries.

A SOC analyst looking at the threat model can then configure monitoring:

Alert on MFA bypass attempts (spoofing).
Alert on invalid session cookies (tampering).
Alert on suspicious SQL in logs (elevation of privilege).

4.5 Threat Hunting

So far, we've discussed threat intelligence as something organizations consume: they read reports, apply IoCs, and update detection rules. Threat hunting is the active, proactive search for attackers who have already breached the network.

Threat hunting assumes that automated detection has missed something. An advanced attacker with persistent access might not trigger alerts: they might move slowly, use legitimate admin tools, and blend in with normal traffic. Threat hunting is the human-led investigation that looks for the subtle indicators of compromise.

The Threat Hunting Process

A threat hunting engagement typically follows this process:

1. Hypothesis. The threat hunter formulates a hypothesis based on threat intelligence or hunches. For example: "APT28 often uses a technique called 'Living Off the Land Binaries,' where they misuse legitimate Windows tools like wmic or certutil. If APT28 has compromised our environment, we should see unusual combinations of these tools being executed."

2. Data gathering. The hunter gathers relevant data: endpoint logs, network logs, application logs, process execution logs. For the hypothesis above, they would pull all wmic and certutil executions over the past 30 days.

3. Analysis. The hunter analyzes the data to look for patterns that match the hypothesis. They might find hundreds of legitimate wmic executions (used by Windows Update and IT tools) and a few unusual ones (executed by a user account at 3 AM, followed by network connections to unknown IPs).

4. Investigation. Promising leads are investigated further. The hunter answers questions: What is this wmic command doing? What does the executing process look like? What network traffic followed? Is this a known admin activity or is it suspicious?

5. Escalation. If the hunter finds evidence of compromise, they escalate to the incident response team.

Figure 4.13: A hunt progresses from hypothesis through data collection, analysis, and investigation. Evidence of compromise leads to incident response; otherwise, the hypothesis may require review.

Text description for Figure 4.13

Step 1 is to formulate a testable hypothesis. Step 2 gathers relevant data. Step 3 analyzes that data. Step 4 investigates leads. A decision asks whether there is evidence of compromise. The Yes branch leads only to Step 5, escalation to incident response. The Not established branch leads to reviewing or refining the hypothesis. This figure is a simplified teaching flow; the review outcome is not a declaration that the environment is free of compromise.

Putting It Together: A Threat Hunting Scenario

A SOC supervisor reviews a threat intelligence report from CISA about APT29's recent activities. The report describes their use of the TEARDROP backdoor, which:

Communicates over HTTPS to attacker-controlled domains.
Creates registry keys in Software\Microsoft\Windows\CurrentVersion\Run.
Uses a DNS query pattern where legitimate names are queried followed by a unique subdomain (e.g., legit.com, then x1234567890.attacker-controlled.com).

The supervisor initiates a threat hunt:

Hypothesis: "APT29 may have compromised our environment. If TEARDROP is present, we should see the characteristic DNS query pattern."

Data gathering: The security operations team exports DNS query logs from the past 90 days.

Analysis: They write a query to look for the pattern: legitimate domain queries (google.com, microsoft.com, etc.) followed by queries to attacker-controlled domains. They generate a list of unusual subdomains.

Investigation: They find one system (WS-Finance-42) that queried google.com and news.com, and then queried x9823lkj.evilc2domain.net. They dig deeper:

Network logs show WS-Finance-42 connecting to evilc2domain.net:443 repeatedly, consistent with TEARDROP's behavior.
Process logs show a legitimate Windows process (svchost.exe) with suspicious parent process.
Registry logs show the suspicious registry key being created.

Escalation: The incident response team takes over. They isolate the system, collect forensic images, and begin determining the scope of the compromise.

Analyst Perspective

Threat hunting is the most rewarding work in the SOC, but also the most time-consuming. It requires deep knowledge of systems, patience to follow leads that might go nowhere, and the ability to recognize subtle patterns. Junior analysts benefit from pairing with experienced hunters. Many SOCs rotate analysts through hunting roles to broaden their skills.

Figure 4.14: Related process, network, and registry observations can form an investigative lead when correlated by host and time.

Text description for Figure 4.14

This illustrative example uses the fictional workstation WS-Example-01. At 09:14, process activity shows an unusual child process, a program launched by another program. At 09:15, network activity shows an external connection. At 09:16, registry activity shows a new startup entry, a Windows configuration entry that can launch a program automatically. The three observations converge on a correlated investigative lead. Shared host identity and nearby times support investigation but do not alone prove a common cause or compromise.

4.6 Cyber Deception: Honeypots and Honeynets

If threat intelligence is about understanding attackers, cyber deception is about catching them in the act.

A honeypot is a decoy system that looks valuable but is not actually in use. An attacker who compromises a honeypot thinks they've found a real asset, but any activity on it is immediately suspicious and is logged.

Examples:

Database honeypot. A fake database server on the network containing dummy customer records. If an attacker accesses it, you know the system is compromised, and you have evidence of what the attacker was trying to do (steal customer data).

Credential honeypot. A fake credential left in an obviously accessible location (an unsecured note in version control, a shared spreadsheet). If this credential is used, you know an attacker found it and used it.

Service honeypot. A fake web service responding to specific requests. If an attacker probes your network for vulnerable services, they might probe this fake one. Any interaction with it is suspicious.

A honeynet is a network of honeypots designed to emulate a target environment. An attacker who breaches into a honeynet thinks they've gotten into the real network, but everything is fake, and all their activity is monitored.

Figure 4.15: A honeypot is one decoy system; a honeynet connects multiple decoys. Both provide activity logs for monitoring.

Text description for Figure 4.15

The left group contains a single decoy labeled Honeypot. The right group contains three interconnected decoys labeled Honeynet. Solid lines connect the honeynet systems. Separate dotted paths from both groups point into a monitoring screen. Interaction with a decoy provides evidence to investigate and does not by itself prove compromise of a production system.

Honeypots and honeynets are particularly useful because:

Low false-positive rate. Legitimate users and processes should never interact with a honeypot. Any interaction is very likely malicious.
Behavioral insight. A honeypot captures the attacker's actions in detail. You see what tools they use, what data they seek, how they move laterally.
Threat intelligence. Studying honeypot data helps develop better detection rules and understand emerging techniques.

The downside is that honeypots require effort to maintain and are sometimes discovered by attackers.

4.7 Putting It Together: Integrating Threat Intelligence into Operations

A well-run SOC integrates threat intelligence into daily operations:

Figure 4.16: Threat intelligence informs detection, response preparation, prioritization, training, and communication.

Text description for Figure 4.16

An assessed intelligence report informs five operational uses. Alert tuning updates detection. Playbooks prepare response procedures. Risk prioritization focuses attention on relevant threats. Training prepares people for those threats. Reporting communicates findings and implications. The five destinations are parallel applications, not ordered stages.

Alert tuning. When a new threat intelligence report is published, analysts review it and ask: Do we have detection rules for these IoCs and TTPs? If not, do we need to create them? If a report describes a spear-phishing technique, the email security team updates filters. If it describes a malware family, the endpoint security team adds signatures.

Playbook development. Common threat actors trigger specific response procedures. If APT28 is active in your sector, the IR team develops a playbook: steps to take immediately upon detecting APT28 TTPs, who to contact, what data to preserve.

Risk prioritization. Threat intelligence informs risk prioritization. If a vulnerability in your critical application is being actively exploited by a nation-state, it jumps to the top of the patch list. If a vulnerability only affects a niche application your organization doesn't use, it's lower priority.

Training. Threat intelligence about phishing campaigns specific to your industry guides awareness training. Finance teams get training on phishing attacks against finance. Healthcare teams get training on healthcare-specific threats.

Reporting. Internal threat intelligence reports summarize the threat landscape relevant to the organization. Executives learn which threat actors are targeting companies like them, what the likely impact would be, and what the organization is doing to defend.

Chapter Summary

Threat actors include nation-states (APTs), cybercriminals, and insiders. Understanding their motivations, capabilities, and tactics informs defense.
APT29's SolarWinds campaign demonstrated the risks of supply chain compromise. A trusted vendor's software was modified to contain a backdoor, affecting thousands of organizations.
Tactics, Techniques, and Procedures (TTPs) describe how attackers operate. Understanding them enables detection and prediction.
The Pyramid of Pain illustrates that file hashes are easy to evade, while TTPs are hardest to change. Detection rules based on TTPs are more resilient.
The MITRE ATT&CK framework provides a comprehensive, vendor-neutral database of tactics and techniques observed in real-world attacks. It is a standard reference for cybersecurity professionals.
Attribution is the process of determining who conducted an attack. It is based on evidence (malware analysis, infrastructure, TTPs, timing) and typically confidence-based, not absolute.
Threat intelligence is collected from open-source (OSINT) and closed-source (commercial vendors, law enforcement) sources. It should be evaluated for timeliness, relevance, and accuracy.
Indicators of Compromise (IoCs) include atomic indicators (file hashes, IP addresses, domains) and behavioral indicators (patterns of activity). Behavioral indicators are more resilient to evasion.
STRIDE is a threat modeling framework that categorizes threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It helps identify what to defend and monitor.
Threat hunting is the proactive search for attackers already in the network. It follows a hypothesis-driven process: hypothesis, data gathering, analysis, investigation, and escalation.
Cyber deception (honeypots and honeynets) creates decoy systems that, if accessed, indicate compromise with high confidence.
Integration of threat intelligence into operations ensures that defenses are informed by knowledge of actual threat actors and their techniques.