"Lab 16 — Threat Intelligence and IOC Enrichment"

Mission Information

Item	Details
Lab	16
Lab Name	Threat Intelligence and IOC Enrichment
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	CySA+ SOC Investigation Lab
Primary Systems	Analyst Workstation + SIEM
Primary Data Types	IP Addresses, Domains, URLs, File Hashes
Skills	Threat Intelligence, IOC Enrichment, Reputation Analysis, DNS Context, Indicator Correlation, Confidence Assessment, SIEM Pivoting

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

During previous investigations, your SOC collected multiple indicators:

Suspicious IP addresses
Domains
URLs
File hashes
Email addresses
Hostnames

An indicator by itself provides limited context.

For example:

203.0.113.50

does not tell you:

Who owns it?
What infrastructure uses it?
Has it been reported as malicious?
Is it associated with malware?
Has your organization communicated with it?
Is it part of a larger campaign?

Your job is to enrich these raw indicators and transform them into useful investigation intelligence.

You will investigate indicators from previous labs and determine:

• reputation

• historical observations

• registration context

• DNS relationships

• malware associations

• known threat activity

• confidence

• organizational exposure

• related indicators

• whether the IOC should be blocked, monitored, or treated as informational

Mission Objective: Enrich security indicators with contextual intelligence and correlate them with internal telemetry to support accurate SOC investigation decisions.

Mission Objectives

By completing this lab, you will be able to:

• explain threat intelligence fundamentals

• distinguish raw indicators from enriched intelligence

• classify common IOC types

• enrich IP addresses

• enrich domains

• enrich URLs

• enrich file hashes

• understand reputation data

• investigate registration context

• investigate DNS relationships

• identify malware associations

• assess source reliability

• assign confidence levels

• recognize false-positive risks

• correlate external intelligence with SIEM telemetry

• build indicator relationships

• document threat-intelligence findings

1. What Is Threat Intelligence?

Threat intelligence is contextual information that helps defenders understand threats and make better security decisions.

A simple progression is:

Raw Data
   ↓
Information
   ↓
Context
   ↓
Analysis
   ↓
Threat Intelligence

For example:

Raw Data:
203.0.113.50

becomes more useful when enriched:

IP:
203.0.113.50

Hosting:
Cloud Provider

Observed Activity:
Malware Delivery

First Seen:
Recent

Associated Domains:
Multiple suspicious domains

Internal Activity:
Three endpoints connected

Confidence:
High

2. Indicator vs Intelligence

An indicator may be:

IP Address
Domain
URL
File Hash
Email Address
Certificate Fingerprint

Threat intelligence adds:

Reputation
Context
Relationships
History
Confidence
Relevance

The distinction is:

IOC
 ↓
What is this?

versus:

Threat Intelligence
 ↓
Why does it matter?

3. Common IOC Types

You will work primarily with:

Indicator	Example
IPv4	203.0.113.50
Domain	example.invalid
URL	hxxps://example[.]invalid/login
SHA-256	<64-character hash>
Email	sender@example.invalid

Other indicators may include:

File Names
Registry Keys
Mutexes
User Agents
TLS Certificates
Hostnames

4. Start the Lab Environment

Start:

CYSA-ANALYST
10.10.10.10

CYSA-SIEM
10.10.10.40

Ensure your SIEM contains telemetry from previous labs, including where available:

Windows
Linux
Zeek
Suricata
Phishing investigation
Malware investigation

5. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB16/{IOCs,Enrichment,DNS,ThreatIntel,Screenshots,Findings}

Create notes:

touch ~/CySA-Lab/Investigations/LAB16/investigation-notes.md

Use:

Investigation ID:
LAB16-INTEL-001

6. Import Indicators from Previous Labs

Use indicators collected during:

Lab 11 — Phishing
Lab 12 — Malware Analysis
Lab 13 — Endpoint Malware Investigation
Lab 15 — Vulnerability Prioritization

Create:

~/CySA-Lab/Investigations/LAB16/IOCs/iocs.txt

Example:

