Learning Objectives

After completing this section, you should be able to:

• Explain the purpose of the Discover interface.

• Perform structured searches.

• Use filters effectively.

• Build complex search expressions.

• Save frequently used searches.

• Investigate alerts using field-based analysis.

Introduction

Imagine someone handed you a library containing ten million books.

Could you find one paragraph discussing a specific historical event?

Probably not.

Now imagine that same library had:

• An index

• A catalog

• Subject headings

• Keywords

• Cross-references

Finding information becomes much easier. The Wazuh Discover interface serves exactly this purpose. It is the analyst’s search engine for security telemetry. Rather than browsing millions of events manually, Discover allows analysts to locate specific evidence within seconds.

What Is Discover?

Discover is the primary investigative workspace used to search indexed security telemetry (Wazuh, Inc., n.d.-a). Unlike the Security Events module, which emphasizes alerts, Discover provides direct access to the underlying event data.

Analysts use Discover to answer questions such as:

• Which host generated this event?

• Which user executed PowerShell?

• Which process contacted this IP address?

• When did the activity begin?

• How many similar events occurred?

• Has this behavior occurred before?

These questions cannot usually be answered by looking at a single alert.

Figure 4-4

The Discover Workflow

Note. The workflow presents the ordered stages of the Discover Workflow and highlights the validation and feedback steps that make the process repeatable.

Notice that the investigation begins with a question, not with a search.

Opening Discover

Navigate to:

Discover

The screen displays recent indexed events. Initially, this can appear overwhelming. Thousands—or even millions—of events may be visible. Do not attempt to read everything. Instead, begin reducing the data.

Understanding the Discover Layout

The interface is organized into several logical areas.

Each area contributes to the investigative process.

Figure 4-5

Discover Layout

Note. The figure summarizes discover Layout and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Learning this layout early significantly improves investigative efficiency.

Step One — Limit the Time Range

Before searching, reduce the investigation window. Suppose you just executed a PowerShell command.

Searching:

Last 30 Days may return hundreds of thousands of events.

Searching:

Last 15 Minutes may return only a few dozen. Smaller datasets produce faster investigations.

SOC Tip

Reduce the time range first. Then search. Not the other way around.

Step Two — Search for a Host

Suppose we investigate the Windows workstation.

Search:

WIN11

Immediately, all unrelated systems disappear. The investigation now focuses only on the endpoint of interest.

Step Three — Narrow Further

Now search for PowerShell.

powershell.exe

The result set becomes even smaller. Good investigations progressively reduce noise.

Figure 4-6

Progressive Filtering

Note. The figure summarizes progressive Filtering and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

This approach is dramatically more efficient than manually reading alerts.

Searching Common Fields

During investigations, analysts repeatedly search the same types of information.

Examples include:

These searches form the foundation of nearly every investigation.

Understanding Fields

Every event contains numerous individual fields.

Examples include:

Think of fields as columns in a database. Note that the field names shown in Discover are Wazuh’s indexed paths (for example, data.srcip), which differ from the raw field names inside Suricata’s eve.json (src_ip). Section 2.9 introduced these indexed paths; always search using the indexed name shown when you expand an event. Searching fields is far more precise than searching raw text.

Analyst Corner

Beginning analysts often search entire log messages. Experienced analysts search fields.

Why?

Because fields are structured.

Searching:

src_ip = 192.168.1.40 is much more reliable than searching every line for:

192.168.1.40

Structured searching produces cleaner investigations.

Expanding an Event

Every event can be expanded. When expanded, additional information becomes available.

Examples include:

• Full JSON record

• Event timestamp

• Agent metadata

• Rule information

• Network information

• Process details

• Parent process

• Command line

• User information

Always expand important alerts. The summary rarely tells the entire story.

Example Investigation

Suppose the following alert appears.

Suspicious PowerShell

Expand the event.

Now ask:

• Which executable started PowerShell?

• Which user executed it?

• What command line was used?

• What process was the parent?

• Was a network connection established?

• Did Sysmon log additional activity?

Notice how one alert generates many investigative questions.

Searching by Rule ID

Every Wazuh alert contains a Rule ID.

Suppose the alert uses:

Rule ID: 5710

Searching the Rule ID allows you to locate:

• Similar alerts

• Previous occurrences

• Historical frequency

• Other affected systems

Rule IDs are one of the fastest ways to identify recurring activity.

Field Pinning

Some fields appear repeatedly during investigations.

Examples:

• Hostname

• Username

• Source IP

• Process

• Rule ID

Rather than expanding every event, pin frequently used fields so they remain visible in the results table. This reduces repetitive clicks and improves analyst efficiency.

Saving Searches

Professional analysts rarely perform identical searches repeatedly. Instead, they save commonly used searches.

Examples include:

Saved searches improve consistency across investigations.

Common Student Mistake

Students often type one broad search into Discover and stop when they receive thousands of results. Professional analysts refine their searches iteratively.

For example:

Instead of:

PowerShell search:

Hostname = WIN11

AND

Process = powershell.exe

AND

Last 30 Minutes

Specific searches produce more meaningful results.

Investigation Exercise

Open Discover and perform the following investigation:

• Set the time range to Last Hour.

• Search for your Windows endpoint.

• Locate a Sysmon Event ID 1.

• Expand the event.

• Record:

• Parent Process

• Command Line

• User

• Timestamp

• Determine whether a DNS query followed.

• Determine whether Suricata detected related network traffic.

• Document your findings in your SOC Engineering Notebook.

Think Like a SOC Analyst

When using Discover, remember:

You are not searching for alerts. You are searching for evidence. Alerts are merely one form of evidence. The real objective is to reconstruct what happened, using structured telemetry collected from multiple sources.

Chapter Connection

By mastering Discover, students gain the ability to efficiently navigate millions of security events without becoming overwhelmed. In the next section, we build upon this skill by introducing timeline analysis—the process of arranging events chronologically to reconstruct attacker behavior. Students will learn that effective investigations depend not only on identifying individual events, but on understanding the sequence in which they occurred. This shift from isolated events to coherent timelines is one of the defining skills of a professional SOC analyst.

Learning Objectives

After completing this section, you should be able to:

• Explain the importance of chronological analysis.

• Build investigative timelines using Wazuh.

• Correlate events from multiple telemetry sources.

• Distinguish cause from effect.

• Identify precursor, primary, and follow-on events.

• Document investigative timelines suitable for incident reports.

Introduction

Imagine watching only five random frames from a two-hour movie.

Could you explain the plot?

Probably not. Cybersecurity investigations are no different. Individual alerts are like individual movie frames.

Useful?

Yes.

Sufficient?

No. Professional investigators reconstruct the entire sequence of events.

They ask:

• What happened first?

• What happened next?

• What triggered the alert?

• What happened afterward?

• What evidence supports each step?

Only then do they determine whether an incident occurred.

Security Events Occur in Sequences

Attackers rarely perform only one action. Instead, attacks unfold as a sequence.

Example:

Figure 4-7

From Phishing Email to Data Exfiltration

Note. The sequence traces how Phishing Email progresses to Data Exfiltration, emphasizing the intermediate evidence and processing steps.

Each step produces telemetry. Your job is to reconstruct that sequence.

Figure 4-8

Timeline Thinking

Note. The timeline places the events associated with timeline Thinking in chronological order to support reconstruction, correlation, and defensible conclusions.

Why Time Matters

Suppose you observe:

• PowerShell

• DNS Query

• Defender Alert

Which happened first?

Without timestamps, you cannot know. Order changes meaning. Consider these two examples.

Timeline A

Figure 4-9

