"Lab 11 — Phishing Email Investigation"

Mission Information

Item	Details
Lab	11
Lab Name	Phishing Email Investigation
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 + Email Evidence
Primary Tools	Email Header Analysis, CyberChef, VirusTotal or Approved Threat Intelligence Sources
Skills	Phishing Analysis, Header Analysis, URL Analysis, IOC Extraction, Attachment Triage, Threat Intelligence, Incident Classification

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

A user has reported a suspicious email appearing to originate from the organization’s IT support team.

The message claims:

URGENT: Your account will be disabled.

We detected unusual activity associated with your account.

Verify your identity immediately to prevent account suspension.

The email contains a link labeled:

Verify Account

Shortly after the message was received, your SIEM detected unusual authentication activity associated with the recipient’s account.

Your SOC needs to determine whether the email is related to the authentication activity investigated in the previous mission.

You have been assigned the suspicious message for analysis.

You must determine:

• who actually sent the message

• whether the visible sender was spoofed

• which systems handled the email

• whether SPF, DKIM, and DMARC passed

• where embedded links lead

• whether domains are suspicious

• whether attachments exist

• whether any indicators are known malicious

• whether the recipient interacted with the message

• whether the email may have contributed to account compromise

Mission Objective: Perform a structured phishing investigation and determine whether the suspicious email represents benign communication, spam, phishing, credential theft, or another malicious email threat.

Mission Objectives

By completing this lab, you will be able to:

• understand phishing investigation methodology

• preserve suspicious email evidence

• analyze .eml messages safely

• distinguish display name from actual sender address

• investigate From

• investigate Return-Path

• investigate Reply-To

• analyze Received headers

• interpret SPF results

• interpret DKIM results

• interpret DMARC results

• extract URLs safely

• investigate domains

• recognize lookalike domains

• identify URL obfuscation

• inspect attachments safely

• calculate attachment hashes

• enrich indicators using threat intelligence

• correlate phishing evidence with SIEM telemetry

• assess user interaction

• classify phishing incidents

• document analyst findings

1. Understand the Phishing Investigation Workflow

A typical phishing investigation follows:

Suspicious Email Reported
        ↓
Preserve Evidence
        ↓
Review Message Content
        ↓
Analyze Sender
        ↓
Analyze Headers
        ↓
Validate Authentication
        ↓
Extract URLs
        ↓
Extract Attachments
        ↓
Identify IOCs
        ↓
Threat Intelligence
        ↓
Investigate Recipient Activity
        ↓
Correlate SIEM Evidence
        ↓
Determine Impact
        ↓
Analyst Verdict

Do not begin by clicking links or opening attachments.

2. Phishing Is More Than a Suspicious Link

Phishing messages may attempt to:

Steal Credentials
Deliver Malware
Collect Financial Information
Convince Users to Transfer Money
Capture MFA Codes
Redirect Users to Fake Portals
Initiate Business Email Compromise

Some messages contain attachments.

Others contain only links.

Some contain neither and instead attempt to convince the recipient to reply.

Therefore:

Analyze the complete message, not just one indicator.

3. Understand Common Email Threat Categories

Spam

Unwanted or unsolicited email without necessarily having malicious intent.

Phishing

Messages designed to deceive recipients into revealing information or performing actions.

Spear Phishing

Phishing tailored toward a particular individual or organization.

Credential Phishing

Attempts to steal usernames, passwords, session information, or MFA information.

Business Email Compromise

Social engineering involving trusted business identities, executives, suppliers, or financial processes.

Malware Delivery

Messages containing or linking to malicious files or software.

4. Start the Lab Environment

Start:

CYSA-ANALYST
10.10.10.10

CYSA-SIEM
10.10.10.40

Keep the suspicious email isolated from normal production mailboxes.

For this lab, use only instructor-provided, synthetic, or otherwise safe email evidence.

5. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB11/{Email,Headers,Attachments,IOCs,Screenshots,Findings}