203.0.113.50
suspicious.example.invalid
hxxps://suspicious[.]example[.]invalid/login
<sha256>

Use real indicators only from safe training evidence.

7. Defang Active Indicators

When documenting potentially malicious infrastructure, use safe forms.

Example:

https://example.com

becomes:

hxxps://example[.]com

IP:

203.0.113.50

may be documented as:

203[.]0[.]113[.]50

Keep the raw value separately when required for SIEM searches.

8. Build an IOC Inventory

Create:

IOC ID	Type	Indicator	Source
IOC-001	IP	203[.]0[.]113[.]50	Malware Lab
IOC-002	Domain	suspicious[.]example	Phishing Lab
IOC-003	URL	hxxps://…	Phishing Lab
IOC-004	SHA-256	<hash>	Malware Lab

Add:

First Seen
Last Seen
Confidence
Status

later.

9. Prioritize Indicators for Enrichment

Not every indicator deserves equal effort.

Prioritize based on:

Alert Severity
Observed Internal Activity
Potential Malware Association
Authentication Correlation
Threat Relevance
Asset Criticality

For this lab, select:

1 IP
1 Domain
1 URL
1 File Hash

for deeper enrichment.

10. Enrich an IP Address

For your selected IP, investigate:

Ownership / ASN
Hosting Provider
Country / Region
Reputation
Historical Reports
Associated Domains
Malware Associations
Scanning Activity
Proxy / VPN / Hosting Context

Use approved threat-intelligence sources.

11. Understand IP Ownership Context

An IP may belong to:

Cloud Provider
CDN
Residential ISP
Hosting Provider
Enterprise
VPN Provider
Security Scanner

A cloud IP is not automatically malicious.

Attackers also use legitimate cloud infrastructure.

Therefore:

Hosting Provider
≠
Threat Verdict

12. Investigate ASN Context

Record:

ASN
Organization
Network Range

This helps identify whether multiple suspicious IPs belong to the same infrastructure.

Example:

IOC-001
   ↓
ASN 64500
   ↓
Hosting Provider

13. Investigate IP Reputation

Review available intelligence:

Malicious Reports
Spam Activity
Scanning
Botnet Activity
Malware C2
Phishing Hosting
Brute Force

Record:

Reputation:
Malicious / Suspicious / Neutral / Unknown

and:

Confidence:
Low / Medium / High

14. Investigate First-Seen and Last-Seen Context

Where available, record:

First Seen
Last Seen
Recent Activity

A recently observed IP may indicate active infrastructure.

An older IP may have changed ownership.

Historical context matters.

15. Investigate Associated Domains

Threat-intelligence platforms may show domains resolving to or associated with the IP.

Example:

203.0.113.50
      ↓
login-secure.example
update-service.example
cdn-example.example

Multiple suspicious relationships can increase confidence.

16. Enrich a Domain

For the selected domain, investigate:

Registration
DNS
Hosting
Reputation
Certificate Context
Associated IPs
Subdomains
Malware Associations
Phishing Reports

17. Investigate Registration Context

Where approved, review:

Registrar
Creation Date
Expiration Date
Name Servers
Registration Status

Some registration data may be privacy protected.

Treat privacy protection as:

Neutral

not:

Malicious

18. Investigate Domain Age

A newly registered domain impersonating a trusted brand may deserve additional scrutiny.

Example:

Brand Impersonation
      +
Domain Created 2 Days Ago
      +
Credential Login Page

is more suspicious than domain age alone.

19. Investigate DNS Records

Using your analyst workstation, for safe domains you control or approved training infrastructure:

dig <domain>

Review:

A
AAAA
MX
NS
TXT
CNAME

You can also use:

nslookup <domain>

Do not intentionally browse to suspicious infrastructure.

20. Understand DNS Relationships

A domain may resolve:

Domain
  ↓
IP Address

The IP may host:

Multiple Domains

The domain may also use:

CNAME
      ↓
Another Domain

These relationships help build infrastructure context.

21. Investigate Name Servers

Review:

NS records

Shared name-server infrastructure can sometimes reveal related domains.

However, many legitimate domains share hosting and DNS providers.

