Why Phishing Works
A phishing lesson framed as scenario, attack chain, observable evidence, operator response, and WitnessOps controls.
Problem this page solves
Phishing reports often jump from "user clicked" to broad cleanup without a clear compromise model. This page gives a stage-based response path so containment matches the evidence quality.
Reader outcome
After this page, you should be able to:
- map a phishing report to a specific chain stage
- collect stage-appropriate signals before taking intrusive actions
- choose containment with explicit escalation gates
Mechanism-first scenario model (phishing chain stages)
Scenario: a supplier-themed invoice email sends a user to a fake login page.
- Delivery — the lure reaches the inbox and looks routine.
- Interaction — the user opens the message and follows a link or attachment.
- Credential capture — credentials, MFA approval, or session token are exposed.
- Session establishment — the attacker authenticates to the real service.
- Post-access actions — forwarding rules, resets, internal phishing, or payment-fraud attempts begin.
Observable signals per stage
| Stage | Directly observable signals |
|---|---|
| Delivery | preserved message, header path, sender/reply-to mismatch, domain age or reputation |
| Interaction | click telemetry, URL resolution, attachment open or execution events |
| Credential capture | user confirmation, fake-login artifact, authentication prompt mismatch |
| Session establishment | unfamiliar successful sign-in, new session or device, impossible-travel pattern |
| Post-access actions | mailbox rule changes, outbound burst, reset attempts, administrative anomalies |
Practical response and containment sequence with decision gates
- Preserve source artifacts, such as the email, URL, attachment hash, and user timeline.
- Validate interaction depth: opened only, clicked, credentials entered, or MFA approved.
- Gate A: No click and no execution -> classify as exposure-only, block indicators, document.
- Gate B: Click or file open without credential evidence -> isolate the endpoint if needed, monitor auth telemetry, continue investigation.
- Gate C: Credential, MFA, or token exposure likely -> revoke sessions, reset credentials, remove attacker changes, run the governed phishing workflow.
- Gate D: Privileged account, multi-user spread, or financial workflow impact -> escalate through the governed incident path.
Close locally only when the evidence is sufficient, risk is bounded, and the selected action stays inside your authorization boundary. Otherwise escalate explicitly.
What WitnessOps controls can support vs what they cannot guarantee
WitnessOps can support:
- Phishing Investigation for governed triage and evidence capture
- Policy Gates for approval before intrusive tenant-wide actions
- What Evidence Is Required? for decision completeness
- Receipts for signed containment and remediation traceability
WitnessOps cannot guarantee:
- prevention of every phishing attempt
- complete reconstruction when telemetry is missing, delayed, or tampered with
- attacker attribution from a single artifact
Observed vs inferred separation
- Observed: message artifact, resolved URL, sign-in record, rule-change log.
- Inferred: "credentials were stolen," "attacker intended fraud," or "blast radius is complete."
Use observed evidence to justify immediate containment. Treat inferred claims as hypotheses until corroborated.
Trust assumptions and limits
Assumptions:
- logs are retained and time-aligned enough for sequence reconstruction
- original artifacts are preserved before cleanup
- responders follow policy gates for high-impact actions
Limits:
- delayed reporting can hide first access
- adversaries may evade or remove telemetry
- some impact-scope decisions remain probabilistic until additional evidence arrives
Next-page handoff
Continue to 7 Phishing Tricks Attackers Use for recurring lure patterns and how they map back to this chain.