Create investigation notes:

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

Use:

Investigation ID:
LAB11-PHISH-001

6. Preserve the Original Email

Ideally, preserve the suspicious message as:

suspicious-email.eml

Store it under:

~/CySA-Lab/Investigations/LAB11/Email/

Avoid modifying the original evidence.

Create a working copy:

cp suspicious-email.eml suspicious-email-working.eml

The investigation model becomes:

Original Evidence
      ↓
Preserved
      ↓
Working Copy
      ↓
Analysis

7. Calculate the Email Hash

Calculate SHA-256:

sha256sum suspicious-email.eml

Record the result.

Example:

SHA256:
<email-hash>

This helps demonstrate evidence integrity.

8. Perform Initial Visual Triage

Without clicking anything, review:

Display Name
Sender Address
Recipient
Subject
Date
Message Body
Links
Attachments
Urgency
Branding
Grammar
Requested Action

Record anything suspicious.

Example:

Display Name:
GHC IT Support

Visible Sender:
support@gohackerscloud.example

Subject:
URGENT — Account Verification Required

Requested Action:
Verify account using embedded link

9. Identify Social Engineering Indicators

Look for language such as:

Urgent
Immediate Action Required
Account Suspended
Password Expiring
Payment Required
Invoice Attached
Security Alert
Verify Identity
MFA Expired
Mailbox Full

Social engineering commonly creates:

Fear
Urgency
Authority
Curiosity
Financial Pressure

These are indicators—not proof by themselves.

10. Understand Display-Name Spoofing

Consider:

Display Name:
GHC Security Team

Email:
security-update@example.invalid

A user may focus only on:

GHC Security Team

and overlook the actual address.

Always compare:

Display Name
     vs
Actual Sender Address

11. View the Raw Email

On Linux:

less suspicious-email.eml

Or:

cat suspicious-email.eml

You should see headers followed by the message body.

Headers may include:

From:
To:
Subject:
Date:
Message-ID:
Return-Path:
Reply-To:
Received:
Authentication-Results:
DKIM-Signature:
Content-Type:

12. Extract the Headers

Extract the header portion into:

~/CySA-Lab/Investigations/LAB11/Headers/email-headers.txt

Review it separately.

The exact header structure depends on the email system that processed the message.

13. Investigate the From Header

Locate:

From:

Example:

From: GHC IT Support <support@example.invalid>

Ask:

Does the domain belong to the claimed organization?

Is the spelling correct?

Is this address expected?

Does it match the visible display name?

14. Investigate Return-Path

Locate:

Return-Path:

This can identify the address used for delivery-related responses.

Compare:

From
     vs
Return-Path

A mismatch is not automatically malicious.

Legitimate mailing platforms often use different envelope senders.

But the relationship should be investigated.

15. Investigate Reply-To

Locate:

Reply-To:

Example:

From:
support@trusted.example

Reply-To:
helpdesk@unrelated.example

A suspicious Reply-To can indicate an attempt to redirect the conversation to attacker-controlled infrastructure.

Again, legitimate systems can also use different reply addresses.

Context matters.

16. Compare Sender Identity Fields

Build:

Field	Value	Observation
Display Name	GHC IT Support	Trusted-looking
From	support@example.invalid	Investigate
Return-Path	mail@example.invalid	Investigate
Reply-To	help@example.invalid	Investigate

The objective is to understand the sender identity chain.

17. Investigate Received Headers

Email servers add Received headers as messages pass through infrastructure.

You may see multiple entries.

Conceptually:

Sending Infrastructure
        ↓
Mail Relay
        ↓
Security Gateway
        ↓
Recipient Mail Server

These records help reconstruct the email delivery path.

18. Read Received Headers Correctly

Received headers are generally analyzed:

Bottom
  ↑
  ↑
  ↑
Top

The earliest trustworthy hop is typically lower in the chain.

Do not blindly trust every header value supplied by the sender.