Avoid over-interpreting infrastructure reuse.

22. Investigate MX Records

For domains involved in phishing emails, inspect:

MX

This helps determine whether the domain receives email.

A phishing domain may:

Host Web Content Only

or:

Send and Receive Email

depending on campaign design.

23. Investigate TXT Records

TXT records may contain:

SPF
Domain Verification
Service Metadata

This can provide context about how the domain is configured.

Remember:

Valid SPF
≠
Legitimate Domain

24. Enrich a URL

A URL adds more detail than a domain.

Example:

hxxps://example[.]invalid/login/verify

Investigate:

Domain
Path
Query Parameters
Redirects
Reputation
Detection History

25. Break the URL into Components

Document:

Scheme
Hostname
Port
Path
Query
Fragment

Example:

Scheme:
https

Host:
login.example.invalid

Path:
/account/verify

Query:
id=1234

26. Investigate URL Reputation Safely

Use approved reputation or sandbox intelligence sources.

Do not navigate directly to the URL.

Review:

Classification
First Seen
Last Seen
Phishing Reports
Malware Reports
Redirect History

27. Investigate Redirect Relationships

A URL may redirect:

URL A
  ↓
URL B
  ↓
URL C

The initial URL may be benign-looking while the final destination is malicious.

Record:

Initial URL
Final URL
Intermediate Redirects

only through safe intelligence methods.

28. Enrich a File Hash

Use the SHA-256 from Lab 12 or Lab 13.

Search using approved malware-intelligence services.

Record:

Detection Count
Classification
Malware Family
Tags
First Seen
Last Seen
Associated Domains
Associated IPs
Behavioral Summary

Prefer hash lookup before uploading any file.

29. Interpret Malware Detection Results

Suppose several vendors classify the file as:

Trojan
Downloader
Backdoor

Naming may vary significantly.

Focus on:

Consensus
Behavior
Relationships
Confidence

rather than assuming all vendor family names will match.

30. Understand Unknown Hashes

If:

Hash Not Found

do not conclude:

File Is Benign

It may be:

New
Targeted
Rare
Modified
Private

Unknown means:

Insufficient External Intelligence

31. Build Indicator Relationships

Suppose:

SHA-256
   ↓
Domain A
   ↓
IP B

and:

Phishing URL
   ↓
Domain A

You now have:

Phishing
   +
Malware
   +
Infrastructure

linked through shared indicators.

32. Create an IOC Relationship Map

Document conceptually:

Phishing Email
      ↓
URL
      ↓
Domain
      ↓
IP Address
      ↑
Malware Sample
      ↑
SHA-256

This is much more useful than isolated indicators.

33. Understand Indicator Confidence

Use confidence levels:

Low
Medium
High

Example:

Domain found only in binary strings:
Medium

versus:

Domain observed in endpoint DNS
+
Threat intelligence confirms malicious use:
High

34. Understand Intelligence Source Reliability

Different intelligence sources have different quality.

Ask:

Who produced the information?

Is the source reputable?

Is the observation recent?

Is there supporting evidence?

Is the intelligence primary or copied?

Does another source confirm it?

Do not blindly trust one reputation score.

35. Distinguish Confidence and Severity

An IOC may have:

High Confidence

that it is malicious but:

Low Organizational Impact

if nobody in your environment contacted it.

Another indicator may have:

Medium Confidence

but affect:

Critical Identity Infrastructure

Both dimensions matter.

36. Search the SIEM for the IP IOC

Search the raw IP:

<IOC IP>

Look across:

Zeek
Suricata
Firewall
Endpoint
DNS
Authentication

Determine:

Which hosts communicated?

When?

Which ports?

How frequently?

37. Search the SIEM for the Domain IOC

Search:

<IOC domain>

Look for:

DNS queries
HTTP requests
TLS SNI
Proxy activity
Endpoint events

Document all affected systems.

38. Search the SIEM for the URL IOC

If proxy or HTTP telemetry is available, search:

URL
Path
Hostname

You may find:

Email Delivery
      ↓
User Endpoint
      ↓