From PowerShell to Defender Detection

Note. The sequence traces how PowerShell progresses to Defender Detection, emphasizing the intermediate evidence and processing steps.

Possible interpretation:

PowerShell initiated suspicious network activity.

Timeline B

Figure 4-10

From Defender Detection to Update Service

Note. The sequence traces how Defender Detection progresses to Update Service, emphasizing the intermediate evidence and processing steps.

Possible interpretation:

Administrator verified a Defender detection. Exactly the same events. Completely different conclusions.

Analyst Corner

One of the easiest ways to misinterpret evidence is to ignore chronology. Events rarely make sense individually. They almost always make sense together. Never investigate isolated timestamps. Investigate timelines.

Building a Timeline

Every investigation should answer five questions.

Notice that “Why?” comes last. Evidence must precede explanation.

Step One — Select the Initial Alert

Suppose Wazuh reports:

Suspicious PowerShell Execution

Record:

• Timestamp

• Host

• User

• Rule ID

• Severity

This becomes the anchor point.

Step Two — Expand the Time Window

Never investigate only the alert itself. Expand the time window.

Example:

15 Minutes Before → Alert → 15 Minutes After

Now additional activity becomes visible.

Step Three — Identify Related Events

Search for activity involving:

• Same hostname

• Same user

• Same process

• Same IP address

• Same timeframe

Avoid introducing unrelated systems too early.

Figure 4-11

Timeline Expansion

Note. The timeline places the events associated with timeline Expansion in chronological order to support reconstruction, correlation, and defensible conclusions.

The investigation now tells a story.

Event Categories

As timelines become larger, group similar events together.

Example:

Grouping improves readability.

Identifying Cause and Effect

Students often confuse correlation with causation.

Suppose you observe:

• PowerShell

• DNS Query

• HTTP Request

Did PowerShell cause the HTTP request?

Perhaps. Or perhaps another application generated it. Evidence determines causation. Chronology alone does not. Professional analysts remain cautious.

Multi-Source Correlation

One timeline should include all available telemetry.

Example:

Now the evidence spans four independent technologies. Confidence increases significantly.

Recognizing Precursor Events

Not every important event triggers an alert. Many attacks begin with seemingly ordinary activity.

Examples include:

• Successful login

• USB insertion

• Office document opened

• Browser started

• Scheduled task created

These events provide context. They often explain later detections.

Primary Events

Primary events represent the activity being investigated.

Examples:

• PowerShell execution

• Privilege escalation

• Malware execution

• Port scan

• Remote shell

• Credential dumping

These typically trigger alerts.

Follow-On Events

After the primary activity, additional events frequently occur.

Examples:

• New process creation

• Registry modification

• DNS requests

• HTTP communication

• Service installation

• Scheduled task creation

Following the timeline beyond the alert often reveals attacker objectives.

Figure 4-12

Attack Timeline

Note. The timeline places the events associated with attack Timeline in chronological order to support reconstruction, correlation, and defensible conclusions.

Professional analysts rarely stop at the first alert.

Visual Timeline Construction

When documenting investigations, consider visual timelines.

Example:

10:01 Login

Figure 4-13

Investigation Timeline — Endpoint Compromise

Note. The timeline places the events associated with investigation Timeline — Endpoint Compromise in chronological order to support reconstruction, correlation, and defensible conclusions.

Visual representations often communicate investigations more effectively than paragraphs.

Common Student Mistake

Students frequently investigate only the alert itself.

Professional analysts investigate:

• Before the alert

• During the alert

• After the alert

Many important events occur outside the original detection window.

SOC Tip

A useful rule of thumb:

For every alert, review at least:

• 15 minutes before

• 15 minutes after

Major incidents may require hours or even days of historical context.

Investigation Exercise

Generate a PowerShell event on your Windows endpoint.

Construct a timeline containing:

• Login

• Process creation

• DNS activity

• Network activity

• Suricata detections

• Windows Defender events

• Wazuh alerts

Present the timeline as a table.

Then answer:

• Which event occurred first?

• Which event initiated the sequence?

• Which events confirmed network activity?

• Which security product first detected suspicious behavior?

• What evidence supports your conclusion?

Think Like a SOC Analyst

An alert is a photograph. A timeline is a documentary. Photographs capture moments. Documentaries explain stories. Your responsibility as an analyst is not merely to identify suspicious events. It is to reconstruct what happened with sufficient accuracy that another investigator could independently reach the same conclusion.

Looking Ahead

The next section introduces event correlation, one of the defining capabilities of a SIEM. Students will learn how Wazuh combines telemetry from Sysmon, Suricata, Windows Defender, Linux logs, and authentication events into a unified investigative picture. They will explore why isolated alerts are often misleading, how multiple independent data sources increase investigative confidence, and how correlation transforms raw telemetry into actionable intelligence suitable for incident response. This chapter builds directly upon timeline analysis and prepares students for increasingly realistic attack scenarios later in the textbook (Wazuh, Inc., n.d.-a).

Learning Objectives

After completing this section, you should be able to:

• Explain the concept of event correlation.

• Differentiate between isolated events and correlated investigations.

• Identify related telemetry across multiple security products.

• Recognize confidence levels based on corroborating evidence.

• Build evidence-supported incident conclusions.

• Avoid common analytical mistakes when correlating events.

Introduction

Imagine asking five witnesses to describe the same automobile accident. Each person observed the event from a different location.

One witnessed:

• The collision.

Another saw:

• The traffic light.

Another noticed:

• The driver using a cellphone.

Another recorded:

• The license plate.

No single witness possesses the complete story. Together, they reconstruct the incident. Security telemetry works exactly the same way. Every security product observes the environment from a unique perspective. The analyst’s responsibility is to combine those observations into a coherent explanation. This process is called event correlation.

Why SIEM Exists

Many students ask:

“Why not just look directly at Sysmon?”

Or:

“Why not simply monitor Suricata?” Because neither provides complete visibility. Consider what each technology observes.

Notice something important. Every tool is incomplete by itself. Together, they provide significantly greater confidence.

Figure 4-14

Individual Visibility

Note. The comparison highlights the operational differences represented by individual Visibility and shows why the distinction matters during analysis.

No single sensor sees everything.

Correlation Defined

Correlation is the process of identifying relationships among multiple security events.

Relationships may include:

• Time

• Host

• User

• Process

• Network connection

• File

• Alert signature

Events become significantly more meaningful when considered together.

Example One — Single Event

Suppose Wazuh reports:

PowerShell Executed

Should you panic?

No. PowerShell executes legitimately thousands of times every day. One event alone provides little context.

Example Two — Correlated Events

Now consider:

Figure 4-15

From PowerShell to Suricata Alert

Note. The sequence traces how PowerShell progresses to Suricata Alert, emphasizing the intermediate evidence and processing steps.

Now we have evidence. The probability of malicious behavior increases dramatically. Nothing changed about the PowerShell event itself. What changed was the surrounding evidence.

Analyst Corner

Students often ask:

“How many alerts prove an attack?”

The answer is:

There is no magic number.

Professional analysts evaluate:

• Quality

• Timing

• Context

• Consistency

• Confidence

Not simply quantity. Five unrelated alerts prove very little. Three strongly related alerts may justify incident response.

Correlation Dimensions

Analysts correlate events across several dimensions.

Time

Did the events occur together?

Example:

10:03 PowerShell

10:04 DNS

10:05 HTTP

Chronological proximity strengthens confidence.

Host

Did the same computer generate multiple alerts?

Example:

WIN11

Repeated activity on one endpoint deserves attention.

User

Did the same user generate multiple suspicious events?