Focus on headers added by infrastructure you trust.

19. Build the Email Delivery Path

Document:

Originating Infrastructure
        ↓
Intermediate Relay
        ↓
Email Gateway
        ↓
Recipient Environment

Record:

IP addresses
Hostnames
Timestamps

This becomes part of your IOC investigation.

20. Understand SPF

Sender Policy Framework — SPF helps receiving systems determine whether an IP address is authorized to send mail for a domain.

You may see:

spf=pass

or:

spf=fail

Other possible results include:

neutral
softfail
none
temperror
permerror

21. Understand SPF Limitations

An SPF pass does not automatically mean:

Email is safe.

An attacker may legitimately control:

malicious-example.invalid

and configure SPF correctly.

SPF answers a narrower question:

Was this sending infrastructure authorized for the evaluated domain?

22. Understand DKIM

DomainKeys Identified Mail — DKIM uses cryptographic signatures to help validate that selected message content was signed by a domain and has not been altered in ways covered by the signature.

Look for:

dkim=pass

or:

dkim=fail

Also inspect:

DKIM-Signature:

23. Understand DMARC

Domain-based Message Authentication, Reporting and Conformance — DMARC builds on SPF and DKIM and checks domain alignment with the visible From domain.

Possible results include:

dmarc=pass
dmarc=fail

DMARC helps organizations establish policies for handling authentication failures.

24. Analyze Authentication Results Together

Create:

Control	Result	Interpretation
SPF	Pass / Fail	Sending authorization
DKIM	Pass / Fail	Message/domain signature validation
DMARC	Pass / Fail	Domain alignment and policy

Do not evaluate these controls independently of sender and message context.

25. Investigate Authentication-Results

Locate:

Authentication-Results:

Example structure:

spf=pass
dkim=pass
dmarc=pass

or:

spf=fail
dkim=none
dmarc=fail

Record the exact results in your investigation notes.

26. Extract URLs Safely

Do not click suspicious links.

Instead, inspect the raw message and extract URLs as text.

You can search:

grep -Eo 'https?://[^ "<>]+' suspicious-email.eml

Depending on MIME encoding, URLs may require additional decoding before they become visible.

Store extracted URLs in:

~/CySA-Lab/Investigations/LAB11/IOCs/urls.txt

27. Compare Displayed Link and Actual Destination

A message may display:

https://login.example.com

while the actual hyperlink points somewhere else.

For HTML email, inspect:

<a href="ACTUAL-DESTINATION">
    DISPLAYED-TEXT
</a>

Always investigate the:

href

rather than trusting the visible text.

28. Recognize Lookalike Domains

Attackers may use domains visually similar to trusted brands.

Conceptual examples:

company.example
cornpany.example
company-security.example
company-login.example

Look for:

Character substitution
Added words
Unexpected subdomains
Different top-level domains
Hyphenation
Brand name embedded inside unrelated domain

29. Understand URL Structure

Consider:

https://login.security.example.invalid/account/verify

Break it into:

Scheme:
https

Hostname:
login.security.example.invalid

Path:
/account/verify

The important question is:

Which domain actually controls the destination?

Do not judge a URL merely because trusted words appear somewhere inside it.

30. Watch for Misleading Subdomains

Consider:

https://gohackerscloud.com.attacker-example.invalid/login

The controlling registrable domain is not:

gohackerscloud.com

The trusted-looking text is only part of the hostname.

This is a common phishing technique.

31. Investigate URL Encoding

Suspicious URLs may contain encoded characters such as:

%2F
%3A
%40

Use a decoding tool such as CyberChef in a controlled analysis workflow.

Decode only the text.

Do not browse to the resulting suspicious URL.

32. Investigate Redirect Parameters

A URL may contain:

redirect=
url=
target=
continue=
next=

Example concept:

trusted-site.example/redirect?url=suspicious-site.example

The first domain may appear legitimate while the final destination is not.

Document the full redirect chain only using safe analysis methods.