HTTP Request

This strengthens phishing investigation context.

39. Search the SIEM for the Hash IOC

If endpoint telemetry contains hashes:

SHA-256

search across:

CYSA-WIN01
Other endpoints
File events
Process events
EDR telemetry

Determine scope.

40. Pivot from IOC to Host

Suppose:

Suspicious IP
      ↓
CYSA-WIN01

Now pivot to:

CYSA-WIN01

Review surrounding activity:

Authentication
Processes
DNS
PowerShell
File activity

The IOC becomes a starting point—not the conclusion.

41. Pivot from Host to User

Identify:

User logged onto affected host

Then search the user across the SIEM.

Determine whether the same identity appears on additional systems or in suspicious authentication events.

42. Pivot from User to Additional Indicators

A user investigation may reveal:

Second Host
Different IP
New Domain
Additional Alert

Add new indicators to the investigation queue.

Threat-intelligence analysis is often iterative.

43. Understand IOC Aging

Indicators lose value over time.

For example:

Malicious Cloud IP

may later be reassigned to a legitimate customer.

Therefore track:

First Seen
Last Seen
Review Date
Expiration

Long-term blocking of volatile indicators can create false positives.

44. Understand IOC Types by Stability

Generally:

File Hash

can be highly specific but easily changed.

IP Address

may be rapidly reassigned.

Domain

may persist longer but can also change infrastructure.

Behavioral indicators can often be more resilient than static IOCs.

45. IOC vs TTP

IOC-based detection asks:

Did we see this exact IP/domain/hash?

TTP-based detection asks:

Did we observe this attacker behavior?

A mature SOC uses both.

For example:

IOC:
Known malicious domain

plus:

Behavior:
PowerShell spawned from Office application

provides stronger coverage.

46. Identify False-Positive Risks

An IP may be associated with:

Shared Hosting
Cloud Services
CDNs
Public DNS
Security Scanners

Blocking the entire IP may disrupt legitimate services.

Always evaluate:

Infrastructure Context
+
Organizational Usage

before recommending a block.

47. Determine IOC Disposition

Use classifications such as:

Confirmed Malicious
Suspicious
Benign
Unknown
Expired
False Positive

Also determine action:

Block
Monitor
Hunt
No Action
Continue Investigation

48. Create the Enrichment Record

For each IOC, document:

## IOC-001

### Indicator

203[.]0[.]113[.]50

### Type

IPv4

### Source

Endpoint Malware Investigation

### External Reputation

Document findings.

### Infrastructure Context

Document:
- ASN
- provider
- region
- hosting context

### Relationships

Document:
- domains
- hashes
- URLs
- campaigns

### Internal Observations

Document:
- affected hosts
- timestamps
- ports
- event sources

### Confidence

Low / Medium / High

### Classification

Malicious / Suspicious / Benign / Unknown

### Recommended Action

Block / Monitor / Hunt / No Action / Continue Investigation

49. Build the IOC Enrichment Table

Create:

IOC	Type	External Verdict	Internal Match	Confidence	Action
IOC-001	IP	Suspicious	Yes	High	Hunt
IOC-002	Domain	Malicious	Yes	High	Block
IOC-003	URL	Phishing	Yes	High	Block
IOC-004	Hash	Known Malicious	No	High	Hunt

This gives the SOC a concise operational view.

50. Build a Relationship Table

Create:

Indicator A	Relationship	Indicator B
Hash	Communicates with	Domain
Domain	Resolves to	IP
URL	Hosted on	Domain
Endpoint	Queried	Domain
User	Logged onto	Endpoint

These relationships help reconstruct campaigns.

51. Build an Investigation Timeline

Example:

Time	Event
08:45	Phishing email delivered
08:50	URL accessed
08:51	Domain resolved
08:51	Endpoint connected to suspicious IP
08:55	File downloaded
09:00	Hash observed
09:05	Threat intelligence enrichment completed

This connects threat intelligence with operational telemetry.

52. Determine Organizational Exposure

For each confirmed malicious indicator, ask:

Did we communicate with it?

How many hosts?