Example:

Figure 4-16

From Student01 to Remote Login

Note. The sequence traces how Student01 progresses to Remote Login, emphasizing the intermediate evidence and processing steps.

Identity frequently connects otherwise unrelated alerts.

Process

Did one executable launch another?

Example:

WINWORD.EXE → powershell.exe → cmd.exe

Process ancestry often reveals attacker techniques.

Network

Did endpoint activity correspond with network communication?

Example:

PowerShell → HTTP GET → Suricata Alert

Multiple sensors now describe the same activity.

File

Was a downloaded file subsequently executed?

Example:

Figure 4-17

From Download to Defender Detection

Note. The sequence traces how Download progresses to Defender Detection, emphasizing the intermediate evidence and processing steps.

File correlation frequently identifies malware infections.

Confidence Levels

Correlation increases investigative confidence.

Example:

Notice that confidence increases as independent evidence accumulates.

Figure 4-18

Confidence Pyramid

Note. The figure shows how confidence Pyramid narrows broad observations into prioritized evidence and increasingly confident analytical judgments.

Example Investigation

Suppose we investigate:

Rule:

Suspicious PowerShell

What additional evidence should we seek?

Every additional source increases confidence.

Correlation Matrix

The following table illustrates how multiple technologies complement one another.

No technology stands alone.

Recognizing False Positives

Correlation also reduces false positives.

Suppose you observe:

PowerShell

Legitimate?

Possibly.

Now ask:

Did Defender detect malware?

No.

Did Suricata observe suspicious traffic?

No.

Did Sysmon show unusual child processes?

No. Probability of malicious behavior decreases. Correlation works both ways. It confirms incidents. It also disproves them.

Common Student Mistake

Students frequently stop investigating once the first suspicious alert appears.

Professional analysts ask:

What other evidence supports this?

And equally important:

What evidence contradicts this?

Both questions matter.

Investigation Exercise

Generate a PowerShell session.

Then intentionally perform:

• DNS lookup

• Web request

• File download

• EICAR test

Document which technologies observed each action. Complete the following matrix.

Students should explain why each technology observed—or did not observe—each activity.

SOC Tip

Correlation should always involve independent evidence. Multiple alerts from the same sensor may indicate repetition. Multiple alerts from different sensors observing the same activity indicate corroboration. Independent confirmation is one of the strongest indicators of investigative confidence.

Think Like a SOC Analyst

Imagine an alert states:

“Potential Malware Download.”

Instead of asking:

Is this malware?

Ask:

• Did the endpoint create a file?

• Was the file executed?

• Did Defender quarantine it?

• Did the process establish outbound communications?

• Did another endpoint contact the same destination?

• Has this behavior occurred before?

Correlation transforms speculation into evidence-based conclusions.

Key Concepts

By the end of this section, you should understand that:

• Correlation is the defining capability of a SIEM.

• No single security technology provides complete visibility.

• Independent evidence increases investigative confidence.

• Correlation helps identify both true positives and false positives.

• Strong investigations are built from multiple corroborating sources rather than isolated alerts.

Looking Ahead

The next section introduces hypothesis-driven investigations, where students move beyond reacting to alerts and begin developing structured investigative theories. They will learn to formulate hypotheses, gather supporting and contradictory evidence, test conclusions against available telemetry, and document findings using professional incident response methodology. This approach prepares students for real-world investigations where the answer is rarely obvious and evidence must be evaluated critically before conclusions are reached.

Learning Objectives

After completing this section, you should be able to:

• Explain the concept of hypothesis-driven investigations.

• Distinguish observations from assumptions.

• Develop investigative hypotheses.

• Gather supporting and contradictory evidence.

• Evaluate competing explanations.

• Reach defensible investigative conclusions.

Introduction

One of the greatest misconceptions about cybersecurity investigations is that alerts identify attacks. They do not. Alerts identify activity.

The analyst determines whether that activity represents:

• Normal operations

• Administrative work

• User error

• Software installation

• Policy violation

• Malicious behavior

Professional investigators avoid jumping directly to conclusions. Instead, they develop one or more hypotheses and systematically evaluate each using available evidence.

What Is a Hypothesis?

A hypothesis is a proposed explanation that can be tested using evidence (Heuer, 1999).

Examples include:

PowerShell executed because malware launched it.

or

PowerShell executed because an administrator installed software. Both explanations are possible. Neither is yet proven. Evidence—not intuition—determines which explanation survives.

Figure 4-19

Investigation Process

Note. The figure summarizes investigation Process and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Notice that the conclusion comes last, not first.

Observation Versus Conclusion

Students frequently confuse these concepts.

Example:

Observed:

PowerShell.exe started.

Incorrect conclusion:

Malware executed.

Correct conclusion:

PowerShell executed. Further investigation required. Observations describe facts. Conclusions explain facts. Those are not the same thing.

Analyst Corner

Whenever you write:

“The attacker…”

Pause.

Ask yourself:

What evidence proves there was an attacker?

If the answer is:

“The alert.” You have not completed the investigation.

Developing Multiple Hypotheses

Suppose you observe:

PowerShell → DNS → HTTP

Possible explanations include:

Professional analysts evaluate all reasonable explanations.

Step One — Record Observations

Write only what you know.

Example:

• PowerShell started.

• User: Student01.

• Parent process: WINWORD.EXE.

• DNS lookup occurred.

• HTTP request followed.

Nothing more. No conclusions.

Step Two — Generate Explanations

Possible explanations:

• Office macro.

• Software installation.

• Malware.

• Administrative script.

• Classroom exercise.

Avoid eliminating possibilities too early.

Step Three — Collect Supporting Evidence

Now investigate each explanation.

Questions include:

• Was Word expected?

• Was a document opened?

• Was software being installed?

• Did Defender detect malware?

• Did Suricata detect downloads?

• Was the activity scheduled?

Evidence begins separating plausible explanations from unlikely ones.

Step Four — Seek Contradictory Evidence

This is where many investigations fail. Do not search only for evidence that supports your preferred explanation. Also search for evidence that disproves it.

Suppose your hypothesis is:

Malware executed.

Contradictory evidence might include:

• Defender quarantined the file before execution.

• User intentionally launched an approved installer.

• Activity matches a scheduled maintenance window.

• The hash matches approved software.

Contradictory evidence strengthens the investigation because it forces you to test your assumptions.

Figure 4-20

Hypothesis Testing

Note. The figure summarizes hypothesis Testing and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Confidence Levels

Investigations rarely end with absolute certainty. Instead, analysts express confidence.

Example:

Confidence communicates uncertainty honestly.

Example Investigation

Observation:

PowerShell → DNS → HTTP Download

Initial hypothesis:

Malware.

Supporting evidence:

• PowerShell launched by Word.

• Suricata detected executable download.

• Defender detected Trojan.

Contradictory evidence:

• No persistence observed.

• Defender quarantined immediately.

Revised conclusion:

Attempted malware execution successfully blocked by endpoint protection. Notice how the conclusion became more precise after considering all available evidence.

Avoiding Confirmation Bias

Confirmation bias occurs when investigators search only for evidence supporting an existing belief.

Example:

Alert:

PowerShell

Analyst immediately concludes:

Malware. Every subsequent observation becomes interpreted through that assumption.

Professional investigators intentionally ask:

What evidence would prove me wrong?

This single question dramatically improves investigative quality.

Common Student Mistake

Students often write incident reports containing statements such as:

“The attacker attempted…”

when no evidence establishes the presence of an attacker.

Instead write:

“Observed activity is consistent with…”

or

“Available evidence suggests…”

