What To Do If You Clicked

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 and 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

1. Capture a short user statement: what was opened, clicked, entered, approved, or executed, and when.
2. Preserve source artifacts before cleanup: original message (.eml when possible), URL, attachment hash, and screenshots.
3. Start a response timeline with UTC timestamps and actor identity for each step.

15–60 minutes: verify exposure and contain account risk

1. Check identity and session telemetry for unfamiliar successful sign-ins near the interaction window.
2. If credential, token, or MFA exposure is plausible, reset credentials and revoke active sessions or tokens for the affected account.
3. Review mailbox and account changes: forwarding rules, OAuth or app grants, reset-method changes, and unusual outbound mail.

1–4 hours: bound impact scope and reduce spread

1. Validate whether adjacent workflows were touched, such as finance approvals, internal messaging, or file-sharing access.
2. Check for secondary phishing from the affected account and notify recipients through known-good channels.
3. 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, or session evidence.
  • Decision: block indicators, retain artifacts, document as exposure-only, monitor.
• Gate B (interaction): click or open evidence exists, but no credential, MFA, or session-compromise evidence yet.
  • Decision: preserve the full timeline, increase auth or endpoint monitoring, apply scoped containment.
• Gate C (account exposure likely): credential entry, unexpected MFA approval, suspicious session, or token or app-grant anomaly.
  • Decision: perform account containment immediately and execute Phishing Investigation.
• Gate D (escalation threshold): privileged account, multi-user spread, finance or regulatory workflow impact, or impact scope cannot be bounded quickly.
  • Decision: escalate through governed incident handling using Do I Need to Escalate? and required approvals.

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.

Evidence preservation requirements during response

• preserve original artifacts before mailbox cleanup or endpoint remediation
• record collection source, timestamp, and collector for each artifact
• retain immutable copies or 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, such as third-party financial reversal timelines

Observed vs inferred separation

• Observed: preserved lure artifact, click or open telemetry, sign-in or session logs, mailbox-rule changes, token or app-grant changes.
• Inferred: "the 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, such as redirect chains or transient sessions
• adversaries may evade, suppress, or overwrite telemetry
• some impact-scope decisions remain probabilistic until more 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.