How many users?

How many times?

When did communication begin?

When did it stop?

Are any critical systems affected?

External intelligence without internal exposure may require hunting.

External intelligence plus internal matches may require incident response.

53. Hunt for Related Indicators

If one IOC is confirmed malicious, search for:

Related Domains
Associated IPs
Sibling URLs
Related File Hashes
Malware Family
Certificate Fingerprints

Do not automatically block every related indicator.

Validate relevance.

54. Create an Indicator Watchlist

For suspicious but unconfirmed IOCs, create:

Monitor List

Include:

Indicator
Reason
Confidence
Review Date
Expiration

This avoids permanently treating uncertain intelligence as malicious.

55. Build an IOC Lifecycle

A useful lifecycle is:

Collected
   ↓
Enriched
   ↓
Validated
   ↓
Deployed
   ↓
Monitored
   ↓
Reviewed
   ↓
Expired / Retired

Threat intelligence requires ongoing maintenance.

56. Map Intelligence to MITRE ATT&CK Context

Where evidence supports it, record behaviors associated with the indicator.

For example:

Phishing Domain
      ↓
Phishing

Malware C2 Domain
      ↓
Application Layer Protocol

Do not assign ATT&CK techniques based solely on reputation labels.

Use observed behavior.

57. Mission Challenge — IOC Enrichment Investigation

The SOC provides four indicators collected from recent incidents:

IOC-001 — IP Address
IOC-002 — Domain
IOC-003 — URL
IOC-004 — SHA-256

Your task is to determine:

1. What type is each IOC?

2. Where was each originally observed?

3. What does external intelligence say?

4. What is the IP ownership or hosting context?

5. What domains are associated with the IP?

6. When was the domain registered?

7. Which IPs does the domain resolve to?

8. What reputation does the domain have?

9. What does the URL path indicate?

10. Are redirects present?

11. Is the hash known?

12. Is a malware family associated?

13. What network infrastructure is associated with the sample?

14. Do multiple IOCs point to the same infrastructure?

15. Do any indicators appear in the SIEM?

16. Which internal hosts match?

17. Which users are associated?

18. What is the timeline?

19. What confidence should be assigned?

20. Which indicators should be blocked?

21. Which should be monitored?

22. Which require additional hunting?

23. Are any indicators likely false positives?

24. What is your final assessment?

58. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB16/investigation-notes.md

Use:

# LAB16 Threat Intelligence Investigation

## Investigation ID

LAB16-INTEL-001

## Indicator Summary

Document:
- indicator
- type
- source
- first seen

## IP Intelligence

Document:
- ASN
- provider
- hosting type
- reputation
- associated domains

## Domain Intelligence

Document:
- registration context
- DNS
- reputation
- related infrastructure

## URL Intelligence

Document:
- domain
- path
- parameters
- redirects
- reputation

## File Intelligence

Document:
- SHA-256
- classification
- malware family
- first seen
- related infrastructure

## Indicator Relationships

Document relationships between:
- IP
- domain
- URL
- hash
- endpoint
- user

## SIEM Correlation

Document:
- internal matches
- affected systems
- users
- timestamps

## Confidence

Assign:
- Low
- Medium
- High

## Classification

Malicious / Suspicious / Benign / Unknown

## Recommended Action

Block / Monitor / Hunt / No Action / Continue Investigation

## Analyst Assessment

Summarize the investigation.

59. Example Analyst Findings

A simulated assessment may resemble:

Investigation:
LAB16-INTEL-001

Primary Domain:
suspicious[.]example

External Intelligence:
Multiple intelligence sources associate the domain with credential phishing.

Infrastructure:
The domain resolved to a cloud-hosted IP also associated with additional suspicious domains.

File Intelligence:
The SHA-256 identified during the malware investigation was associated with the same infrastructure.

Internal Exposure:
CYSA-WIN01 queried the suspicious domain and established a network connection shortly after receiving the phishing message.

Relationships:
Phishing URL
      ↓
Domain
      ↓
IP
      ↑
Malware Sample

Confidence:
High

