What To Do If You Clicked
A recovery lesson framed as scenario, attack chain, observable evidence, operator response, and WitnessOps controls.
Problem this page solves
After a phishing click, teams often choose between fast cleanup and careful investigation without a clear recovery model. This page gives a time-bounded, evidence-first sequence so early actions reduce risk without destroying proof.
Reader outcome
After this page, you should be able to:
- run first-hour triage with explicit evidence boundaries
- choose containment actions based on interaction depth, not assumptions
- escalate when impact or uncertainty crosses defined thresholds
Mechanism-first recovery sequence (first minutes/hours)
Use this sequence when a user reports clicking a suspicious link, opening an attachment, entering credentials, or approving MFA unexpectedly.
0–15 minutes: stabilize and preserve
- Capture a short user statement: what was opened, clicked, entered, approved, or executed, and when.
- Preserve source artifacts before cleanup: original message (
.emlwhen possible), URL, attachment hash, and screenshots. - Start a response timeline with UTC timestamps and actor identity for each step.
15–60 minutes: verify exposure and contain account risk
- Check identity and session telemetry for unfamiliar successful sign-ins near the interaction window.
- If credential, token, or MFA exposure is plausible, reset credentials and revoke active sessions/tokens for the affected account.
- Review mailbox and account changes: forwarding rules, OAuth/app grants, reset-method changes, and unusual outbound mail.
1–4 hours: bound scope and reduce spread
- Validate whether adjacent workflows were touched (finance approvals, internal messaging, file-sharing access).
- Check for secondary phishing from the affected account and notify recipients through known-good channels.
- Run endpoint triage when attachment open or execution evidence exists; avoid destructive cleanup until key artifacts are captured.
Decision gates for containment vs escalation
- Gate A (exposure-only): message reported, no click/open/credential/MFA/session evidence.
- Decision: block indicators, retain artifacts, document as exposure-only, monitor.
- Gate B (interaction): click/open evidence exists, but no credential/MFA/session compromise evidence yet.
- Decision: preserve full timeline, increase auth/endpoint monitoring, apply scoped containment.
- Gate C (account exposure likely): credential entry, unexpected MFA approval, suspicious session, or token/app-grant anomaly.
- Decision: perform account containment immediately and execute Phishing Investigation.
- Gate D (escalation threshold): privileged account, multi-user spread, finance/regulatory workflow impact, or scope cannot be bounded quickly.
- Decision: escalate through governed incident handling using Do I Need to Escalate? and required approvals.
Evidence preservation requirements during response
- preserve original artifacts before user mailbox cleanup or endpoint remediation
- record collection source, timestamp, and collector for each artifact
- retain immutable copies/hashes for URLs, attachments, and key logs where possible
- document each containment action (what changed, by whom, and why)
- keep sensitive artifacts in controlled handling paths via Sensitive Artifact Handling
What WitnessOps controls support vs cannot guarantee
WitnessOps can support:
- Phishing Investigation for governed recovery sequencing
- Do I Need to Escalate? for impact- and uncertainty-based escalation gates
- What Evidence Is Required? for minimum decision completeness
- Sensitive Artifact Handling and Receipts for controlled evidence flow and signed response history
WitnessOps cannot guarantee:
- prevention of all phishing interactions
- complete reconstruction if required telemetry is missing, late, or altered
- attacker attribution from a single event
- external recovery outcomes (for example, third-party financial reversal timelines)
Observed vs inferred separation
- Observed: preserved lure artifact, click/open telemetry, sign-in/session logs, mailbox-rule changes, token/app-grant changes.
- Inferred: "attacker fully controlled the account," "all impacted systems are known," or "no further risk remains."
Use observed evidence to justify immediate response actions. Keep inferred statements explicit and provisional until corroborated.
Trust assumptions and limits
Assumptions:
- identity, mailbox, and endpoint telemetry is retained and time-aligned enough for sequence reconstruction
- responders preserve key artifacts before broad cleanup
- high-impact actions follow policy and approval gates
Limits:
- delayed reporting can remove short-lived evidence (redirect chains, transient sessions)
- adversaries may evade, suppress, or overwrite telemetry
- some scope decisions remain probabilistic until additional corroborating evidence is collected
Next-page handoff
Continue to How Attackers Think for attacker economics and path selection logic that explain why these recovery gates matter.