Lab 03 — Phishing Email Investigation

Welcome to:

Lab 03 — Phishing Email Investigation

In the previous lab, you investigated a confirmed identity compromise involving:

Password Abuse

MFA Fatigue

Unauthorized Session

Mailbox Persistence

Now you will move one step earlier in the attack chain.

You will investigate:

How Did
the Attack
Begin?

One of the most common enterprise entry points is:

Email

A suspicious email may attempt to:

Steal Credentials

Deliver Malware

Redirect Users

Impersonate Executives

Create Urgency

Trigger Fraud

Your mission is to determine whether a reported email represents:

Spam

Benign Email

Credential Phishing

Malware Delivery

Business Email
Compromise Attempt

and whether any users interacted with it.

Mission Information

Your Role

You are continuing as a:

SOC Analyst

at:

CloudNova Technologies

A finance employee reports a suspicious email through the organization’s phishing-reporting process.

The email claims that the user’s Microsoft 365 password will expire shortly and asks them to sign in through a provided link.

Your job is to:

Validate

Analyze

Determine Scope

Identify Impact

Contain

Document

the phishing incident.

Enterprise Environment

CloudNova uses:

Microsoft 365

Enterprise Email Gateway

Microsoft Entra ID

Windows Endpoints

EDR

SIEM

Web Proxy

DNS

Threat Intelligence

Available evidence includes:

Original Email

Email Headers

Mail Gateway Logs

URL Data

DNS Logs

Proxy Logs

Endpoint Telemetry

Authentication Logs

Threat Intelligence

Initial Report

The SOC receives:

Case ID:
PHISH-3001

Reported By:
sarah.mitchell@cloudnova.example

Department:
Finance

Report Time:
09:18 UTC

Subject:
URGENT: Your Microsoft 365 Password Expires Today

Sender:
Microsoft Security
<security-update@micros0ft-support.example>

Recipient:
sarah.mitchell@cloudnova.example

Attachment:
None

URL:
hxxps://login-microsoft365-security.example/account

Initial Analyst Question

Do not immediately classify the message as:

Phishing

because it:

Looks Suspicious

Your task is to establish:

Who Sent It?

Was the Sender
Authentic?

What Infrastructure
Delivered It?

Where Does
the Link Go?

Did Anyone Click?

Were Credentials
Submitted?

Did Any Compromise
Follow?

Lab Objectives

By completing this lab, you will learn how to:

• investigate a reported phishing email.

• preserve the original message.

• analyze sender information.

• analyze reply-to information.

• understand email envelope data.

• analyze email headers.

• review Received headers.

• understand SPF.

• understand DKIM.

• understand DMARC.

• identify domain impersonation.

• identify lookalike domains.

• analyze email URLs.

• distinguish visible links from actual destinations.

• evaluate redirects.

• analyze domain reputation.

• analyze attachment metadata.

• understand safe attachment handling.

• identify recipients.

• search for similar messages.

• determine who clicked a URL.

• correlate proxy and DNS telemetry.

• correlate endpoint evidence.

• review authentication after phishing interaction.

• determine whether credentials were submitted.

• determine incident scope.

• identify indicators of compromise.

• map activity to MITRE ATT&CK.

• recommend containment.

• remove malicious emails.

• block domains and URLs.

• document findings.

• create an escalation handoff.

Prerequisites

You should understand:

Email

SMTP

Domain

URL

DNS

Authentication

MFA

SIEM

Proxy

Threat Intelligence

Tools Required

Assume access to:

Email Security Gateway

Microsoft 365 Audit Logs

SIEM

Proxy Logs

DNS Logs

EDR

Identity Logs

Threat Intelligence

Case Management

Lab Artifacts

By the end of this lab, create:

01 Email_Triage_Worksheet.csv

02 Header_Analysis.md

03 URL_Analysis.csv

04 Recipient_Register.csv

05 User_Interaction_Register.csv

06 Evidence_Register.csv

07 IOC_Register.csv

08 Investigation_Timeline.csv

09 MITRE_ATTACK_Mapping.csv

10 Containment_Plan.md

11 Escalation_Handoff.md

12 Phishing_Investigation_Report.md

Part 1 — Preserve the Original Email

Before modifying or deleting anything, preserve:

Original Message

Headers

Body

Attachments

URLs

Message ID

Create:

Email_Triage_Worksheet.csv

Use:

Field	Value
Case ID	PHISH-3001
Reporter	Sarah Mitchell
Sender	security-update@micros0ft-support.example
Subject	URGENT: Your Microsoft 365 Password Expires Today
Recipient	sarah.mitchell@cloudnova.example
Attachment	None
URL	login-microsoft365-security.example/account
Report Time	09:18 UTC

Part 2 — Examine the Display Name

Displayed sender:

Microsoft Security

Actual address:

security-update@
micros0ft-support.example

Notice:

Microsoft

versus:

micros0ft

with:

0

instead of:

o

This is a classic:

Lookalike Domain

pattern.

Part 3 — Display Name Impersonation

Attackers may set the visible name to:

Microsoft

CEO

Finance

IT Support

Human Resources

even when the actual address belongs to a completely unrelated domain.

Therefore:

Display Name
      ≠
Verified Sender

Part 4 — Analyze Reply-To

Header review shows:

From:
security-update@
micros0ft-support.example

Reply-To:
accountvalidation@
mail-check.example

The mismatch between:

From

and:

Reply-To

adds suspicion.

But remember:

Reply-To Mismatch
      ≠
Automatic Phishing

Legitimate services can use different reply addresses.

Context matters.

Part 5 — Analyze the Message ID

You find:

Message-ID:
<839021.88291@
bulkmailer-host.example>

This suggests the message was generated through:

Third-Party
Mail Infrastructure

rather than Microsoft’s normal email infrastructure.

This is another useful signal.

Part 6 — Review Received Headers

The top relevant Received chain shows:

Received:
from smtp.bulkmailer-host.example

IP:
198.51.100.210

by:
cloudnova mail gateway

Time:
09:05 UTC

This identifies the infrastructure that delivered the email.

Part 7 — Header Analysis Principles

Do not trust only:

From:

because it can be spoofed.

Review:

Received

Return-Path

Reply-To

Message-ID

Authentication-Results

together.

Part 8 — SPF

SPF stands for:

Sender Policy
Framework

It allows a domain owner to publish which systems are authorized to send mail for that domain.

Header result:

SPF:
Fail

for:

micros0ft-support.example

What SPF Tells You

Conceptually:

Sending IP
      ↓
Checked Against
Domain SPF Policy
      ↓
Authorized?

In this case:

No

SPF Limitation

An SPF pass does not prove:

Message
Is Legitimate

Attackers can:

Register Their
Own Domain

Configure SPF

Send Phishing

and receive:

SPF Pass

Part 9 — DKIM

DKIM stands for:

DomainKeys
Identified Mail

It cryptographically signs parts of an email.

Current result:

DKIM:
None

No valid DKIM signature is present.

Part 10 — DMARC

DMARC helps domain owners specify how SPF and DKIM should align with the domain shown to users.

Header result:

DMARC:
Fail

Current Authentication Results

SPF:
Fail

DKIM:
None

DMARC:
Fail

This strongly increases suspicion.

But remember:

Email Authentication
Results

are one part of the investigation.

Part 11 — Build Header Analysis

Create:

Header_Analysis.md

Use:

# Sender

Display Name:
Microsoft Security

From:
security-update@
micros0ft-support.example

Reply-To:
accountvalidation@
mail-check.example

# Delivery

Sending Host:
smtp.bulkmailer-host.example

Sending IP:
198.51.100.210

# Authentication

SPF:
Fail

DKIM:
None

DMARC:
Fail

# Observations

Lookalike sender domain.

Reply-To mismatch.

Mail infrastructure does
not align with claimed sender.

Email authentication
does not validate sender.

# Initial Assessment

Highly suspicious.

Part 12 — Analyze the Subject

Subject:

URGENT:
Your Microsoft 365
Password Expires Today

Common social-engineering techniques include:

Urgency

Fear

Authority

Scarcity

Curiosity

This message uses:

Urgency
+
Fear of
Account Loss

Part 13 — Analyze the Body

Message body:

Your Microsoft 365
password expires today.

Failure to confirm
your account will
result in immediate
mailbox suspension.

Verify your account:

Microsoft 365
Security Portal

The visible link text appears trustworthy.

But you must inspect:

Actual URL

Part 14 — Visible Link vs Actual URL

Visible:

Microsoft 365
Security Portal

Actual:

hxxps://
login-microsoft365-security.example/
account

Therefore:

Visible Text
      ≠
Destination

Part 15 — URL Analysis

Create:

URL_Analysis.csv

