Lab 07 Browser, Email & Phishing Forensics

Mission Overview

Welcome to Lab 07 — Browser, Email & Phishing Forensics.

In the previous labs, you investigated disk artifacts, deleted files, Windows and Linux endpoints, and volatile memory.

Now you will investigate a very common enterprise incident path:

Suspicious Email → User Interaction → Browser Activity → Download → Endpoint Evidence

Phishing investigations often fail when analysts examine only one source.

An email may look suspicious, but the real forensic questions are:

• Was the email delivered?

• Was the sender identity consistent?

• Did the user visit the embedded link?

• Was a file downloaded?

• Did the file exist on the endpoint?

• Was it opened or executed?

• Did the system communicate with related infrastructure?

• Which parts of that sequence are confirmed, supported, or still unknown?

Mission Goal: Analyze a provided phishing email and associated browser/endpoint evidence, reconstruct the interaction sequence, correlate email headers, URLs, browser history, downloads, files, DNS/network evidence, and produce a defensible Phishing Forensic Investigation Report.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Phishing Forensics
Secondary Skill	Browser & Email Artifact Correlation
Environment	GoHackersCloud Digital Forensics Lab
Evidence Type	Training email + browser + endpoint evidence
Testing Type	Offline forensic examination
Primary Outcome	Phishing Evidence Correlation Matrix
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• preserve phishing evidence safely

• identify relevant email-header fields

• distinguish visible sender from technical sender evidence

• analyze reply-to inconsistencies

• review email-routing information

• identify URLs without visiting them

• examine attachment metadata safely

• investigate browser history

• analyze browser download records

• correlate URLs with downloaded files

• review endpoint file evidence

• compare timestamps across evidence sources

• correlate DNS and network evidence

• identify evidence of user interaction

• distinguish delivery from interaction

• distinguish download from execution

• build a phishing activity timeline

• maintain evidence lineage

• document indicators without overclaiming

• produce a professional phishing-forensics report

Investigation Methodology

Use:

Email → Header → URL/Attachment → Browser → Download → File → Endpoint Activity → Network → Timeline → Correlation → Conclusion

Conceptually:

Suspicious Email
       │
       ▼
Header Analysis
       │
       ▼
URL / Attachment
       │
       ▼
Browser Evidence
       │
       ▼
Download Evidence
       │
       ▼
Endpoint File
       │
       ▼
Execution / Activity Evidence
       │
       ▼
DNS / Network
       │
       ▼
Timeline
       │
       ▼
Correlated Conclusion

The key principle is:

An email being malicious does not automatically prove the user interacted with it.

Part 1 — Confirm Evidence Integrity

Document:

Case ID:

Evidence ID:

Email Evidence:

Browser Evidence:

Endpoint Evidence:

Network Evidence:

Expected SHA-256:

Current SHA-256:

Hash Match:

Investigator:

Date:

Start Time:

Hash important evidence files where applicable:

sha256sum suspicious-email.eml

and:

sha256sum browser-artifacts.zip

Work only from verified copies.

Part 2 — Create the Lab Workspace

Create:

Digital-Forensics-Labs/
└── Lab-07/
    ├── Notes/
    ├── Evidence/
    │   ├── Email/
    │   ├── Headers/
    │   ├── URLs/
    │   ├── Attachments/
    │   ├── Browser/
    │   ├── Downloads/
    │   ├── Endpoint/
    │   ├── DNS/
    │   └── Network/
    ├── Screenshots/
    ├── Timeline/
    ├── Findings/
    └── Report/

Create:

Lab-07-Phishing-Forensics-Journal.md

Suggested structure:

# Lab 07 — Browser, Email & Phishing Forensics

## Mission Objective

## Evidence Information

## Integrity Verification

## Email Summary

## Header Analysis

## Sender Analysis

## URL Analysis

## Attachment Analysis

## Browser History

## Browser Downloads

## Endpoint File Evidence