These statements accurately communicate uncertainty while remaining evidence-based.

Investigation Exercise

Generate the following activity:

• Open Microsoft Word.

• Launch PowerShell.

• Perform a DNS lookup.

• Browse to a website.

Now answer:

• What observations can you make?

• List three possible explanations.

• Which evidence supports each explanation?

• Which evidence contradicts each explanation?

• Which hypothesis is currently best supported?

• What additional evidence would increase your confidence?

Students should present their findings in a structured table rather than narrative form.

Evidence Worksheet

This worksheet encourages balanced reasoning.

Think Like a SOC Analyst

Imagine two analysts receive the same alert.

Analyst A immediately declares:

“The endpoint is compromised.”

Analyst B says:

“Current evidence suggests suspicious activity. I need to determine whether it represents malicious behavior, administrative activity, or an expected laboratory exercise.”

Which analyst would you trust to investigate a real incident?

Professionalism comes from disciplined reasoning—not confidence alone.

Key Concepts

By the end of this section, you should understand that:

• Alerts generate questions, not answers.

• Observations are facts; conclusions are interpretations.

• Multiple hypotheses should be considered.

• Supporting and contradictory evidence are equally valuable.

• Confidence should reflect the available evidence.

• Well-documented reasoning is as important as the conclusion itself.

Looking Ahead

The next section introduces professional incident documentation. Students will learn how to record observations, maintain investigation notes, construct executive and technical summaries, document evidence, and write incident reports that can be understood by analysts, managers, auditors, and legal teams. Strong technical investigations lose value if they are not documented clearly, accurately, and objectively. This chapter therefore shifts from analytical thinking to communicating investigative findings—a critical skill for every Security Operations Center analyst.

Learning Objectives

After completing this section, you should be able to:

• Explain why documentation is essential in cybersecurity.

• Differentiate between technical notes and incident reports.

• Record objective investigative observations.

• Document evidence without introducing bias.

• Write concise technical summaries.

• Prepare incident reports suitable for management and auditors.

Introduction

Imagine you spend four hours investigating a suspected malware infection.

You identify:

• Initial access

• Malware execution

• Command-and-control communication

• Defender quarantine

• Timeline

• Indicators of Compromise (IOCs)

At the end of the investigation someone asks:

“Can you explain exactly what happened?”

Suppose your answer is:

“I remember most of it.” That is not acceptable in professional cybersecurity.

Investigations must be documented accurately because:

• Other analysts continue investigations.

• Managers require status updates.

• Incident response teams rely on findings.

• Auditors review investigations.

• Legal teams may require evidence.

• Lessons learned improve future detection.

Documentation transforms individual knowledge into organizational knowledge.

Documentation Serves Multiple Audiences

One report rarely satisfies everyone. Different audiences require different levels of detail.

Effective analysts adjust the level of detail without changing the underlying facts.

The Four Components of Every Investigation

Professional documentation contains four major sections.

Figure 4-21

From Observations to Conclusion

Note. The sequence traces how Observations progresses to Conclusion, emphasizing the intermediate evidence and processing steps.

Each section serves a distinct purpose.

Section 1 — Observations

Observations are objective facts.

Examples:

✓ PowerShell started at 10:15:03. ✓ User Student01 authenticated successfully. ✓ Suricata detected an HTTP download. ✓ Defender quarantined a file. Notice what is missing. No assumptions. No speculation. No opinions.

Poor Observation

The attacker launched malware. No evidence has yet established an attacker.

Good Observation

PowerShell.exe executed at 10:15:03. Parent process: WINWORD.EXE. HTTP communication followed. Windows Defender generated a malware alert. Every statement is directly supported by telemetry.

Analyst Corner

A useful writing habit is:

Write what you observed.

Not:

Write what you think happened. Those are different.

Section 2 — Evidence

Evidence answers the question:

How do you know?

Every conclusion should reference supporting evidence.

Example:

Readers should never wonder where information originated.

Section 3 — Analysis

Analysis explains relationships.

Example:

Observed facts:

• Word started PowerShell.

• DNS lookup followed.

• HTTP download occurred.

• Defender quarantined a Trojan.

Analysis:

The sequence is consistent with a malicious Office document attempting to download additional content. Notice the wording.

“Consistent with”

Not:

“Proves.” Professional analysts communicate uncertainty honestly.

Section 4 — Conclusions

Conclusions summarize the investigation.

A strong conclusion answers:

• What happened?

• What evidence supports it?

• What confidence level exists?

• What should happen next?

Example:

Current evidence indicates an attempted malware download originating from a Microsoft Word document. Windows Defender quarantined the downloaded file before execution. No evidence of persistence or lateral movement was observed during the investigation. Confidence in this assessment is high due to corroborating evidence from Sysmon, Suricata, Windows Defender, and Wazuh.

This conclusion is:

• Objective

• Supported

• Defensible

Writing Clearly

Technical writing should be:

• Accurate

• Concise

• Objective

• Chronological

• Reproducible

Avoid unnecessary adjectives.

Poor:

A really suspicious PowerShell attack was definitely executed.

Better:

PowerShell.exe executed at 10:15:03 and initiated an outbound HTTP connection. Additional evidence is consistent with an attempted malware download. Specific evidence is always more valuable than dramatic language.

Building an Investigation Timeline

Every report should include a timeline.

Example:

A timeline allows another analyst to reconstruct the incident without re-performing the investigation.

Recording Indicators of Compromise (IOCs)

Every investigation should capture important indicators.

Examples include:

Even if the incident is closed, these indicators may prove valuable during future investigations.

Investigation Notes

Professional analysts keep notes throughout an investigation.

Example:

10:15

PowerShell observed.

10:18

Confirmed DNS query.

10:22

Suricata detected HTTP download.

10:25

Defender quarantined file.

10:30

No persistence identified.

Notice the notes are:

• Short

• Chronological

• Factual

Later, these notes become the final report.

Common Student Mistake

Students frequently wait until the investigation is complete before documenting anything. Hours later, important details have been forgotten. Professional analysts document continuously. Documentation is part of the investigation—not something performed afterward.

Investigation Report Template

Use the following structure for every incident report.

Incident Summary

Briefly describe the incident.

Initial Alert

• Rule ID

• Severity

• Time

• Host

Systems Involved

• Hostnames

• Users

• IP addresses

Timeline

Chronological sequence of events.

Evidence

List:

• Sysmon

• Suricata

• Defender

• Wazuh

• Linux Logs

Indicators of Compromise

Document all observed IOCs.

Analysis

Explain relationships among the evidence.

Conclusion

State:

• Assessment

• Confidence

• Recommended actions

Think Like a SOC Analyst

Imagine your shift ends at 5:00 PM. Another analyst begins work at 5:01 PM. They have never spoken to you.

Could they continue the investigation using only your documentation?

If the answer is yes, your documentation is effective. If the answer is no, your investigation is incomplete. Professional investigations must survive analyst shift changes, management review, audits, and legal scrutiny.

Objective

Conduct a structured investigation and prepare a professional incident report using evidence collected from your SOC laboratory.

Scenario

Generate the following controlled activity:

• Launch PowerShell.

• Perform a DNS lookup (nslookup example.com).

• Browse to a website.

• Download the EICAR test file (EICAR, n.d.).

• Observe Windows Defender quarantine the file.

• Locate the associated Wazuh and Suricata events.

Student Tasks

• Record the initial Wazuh alert.

• Expand the investigation window to ±15 minutes.

• Build a chronological timeline.

• Collect supporting evidence from:

• Sysmon

• Suricata

• Windows Defender

• Wazuh

• Record all relevant IOCs.