33. Extract Domain Indicators

Create:

~/CySA-Lab/Investigations/LAB11/IOCs/domains.txt

Record domains found in:

From
Return-Path
Reply-To
Received headers
URLs
Attachments or message content

Remove obvious trusted infrastructure only after validating it.

34. Extract IP Indicators

Create:

~/CySA-Lab/Investigations/LAB11/IOCs/ip-addresses.txt

Potential IP sources include:

Received headers
URLs using direct IP addresses
Email gateway telemetry
SIEM events
DNS records

35. Perform Threat Intelligence Enrichment

For suspicious indicators, use approved threat-intelligence sources.

You may investigate:

Domain
IP Address
URL
File Hash

Look for:

Reputation
Previous detections
Malware associations
Phishing reports
First-seen information
Detection consensus

Never upload confidential organizational files to public analysis services without authorization.

36. Understand Threat Intelligence Limitations

If a reputation service reports:

0 detections

that does not prove the indicator is safe.

The infrastructure may be:

New
Rare
Unreported
Short-lived
Targeted

Threat intelligence is supporting evidence.

It is not the entire investigation.

37. Investigate Domain Context

Where approved, investigate:

Domain age
Registration context
DNS records
Hosting infrastructure
Certificate information
Historical reputation

A domain created recently and impersonating a known brand may deserve increased scrutiny.

Do not use domain age as the sole basis for classification.

38. Investigate Attachments

First identify whether the email contains attachments.

Possible types include:

PDF
DOCX
XLSX
ZIP
HTML
ISO
Image
Executable
Script

Do not double-click suspicious attachments.

39. Save Attachments Safely

If your email-analysis tooling supports safe extraction, place attachments in:

~/CySA-Lab/Investigations/LAB11/Attachments/

Do not execute them.

Keep analysis inside your isolated environment.

40. Calculate Attachment Hashes

For each extracted file:

sha256sum <filename>

You may also calculate:

md5sum <filename>

and:

sha1sum <filename>

For modern IOC tracking, prefer:

SHA-256

41. Identify the File Type

Use:

file <filename>

Do not rely only on the filename extension.

For example:

invoice.pdf

may not necessarily be a PDF.

The actual file type should be verified.

42. Check Basic File Metadata

Run:

ls -lh <filename>

Record:

Filename
Size
File Type
SHA-256

This creates a basic attachment inventory.

43. Perform Safe Static Triage

Depending on the file type, you may inspect:

Metadata
Strings
Archive contents
Document structure
Hashes
Embedded URLs

Do not execute suspicious binaries or scripts as part of this introductory lab.

Dynamic malware analysis belongs in an isolated malware-analysis environment.

44. Search for URLs Inside Extracted Text

If you safely extract text from a document, search for:

http://
https://

Record any discovered indicators.

An attachment can be used simply as another layer leading the victim to a credential phishing site.

45. Create the IOC Inventory

Build:

Type	Indicator	Source	Assessment
Email	sender@example.invalid	From	Suspicious
Domain	example.invalid	URL	Investigate
IP	192.0.2.50	Received	Investigate
URL	hxxps://example[.]invalid/login	Email	Suspicious
SHA-256	<hash>	Attachment	Investigate

When documenting malicious URLs for reports, consider defanging them.

46. Understand Defanging

Instead of writing an active indicator such as:

https://malicious.example

an analyst may document:

hxxps://malicious[.]example

This reduces accidental clicking.

Similarly:

192.0.2.10

may be represented as:

192[.]0[.]2[.]10

when appropriate for reports.

47. Search the SIEM for the Recipient

Now connect the email investigation to your authentication investigation.

Search:

Recipient Username

Look for events occurring:

Before Email
During Email Delivery
After Email

The objective is to determine whether suspicious account activity followed the phishing message.

48. Search for Phishing Domains in the SIEM

Search the extracted domain across available telemetry.

Potential sources include:

DNS
Zeek
Proxy
Firewall
Endpoint
EDR

Ask:

Did the recipient’s endpoint communicate with the suspicious infrastructure?

49. Search Zeek DNS Telemetry

If Zeek logs are ingested into the SIEM, search:

Suspicious Domain

A match could indicate:

Endpoint
    ↓
DNS Query
    ↓
Suspicious Domain

This does not automatically prove the user visited the site.

But it strengthens the investigation.

50. Search Zeek Connection Telemetry

If the suspicious domain resolved to an IP, search for connections to that IP.

Look for:

Source IP
Destination IP
Destination Port
Timestamp
Service

Compare the timestamp with email delivery and authentication events.

51. Search Suricata Telemetry

Search Suricata events for:

Suspicious Domain
Suspicious IP
Recipient Endpoint

Review any relevant IDS alerts.

This provides another source of network evidence.

52. Investigate Browser or Proxy Evidence

If available in your environment, review:

Web Proxy Logs
Browser History
DNS Logs
Secure Web Gateway Logs
Endpoint Telemetry

Determine whether the user accessed the suspicious URL.

Do not assume interaction merely because the email was delivered.

53. Determine Whether the User Clicked

Possible evidence:

DNS query for phishing domain
      ↓
Connection to phishing IP
      ↓
HTTP/TLS session

This can support:

Possible User Interaction

But additional evidence may be required to determine exactly what information was submitted.

54. Correlate Authentication Activity

Suppose:

09:00
Phishing Email Delivered

09:05
Endpoint Resolves Suspicious Domain

09:06
Endpoint Connects to Suspicious Infrastructure

09:15
Account Authentication from New Source

09:17
Privileged Activity

The investigation now has a possible chain:

Phishing
   ↓
User Interaction
   ↓
Possible Credential Exposure
   ↓
Suspicious Authentication
   ↓
Account Activity

Correlation is essential.

55. Do Not Confuse Correlation with Proof

The timeline may strongly suggest credential theft.

But be precise.

For example:

Evidence confirms:
Email delivery
Domain resolution
Network connection
Suspicious authentication

It may not confirm:

User entered password into phishing page

unless additional evidence supports that conclusion.

Analyst reports should distinguish:

Confirmed
Likely
Possible
Unknown

56. Investigate Other Recipients

Search the email environment or SIEM for:

Sender
Subject
Domain
URL
Message-ID patterns

Determine whether the same campaign targeted additional users.

Example:

1 Suspicious Email
      ↓
Search Environment
      ↓
27 Matching Messages

The investigation may now become a broader phishing campaign response.

57. Identify Potentially Affected Users

Create:

Recipient	Delivered	Click Evidence	Suspicious Login	Status
user01	Yes	Yes	Yes	Investigate
user02	Yes	No	No	Monitor
user03	Yes	Unknown	No	Investigate

This helps prioritize response.

58. Determine the Email Verdict

Possible classifications include:

Benign
Spam
Suspicious
Phishing
Credential Phishing
Malware Delivery
Business Email Compromise

Base the verdict on multiple indicators.

59. Build a Phishing Scoring Model

For learning purposes, evaluate:

Sender mismatch
Authentication failures
Lookalike domain
Suspicious URL
Recently observed domain
Attachment risk
Threat intelligence hits
User interaction
Suspicious authentication afterward

The more independent evidence sources agree, the stronger your conclusion becomes.

Do not treat this as a universal numerical risk formula.

60. Map the Activity to MITRE ATT&CK

Depending on the evidence, relevant ATT&CK context may include:

Phishing
Spearphishing Link
Spearphishing Attachment
Valid Accounts

Only map techniques supported by the observed evidence.

61. Determine Incident Scope

Ask:

How many recipients?

How many clicked?

How many accounts show suspicious authentication?

Were privileged accounts affected?

Was malware delivered?

Were additional systems contacted?

Did the attacker perform post-login activity?