with:

URL	Domain	Reputation	Age	Redirect	Result
login-microsoft365-security.example/account	login-microsoft365-security.example	Suspicious	Recently registered	Yes	Malicious

Part 16 — Domain Analysis

Threat intelligence shows:

Domain:
login-microsoft365-security.example

Registered:
3 Days Ago

Hosting:
Cloud VPS

Reputation:
Suspicious

Category:
Credential Phishing

First Seen:
Yesterday

Why Domain Age Matters

A newly registered domain can be suspicious.

But:

New Domain
      ≠
Malicious

It becomes more meaningful when combined with:

Lookalike Branding

Credential Page

Suspicious Infrastructure

Threat Intelligence

Part 17 — URL Redirect Chain

Safe analysis identifies:

Initial URL
      ↓
redirect-check.example
      ↓
login-microsoft365-security.example

Attackers may use redirects to:

Hide Destination

Bypass Filters

Track Victims

Part 18 — Credential Harvesting Page

The destination page visually resembles:

Microsoft 365
Login

and requests:

Email Address

Password

This strongly indicates:

Credential
Phishing

Safety Principle

Do not enter:

Real Credentials

into suspicious pages.

Use approved analysis methods and isolated environments.

Part 19 — Attachment Review

This message contains:

No Attachment

Therefore the primary attack mechanism is:

URL-Based
Credential Phishing

Part 20 — If an Attachment Existed

You would analyze:

File Name

Extension

MIME Type

Hash

Metadata

Macros

Behavior

Never execute unknown attachments on:

Production

Personal Workstation

Part 21 — Search for Other Recipients

Search the email gateway using:

Sender

Subject

Domain

URL

Message ID

Sending IP

Assume you discover:

Total Recipients:
37

Delivered:
34

Blocked:
3

Important Scope Change

This is no longer:

One User's
Suspicious Email

It is:

Enterprise
Phishing Campaign

Part 22 — Build Recipient Register

Create:

Recipient_Register.csv

with:

Recipient	Department	Delivered	Reported	Clicked	Status

Populate:

37 Users

Part 23 — Determine Who Clicked

Search proxy logs for:

login-microsoft365-security.example

You find:

5 Users
Connected
to the Domain

Users:

Sarah Mitchell

Daniel Brooks

Priya Shah

Michael Grant

Laura Evans

Important Principle

URL Click
      ≠
Credential Submission

Clicking proves:

Browser
Accessed
the Destination

not that credentials were entered.

Part 24 — Build User Interaction Register

Create:

User_Interaction_Register.csv

with:

User	Email Received	URL Click	Credentials Submitted	Suspicious Login	Status

Part 25 — Review DNS

DNS telemetry confirms:

5 Workstations
Resolved

login-microsoft365-security.example

This supports the proxy evidence.

Part 26 — Review Endpoint Activity

Search EDR for those five devices.

Findings:

No File Downloads

No Malware Execution

No Suspicious PowerShell

No Unknown Executables

This supports:

Credential
Phishing

rather than:

Malware Delivery

for the observed campaign.

Part 27 — Investigate Sarah Mitchell

Sarah reported the email.

Proxy logs show:

Sarah:
No URL Click

She used the:

Report Phishing

function without accessing the destination.

Assessment:

No Interaction
Beyond Reporting

Part 28 — Investigate Daniel Brooks

Proxy logs show:

09:11
URL Access

Identity logs show:

No Suspicious
Authentication

User interview:

I clicked the link,
saw the login page,
and closed it.

I did not enter
my password.

Assessment:

Clicked

No Evidence
of Credential Submission

Part 29 — Investigate Priya Shah

Proxy logs:

09:09
URL Access

Identity logs:

09:14
Successful Login
from New Source

Source IP:

203.0.113.145

Country:

Germany

Device:

Unknown

MFA:

Denied

Denied

Approved

This requires immediate investigation.

Part 30 — Investigation Pivot

The phishing investigation has now identified:

Potential
Account Compromise

for:

Priya Shah

Part 31 — Correlate Timing

Timeline:

09:05
Phishing Email Delivered

09:09
Priya Clicks URL

09:14
New Authentication

09:15
MFA Approval

09:18
Mailbox Access

This sequence strongly supports a relationship.

But:

Click
      +
Suspicious Login

still does not independently prove:

Credentials
Were Submitted

Seek additional evidence.

Part 32 — User Verification

Priya states:

I clicked the email
and entered my
Microsoft 365 password.

I then received
several MFA prompts.

I approved one
because I thought
it was part of
the login process.

Critical Finding

You now have:

Phishing Click

      +

Credential Submission

      +

MFA Approval

      +

Unauthorized Login

This confirms:

Credential
Compromise

with high confidence.

Part 33 — Investigate Michael Grant

Proxy:

Clicked

Identity:

No Authentication
Anomaly

User:

Clicked
but did not
enter credentials

Status:

Exposure
without Confirmed
Credential Compromise

Part 34 — Investigate Laura Evans

Proxy:

Clicked

User cannot initially be reached.

Identity logs show:

No Suspicious Login

Status:

Requires
User Verification

Do not assume:

Safe

until investigation is complete.

Part 35 — Search Authentication Across All Recipients

Search:

All 37 Recipients

for:

New Location

New Device

MFA Anomaly

Failed Logins

Suspicious Sessions

You identify:

Priya Shah

as the only user with confirmed suspicious authentication during the investigation window.

Part 36 — Search the Source Infrastructure

Search identity logs for:

203.0.113.145

Assume:

Priya Shah:
Successful Login

3 Other Users:
Failed Attempts

This may indicate additional credential attack activity.

Part 37 — Determine Email Classification

Evidence now supports:

Malicious
Credential Phishing
Campaign

with:

Confirmed
Account Compromise

of at least:

One User

Part 38 — Identify IOCs

Create:

IOC_Register.csv

with:

IOC	Type	Context	Confidence	Action
micros0ft-support.example	Domain	Sender impersonation	High	Block
login-microsoft365-security.example	Domain	Credential phishing	Confirmed	Block
198.51.100.210	IP	Email infrastructure	High	Monitor/Block per policy
203.0.113.145	IP	Suspicious login	High	Block/Monitor
mail-check.example	Domain	Reply-To infrastructure	High	Investigate/Block

Part 39 — Build Evidence Register

Create:

Evidence_Register.csv

with:

Evidence ID	Source	Observation	Significance
EVD-001	Email	Lookalike sender domain	Phishing indicator
EVD-002	Headers	SPF fail	Sender validation failure
EVD-003	Headers	DMARC fail	Authentication failure
EVD-004	Threat Intel	Credential phishing domain	Confirms malicious infrastructure
EVD-005	Gateway	37 recipients	Campaign scope
EVD-006	Proxy	5 users clicked	User exposure
EVD-007	Identity	Priya suspicious login	Account compromise
EVD-008	User	Priya confirms credential submission	Strong validation
EVD-009	MFA	Priya approved unexpected request	Compromise chain

Part 40 — Build Investigation Timeline

Create:

Investigation_Timeline.csv

Example:

Time	Source	Event	Significance
09:05	Email	Campaign delivered	Initial access
09:09	Proxy	Priya opens phishing URL	User execution
09:14	Identity	Login from new source	Credential abuse
09:15	MFA	Unexpected MFA approved	Authentication completed
09:18	Email	Mailbox accessed	Post-compromise activity
09:18	User	Sarah reports email	Detection
09:25	SOC	Campaign scope identified	Investigation
09:35	SOC	Malicious domain blocked	Containment

Part 41 — MITRE ATT&CK Mapping

Create:

MITRE_ATTACK_Mapping.csv

Possible mappings include:

Activity	Tactic	Technique
Phishing email	Initial Access	Phishing
Credential harvesting	Credential Access	Credentials from Password Stores / input capture context
Valid login	Initial Access / Persistence	Valid Accounts
MFA manipulation	Credential Access / Defense Evasion context	Authentication Process Abuse
Mailbox access	Collection	Email Collection

Use the ATT&CK mappings appropriate to your current ATT&CK version and curriculum.

Part 42 — Determine Scope

Current scope:

37 Recipients

34 Delivered Messages

5 URL Clicks

1 Confirmed
Credential Submission

1 Confirmed
Account Compromise

4 Other Clicked Users
Require Closure
or Follow-Up

Part 43 — Immediate Email Containment

Recommended actions:

Search and
Remove Email
from All Mailboxes

      ↓

Block Sender Domain

      ↓

Block Reply-To Domain

      ↓

Block Phishing Domain

      ↓

Block Malicious URLs

      ↓

Update Email
Security Detection

Part 44 — Identity Containment for Priya

Perform:

Revoke Sessions