• Identify evidence supporting and contradicting your initial hypothesis.

• Write:

• An executive summary (150–200 words)

• A technical summary (300–500 words)

• A conclusion with a stated confidence level

• Peer-review another student’s report and identify:

• Missing evidence

• Unsupported conclusions

• Areas requiring clarification

Chapter Connection

The next section introduces evidence collection and preservation. Students will learn the distinction between operational monitoring and digital evidence, understand the principles of maintaining evidentiary integrity, preserve logs and artifacts for later analysis, and appreciate why proper handling of telemetry is essential for incident response, forensic investigations, compliance, and potential legal proceedings. This chapter naturally extends professional documentation by ensuring that the evidence described in reports remains trustworthy, reproducible, and defensible.

Learning Objectives

After completing this section, you should be able to:

• Explain the importance of evidence preservation.

• Differentiate operational logs from forensic evidence.

• Identify common digital evidence sources.

• Preserve security artifacts without modifying them.

• Understand chain of custody concepts.

• Collect evidence suitable for later forensic analysis.

Introduction

Imagine your organization experiences a ransomware attack. Within minutes, the Security Operations Center begins investigating. Alerts appear. Telemetry arrives. Processes execute. Network traffic is detected. Files are quarantined. Now imagine someone accidentally deletes the only log proving how the attacker entered the organization. The investigation becomes significantly more difficult. Professional cybersecurity investigations depend upon reliable evidence.

Evidence must be:

• Accurate

• Complete

• Verifiable

• Preserved

Without trustworthy evidence, even excellent investigations lose credibility.

What Is Digital Evidence?

Digital evidence is any information that helps establish facts regarding an investigation.

Examples include:

• Event Logs

• Sysmon Events

• Suricata Alerts

• Network Packet Captures

• Windows Registry

• Authentication Logs

• File Metadata

• Browser History

• Memory Images

• Disk Images

Every investigation combines multiple evidence sources.

Figure 4-22

Evidence Sources

Note. The figure summarizes evidence Sources and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Notice that evidence originates from many independent systems.

Operational Data Versus Forensic Evidence

These terms are often confused. They are not identical.

During normal SOC operations, telemetry flows continuously. When an incident occurs, selected telemetry becomes evidence.

Analyst Corner

A log file is not automatically forensic evidence. It becomes evidence when it is relevant to an investigation and is preserved appropriately. Context determines evidentiary value.

Primary Evidence Sources in Our Laboratory

Throughout this textbook we repeatedly collect evidence from these locations.

Students should become familiar with each location.

Preserve Before You Analyze

One of the first rules of digital forensics (Kent et al., 2006) is:

Preserve first. Analyze second.

Why?

Because analysis sometimes changes evidence.

Examples include:

• Opening files

• Restarting services

• Clearing logs

• Updating software

• Rebooting systems

These actions may overwrite valuable artifacts. Professional investigators minimize unnecessary changes.

Chain of Custody

In many organizations, evidence passes between multiple people.

Chain of custody documents:

• Who collected the evidence

• When it was collected

• Where it was stored

• Who accessed it

• Why it was transferred

Although our classroom laboratory does not require formal legal documentation, developing this habit prepares students for professional incident response and forensic work.

Example Chain of Custody Record

Evidence Integrity

How do you prove evidence was not modified?

One common technique is cryptographic hashing.

Example:

Figure 4-23

From Original File to Integrity Verified

Note. The sequence traces how Original File progresses to Integrity Verified, emphasizing the intermediate evidence and processing steps.

If the hash changes, the file changed. This concept becomes extremely important in later forensic chapters.

Collecting Wazuh Evidence

When documenting an alert, preserve more than a screenshot.

Record:

• Rule ID

• Timestamp

• Agent Name

• Alert Level

• Full JSON document

• Related events

• Investigation notes

Screenshots are useful. Structured data is better.

Collecting Suricata Evidence

Important artifacts include:

/var/log/suricata/eve.json suricata.log stats.log

If packet captures are available, preserve those as well.

Remember:

Suricata explains what it detected. A packet capture often explains why.

Collecting Sysmon Evidence

Useful artifacts include:

• Process Creation (Event ID 1)

• Network Connections (Event ID 3)

• CreateRemoteThread (Event ID 8)

• File Creation (Event ID 11)

• DNS Query (Event ID 22)

Students should record:

• Event ID

• Timestamp

• Process

• Parent Process

• User

• Command Line

These fields frequently become key investigative evidence.

Evidence Collection Matrix

Notice how each technology contributes different evidence.

Avoiding Evidence Contamination

Investigators should avoid actions that unnecessarily modify systems.

Examples include:

❌ Rebooting immediately

❌ Clearing log files

❌ Updating software before collecting evidence

❌ Restarting services without documenting the reason

Instead:

✓ Record observations. ✓ Preserve relevant logs. ✓ Document timestamps. ✓ Capture evidence before making corrective changes whenever practical.

Common Student Mistake

Students often troubleshoot first and document later.

Example:

Restart Suricata

Restart Wazuh

Clear logs

Run updates

Reboot

Only afterward do they ask:

“What happened?” Unfortunately, much of the evidence has already changed. Develop the habit of preserving relevant evidence before making significant system changes.

Investigation Exercise

A controlled malware simulation has generated the following telemetry:

• PowerShell execution

• DNS lookup

• HTTP download

• Suricata alert

• Windows Defender quarantine

Your task:

• Preserve the Wazuh alert.

• Record the Sysmon Event IDs.

• Preserve the Suricata alert from eve.json.

• Record the Defender event.

• Build a unified timeline.

• Calculate and record the SHA-256 hash of any downloaded sample (where appropriate and safe).

• Complete an evidence inventory.

Evidence Inventory Worksheet

Students should include this inventory with every investigation.

Think Like a SOC Analyst

Suppose you detect suspicious activity on a workstation. Two analysts respond.

Analyst A:

• Reboots the computer immediately.

• Installs updates.

• Clears temporary files.

• Restarts services.

Analyst B:

• Records timestamps.

• Preserves relevant logs.

• Exports key events.

• Documents the system state.

• Then begins remediation.

Which investigation would be easier to review next week?

Which one would withstand an external audit?

Professional analysts understand that preserving trustworthy evidence is just as important as finding it.

Key Concepts

By the end of this section, you should understand that:

• Digital evidence must be preserved before major changes are made.

• Operational telemetry can become forensic evidence during an investigation.

• Multiple independent evidence sources strengthen investigative conclusions.

• Documentation and evidence preservation are inseparable.

• Maintaining evidence integrity supports repeatability, incident response, compliance, and forensic analysis.

Looking Ahead

The next section introduces Indicators of Compromise (IOCs) and Indicators of Attack (IOAs). Students will learn the difference between static artifacts (such as file hashes, domains, and IP addresses) and behavioral indicators (such as suspicious process chains and attacker techniques). Using the SOC laboratory, they will identify, collect, and validate IOCs and IOAs from Sysmon, Suricata, Windows Defender, and Wazuh, laying the groundwork for threat hunting and detection engineering in later chapters.

Learning Objectives

After completing this section, you should be able to:

• Differentiate between Indicators of Compromise (IOCs) and Indicators of Attack (IOAs).

• Identify common IOC types collected by Wazuh.

• Recognize attacker behaviors represented by IOAs.

• Collect IOCs and IOAs from Sysmon, Suricata, Windows Defender, and Linux logs.

• Explain why behavioral detection is increasingly important.

• Document indicators during an investigation.

Introduction

Suppose your organization discovers malware on a workstation.

One investigator records:

• File hash

• Filename

• IP address