Scope determines incident severity.

62. Determine Containment Requirements

For a confirmed phishing incident, possible actions include:

Block sender
Block domain
Block URL
Block malicious IP
Remove matching emails
Reset compromised credentials
Revoke sessions
Require MFA reauthentication
Isolate affected endpoint if needed
Search for additional victims
Preserve evidence

Follow organizational incident-response procedures.

63. Mission Challenge — Phishing Investigation

The SOC provides:

A suspicious account-verification email was reported shortly before unusual authentication activity was detected. Determine whether the email and authentication events are related.

Investigate and answer:

1. What is the visible sender?

2. What is the actual sender address?

3. What is the Return-Path?

4. Is a Reply-To present?

5. Do the sender fields align?

6. What infrastructure delivered the email?

7. What is the SPF result?

8. What is the DKIM result?

9. What is the DMARC result?

10. What URLs are present?

11. Do displayed links match actual destinations?

12. Are lookalike domains present?

13. Are redirects present?

14. Are attachments present?

15. What are the attachment hashes?

16. What IOCs can be extracted?

17. What does threat-intelligence enrichment show?

18. Did the recipient endpoint resolve the suspicious domain?

19. Did the endpoint connect to suspicious infrastructure?

20. Did suspicious authentication occur afterward?

21. Were additional recipients targeted?

22. What is the final email classification?

23. What is the incident scope?

24. What response actions are recommended?

64. Document Your Findings

Update:

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

Use:

# LAB11 Phishing Investigation

## Investigation ID

LAB11-PHISH-001

## Email Summary

- Sender:
- Recipient:
- Subject:
- Date:
- Message-ID:

## Sender Analysis

- Display Name:
- From:
- Return-Path:
- Reply-To:

## Email Authentication

- SPF:
- DKIM:
- DMARC:

## Delivery Path

Document relevant Received headers.

## URL Analysis

Document:
- displayed URL
- actual URL
- domain
- redirects
- reputation

## Attachment Analysis

Document:
- filename
- file type
- size
- SHA-256
- reputation

## Indicators of Compromise

Document:
- domains
- IP addresses
- URLs
- hashes
- sender addresses

## SIEM Correlation

Document:
- DNS activity
- network connections
- IDS alerts
- authentication activity

## User Impact

Determine:
- email delivered?
- link accessed?
- attachment opened?
- credentials potentially exposed?
- suspicious authentication?

## Scope

Document additional recipients or affected systems.

## Verdict

Benign / Spam / Suspicious / Phishing / Credential Phishing / Malware Delivery / BEC

## Severity

Low / Medium / High / Critical

## Recommended Actions

Document containment and follow-up actions.

65. Example Analyst Findings

A simulated lab assessment may resemble:

Investigation:
LAB11-PHISH-001

Email Type:
Account Verification Message

Sender Analysis:
Display name impersonated the organization's IT support function.

Email Authentication:
Sender authentication and alignment results contained indicators requiring investigation.

URL Analysis:
Embedded link directed the recipient to infrastructure unrelated to the claimed organization.

Threat Intelligence:
The destination exhibited suspicious characteristics.

Recipient Activity:
Network telemetry indicated the recipient endpoint communicated with the suspicious infrastructure after email delivery.

Authentication Correlation:
Suspicious authentication activity was observed shortly afterward.

Assessment:
Evidence is consistent with a credential-phishing scenario.

Classification:
Credential Phishing

Severity:
High

Recommended Action:
Contain affected identity, revoke active sessions, reset credentials, block identified indicators, search for additional recipients, and investigate post-authentication activity.

66. Evidence to Capture

Capture:

01-original-email.png
02-message-body.png
03-display-name-and-sender.png
04-raw-email-headers.png
05-return-path.png
06-reply-to.png
07-received-chain.png
08-spf-result.png
09-dkim-result.png
10-dmarc-result.png
11-url-extraction.png
12-lookalike-domain.png
13-url-analysis.png
14-attachment-inventory.png
15-file-hash.png
16-threat-intelligence.png
17-ioc-inventory.png
18-siem-domain-search.png
19-zeek-correlation.png
20-authentication-correlation.png
21-incident-timeline.png
22-analyst-verdict.png

