Lab 7 — Threat Intelligence Investigation: Enriching Indicators and Operationalizing Intel

Objective

Take a set of raw indicators pulled from your own telemetry, enrich them against threat intelligence to reach a defensible verdict, then operationalize the confirmed malicious indicators inside Wazuh — turning "an unknown IP" into "a known-bad indicator my SIEM now alerts on."

Labs 5 and 6 taught you to find suspicious activity on the host and the wire. But finding a suspicious IP or domain is only half an analyst's job. The other half is answering the question every investigation eventually reaches: "Is this actually malicious, and how do I know?" That question is answered with threat intelligence — the enrichment of an indicator against what the broader security community already knows about it. This lab teaches the full intel workflow: extract indicators, enrich them, reach a verdict with confidence and sourcing, and feed the confirmed ones back into Wazuh so the SOC catches them automatically next time.

A Note on This Lab's Threat-Intel Approach

A full MISP (Malware Information Sharing Platform) deployment is the enterprise standard for managing threat intelligence, and Chapter 3 of the reference literature describes integrating MISP with Wazuh. However, a production MISP instance is resource-heavy (its own database, cache, and workers), which exceeds this laboratory's footprint. This lab therefore teaches the analyst skill MISP exists to support — indicator enrichment and operationalization — using free, publicly available threat-intelligence services (the same OSINT sources a MISP instance ingests as feeds) plus Wazuh's native CDB-list capability as the operationalization layer.

The skill is identical whether the intel comes from a local MISP GUI or a public API: extract an indicator, ask trusted sources what is known about it, weigh the evidence, and act. Students who later work with a full MISP deployment will find the workflow already familiar — MISP simply centralizes and automates the same steps.

Overview

You are handed a planted set of indicators — IPs, domains, and file hashes — presented as if extracted from a fresh incident. Some are genuinely malicious (known-bad, confirmed by public intel); some are benign (false alarms an analyst must clear). Your job is to enrich each one, sort malicious from benign, and produce two deliverables:

• A concise IOC report with a verdict, confidence, sourcing, and recommended actions for each indicator.

• A Wazuh CDB list and detection rule that operationalize the confirmed-malicious indicators, so any future match in your telemetry raises an alert.

Every activity follows the course pattern, adapted for intel work:

Extract → Enrich → Verdict (with sourcing) → Operationalize → Verify

Prerequisites

• Lab 0 completed — Wazuh operational, Dashboard reachable at https://192.168.1.30.

• Internet access from WIN11 (192.168.1.40) to reach public threat-intel services (browser-based enrichment).

• A free AbuseIPDB API key (register at abuseipdb.com) and/or an AlienVault OTX account — optional but recommended; the lab also works with the web UIs.

• On WAZUH-SRV: sudo access to edit /var/ossec/etc/lists/, ossec.conf, and local_rules.xml.

• The planted indicator set lab7-iocs.txt (provided with this lab).

Lab Environment Recap

Learning Outcomes

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

• Extract and normalize indicators of compromise (IOCs) from investigation data.

• Enrich IPs, domains, and file hashes against free public threat-intelligence services.

• Reach a defensible verdict for each indicator, citing sources and stating confidence.

• Distinguish a genuine malicious indicator from a benign false alarm.

• Author a Wazuh CDB list of known-bad indicators.

• Write a Wazuh rule that alerts when telemetry matches a CDB-listed indicator.

• Produce a professional IOC report with verdicts and recommended actions.

Key Terms

The Enrichment Services You Will Use

A safety note: You will look up indicators, not visit them. Never browse to a suspected-malicious domain or download a suspected-malicious file to "check" it. Enrichment services exist precisely so you can assess an indicator without touching it.

Task 1.1 — Review the Indicator Set

Open the provided lab7-iocs.txt on WIN11 (192.168.1.40). It contains a mixed set of indicators presented as if pulled from a recent investigation:

• Several IPv4 addresses

• Several domains

• Several file hashes (SHA-256)

Do not assume any are malicious yet. Some are planted known-bad indicators; some are deliberately benign (a legitimate CDN, a well-known domain, a clean file hash) included as false-positive traps.

Why this matters: Real IOC lists arrive dirty — mixed types, some benign, some malicious, often with duplicates or typos. An analyst who assumes everything on a list is bad will block legitimate services and erode trust in the SOC. The discipline is to treat every indicator as unverified until enrichment says otherwise.

Task 1.2 — Normalize and Categorize

Sort the indicators by type into your SOC Engineering Notebook:

Why this matters: Different indicator types are enriched with different services and different queries — you look up an IP's abuse history but a hash's antivirus verdict. Sorting first means you can batch-enrich efficiently and never apply the wrong lookup to the wrong type. Normalization (consistent case for hashes, stripped whitespace) also prevents lookup failures from formatting noise.