• Domain

Another investigator records:

• Word launched PowerShell.

• PowerShell contacted an external server.

• PowerShell downloaded an executable.

• The executable attempted persistence.

• Defender quarantined the file.

Which investigation is more valuable?

The answer is:

Both. One describes what was observed. The other describes how the attack occurred. Professional SOC analysts collect both types of indicators.

What Is an IOC?

An Indicator of Compromise (IOC) is an artifact that suggests a system may have been compromised (Cichonski et al., 2012). IOCs are typically static values.

Examples include:

• IP addresses

• Domain names

• URLs

• File hashes

• Registry keys

• File names

• Email addresses

• Certificate fingerprints

IOCs are often shared through threat intelligence feeds and block lists.

Common IOC Types

These indicators are valuable because they are easy to search and compare.

IOC Collection in Our SOC

Throughout this laboratory, Wazuh collects IOCs from multiple sources.

Notice that every technology contributes different artifacts.

Limitations of IOCs

Suppose malware uses:

bad.exe

Tomorrow, the attacker changes it to:

update.exe

Hash?

Changed.

Filename?

Changed.

Domain?

Changed.

IP?

Changed. Traditional IOC detection becomes much less effective. Attackers know defenders collect IOCs. Therefore, they change them frequently.

Analyst Corner

Think of an IOC as a license plate. It identifies one vehicle. If the criminal changes vehicles, the license plate no longer helps. Now imagine identifying the driver’s behavior instead. Behavior is much harder to disguise.

What Is an IOA?

An Indicator of Attack (IOA) identifies suspicious behavior rather than a specific artifact.

Instead of asking:

Which file?

IOAs ask:

What behavior occurred?

Behavior changes much more slowly than malware hashes.

Examples of IOAs

Notice that no hashes are required. The behavior itself is the indicator.

Figure 4-24

IOC vs. IOA

Note. The comparison highlights the operational differences represented by iOC vs. IOA and shows why the distinction matters during analysis.

Modern SOCs increasingly prioritize IOAs because they remain effective even when attackers modify specific artifacts.

Behavioral Detection

Consider the following sequence.

Figure 4-25

From WINWORD.EXE to Beaconing

Note. The sequence traces how WINWORD.EXE progresses to Beaconing, emphasizing the intermediate evidence and processing steps.

Every step represents behavior. Even if every file hash changes, the behavior remains highly suspicious.

Collecting IOAs from Sysmon

Sysmon provides excellent behavioral telemetry (Russinovich & Garnier, n.d.).

Examples include:

Combined, these events describe attacker activity rather than simply identifying malware.

Collecting IOAs from Suricata

Suricata observes network behavior.

Examples include:

• Port scans

• Command-and-control traffic

• Protocol anomalies

• Malware downloads

• DNS tunneling

• Suspicious TLS sessions

Notice again:

Behavior, not simply IP addresses.

Collecting IOAs from Wazuh

Because Wazuh correlates multiple telemetry sources, it often reveals behaviors that individual sensors cannot.

Example:

Figure 4-26

From PowerShell to Persistence

Note. The sequence traces how PowerShell progresses to Persistence, emphasizing the intermediate evidence and processing steps.

This sequence is significantly stronger than any individual event.

Case Study

Suppose Defender reports:

Trojan Detected

IOC Investigation:

• Hash

• Filename

• IP

• Domain

IOA Investigation:

• What launched the malware?

• Which user executed it?

• Did PowerShell download it?

• Did it attempt persistence?

• Was lateral movement attempted?

• Was data exfiltration observed?

Both investigations are useful. The IOA investigation provides much deeper understanding.

Threat Intelligence

Threat intelligence feeds frequently distribute IOCs.

Examples include:

• Malicious domains

• IP addresses

• File hashes

• URLs

Threat hunting frequently focuses on IOAs.

Examples include:

• PowerShell abuse

• Living-off-the-Land techniques

• Credential dumping

• Suspicious parent-child process relationships

• Network reconnaissance

Future chapters will combine both approaches.

Common Student Mistake

Students often record only:

• Hash

• IP

• Filename

Then stop.

Professional analysts also document:

• Process ancestry

• User activity

• Network behavior

• Timeline

• Correlated events

• MITRE ATT&CK techniques

• Detection rules triggered

Behavior tells the complete story.

Investigation Exercise

Perform the following activities.

• Open Microsoft Word.

• Launch PowerShell.

• Perform a DNS lookup.

• Browse to a website.

• Download the EICAR file.

• Observe Windows Defender detection.

Complete the following table.

Students should identify at least:

• Five IOCs

• Five IOAs

from the investigation.

IOC/IOA Worksheet

This worksheet will become a recurring artifact throughout the remainder of the course.

Think Like a SOC Analyst

Imagine an attacker changes:

• Every filename

• Every hash

• Every domain

• Every IP address

Would your SOC still detect the attack?

If your detections rely only on IOCs, perhaps not. If your detections focus on behaviors such as Office spawning PowerShell, suspicious parent-child processes, encoded commands, credential dumping, and unusual network communication, the answer is far more likely to be yes. Behavior is significantly harder to disguise than artifacts.

Key Concepts

By the end of this section, you should understand that:

• IOCs identify specific artifacts associated with an incident.

• IOAs identify attacker behaviors and techniques.

• Effective SOC investigations collect both.

• Behavioral detections remain useful even when attackers modify malware.

• Modern detection engineering increasingly emphasizes behaviors over individual artifacts.

Looking Ahead

The next section introduces the MITRE ATT&CK® Framework, which provides a standardized language for describing attacker behavior (MITRE Corporation, n.d.-a). Students will map Sysmon events, Suricata alerts, Windows Defender detections, and Wazuh rules to ATT&CK tactics and techniques, learning to interpret investigations in terms of adversary objectives rather than isolated alerts. This framework will become the organizing model for threat hunting, detection engineering, purple teaming, and incident response throughout the remainder of the textbook. It also establishes a common vocabulary used by SOCs, incident response teams, and threat intelligence analysts worldwide.

Learning Objectives

After completing this section, you should be able to:

• Explain the purpose of the MITRE ATT&CK Framework.

• Differentiate between tactics and techniques.

• Map Wazuh alerts to ATT&CK techniques.

• Use ATT&CK during investigations.

• Explain attacker objectives using standardized terminology.

• Recognize how ATT&CK supports detection engineering and threat hunting.

Introduction

Suppose two analysts investigate the same attack.

One writes:

Malware probably downloaded another file.

The second writes:

Activity is consistent with T1105 – Ingress Tool Transfer following T1059.001 – PowerShell execution.

Which report is easier for another analyst to understand?

The second.

Why?

Because ATT&CK provides a standardized vocabulary. As introduced in Chapter 1, rather than inventing descriptions, analysts describe attacker behavior using common terminology understood throughout the cybersecurity community.

A Brief Recap

Chapter 1 introduced the MITRE ATT&CK Framework as a shared vocabulary for adversary behavior — a publicly available knowledge base documenting real-world attacker tactics and techniques (MITRE Corporation, n.d.-a). This section moves from that introduction to application: using ATT&CK as a working investigative framework to map telemetry, describe attack progressions, and communicate findings. Rather than cataloging malware, ATT&CK catalogs how attackers operate.

It answers questions such as:

• How do attackers gain access?

• How do they execute malicious code?

• How do they establish persistence?

• How do they evade defenses?

• How do they steal credentials?

• How do they move laterally?

• How do they exfiltrate data?

ATT&CK focuses on behavior, making it an ideal companion to the IOC and IOA concepts introduced in the previous section (MITRE Corporation, n.d.-a).