## Execution Evidence

## DNS Evidence

## Network Evidence

## Timeline

## Correlation

## Findings

## Limitations

## Conclusion

Part 3 — Preserve the Email

The training email may be provided as:

.eml

.msg

mbox

Exported email text

Do not forward the message to personal accounts.

Do not click URLs.

Do not open attachments using normal desktop applications.

Treat the email as evidence.

Record:

Email Evidence ID:

Format:

Filename:

SHA-256:

Source:

Acquisition Method:

Part 4 — Understand Email Evidence Layers

An email has several layers:

Visible Message
      │
      ├── Display Name
      ├── Subject
      ├── Body
      └── Visible Links
            │
            ▼
Technical Evidence
      ├── Headers
      ├── Routing
      ├── Sender Domains
      ├── Authentication Results
      └── MIME / Attachments

Do not judge legitimacy solely by what the user sees.

Part 5 — Record Basic Email Information

Create:

Subject:

Display Name:

From Address:

Reply-To:

To:

CC:

Date:

Message-ID:

Attachment Present:
Yes / No

URLs Present:
Yes / No

This becomes your baseline.

Part 6 — Distinguish Display Name from Email Address

Example:

Display Name:
IT Support

but:

From:
support@example-training.net

The display name is user-facing text.

It is not proof of identity.

Record both separately.

Part 7 — Examine the From Header

Document:

From Display Name:

From Address:

Domain:

Expected Organization Domain:

Match:
Yes / No / Unknown

A mismatch can be relevant, but not every external sender is malicious.

Part 8 — Examine Reply-To

A common investigative question is:

Does the Reply-To destination differ from the visible sender?

Create:

Field	Value
From
Reply-To
Same Domain	Yes / No
Relevance

A mismatch is an indicator requiring context.

It is not proof of phishing by itself.

Part 9 — Examine Return-Path

Where available, record:

Return-Path:

Domain:

Relationship to From:

Expected:
Yes / No / Unknown

This can provide additional sender-context evidence.

Part 10 — Review Received Headers

Email may pass through multiple mail systems.

Received headers can help reconstruct routing.

Conceptually:

Sender
   ↓
Mail Server A
   ↓
Mail Server B
   ↓
Recipient Environment

Record the relevant routing chain.

Part 11 — Build the Email Routing Register

Sequence	Server / IP	Timestamp	Observation
1
2
3

Remember:

Email headers are generally read from the bottom upward when reconstructing routing, but trust depends on which systems inserted each field.

Do not assume every sender-supplied header is trustworthy.

Part 12 — Review Email Authentication Results

Depending on the training evidence, headers may contain results for:

SPF

DKIM

DMARC

Record:

Control	Result	Domain	Interpretation
SPF
DKIM
DMARC

Part 13 — Understand SPF

SPF helps determine whether the sending system is authorized for a domain’s mail policy.

A result such as:

pass

does not automatically mean:

The email is safe.

An attacker can legitimately send mail from an attacker-controlled domain with correct SPF.

Part 14 — Understand DKIM

DKIM can provide cryptographic validation of particular message content and domain signing.

Again:

DKIM pass

does not mean:

Message is benign

It means the relevant DKIM validation succeeded.

Part 15 — Understand DMARC

DMARC uses domain alignment and policy around SPF/DKIM.

Record the actual result.

Do not simplify:

DMARC pass = trusted email

That conclusion is too strong.

Part 16 — Build the Sender Authentication Matrix

Evidence	Value	Supports Legitimacy	Raises Concern
From Domain
Reply-To
SPF
DKIM
DMARC
Routing

Use the total picture.

Part 17 — Review the Subject and Message Body

Examine the body as evidence.

Look for training indicators such as:

• urgency

• account warnings

• payment requests

• credential requests

• unexpected attachments

• link prompts

• impersonation language

Do not classify the email based on wording alone.

Part 18 — Extract URLs Without Visiting Them