CONCLUSION: You have a clean, categorized worklist of unverified indicators. Every one now needs a verdict, and no indicator is guilty until the intelligence says so.

Task 2.1 — Enrich the IP Addresses

For each IPv4 indicator, query a reputation service. Using AbuseIPDB (web UI or API):

Web UI: browse to abuseipdb.com, enter the IP in the check box.

API (if you have a key):

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

curl -s -G https://api.abuseipdb.com/api/v2/check --data-urlencode "ipAddress=<IP>" -d maxAgeInDays=90 -H "Key: <YOUR_API_KEY>" -H "Accept: application/json"

Record for each IP:

| **Field** | **What to Record** |
| --- | --- |
| abuseConfidenceScore | 0-100; higher means more reported abuse |
| totalReports | How many distinct sources reported it |
| countryCode / ISP | Attribution context |
| usageType | Hosting, ISP, etc. |

Cross-check high-suspicion IPs against a second source (Talos or OTX) before finalizing.

Why this matters: A single source is a data point, not a verdict. abuseConfidenceScore is a community-derived signal, not proof — a high score from many independent reporters is strong evidence; a score of 5 from one reporter may be noise. Cross-checking against a second, independent service is how you separate a confirmed-bad IP from a mislabeled one. This is the same "cross-check independent vantage points" discipline from Lab 0, applied to intel.

Task 2.2 — Enrich the Domains

For each domain, use VirusTotal (Domains tab) and/or Talos:

• VirusTotal: how many engines flag it? What categories?

• Talos: what is the domain's reputation and category (e.g., "Malware," "Newly Seen")?

Record the number of detections, the categories, and any associated campaigns or malware families.

Why this matters: Domains carry context IPs often lack — a domain flagged by multiple engines and categorized as "malware C2" is a strong verdict, while a brand-new domain with no history ("Newly Seen") is suspicious but not yet confirmed. Learning to distinguish "confirmed malicious" from "suspicious, insufficient data" is exactly the judgment that separates an analyst from a blocklist.

Task 2.3 — Enrich the File Hashes

For each SHA-256, query VirusTotal (Files) — never download the file:

• How many of the ~70 antivirus engines detect it?

• What malware family names appear?

• What is the first-submission date?

Why this matters: A hash is the most decisive indicator type — a file's hash is unique, so a VirusTotal hit against a known malware sample is near-certain confirmation. Note the reasoning: unlike an IP (which can be shared or reassigned), a matching hash is the malicious file. This is why hash-based CDB detection (your capstone) is high-confidence and low-false-positive.

Task 2.4 — Reach a Verdict for Each Indicator

Complete the verdict column for every indicator. Use a consistent scheme:

For each, record the sources you used and a one-line justification.

Why this matters: A verdict without sourcing is an opinion; a verdict with sourcing is intelligence. The confidence level matters as much as the label — acting on a Medium-confidence verdict as if it were High is how SOCs block legitimate traffic. Recording why you reached each verdict makes your work defensible and reproducible, the same evidentiary standard your notebook has upheld since Lab 0.

Task 2.5 — Identify the False Positives

Explicitly flag the benign indicators — the traps. For each, note why it initially looked suspicious (if it did) and what evidence cleared it.

Why this matters: Clearing false positives is not a footnote — it is half the job. An analyst who can confidently say "this IP is a Cloudflare edge node, not an attacker" prevents an outage. The benign indicators in this set are there to train the reflex of disproving malice with the same rigor used to prove it. Never operationalize an indicator you have not cleared or confirmed.

CONCLUSION: Every indicator now has a sourced verdict. You have separated the genuinely malicious from the benign, with evidence for each — the raw material for both your report and your detection.

Task 3.1 — Understand the CDB List

A CDB (constant database) list is a text file of indicators — IPs, domains, hashes, or users — that Wazuh rules can look up as an allow or deny list. When telemetry contains a value matching a CDB entry, a rule can fire. You will build a deny list of your confirmed-malicious IPs and domains.

Why this matters: A CDB list turns your one-time investigation into standing detection. Every IP and domain you confirmed malicious today becomes something the SOC watches for indefinitely — without an analyst re-checking. This is the intelligence lifecycle closing: detection → investigation → enrichment → back to detection.

Task 3.2 — Create the CDB List File

On WAZUH-SRV, CDB lists live in /var/ossec/etc/lists/. Create a threat-intel list:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo nano /var/ossec/etc/lists/lab7-malicious-ips

Add your confirmed-malicious IPs in key:value format -- the indicator as the key, a label as the value:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

203.0.113.66:lab7-c2-confirmed
198.51.100.23:lab7-malware-host

(Use the actual IPs your enrichment confirmed as malicious. Include only High-confidence verdicts -- never a Suspicious/Medium indicator.)