Reset Password

Review MFA Methods

Reset MFA
if Required

Review Mailbox

Review OAuth

Review Cloud Access

Review Applications

Monitor Reauthentication

Part 45 — Do Not Reset Everyone Automatically

A campaign affected:

37 Users

but current evidence confirms credential compromise for:

1 User

Response should be:

Evidence-Based

rather than automatically resetting every user’s account unless organizational policy requires it.

Part 46 — User Follow-Up

For users who clicked:

Confirm
Credential Submission

Review Authentication

Review Endpoint Activity

Provide Guidance

Part 47 — Search for Similar Campaigns

Hunt previous:

30 Days

for:

Sender Domain

Reply-To Domain

Phishing Domain

Sending IP

Subject Pattern

Message ID Pattern

This may reveal:

Earlier
Undetected Campaigns

Part 48 — Threat Hunt Pivot

Search:

Phishing Domain
      ↓
DNS
      ↓
Proxy
      ↓
Endpoints
      ↓
Users

Then:

Suspicious Login IP
      ↓
Identity Logs
      ↓
Other Users

Part 49 — Email Gateway Gap

The malicious message was:

Delivered
to 34 Users

despite:

SPF Fail

DMARC Fail

Lookalike Domain

Credential URL

This may indicate:

Email Security
Control Gap

Part 50 — Detection Improvement

Create candidate detection requirements for:

Lookalike Microsoft Domains

DMARC Failure
with Credential Language

Recently Registered
Credential Domains

External Login Page
Impersonating Microsoft

Mass Similar Email
Delivery

Part 51 — User Awareness Improvement

The phishing message used:

Password Expiration

Urgency

Microsoft Branding

Include this scenario in future:

Security Awareness
Training

But do not treat awareness training as the only control.

Use:

Technology
+
Process
+
People

Part 52 — Containment Plan

Create:

Containment_Plan.md

Use:

# Email Actions

Remove malicious
message from mailboxes.

Block sender domain.

Block Reply-To domain.

Block malicious URL
and destination domain.

Search for related
campaign messages.

# Identity Actions

Contain Priya's account.

Revoke sessions.

Reset password.

Review MFA.

Review mailbox activity.

Review OAuth grants.

# Endpoint Actions

Review devices belonging
to users who clicked.

Confirm no malware
delivery occurred.

# Network Actions

Block malicious domain.

Review proxy access.

Search DNS history.

# SOC Actions

Hunt source IPs.

Search all recipients.

Update detection logic.

Continue monitoring.

Part 53 — Escalation

This incident should be escalated because it includes:

Enterprise
Phishing Campaign

      +

Credential Theft

      +

Confirmed
Account Compromise

Potential teams:

Tier 2 SOC

Incident Response

Identity Security

Email Security

Security Awareness

Part 54 — Escalation Handoff

Create:

Escalation_Handoff.md

Use:

# Incident

Credential phishing
campaign targeting
CloudNova employees.

# Scope

37 targeted users.

34 emails delivered.

5 confirmed URL clicks.

1 confirmed credential
submission and account
compromise.

# Malicious Infrastructure

Sender:
micros0ft-support.example

Phishing:
login-microsoft365-security.example

Sending IP:
198.51.100.210

Login IP:
203.0.113.145

# Confirmed Impact

Priya Shah entered
credentials into phishing
site and approved an
unexpected MFA request.

Unauthorized authentication
followed.

# Actions Required

Remove emails.

Block infrastructure.

Contain Priya's account.

Review clicked users.

Search authentication
across all recipients.

Expand threat hunt.

Improve email detection.

Part 55 — Phishing Investigation Report

Create:

Phishing_Investigation_Report.md

Use:

# Case Information

Case ID:
PHISH-3001

# Initial Report

Document reported email.

# Email Analysis

Sender

Reply-To

Message ID

Received Headers

SPF

DKIM

DMARC

# URL Analysis

Domain

Registration

Reputation

Redirect

Landing Page

# Campaign Scope

Recipients

Delivered

Blocked

Clicked

# User Interaction

Sarah Mitchell

Daniel Brooks

Priya Shah

Michael Grant

Laura Evans

# Identity Investigation

Document suspicious
authentication.

# Endpoint Investigation

Document EDR findings.

# IOCs

Reference IOC_Register.csv

# Timeline

Reference
Investigation_Timeline.csv

# MITRE ATT&CK