Record URLs as text.

Do not click them.

Create:

URL ID	Display Text	Actual URL	Domain	Relevance
URL-01

If the visible text and target differ, document that distinction.

Part 19 — Defang URLs for Reporting

In reports, consider formatting indicators safely.

Example:

hxxps://training-example[.]com/login

instead of creating clickable links.

This is especially useful for reports shared outside the lab.

Part 20 — Identify URL Components

For each relevant URL, record:

Scheme:

Hostname:

Domain:

Subdomain:

Path:

Query Parameters:

Port:
If present

This helps separate the infrastructure from the page path.

Part 21 — Do Not Browse to the URL

Do not:

Open the link

Submit credentials

Download content

Interact with the website

The lab focuses on forensic evidence already provided.

Use existing browser, DNS, and network artifacts.

Part 22 — Analyze Attachments Safely

If the email contains an attachment, document:

Attachment ID:

Original Filename:

MIME Type:

File Size:

SHA-256:

Extension:

Detected File Type:

Do not open it using its associated application.

Part 23 — Compare Extension and Actual Type

Example:

invoice.pdf

but forensic file identification indicates another format.

Record:

Attachment	Extension	Detected Type	Match

A mismatch requires further examination.

It does not automatically prove maliciousness.

Part 24 — Build the Attachment Register

ID	Filename	Size	SHA-256	Type	Relevance
ATT-01

Maintain evidence lineage.

Part 25 — Understand MIME Structure

Email attachments and body sections may be stored as MIME parts.

Conceptually:

Email
  ├── Text Body
  ├── HTML Body
  └── Attachment

The visible message may not reveal all MIME content.

Record only what is relevant to the investigation.

Part 26 — Identify Browser Evidence

The lab may provide browser artifacts from software such as:

• Chromium-based browsers

• Firefox

• Edge

• another training browser

Potential evidence can include:

History

Downloads

Cookies

Cache

Sessions

Visited URLs

Search Terms

Focus on the case-relevant artifacts.

Part 27 — Build the Browser Profile Register

Create:

Browser	Profile	User	Relevant

Do not assume a browser profile belongs to the only human using the machine without supporting context.

Part 28 — Examine Browser History

Record case-relevant visits:

Time	URL	Title	Browser	Relevance

Pay particular attention to:

• email-linked domains

• redirects

• login pages

• download endpoints

Part 29 — Correlate Email URL with Browser History

Suppose the email contains:

hxxps://training-login[.]example/path

and browser history shows the same destination.

Now you have evidence supporting interaction.

Conceptually:

Email URL
    +
Browser Visit
    =
Supported Link Interaction

This is stronger than finding the URL only in the email.

Part 30 — Understand Browser History Limitations

History can be:

• deleted

• incomplete

• synchronized

• affected by private browsing

• retained inconsistently

• altered by browser configuration

Absence of browser history does not prove the link was never visited.

Part 31 — Analyze Redirect Chains

A browser may move through multiple URLs:

Email Link
    ↓
Redirect 1
    ↓
Redirect 2
    ↓
Final Page

Record the chain where evidence supports it.

Create:

Sequence	URL	Time	Source
1			Browser
2			Browser
3			Browser

Part 32 — Examine Download Evidence

Browser databases may record:

Filename

Source URL

Destination Path

Start Time

Completion Time

File Size

Download Status

depending on browser and version.

Create:

Time	File	Source URL	Destination	Status

Part 33 — Distinguish Visit from Download

These are different events.

URL Visited
     ≠
File Downloaded

and:

Download Started
     ≠
Download Completed

Document the exact evidence.

Part 34 — Correlate URL and Download

Example:

Email:
URL-01

then:

Browser History:
URL-01 visited

then:

Browser Download:
invoice-training.zip downloaded

This creates a stronger activity sequence.

Part 35 — Identify the Download Destination

Record:

Downloaded Filename:

Destination Directory:

Full Path:

Browser:

Start Time:

Completion Time:

Source URL:

The path may later correlate with Windows/Linux filesystem evidence.

Part 36 — Hash Downloaded Evidence

If the downloaded file is present in the evidence set:

sha256sum downloaded-training-file

Record:

Download Evidence ID:

SHA-256:

Filesystem Path:

File Size:

Detected Type:

Do not execute it.

Part 37 — Correlate Browser and Filesystem Evidence

Example:

Browser Download:
09:14 — training-file.zip

and:

Filesystem:
C:\Users\lab-user\Downloads\training-file.zip

with a matching hash.

This strongly supports that the browser-downloaded content corresponds to the endpoint artifact.

Part 38 — Distinguish Download from Execution

A downloaded file proves:

The file arrived on the endpoint, if sufficiently supported.

It does not automatically prove:

The file was opened or executed.

For that, examine:

• Prefetch

• process logs

• memory

• UserAssist

• shell history

• execution telemetry

• recent-item artifacts

depending on system type.

Part 39 — Correlate with Windows Evidence

For a Windows endpoint, you may have:

Browser Download
      +
Filesystem File
      +
Prefetch
      +
LNK / Jump List
      +
Memory Process
      =
Stronger Interaction Evidence

Not every artifact will be available.

Use what the evidence supports.

Part 40 — Correlate with Linux Evidence

For Linux:

Browser Download
      +
Filesystem File
      +
Shell / Service Evidence
      +
Authentication
      +
Logs
      =
Stronger Activity Reconstruction

Again, do not execute the downloaded artifact.

Part 41 — Examine DNS Evidence

If DNS logs are provided, search for relevant domains.

Record:

Time	Client	Query	Result	Relevance

DNS evidence may support that the system attempted to resolve the domain.

Part 42 — Understand DNS Limitations

DNS resolution does not automatically prove:

• browser interaction

• successful connection

• malicious activity

• page loading

Applications and background services can perform DNS queries.

Correlate.

Part 43 — Examine Network Evidence

If a PCAP or network log is provided, identify connections related to case-relevant domains/IPs.

Record:

Source:

Destination:

Protocol:

Port:

Time:

Associated Domain:
If supported

Relevant Process:
If available through correlation

Part 44 — Build the Network Evidence Register

Time	Source	Destination	Port	Related Artifact

Part 45 — Correlate Browser, DNS, and Network

Example:

Browser History
     │
     ├── URL visited at 09:10
     │
DNS
     ├── Domain resolved at 09:10
     │
Network
     └── Connection at 09:10

Together:

The evidence strongly supports browser interaction with the relevant destination.

Part 46 — Examine Email Timestamps Carefully

Email evidence may contain several times:

Sender Date

Server Received Time

Mailbox Delivery Time

The sender-controlled date may not be the most trustworthy timestamp.

Prefer infrastructure-generated timestamps where appropriate.

Part 47 — Normalize All Times

You may now have:

Email server timestamps

Browser timestamps

Filesystem timestamps

Windows Event Logs

Memory acquisition times

DNS logs

PCAP timestamps

Convert to one standard.

Record:

Email Timezone:

Endpoint Timezone:

Network Timezone:

Normalized Standard:
UTC / Local

Conversion Applied:

Part 48 — Build the Phishing Timeline

Example:

Time	Source	Event	Confidence
09:02	Mail	Email received	Confirmed
09:07	Browser	Link visited	Confirmed
09:08	DNS	Domain resolved	Confirmed
09:09	Browser	File download started	Confirmed
09:09	Filesystem	File created	Supported
09:11	Endpoint	Program activity	Correlated

Part 49 — Build the Evidence Chain

Conceptually:

Email Delivered
      ↓
Link Present
      ↓
Browser Visit
      ↓
DNS Resolution
      ↓
Network Connection
      ↓
File Download
      ↓
Filesystem Artifact
      ↓