67. Validation Checklist

• Original email evidence was preserved

• Email SHA-256 was calculated

• Initial visual triage was completed

• Display name was investigated

• Actual sender was identified

• From was analyzed

• Return-Path was analyzed

• Reply-To was analyzed

• Received headers were investigated

• Email delivery path was reconstructed

• SPF was investigated

• DKIM was investigated

• DMARC was investigated

• URLs were extracted without clicking

• Displayed and actual URLs were compared

• Lookalike domains were investigated

• Redirect indicators were reviewed

• Domain indicators were extracted

• IP indicators were extracted

• Attachments were identified

• Attachment file types were verified

• SHA-256 hashes were calculated

• Threat-intelligence enrichment was performed

• IOC inventory was created

• Recipient activity was investigated

• SIEM telemetry was correlated

• Zeek evidence was reviewed where available

• Suricata evidence was reviewed where available

• Authentication activity was correlated

• Additional recipients were investigated

• Incident scope was determined

• Email verdict was assigned

• Recommended response actions were documented

• Evidence was captured

68. Mission Review

In this mission, you investigated the potential initial-access mechanism behind suspicious authentication activity.

You followed:

Suspicious Email
      ↓
Preserve Evidence
      ↓
Sender Analysis
      ↓
Header Analysis
      ↓
SPF / DKIM / DMARC
      ↓
URL / Domain Analysis
      ↓
Attachment Analysis
      ↓
IOC Extraction
      ↓
Threat Intelligence
      ↓
SIEM Correlation
      ↓
User Activity
      ↓
Authentication Correlation
      ↓
Scope
      ↓
Analyst Verdict

The key lesson is:

A phishing verdict should be based on evidence from the complete message and surrounding environment—not simply on whether an email looks suspicious.

A strong investigation combines:

Email Evidence
      +
Sender Identity
      +
Authentication Results
      +
URL / Attachment Evidence
      +
Threat Intelligence
      +
Endpoint / Network Telemetry
      +
Identity Activity
      =
Phishing Incident Context

Skills Developed

After completing this mission, you should be able to:

• preserve suspicious email evidence

• analyze raw email headers

• investigate sender identity

• analyze From, Return-Path, and Reply-To

• reconstruct email delivery paths

• interpret SPF, DKIM, and DMARC

• safely extract URLs

• identify misleading hyperlinks

• recognize lookalike domains

• analyze URL structure

• identify redirect indicators

• extract domains and IP addresses

• triage email attachments safely

• calculate file hashes

• build IOC inventories

• perform threat-intelligence enrichment

• correlate email and network telemetry

• investigate recipient interaction

• correlate phishing with authentication activity

• determine phishing campaign scope

• classify phishing incidents

• recommend containment actions

What’s Next?

Lab 12 — Malware Analysis Fundamentals

You have now investigated a potential phishing delivery mechanism.

A phishing email may also contain or deliver a malicious file.

In the next mission, you will move into foundational malware triage and analysis using safe, controlled samples and non-executing techniques.

You will investigate:

• malware-analysis safety

• static vs dynamic analysis

• file identification

• file extensions vs actual file types

• cryptographic hashes

• strings

• executable metadata

• PE file fundamentals

• suspicious imports

• embedded URLs and domains

• IOC extraction

• threat-intelligence enrichment

• behavioral indicators

• malware classification

• analyst reporting

The investigation progresses from:

Phishing Email
      ↓
Suspicious Attachment

to:

Suspicious File
      ↓
Static Analysis
      ↓
Indicators
      ↓
Threat Intelligence
      ↓
Malware Assessment

➡️ Next: Lab 12 — Malware Analysis Fundamentals