Classification:
Malicious Infrastructure — Simulated Laboratory Scenario

Recommended Action:
Block validated malicious indicators, search all telemetry for related infrastructure, investigate affected endpoints and identities, and monitor related indicators for further activity.

60. Evidence to Capture

Capture:

01-ioc-inventory.png
02-ip-reputation.png
03-ip-asn-context.png
04-associated-domains.png
05-domain-registration.png
06-domain-dns.png
07-domain-reputation.png
08-url-analysis.png
09-url-redirects.png
10-hash-reputation.png
11-malware-family.png
12-related-infrastructure.png
13-ioc-relationship-map.png
14-siem-ip-search.png
15-siem-domain-search.png
16-siem-hash-search.png
17-endpoint-pivot.png
18-user-pivot.png
19-ioc-enrichment-table.png
20-investigation-timeline.png
21-final-assessment.png

61. Validation Checklist

• Threat intelligence concepts were understood

• Raw indicators were imported

• Indicators were categorized by type

• Active indicators were safely defanged for documentation

• IOC inventory was created

• IP ownership was investigated

• ASN context was reviewed

• IP reputation was investigated

• First-seen and last-seen context was considered

• Associated domains were investigated

• Domain registration context was reviewed

• Domain age was considered

• DNS records were investigated

• Name-server context was considered

• URL structure was analyzed

• Redirect relationships were investigated

• File hash was enriched

• Malware associations were reviewed

• Unknown-hash limitations were understood

• Indicator relationships were created

• Intelligence-source reliability was considered

• Confidence levels were assigned

• SIEM was searched for IP indicators

• SIEM was searched for domains

• SIEM was searched for URLs where supported

• SIEM was searched for file hashes

• Endpoint pivoting was performed

• User pivoting was performed

• IOC aging was understood

• False-positive risk was considered

• Indicator disposition was assigned

• IOC enrichment table was created

• Organizational exposure was determined

• Final analyst assessment was documented

• Evidence was captured

62. Mission Review

In this mission, you transformed raw indicators into actionable investigation context.

You moved from:

203.0.113.50

example.invalid

<sha256>

to:

Indicator
   ↓
External Intelligence
   ↓
Infrastructure Context
   ↓
Relationships
   ↓
Internal SIEM Matches
   ↓
Affected Assets
   ↓
Confidence
   ↓
Analyst Decision

The most important lesson is:

An IOC becomes useful when you understand its context, relationships, confidence, and relevance to your own environment.

A strong analyst combines:

External Intelligence
       +
Internal Telemetry
       +
Historical Context
       +
Indicator Relationships
       +
Analyst Judgment
       =
Actionable Threat Intelligence

Skills Developed

After completing this mission, you should be able to:

• distinguish indicators from intelligence

• enrich IP addresses

• investigate ASN and hosting context

• analyze domain registration and DNS

• investigate URL structure and redirects

• enrich file hashes

• interpret reputation data

• understand malware associations

• evaluate threat-intelligence source quality

• assign confidence levels

• identify IOC relationships

• correlate external intelligence with internal telemetry

• pivot from IOC to host

• pivot from host to user

• assess organizational exposure

• identify potential false positives

• assign IOC disposition

• build threat-intelligence investigation records

What’s Next?

Lab 17 — Incident Triage and Evidence Collection

You now know how to enrich security indicators and determine whether they matter to your environment.

In the next mission, you will bring together the investigation skills developed across the previous labs and perform structured incident triage.

You will investigate:

• alert validation

• incident scoping

• severity classification

• impacted assets

• affected users

• evidence preservation

• event logs

• packet captures

• volatile evidence

• timestamps

• hashes

• chain-of-custody fundamentals

• evidence integrity

• IOC collection

• investigation timelines

• containment recommendations

• escalation decisions

The workflow progresses from:

Security Alert
      ↓
Individual Investigation

to:

Security Alert
      ↓
Incident Triage
      ↓
Scope
      ↓
Evidence
      ↓
Severity
      ↓
Containment
      ↓
Escalation

➡️ Next: Lab 17 — Incident Triage and Evidence Collection