Figure 4-27

ATT&CK Philosophy

Note. The figure summarizes aTT&CK Philosophy and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Notice that ATT&CK emphasizes behavior rather than individual malware samples.

ATT&CK Tactics

ATT&CK organizes attacker behavior into tactics.

A tactic answers the question:

What objective is the attacker trying to accomplish?

Common Enterprise tactics include:

Think of tactics as the attacker’s goals.

ATT&CK Techniques

Each tactic contains one or more techniques.

A technique answers the question:

How did the attacker accomplish the objective?

Example:

Techniques describe specific behaviors observed during an attack.

Analyst Corner

Students often memorize ATT&CK IDs. That is not the objective. The objective is understanding behavior. If you understand what PowerShell abuse looks like, you can always look up T1059.001. Understanding is more valuable than memorization.

Mapping Laboratory Events to ATT&CK

Throughout this textbook, students will map their laboratory activities to ATT&CK.

Notice that one investigation often maps to multiple techniques.

Figure 4-28

Mapping Events to ATT&CK

Note. The figure maps the principal dimensions of mapping Events to ATT&CK so analysts can compare relationships, identify gaps, and prioritize follow-up work.

ATT&CK and Wazuh

Many Wazuh rules include ATT&CK mappings.

An alert may contain information similar to:

• ATT&CK Tactic

• ATT&CK Technique

• ATT&CK ID

Students should learn to identify these mappings when reviewing alerts. They provide valuable context and facilitate communication among analysts.

ATT&CK and Sysmon

Sysmon provides telemetry for many ATT&CK techniques.

Examples include:

Notice that Sysmon does not “detect ATT&CK.” Rather, it records telemetry associated with behaviors described in ATT&CK.

ATT&CK and Suricata

Suricata observes attacker behavior occurring on the network.

Examples include:

Network telemetry frequently provides evidence supporting ATT&CK mappings identified from endpoint activity.

ATT&CK and Threat Hunting

Threat hunting often begins with ATT&CK.

Instead of searching for:

Malware hash

Hunters search for:

• Office spawning PowerShell

• Encoded PowerShell commands

• Unusual parent-child processes

• Credential dumping behavior

• Network reconnaissance

• Remote service creation

Behavior survives even when malware changes.

Building an ATT&CK Timeline

Consider the following investigation.

Rather than merely listing events, the analyst now describes attacker objectives.

Common Student Mistake

Students sometimes assume:

Every PowerShell execution equals T1059.001. Technically, PowerShell execution may correspond to that technique, but context determines whether it represents legitimate administration or malicious activity. ATT&CK describes behaviors. It does not automatically imply malicious intent. Evidence and context remain essential.

Investigation Exercise

Repeat the controlled laboratory exercise:

• Launch PowerShell.

• Perform a DNS lookup.

• Browse to a website.

• Download the EICAR file.

• Observe Defender detection.

Complete the following table.

Students should explain why they selected each mapping and identify any assumptions made.

ATT&CK Mapping Worksheet

This worksheet becomes part of every major investigation later in the course.

Think Like a SOC Analyst

Suppose two incident reports describe the same event.

Report A

PowerShell downloaded a file.

Report B

Evidence is consistent with Execution (T1059.001) followed by Ingress Tool Transfer (T1105). Additional network telemetry suggests possible Application Layer Protocol (T1071) activity. Supporting evidence was collected from Sysmon, Suricata, Windows Defender, and Wazuh.

Which report would be easier for another SOC analyst, threat hunter, or incident responder to understand?

Professional cybersecurity teams increasingly communicate using ATT&CK because it describes attacker behavior in a standardized, technology-neutral manner (MITRE Corporation, n.d.-a).

Key Concepts

By the end of this section, you should understand that:

• ATT&CK is a framework describing adversary behavior, not malware.

• Tactics describe attacker objectives.

• Techniques describe how those objectives are accomplished.

• Wazuh, Sysmon, and Suricata provide telemetry that can be mapped to ATT&CK.

• ATT&CK improves communication, detection engineering, threat hunting, and incident response.

• Context is essential—an ATT&CK technique describes behavior, but additional evidence is required to determine whether the behavior is malicious.

Looking Ahead

The next section introduces MITRE ATT&CK Navigator, where students will visualize detections across the ATT&CK matrix, identify coverage gaps within their laboratory SOC, and measure which adversary behaviors are currently detectable. They will use the telemetry generated throughout the course to build their first ATT&CK heat maps, assess detection maturity, and prioritize improvements. This marks the beginning of detection engineering, where the goal shifts from simply responding to alerts to deliberately improving the SOC’s ability to detect attacker behavior.

Learning Objectives

After completing this section, you should be able to:

• Explain the purpose of MITRE ATT&CK Navigator.

• Visualize detection coverage across ATT&CK techniques.

• Identify strengths and weaknesses within your SOC.

• Build an ATT&CK heat map.

• Measure detection maturity.

• Prioritize future detection engineering efforts.

Introduction

Suppose someone asks:

“How good is your SOC?”

Many beginning analysts answer:

“We have Wazuh.”

Or:

“We use Suricata.” Neither answer measures detection capability. Professional SOCs measure coverage, not products.

Coverage answers questions such as:

• Which ATT&CK techniques can we detect?

• Which techniques have partial visibility?

• Which techniques have no visibility at all?

• Which detections require improvement?

ATT&CK Navigator provides a visual method for answering these questions.

What Is ATT&CK Navigator?

MITRE ATT&CK Navigator is a visualization tool that allows analysts to map techniques onto the ATT&CK matrix. Instead of reading long technique lists, analysts see a visual representation of detection coverage. Think of it as a map of your SOC’s current visibility.

Figure 4-29

Detection Coverage Concept

Note. The figure maps the principal dimensions of detection Coverage Concept so analysts can compare relationships, identify gaps, and prioritize follow-up work.

The objective is not to make every square green. The objective is to understand where your visibility exists—and where it does not.

Why Coverage Matters

Imagine two SOCs.

SOC A

• Detects PowerShell

• Detects DNS

• Detects HTTP

• Detects Malware

SOC B

• Detects PowerShell

• Detects DNS

• Detects HTTP

• Detects Malware

• Detects Credential Dumping

• Detects Lateral Movement

• Detects Persistence

• Detects Defense Evasion

Which SOC is more mature?

Clearly SOC B. Coverage provides an objective method for measuring detection capability.

Our Laboratory Coverage

By the end of Chapter 4, our SOC detects behavior associated with several ATT&CK techniques.

This list will grow throughout the semester.

Analyst Corner

Students often ask:

“Is our SOC complete?” No. No SOC is. Detection engineering is an ongoing process. Every week, new attacker techniques appear. Every month, organizations improve coverage. Detection is never finished.

Detection Maturity

Note that this per-technique maturity scale is distinct from the SOC-wide SIEM maturity model in Section 2.12; here we measure how well the SOC detects a single technique, not the maturity of the SOC as a whole.

Rather than asking:

Can we detect T1059?

Ask:

How well can we detect T1059?

Example maturity scale:

Our laboratory aims to progress from Levels 1–2 early in the semester toward Levels 3–4 as students add correlation, custom rules, and threat hunting.

Building a Heat Map

Students should classify techniques into categories.

Example:

Visualization immediately highlights detection gaps.

Figure 4-30

Example Coverage Matrix

Note. The figure maps the principal dimensions of example Coverage Matrix so analysts can compare relationships, identify gaps, and prioritize follow-up work.

Notice that weaknesses become obvious.

Mapping Laboratory Exercises

Each laboratory contributes additional ATT&CK coverage.