Program / User Activity

Your task is to determine how far the evidence chain can actually be proven.

Part 50 — Classify Interaction Level

Use a simple classification:

Level 0 — Delivery Only

Email arrived.

Level 1 — Message Interaction Supported

Evidence indicates message or associated content was accessed.

Level 2 — Link Interaction

Browser evidence supports URL visit.

Level 3 — Download

Download evidence supports file acquisition.

Level 4 — File Open / Execution

Endpoint evidence supports opening or execution.

Level 5 — Subsequent System / Network Activity

Correlated evidence shows relevant post-interaction behavior.

Do not assign a higher level than the evidence supports.

Part 51 — Build the Interaction Assessment

Email Delivered:
Yes / No

Link Present:
Yes / No

Link Visited:
Confirmed / Supported / Unknown

Download Started:
Confirmed / Supported / Unknown

Download Completed:
Confirmed / Supported / Unknown

File Present:
Confirmed / Unknown

File Opened:
Confirmed / Supported / Unknown

File Executed:
Confirmed / Supported / Unknown

Post-Execution Network Activity:
Confirmed / Supported / Unknown

Part 52 — Create the Phishing Evidence Correlation Matrix

Question	Email	Browser	Endpoint	Network	Confidence
Was email delivered?	Yes				High
Was link visited?	URL present	History		DNS	High
Was file downloaded?	Link	Download DB	File exists		High
Was file executed?			Execution artifact	Memory	Varies

This is the primary deliverable.

Part 53 — Separate Indicator from Finding

Indicator

Reply-To differs from From.

Finding

The email demonstrates multiple characteristics consistent with
the simulated phishing scenario, including sender inconsistency,
a case-relevant URL, and subsequent correlated browser activity.

A finding should be supported by several observations.

Part 54 — Separate Fact, Interpretation, Hypothesis

Fact

Browser history records a visit to the training URL.

Interpretation

The endpoint browser accessed the URL.

Hypothesis

The named employee knowingly clicked the phishing link.

The last statement requires human attribution that endpoint evidence may not independently establish.

Part 55 — Example Finding: Email Impersonation Indicators

Finding:
The message contains sender-identity inconsistencies relevant to
the simulated phishing investigation.

Evidence:
The visible display name represents the training organization's
support function, while the technical sender and reply-to domains
differ from the expected organizational domain.

Supporting Evidence:
The message also contains a case-relevant external URL.

Conclusion:
The email exhibits characteristics consistent with the training
phishing scenario.

Limitation:
Sender inconsistency alone is not sufficient to establish
malicious intent.

Part 56 — Example Finding: Link Interaction

Finding:
Browser evidence supports interaction with the URL contained in
the suspicious email.

Evidence:
The email contains URL-01 and browser history records a visit to
the corresponding destination shortly after message delivery.

Correlation:
DNS evidence records resolution of the same domain during the
same period.

Confidence:
High.

Part 57 — Example Finding: File Download

Finding:
A case-relevant file was downloaded following browser interaction.

Evidence:
The browser download database records the training file, its
source URL, destination path, and download timestamp.

Correlation:
A file with the corresponding name and hash exists at the
recorded endpoint location.

Conclusion:
The evidence supports successful acquisition of the file.

Limitation:
Download evidence alone does not prove the file was opened or
executed.

Part 58 — Example Finding: File Execution

Where execution evidence exists:

Finding:
Endpoint evidence supports execution of the downloaded training
file.

Evidence:
The downloaded artifact is correlated with a case-relevant
execution artifact during the post-download period.

Supporting Evidence:
Memory or endpoint telemetry independently references the same
file/process.

Confidence:
High.

If execution evidence does not exist:

Execution Status:
Unconfirmed

Do not fill the gap with assumption.

Part 59 — Build the Indicator Register

Create:

ID	Type	Indicator	Source	Relevance
IOC-01	Domain		Email	High
IOC-02	URL		Email	High
IOC-03	Hash		Attachment/File	High
IOC-04	IP		Network	Medium

