A Real Phishing Email

A line-by-line phishing example framed as scenario, attack chain, observable evidence, operator response, and WitnessOps controls.

Problem this page solves

Phishing examples often become stories instead of investigations, which makes response decisions drift away from evidence. This page shows a representative phishing artifact set and ties each conclusion to what is directly observable.

Reader outcome

After this page, you should be able to:

walk a phishing report through delivery, interaction, credential, and post-access stages
state what each artifact supports and what it does not support
choose a response gate that matches the evidence quality

Mechanism-first walkthrough of a representative phishing artifact or event

This walkthrough is synthetic but mechanically representative. Treat it as an artifact-handling exercise, not as attribution.

Representative lure artifact (preserved message excerpt)

From: Microsoft Account Team <security@microsft-account.com>
Reply-To: noreply@microsft-account.com
Subject: Unusual sign-in activity on your account

We detected unusual activity.
Verify your account now to avoid access restrictions.

Verify My Account:
https://login-microsoft-security-check[.]com/verify

Stage-by-stage artifact walkthrough

Chain stage	Primary artifact	What to verify in that artifact	Evidence boundary
Delivery	`phishing-email.eml`	sender or reply-to mismatch, header path, auth results	supports suspicious-message classification, not account compromise
Interaction	click telemetry or browser history	whether and when the user opened or clicked	supports interaction timing, not credential exposure
Credential capture	fake-page capture + user statement	non-canonical login domain, credential-entry claim, unexpected MFA prompt context	supports likely credential exposure when corroborated
Session establishment	identity sign-in logs	successful sign-in from an unfamiliar IP or device after interaction	supports possible unauthorized session
Post-access actions	mailbox or cloud audit logs	forwarding rules, outbound anomalies, token or app changes	supports impact progression if present

Observable indicators and what each indicator supports

Observable indicator	Source artifact	What it supports	What it does not prove by itself
Claimed brand does not match sender domain	preserved email headers	impersonation attempt	that credentials were entered
Link resolves to a non-canonical or lookalike domain	resolved URL evidence	lure destination is attacker-controlled or untrusted	that compromise already occurred
User confirms entering credentials or approving MFA	user interview + timeline note	account-exposure likelihood	that the attacker successfully authenticated
Successful new sign-in after the interaction window	identity-provider sign-in logs	possible unauthorized session establishment	full impact scope
New forwarding rule or unusual outbound activity	mailbox audit logs	post-access activity likely occurred	attacker intent or attribution

Response decisions and escalation gates tied to evidence quality

Gate A (exposure-only): preserved lure artifact, no click or open evidence.
- Decision: classify exposure-only, block indicators, notify the user, document the receipt.
Gate B (interaction): click or open evidence exists, but no credential, MFA, or session evidence.
- Decision: preserve the full timeline, monitor sign-in telemetry, run endpoint checks if attachment interaction occurred.
Gate C (account exposure likely): credential entry, MFA approval, or suspicious new session evidence.
- Decision: reset credentials, revoke sessions or tokens, inspect mailbox changes, execute Phishing Investigation.
Gate D (high impact): privileged account, multi-user spread, or payment or workflow impact.
- Decision: escalate through the governed incident path with Policy Gates before high-impact actions.

Close locally only when the evidence is sufficient, the impact scope is bounded, and the selected action stays inside your authorization boundary. Otherwise escalate explicitly.

What WitnessOps controls support vs cannot guarantee

WitnessOps controls can support:

Phishing Investigation for governed triage and containment sequencing
What Evidence Is Required? for minimum evidence completeness before intrusive action
Do I Need to Escalate? for escalation criteria tied to impact and uncertainty
Sensitive Artifact Handling for controlled handling of email, URL, and identity artifacts
Receipts for signed, replayable decision records

WitnessOps cannot guarantee:

prevention of all phishing delivery attempts
complete reconstruction when telemetry is missing, delayed, or altered
attacker attribution from a single lure or sign-in event
external recovery outcomes, such as third-party financial reversal

Observed vs inferred separation

Observed: preserved email headers, resolved URL, click timestamp, sign-in event record, mailbox rule-change log.
Inferred: "credentials were definitely stolen," "the attacker fully controlled the mailbox," or "the full impact scope is known."

Use observed artifacts to justify immediate containment. Keep inferred claims explicit and provisional until more evidence confirms them.

Trust assumptions and limits

Assumptions:

email, identity, and mailbox telemetry is retained and time-aligned enough to reconstruct sequence
original artifacts are preserved before mailbox cleanup or endpoint remediation
high-impact actions follow policy and approval gates

Limits:

delayed reporting can remove short-lived evidence, such as redirect chains or transient sessions
adversaries may evade, suppress, or overwrite telemetry
some impact-scope conclusions remain probabilistic until more corroborating evidence is collected

Next-page handoff

Continue to What To Do If You Clicked for time-bounded recovery actions when interaction has already occurred.