Students should update their Navigator layer after every completed lab. By the end of the course, the heat map becomes a visual record of their learning.

Coverage Does Not Equal Prevention

Another common misconception:

Detection means protection. Not necessarily.

Detection answers:

Did we observe the activity?

Prevention answers:

Did we stop the activity?

Many organizations intentionally detect behaviors they choose not to block because the operational cost of false positives would be too high. Understanding this distinction is essential for designing practical security operations.

Identifying Detection Gaps

After mapping existing detections, ask:

• Which ATT&CK tactics have little or no visibility?

• Which techniques rely on only one sensor?

• Where would additional logging improve confidence?

• Which custom Wazuh rules should we develop?

• Would Sysmon configuration changes improve coverage?

• Would additional Suricata signatures increase visibility?

Detection engineering is a process of continuous improvement.

Common Student Mistake

Students often celebrate every new detection.

Professional engineers ask a different question:

What still goes undetected?

The objective is not simply to add detections. The objective is to reduce unknown risk.

Investigation Exercise

Using the laboratory completed so far:

• Review recent Wazuh alerts.

• Identify the associated ATT&CK techniques.

• Assign each technique a maturity level (0–5).

• Create a simple coverage table.

• Identify three techniques for which your SOC currently has little or no visibility.

• Recommend one improvement for each gap.

Sample Coverage Assessment

This table evolves as students complete additional chapters.

Designing Better Detections

Suppose students identify weak coverage for:

Credential Dumping.

Possible improvements include:

• Enable additional Sysmon logging.

• Develop custom Wazuh rules.

• Simulate Mimikatz in an isolated lab.

• Correlate LSASS access with PowerShell activity.

• Map detections to ATT&CK.

Notice that detection engineering is an iterative cycle.

Detection Engineering Workflow

Figure 4-31

From Identify Gap to Repeat

Note. The sequence traces how Identify Gap progresses to Repeat, emphasizing the intermediate evidence and processing steps.

This workflow becomes the foundation for later chapters on custom rule creation and purple teaming.

Think Like a Detection Engineer

Imagine your organization experiences an incident involving lateral movement. After the investigation, you discover that your SOC had excellent visibility into execution, but almost no visibility into remote administration protocols.

Rather than asking:

“Why didn’t Wazuh detect it?”

A better question is:

“What telemetry, rules, or sensors would have allowed us to detect it?” That shift—from blaming tools to improving coverage—is the hallmark of a mature detection engineering mindset.

Key Concepts

By the end of this section, you should understand that:

• Detection coverage is more meaningful than simply listing security tools.

• ATT&CK Navigator provides a visual representation of SOC visibility.

• Detection maturity can be measured and improved over time.

• Coverage assessments help prioritize engineering efforts.

• Effective SOCs continuously identify, validate, and close detection gaps.

Chapter Summary

Congratulations. By completing Chapter 4, you have transitioned from building a Security Operations Center to operating one.

You can now:

• Navigate the Wazuh Dashboard confidently.

• Conduct structured investigations.

• Use Discover to search millions of events efficiently.

• Build and analyze timelines.

• Correlate endpoint and network telemetry.

• Develop and test investigative hypotheses.

• Write professional incident reports.

• Preserve digital evidence.

• Differentiate IOCs from IOAs.

• Map activity to the MITRE ATT&CK Framework.

• Measure your SOC’s detection coverage using ATT&CK Navigator.

These skills form the analytical foundation required for the remainder of this textbook.

Chapter 4 Key Terms

Knowledge Check

Select the best answer for each question.

1. What is the primary purpose of the Discover interface in Wazuh?

A. To configure agent installation

B. To write Suricata rules

C. To search, filter, and investigate security events

D. To manage VMware snapshots

2. Why do experienced analysts expand the time window before and after an alert?

A. To reduce the number of events displayed

B. To reveal related activity that provides context for the investigation

C. To improve Suricata performance

D. It is required by the Wazuh license

3. Which best describes an Indicator of Compromise (IOC)?

A. A tactic used by MITRE ATT&CK

B. A category of Wazuh detection rule severity

C. A type of VMware network adapter

D. A forensic artifact such as a file hash, IP address, or domain tied to a known threat

4. Which best describes an Indicator of Attack (IOA)?

A. Evidence of attacker behavior or technique in progress, regardless of the specific tool used

B. A signature-based antivirus detection

C. A firewall configuration setting

D. A Suricata rule category

5. In MITRE ATT&CK, what does a technique ID such as T1059.001 represent?

A. A tactic

B. A Suricata signature ID

C. A Wazuh rule ID

D. A sub-technique — in this case, PowerShell under Command and Scripting Interpreter

6. Which MITRE ATT&CK tactic best describes T1003 (OS Credential Dumping)?

A. Discovery

B. Exfiltration

C. Credential Access

D. Initial Access

7. What is the purpose of the MITRE ATT&CK Navigator in a SOC?

A. To visualize and measure which adversary techniques the SOC can currently detect

B. To replace the Wazuh Dashboard

C. To install Suricata rules automatically

D. To generate VMware snapshots

8. Why should analysts avoid forming a conclusion before collecting evidence?

A. Evidence collection is optional in professional investigations

B. Premature conclusions introduce confirmation bias and can lead to incorrect findings

C. Wazuh requires evidence to be collected in a specific order

D. It has no real effect on investigation quality

9. What is the main goal of professional incident documentation?

A. To satisfy a checklist requirement

B. To reduce the number of alerts generated

C. To automatically close tickets

D. To allow another analyst to understand and reproduce your reasoning without speaking to you

10. Why is correlating endpoint and network telemetry more valuable than examining either source alone?

A. It reduces the total number of alerts

B. It is required by Wazuh licensing

C. No single sensor sees the entire attack; combining sources produces a more complete and reliable picture

D. Network telemetry is always more accurate than endpoint telemetry

Answer Key

Chapter Discussion Questions

• Why does a broad, expanding search strategy typically outperform a narrow search focused only on the original alert?

• Explain the difference between an Indicator of Compromise and an Indicator of Attack, and give an example of each from this chapter.

• Why is mapping an investigation to MITRE ATT&CK more useful than simply describing what happened in plain language?

• Describe how you would test a hypothesis during an investigation rather than simply accepting your first explanation.

• Why does professional incident documentation matter even when an alert turns out to be a false positive?

• Explain how the MITRE ATT&CK Navigator could be used to identify gaps in a SOC’s detection coverage.

• Walk through how you would correlate a Sysmon PowerShell event with a Suricata network alert during an investigation.

Looking Ahead — Chapter 5

Chapter 5 shifts from investigating alerts to engineering detections. Students will begin writing and tuning Wazuh rules, customizing Sysmon configurations, developing local Suricata signatures, reducing false positives, validating detections with controlled attack simulations, and measuring improvements using ATT&CK. By the end of the chapter, students will no longer be passive users of security tools—they will be capable of designing, testing, and maintaining their own detection capabilities, which is the defining skill of a modern Detection Engineer and an advanced Security Operations Center analyst.

Further Resources

• MITRE ATT&CK (https://attack.mitre.org) — Look up any technique ID you encounter in an alert.

• MITRE ATT&CK Navigator (https://mitre-attack.github.io/attack-navigator/) — Build the coverage layers described in section 4.9.

• NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response (https://csrc.nist.gov/pubs/sp/800/86/final) — Evidence handling principles that underpin section 4.6.

• Wazuh — User Manual (https://documentation.wazuh.com/current/user-manual/index.html) — Dashboard and Discover reference used throughout this chapter.

    Version 8       Page  of