Why this matters: The key:value format lets the value carry context -- when the alert fires, the label tells the responding analyst why this IP is listed and where the verdict came from. Including only High-confidence indicators is a deliberate discipline: a deny list is an automated action, and automating on a shaky verdict causes automated mistakes (blocking legitimate traffic at scale).

Task 3.3 — Reference the List in ossec.conf

Wazuh must be told the list exists. Edit the Manager configuration:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo nano /var/ossec/etc/ossec.conf

Inside the <ruleset> block, add a <list> entry:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

<ruleset>

  <!-- existing entries... -->

  <list>etc/lists/lab7-malicious-ips</list>

</ruleset>

Why this matters: The reference is what compiles your text file into the constant database Wazuh queries at runtime. Forgetting this step is the most common CDB error -- the file exists, the rule references it, but nothing fires because the Manager never loaded it. This is analogous to the "rules downloaded but not loaded" trap from Lab 0.

Task 3.4 — Write the Detection Rule

Add a rule to local_rules.xml that fires when a Suricata (or other) alert contains a source or destination IP found in your CDB list:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo nano /var/ossec/etc/rules/local_rules.xml

<group name="threat_intel,lab7,">

  <rule id="100710" level="12">

    <if_group>suricata</if_group>

    <list field="data.dest_ip" lookup="address_match_key">etc/lists/lab7-malicious-ips</list>

    <description>Lab7: Connection to known-malicious IP (threat intel match): $(data.dest_ip)</description>

    <mitre>

      <id>T1071</id>

    </mitre>

    <options>no_full_log</options>

  </rule>

</group>

Why this matters: Read the rule as intel-driven logic. suricata scopes it to network events; performs the CDB lookup -- if the alert's destination IP is in your list, the rule fires. level 12 puts a confirmed-intel match in the High band, and the $(data.dest_ip) in the description injects the offending IP into the alert. This rule means: any future connection to a confirmed-bad IP -- from any host, in any Suricata alert -- now generates a high-severity, intel-attributed alert. You have operationalized your investigation.

Task 3.5 — Validate and Restart

The Lab 0 / Lab 5 discipline — validate before restart:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo /var/ossec/bin/wazuh-logtest

sudo systemctl restart wazuh-manager

sudo /var/ossec/bin/wazuh-control status

Confirm all services return healthy.

Why this matters: A CDB rule with a malformed reference or a bad path can prevent the ruleset from loading -- the same "test, then apply" habit applies. wazuh-logtest confirms the configuration parses before you commit it with a restart.

Task 3.6 — Test the Detection

Generate a controlled connection attempt toward one of your CDB-listed IPs so Suricata reports it and your rule evaluates the destination. (Use a benign-but-listed test IP, or a lab-safe method your instructor specifies — do not actually connect to real malicious infrastructure.) Then, in the Dashboard:

::: {custom-style="CodeLabel"} Wazuh Dashboard · Discover query :::

rule.id:"100710"

Expected result: your intel-driven alert fires at level 12, naming the matched IP.

Why this matters: Testing proves the loop is closed. A CDB list and rule that are deployed but never shown to fire are unverified -- the same standard as every detection you built in Labs 5 and 6. When this alert fires on a known-bad IP with no analyst in the loop, your threat intelligence is doing its job.

CONCLUSION: You operationalized confirmed intelligence into a live Wazuh detection. Future connections to any indicator you confirmed today will now raise an automatic, high-severity, attributed alert.

Task 4.1 — Write the IOC Report

Produce a short report (one to two pages) containing:

1. Summary — one paragraph: what the indicator set was, how many were confirmed malicious vs. benign, and the top recommended action.

2. Indicator Findings Table:

3. Recommended Actions — for the confirmed-malicious indicators: what should the SOC do? (Block at firewall, add to CDB deny list — done — hunt for prior connections, etc.) For the benign: explicitly state they are cleared and should not be blocked.

4. Operationalization — note that the confirmed indicators were added to the Wazuh CDB list (name the list and rule ID) and that detection is now active.

Why this matters: The report is where investigation becomes decision. An incident commander does not read raw enrichment output — they read your verdict, your confidence, and your recommendation. Explicitly clearing the benign indicators is as important as flagging the malicious ones: it tells the SOC what not to block, preventing self-inflicted outages. This report is the analyst's actual product; everything before it was the work that earned the right to write it.

Task 4.2 — State Confidence and Limits

In a closing note, address:

• Which verdicts are High confidence and which are Medium (and why the Medium ones need more data before action).

• The perishability of intelligence: an IP clean today may be compromised tomorrow, and a malicious IP may be remediated and reassigned. How often should this list be reviewed?

• What you did not check (e.g., you enriched but did not sandbox the hashed files) and what a deeper investigation would add.