Reference
MITRE_ATTACK_Mapping.csv

# Classification

Malicious
Credential Phishing

# Confirmed Impact

One confirmed
account compromise.

# Containment

Document actions.

# Outstanding Questions

Other credential submissions?

Historical campaign activity?

Email exposure after
Priya compromise?

# Conclusion

Document final
evidence-based assessment.

Part 56 — Final Analyst Conclusion

Example:

Investigation confirmed
a malicious credential
phishing campaign targeting
CloudNova employees.

The message impersonated
Microsoft Security using
a lookalike sender domain
and directed users to
a recently registered
credential-harvesting site.

Header analysis identified
failed SPF and DMARC
validation, no valid DKIM
signature and delivery
infrastructure inconsistent
with the claimed sender.

The campaign targeted
37 users, with 34 messages
successfully delivered.

Proxy and DNS telemetry
identified five users who
accessed the phishing
destination.

One user, Priya Shah,
confirmed entering her
enterprise credentials
into the fraudulent login
page and subsequently
approving an unexpected
MFA request.

Identity logs confirmed
an unauthorized login
from a previously unseen
source shortly afterward.

The campaign is therefore
classified as malicious
credential phishing with
one confirmed account
compromise.

Immediate email removal,
infrastructure blocking,
identity containment,
user follow-up and
expanded threat hunting
are required.

Part 57 — Facts vs Hypotheses

Facts:

Email Delivered

Lookalike Domain

Phishing URL

Credential Page

Five Clicks

Priya Submitted
Credentials

Unauthorized Login
Occurred

Hypotheses:

Specific Threat Actor
Responsible

Credentials Sold
to Another Actor

Other Users
Submitted Credentials
without Reporting

Do not report these as facts without evidence.

Part 58 — What Not to Claim

Do not say:

All Five Clicked
Users Were Compromised

because:

Click
      ≠
Credential Submission

Do not say:

Email Authentication
Failure Proves Phishing

because SPF/DKIM/DMARC are supporting signals.

Do not say:

No Attachment
Means No Risk

because credential phishing may require no attachment.

Part 59 — Phishing Investigation Decision Tree

Reported Email
      ↓
Preserve
      ↓
Analyze Sender
      ↓
Analyze Headers
      ↓
Analyze URL /
Attachment
      ↓
Determine Malicious?
      │
      ├── No
      │    ↓
      │ Close / Document
      │
      └── Yes
           ↓
      Search Recipients
           ↓
      Identify Clicks
           ↓
      Identify Credential
      Submission
           ↓
      Review Authentication
           ↓
      Contain
           ↓
      Hunt

Part 60 — Phishing Investigation Checklist

Use:

01 Preserve email

02 Record sender

03 Record Reply-To

04 Review Return-Path

05 Review Message-ID

06 Review Received headers

07 Check SPF

08 Check DKIM

09 Check DMARC

10 Inspect URLs

11 Inspect redirects

12 Check domain reputation

13 Check domain age

14 Inspect attachments

15 Search other recipients

16 Identify clicks

17 Review DNS

18 Review proxy

19 Review EDR

20 Review authentication

21 Verify user interaction

22 Determine credential submission

23 Determine scope

24 Identify IOCs

25 Remove message

26 Block infrastructure

27 Contain accounts

28 Hunt related activity

29 Document

30 Escalate

Mission Success Criteria

You have successfully completed this lab when you can explain:

Why Display Names
Cannot Be Trusted

How Received Headers
Help Identify
Sending Infrastructure

What SPF Does

What DKIM Does

What DMARC Does

Why Their Failure
Was Important

Why URL Analysis
Was Critical

Why Click
Did Not Equal
Credential Compromise

How Proxy and DNS
Established Interaction

How User Confirmation
Established Credential
Submission

How Authentication
Confirmed Compromise

How Campaign Scope
Was Determined

Why Email Removal
and Identity Containment
Were Both Required

Portfolio Deliverables

Keep:

01 Email_Triage_Worksheet.csv

02 Header_Analysis.md

03 URL_Analysis.csv

04 Recipient_Register.csv

05 User_Interaction_Register.csv

06 Evidence_Register.csv

07 IOC_Register.csv

08 Investigation_Timeline.csv

09 MITRE_ATTACK_Mapping.csv

10 Containment_Plan.md

11 Escalation_Handoff.md

12 Phishing_Investigation_Report.md

Portfolio Structure