Keep indicators associated with evidence source.

Part 60 — Understand IOC Limitations

An IOC may be:

• temporary

• shared infrastructure

• benign in another context

• reused

• stale

Therefore:

Indicator match ≠ complete incident conclusion.

The surrounding behavior matters.

Part 61 — Build the Evidence Lineage

Example:

E07-01 — Suspicious Email
   │
   ├── URL-01
   └── ATT-01
           │
           ▼
E07-02 — Browser Evidence
           │
           ├── HIST-01
           └── DL-01
                   │
                   ▼
E07-03 — Endpoint Artifact
                   │
                   ▼
E07-04 — Network Evidence

Maintain traceability across evidence sources.

Part 62 — Hash Extracted Evidence

For important extracted items:

sha256sum attachment-training.bin

and:

sha256sum downloaded-training.bin

Record:

Evidence ID:

Parent Evidence:

Original Location:

SHA-256:

Extraction Method:

Investigator:

Part 63 — Build the Investigation Hypothesis Register

Hypothesis	Supporting Evidence	Missing Evidence	Status
Email delivered	Mail artifact	None	Confirmed
Link visited	Browser + DNS	None	Confirmed
File downloaded	Browser + filesystem	None	Confirmed
File executed	File present	Execution evidence	Unconfirmed

Part 64 — Document Positive Evidence

Examples:

No attachment present

No execution artifact found

No subsequent connection to case-relevant endpoint

Browser history shows no visit

Download failed

Security control blocked access

These can significantly change incident severity.

Do not ignore evidence that disproves your initial hypothesis.

Part 65 — Reverify Evidence

At completion, verify key evidence hashes again where appropriate.

Record:

Email Pre-Analysis Hash:

Email Post-Analysis Hash:

Browser Evidence Pre-Analysis Hash:

Browser Evidence Post-Analysis Hash:

Match:

Integrity Status:

Part 66 — Mission Challenge

Using the supplied phishing evidence, complete:

CASE INFORMATION

Case ID:

Email Evidence ID:

Browser Evidence ID:

Endpoint Evidence ID:

Network Evidence ID:


EMAIL

Subject:

Display Name:

From:

Reply-To:

Return-Path:

Message-ID:

Received Time:

Attachment:
Yes / No

URL:
Yes / No


AUTHENTICATION

SPF:

DKIM:

DMARC:

Sender Domain Expected:
Yes / No


URL

URL ID:

Displayed URL:

Actual URL:

Domain:

Redirects:

Risk / Relevance:


ATTACHMENT

Filename:

MIME Type:

Detected Type:

SHA-256:

Extension Match:

Present on Endpoint:
Yes / No


BROWSER

Browser:

User Profile:

URL Visited:

Visit Time:

Redirect Evidence:

Download Started:

Download Completed:

Downloaded Filename:

Destination:

Source URL:


ENDPOINT

Downloaded File Present:

SHA-256 Match:

Creation Time:

Execution Evidence:

Process / Application:

Relevant User Context:


NETWORK

DNS Query:

Resolved IP:

Network Connection:

Destination:

Port:

Process Correlation:


TIMELINE

Email Delivered:

URL Visit:

DNS Resolution:

Download:

File Creation:

File Execution:

Network Activity:


INTERACTION LEVEL

Level:

Reason:


FINAL ANALYSIS

Email Suspicious:
Yes / No / Inconclusive

Link Interaction:
Confirmed / Supported / Unknown

Download:
Confirmed / Supported / Unknown

Execution:
Confirmed / Supported / Unknown

Post-Execution Activity:
Confirmed / Supported / Unknown

Strongest Evidence:

Largest Evidence Gap:

Highest-Confidence Finding:

Overall Conclusion:

Recommended Next Investigation:

Part 67 — What Not to Do

Do not:

Click suspicious links

Browse to suspicious domains

Submit credentials

Open unknown attachments normally

Execute downloaded files

Enable document macros

Forward evidence to personal mail

Modify the original email

Use discovered credentials

Assume SPF pass means safe

Assume suspicious email means user clicked

Assume browser visit means credentials entered

Assume download means execution

Assume execution automatically means compromise

Ignore timezone differences

Ignore evidence that disproves the phishing hypothesis

Attribute action to a specific human without supporting evidence

The rule is:

Preserve → Parse → Correlate → Qualify → Report.

Part 68 — Troubleshooting

Email Headers Are Incomplete

Record:

Header Coverage:
Incomplete

Do not invent routing or authentication results.

SPF/DKIM/DMARC Are Missing

This can occur for multiple reasons.

Record:

Authentication Evidence:
Not Available

Do not assume failure.

Browser History Is Missing

Possible explanations include:

• private mode

• clearing

• profile not included

• unsupported artifact

• evidence retention

Use DNS, filesystem, network, and endpoint evidence.

Download Entry Exists but File Is Missing

Possible explanations:

• download failed

• file deleted

• cleanup

• endpoint image taken later

• file moved

Correlate with Lab 03 deleted-file evidence.

File Exists but Browser Download Evidence Is Missing

The file may have arrived by:

• another browser

• email attachment

• removable media

• file share

• another application

Do not force the phishing narrative.

DNS Query Exists but Browser History Does Not

Another application may have caused the lookup.

Record the query as network/DNS evidence only until correlated.

Evidence Requirements

Capture:

Evidence 01

Email integrity hash.

Evidence 02

Email summary.

Evidence 03

From/Reply-To/Return-Path evidence.

Evidence 04

Received-header routing.

Evidence 05

SPF/DKIM/DMARC results where available.

Evidence 06

Sender Authentication Matrix.

Evidence 07

URL Register.

Evidence 08

Attachment Register.

Evidence 09

Browser Profile Register.

Evidence 10

Browser History evidence.

Evidence 11

Redirect-chain evidence.

Evidence 12

Download Register.

Evidence 13

Downloaded-file hash.

Evidence 14

Filesystem correlation.

Evidence 15

Execution evidence or documented absence.

Evidence 16

DNS evidence.

Evidence 17

Network Evidence Register.

Evidence 18

Phishing Timeline.

Evidence 19

Interaction Assessment.

Evidence 20

Phishing Evidence Correlation Matrix.

Evidence 21

Indicator Register.

Evidence 22

Hypothesis Register.

Evidence 23

Evidence lineage.

Evidence 24

Final forensic report.

Mission Deliverables

Complete:

• email evidence preserved

• evidence hashes verified

• sender fields recorded

• From and Reply-To compared

• routing reviewed

• authentication results documented

• Sender Authentication Matrix created

• URLs extracted without visiting

• URLs safely documented

• attachments hashed and identified

• browser profile identified

• browser history examined

• email URL correlated with browser evidence

• redirect chain reviewed

• download artifacts examined

• download status determined

• downloaded file located where available

• file hash correlated

• execution evidence assessed

• DNS evidence reviewed

• network evidence reviewed

• all timestamps normalized

• phishing timeline created

• interaction level assigned

• indicators documented

• facts separated from hypotheses

• positive evidence documented

• Phishing Evidence Correlation Matrix completed

• evidence lineage maintained

• final report completed

Lab Report Template

# Lab 07 — Browser, Email & Phishing Forensics

## Executive Summary

## Mission Objective

## Case Information

## Evidence Information

## Integrity Verification

## Email Analysis

### Subject and Sender
### Reply-To
### Return-Path
### Message-ID
### Routing

## Email Authentication

### SPF
### DKIM
### DMARC

## URL Analysis

## Attachment Analysis

## Browser Profile Analysis

## Browser History

## Redirect Analysis

## Download Analysis