Why this matters: Intelligence has a shelf life and a confidence level, and a report that hides its own uncertainty is dangerous. Stating what you are not sure of, and what you did not do, is what makes an intel product trustworthy. The reviewer needs to know the boundaries of your confidence to weigh your recommendations correctly — the same intellectual honesty your notebooks have modeled throughout the course.

CONCLUSION: You produced a professional intelligence product — sourced verdicts, clear recommendations, and honest limits — and operationalized its confirmed findings in the SIEM. This is the complete threat-intelligence workflow, from raw indicator to standing detection to communicated decision.

Answer Key

About the Planted Indicators

The lab7-iocs.txt set is deliberately mixed: confirmed-malicious indicators drawn from well-known, safely-referenceable sources, alongside benign false-positive traps (legitimate CDNs, popular domains, clean file hashes). The malicious indicators are chosen to be known-bad in public intel so enrichment returns clear, reproducible results — and safe to reference (you look them up; you never connect to them).

Recommended Safe Indicator Categories

Instructors building or refreshing the set should choose indicators that are (a) reliably flagged by public intel and (b) safe to reference:

Determinism note: Public reputation scores drift over time. For a graded lab, verify each planted indicator's current enrichment result on your master run shortly before the assignment, and record the expected verdicts in the Answer Key. The EICAR hash is the most stable malicious indicator (always flagged); a real-world abuse IP's score may change week to week.

The EICAR Hash (Guaranteed-Safe Malicious Indicator)

The EICAR test file is the safest possible "malicious" indicator: every antivirus engine flags it, yet it is completely harmless. Its content is a fixed ASCII string, and its SHA-256 is stable. Including it guarantees at least one indicator returns a clear, reproducible "malicious" verdict from VirusTotal regardless of when the lab is run.

Enrichment Service Reference

AbuseIPDB (IP reputation)

• Web: abuseipdb.com — paste an IP into the check field.

• API:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

curl -s -G https://api.abuseipdb.com/api/v2/check --data-urlencode "ipAddress=<IP>" -d maxAgeInDays=90 -H "Key: <API_KEY>" -H "Accept: application/json"

• Key fields: abuseConfidenceScore (0-100), totalReports, countryCode, usageType.

VirusTotal (hashes, domains, URLs, IPs)

• Web: virustotal.com -- paste a hash, domain, or IP (never upload a suspected-malicious file; search by hash).

• Key fields: last_analysis_stats (malicious/suspicious/harmless counts), popular_threat_classification, first_submission_date.

AlienVault OTX (IPs, domains, hashes, pulses)

• Web: otx.alienvault.com -- search the indicator; review associated "pulses" (campaigns).

• Useful for seeing whether an indicator is tied to a named threat campaign.

Cisco Talos (domain/IP reputation, no key)

• Web: talosintelligence.com/reputation_center -- enter a domain or IP for reputation and category.

Expected Verdict Table (Instructor Reference)

INSTRUCTOR: Fill in the actual indicators and verify their live enrichment before each offering. Template:

Building the CDB List — Reference

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

# On WAZUH-SRV
sudo nano /var/ossec/etc/lists/lab7-malicious-ips

# key:value, confirmed-malicious only:
203.0.113.66:lab7-c2-confirmed
198.51.100.23:lab7-malware-host

# Reference it in ossec.conf <ruleset>:
#   <list>etc/lists/lab7-malicious-ips</list>

# Add the rule to local_rules.xml (see Task 3.4), then validate and restart:
sudo /var/ossec/bin/wazuh-logtest
sudo systemctl restart wazuh-manager

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo /var/ossec/bin/wazuh-control status

Note on CDB compilation: Wazuh compiles the list on Manager restart. If the rule never fires, verify (1) the <list> line is inside <ruleset>, (2) the path is relative (etc/lists/...), and (3) the file has no trailing blank-key lines. These mirror the three most common CDB pitfalls.

Instructor Notes

• Per-section uniqueness: Swap the planted IPs/domains per section so verdicts and CDB entries differ, defeating answer sharing. Keep the EICAR hash as a constant "known-good malicious" anchor.

• API keys: AbuseIPDB and OTX free keys are sufficient. If students cannot register, the web UIs cover every task — the API is a convenience, not a requirement.

• No-Internet fallback: If the lab network blocks outbound Internet, pre-capture the enrichment results (screenshots/JSON) for each indicator and provide them as an "intel packet," turning the lab into an analysis-only exercise while preserving the verdict/report/CDB workflow.

• Active Response extension (advanced): Pair the CDB rule with Wazuh Active Response to automatically block a matched IP at the endpoint firewall — a strong lead-in to the incident-response material, with an explicit discussion of the risks of automated blocking on a threat-intel match.

• MISP forward-reference: For programs that later deploy MISP, note that the CDB list here is the manual equivalent of a MISP feed export — the same indicators, centralized and automated in a full deployment.