Lab 03 — Phishing Email Investigation
│
├── 01 Email Triage
├── 02 Headers
├── 03 URLs
├── 04 Recipients
├── 05 User Interaction
├── 06 Evidence
├── 07 IOCs
├── 08 Timeline
├── 09 ATT&CK
├── 10 Containment
├── 11 Escalation
└── 12 Investigation Report

Knowledge Check

1. What is phishing?

2. Why should the original email be preserved?

3. Why can a display name be misleading?

4. What is a lookalike domain?

5. What is the Reply-To field?

6. Why can Reply-To mismatch be suspicious?

7. What does the Received header show?

8. What is SPF?

9. What does an SPF fail indicate?

10. Does SPF pass prove an email is legitimate?

11. What is DKIM?

12. What is DMARC?

13. Why should SPF, DKIM and DMARC be reviewed together?

14. Why should visible link text not be trusted?

15. What is URL redirection?

16. Why can recently registered domains be interesting?

17. Does a newly registered domain prove phishing?

18. What is a credential-harvesting page?

19. Why should suspicious pages never receive real credentials?

20. Why should attachments be analyzed safely?

21. Why must the SOC search for other recipients?

22. What is campaign scope?

23. Does clicking a phishing link prove compromise?

24. What does proxy telemetry establish?

25. What does DNS telemetry establish?

26. Why should endpoint telemetry be reviewed?

27. What evidence can confirm credential submission?

28. Why should authentication logs be reviewed after phishing?

29. Why was Priya’s account considered compromised?

30. Why were all clicked users not automatically classified as compromised?

31. What is an IOC?

32. What email-related IOCs can be collected?

33. Why should malicious messages be removed from all mailboxes?

34. Why should domains and URLs be blocked?

35. Why should historical telemetry be searched?

36. How can phishing investigations improve detection engineering?

37. How can phishing investigations support threat hunting?

38. Why must facts and hypotheses remain separate?

39. Why does forwarding configuration not automatically prove data exfiltration?

40. What makes a phishing investigation defensible?

Key Takeaways

Phishing investigation follows:

Report
      ↓
Preserve
      ↓
Analyze Headers
      ↓
Analyze Sender
      ↓
Analyze URL
      ↓
Determine Scope
      ↓
Identify Interaction
      ↓
Review Authentication
      ↓
Determine Impact
      ↓
Contain
      ↓
Hunt

Remember:

Display Name
      ≠
Verified Sender

SPF Pass
      ≠
Legitimate Email

New Domain
      ≠
Malicious Domain

URL Click
      ≠
Credential Submission

Credential Submission
      ≠
Confirmed Account Abuse

until authentication or related evidence supports it.

But:

Malicious Email
+
Credential Site
+
User Submission
+
Unauthorized Login

creates strong evidence of:

Successful
Credential Phishing

Career Connection

This lab mirrors work performed by:

SOC Analysts

Email Security Analysts

Blue Team Analysts

Incident Responders

Security Operations Analysts

During an interview, you should be able to explain:

I investigated
a Microsoft-themed
credential phishing
campaign.

I preserved and analyzed
the original email,
reviewed sender and
Reply-To information,
Received headers and
SPF, DKIM and DMARC.

I analyzed the phishing
URL and identified a
recently registered
credential-harvesting
domain.

I searched enterprise
email, proxy and DNS
telemetry to identify
all recipients and users
who interacted with
the campaign.

I correlated one user's
phishing interaction with
credential submission,
MFA approval and an
unauthorized authentication.

I contained the affected
identity, removed the
malicious messages,
blocked the attacker
infrastructure and expanded
the investigation across
the enterprise.

What’s Next?

➡️ Next: Lab 04 — Business Email Compromise Investigation

In this lab, you investigated:

How Credentials
Can Be Stolen

through phishing.

The next lab begins after an attacker already has access to a corporate mailbox.

You will investigate:

Suspicious Login
      ↓
Mailbox Access
      ↓
Inbox Rules
      ↓
External Forwarding
      ↓
Internal Impersonation
      ↓
Payment Fraud

You will analyze:

Authentication

Mailbox Audit Logs

Inbox Rules

Forwarding

Sent Messages

Deleted Messages

OAuth Applications

Finance Communications

Identity Activity

and determine whether the incident represents:

Mailbox Compromise

Business Email Compromise

Fraud Attempt

Data Exposure

➡️ Next: Lab 04 — Business Email Compromise Investigation