## Endpoint File Correlation

## Execution Assessment

## DNS Analysis

## Network Analysis

## Phishing Activity Timeline

## Interaction Assessment

## Indicator Register

## Evidence Correlation

## Investigation Hypotheses

## Positive Evidence

## Findings

## Limitations

## Recommended Follow-Up

## Conclusion

## Appendix A — Email Header Evidence

## Appendix B — Indicators

## Appendix C — Hashes

## Appendix D — Evidence Lineage

Knowledge Check

Question 1 — Does a familiar display name prove the sender’s identity?

No.

The technical sender and authentication evidence must also be examined.

Question 2 — Does SPF pass mean an email is safe?

No.

It only indicates the relevant SPF check succeeded.

Question 3 — Why examine Reply-To?

Because it can reveal that responses would be sent somewhere different from the apparent sender.

Question 4 — Should a forensic examiner click a suspicious URL?

No.

Use the supplied offline evidence instead.

Question 5 — Does browser history matching the email URL strengthen the case for interaction?

Yes.

It provides independent evidence that the destination was visited.

Question 6 — Does DNS resolution prove the user viewed the page?

No.

It only supports that a domain lookup occurred.

Question 7 — Does a browser download entry prove execution?

No.

Execution requires endpoint or runtime evidence.

Question 8 — Why correlate the downloaded file hash?

To establish whether the endpoint artifact corresponds to the downloaded evidence.

Question 9 — What is the strongest phishing investigation approach?

Correlating email, browser, endpoint, DNS, and network evidence.

Question 10 — What distinction must always be maintained?

Delivery → Interaction → Download → Execution → Impact are separate stages that require separate evidence.

Skills Achieved

After completing this lab, you should understand:

• email forensic preservation

• email header analysis

• sender-identity analysis

• Reply-To investigation

• mail-routing analysis

• SPF concepts

• DKIM concepts

• DMARC concepts

• URL extraction

• safe URL reporting

• attachment evidence handling

• MIME concepts

• browser profile analysis

• browser history forensics

• browser download analysis

• redirect-chain analysis

• endpoint file correlation

• file-hash correlation

• execution assessment

• DNS correlation

• network correlation

• timeline normalization

• interaction-level assessment

• IOC documentation

• hypothesis management

• evidence lineage

• professional phishing forensic reporting

Professional Takeaway

A phishing investigation should never stop at:

“The email looks suspicious.”

The professional workflow is:

Email Delivered
      +
Sender Evidence
      +
URL / Attachment
      +
Browser History
      +
Download Evidence
      +
Endpoint File
      +
Execution Evidence
      +
DNS / Network
      =
Defensible Phishing Reconstruction

Always distinguish:

Email Delivered
      ≠
Email Interacted With

Link Present
      ≠
Link Visited

Link Visited
      ≠
Credentials Submitted

File Downloaded
      ≠
File Executed

File Executed
      ≠
Compromise Automatically Proven

The core investigative question is:

“How far through the phishing interaction chain can the evidence actually prove the endpoint progressed?”

That is the difference between a suspicious-email review and a professional phishing forensic investigation.

What’s Next?

➡️ Lab 08 — Network Forensics & Packet Investigation

In the next lab, you will move from endpoint and phishing evidence to the network itself.

You will investigate:

• PCAP integrity

• endpoints

• conversations

• protocols

• DNS

• HTTP/HTTPS metadata

• TCP sessions

• unusual communication patterns

• timing

• internal-to-external connections

• packet-level evidence

• browser/network correlation

• endpoint/process correlation

• network timeline reconstruction

The methodology becomes:

PCAP → Hosts → Conversations → Protocol → DNS → Session → Application Metadata → Correlation → Timeline → Evidence

By the end of Lab 08, you should be able to answer:

“Which systems communicated, which protocols and destinations were involved, how does packet evidence align with endpoint activity, and what network conclusions can be supported without overinterpreting individual packets?”