Someone clicked the phishing link
A proportionate response based on what the user entered, downloaded, approved, or executed—not panic based on the click alone.
Scope
For help desks and security teams triaging a reported phishing click on a managed user account or endpoint.
Start with the situation, not the slogan
An incident rarely arrives with a neat label. It arrives as a forwarded screenshot, a worried telephone call, or a monitoring alert written by a machine with no sense of occasion. In this case “Someone clicked the phishing link” is the working heading, but the label is only a starting hypothesis. The useful work is to establish what happened, what can still happen, and which decision cannot safely wait.
Keep three clocks in view: the attacker’s opportunity, the business interruption, and the lifetime of the evidence. They do not run at the same speed. A hasty change may interrupt access but erase context; a perfect investigation conducted at geological pace may leave the organisation exposed. Good response is the slightly unglamorous art of making the next reversible decision with the best evidence currently available.
A click can mean anything from a blocked page to credential theft, OAuth consent, session theft, or malware execution. The correct response depends on the interaction and the evidence that followed it.
Composite scenario
How this usually reaches the desk
Imagine the report begins with this observation: “Browser history, download records, endpoint alerts, and the exact destination URL and redirect chain.” A second check returns another clue: “Authentication events following the click, including MFA prompts, token use, and new sessions.” Neither fact alone tells the whole story. Together they justify a documented incident, a defined owner, and a deliberate containment decision. This is where a timeline beats a collection of heroic memories; memory is an excellent storyteller and a dreadful audit log.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
Browser history, download records, endpoint alerts, and the exact destination URL and redirect chain.
Record the exact time, source, identity, system and time zone. Compare it with a known-good baseline and with what the user or service owner expected. A surprising event is a lead, not a conviction.
Authentication events following the click, including MFA prompts, token use, and new sessions.
Look for the control-plane event that made the visible activity possible: a changed credential, permission, rule, route, token or trusted device. Persistence often looks administrative because, technically, it is.
Email or cloud changes such as rules, forwarding, consent grants, password resets, or outbound messages.
Correlate the report with independent telemetry before deciding scope. User testimony, identity logs, endpoint evidence and service audit records are strongest when they agree on sequence rather than merely on mood.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Extract the authentication results from an EML file
- Prerequisites
- A saved `.eml` message; do not open attachments or remote content.
grep -iE '^(From|Return-Path|Reply-To|Message-ID|Received|Authentication-Results|DKIM-Signature):' suspicious.eml > headers.txt
shasum -a 256 suspicious.eml headers.txtThe selected headers are written to a text file and both files receive hashes.
SPF, DKIM and DMARC results describe domain authentication, not whether the message is honest. Inspect the full Received chain and business context.
Compare the sending infrastructure and reply path with a known-good message from the claimed organisation.
Reveal a link target without visiting it
- Prerequisites
- A saved `.eml`; no browser is required.
python3 - <<'PY'
from email import policy
from email.parser import BytesParser
from html.parser import HTMLParser
class Links(HTMLParser):
def handle_starttag(self, tag, attrs):
if tag == 'a': print(dict(attrs).get('href',''))
with open('suspicious.eml','rb') as f:
msg=BytesParser(policy=policy.default).parse(f)
for part in msg.walk():
if part.get_content_type()=='text/html': Links().feed(part.get_content())
PYEvery HTML anchor destination is printed as text.
A blank result can mean the message is plain text, encoded unusually or contains a button built without an anchor. Do not browse the URLs from a trusted session.
Defang URLs for the case record, search mail telemetry for other recipients, and block only after confirming the correct domain or indicator.
Hash every attachment without executing it
- Prerequisites
- A saved `.eml` and a new empty output directory.
mkdir attachments
python3 - <<'PY'
from email import policy
from email.parser import BytesParser
from pathlib import Path
import hashlib
m=BytesParser(policy=policy.default).parse(open('suspicious.eml','rb'))
for p in m.iter_attachments():
data=p.get_payload(decode=True) or b''
name=Path(p.get_filename() or 'attachment.bin').name
out=Path('attachments')/name; out.write_bytes(data)
print(hashlib.sha256(data).hexdigest(), name)
PYAttachments are written without launching their associated applications and each SHA-256 is printed.
Extraction is not detonation. A clean reputation result cannot prove safety, and confidential attachments should not be uploaded to public services.
Scan in an approved isolated environment, retain the original message, and correlate hashes with endpoint and mail-gateway telemetry.
What to do
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Containment and recovery are different verbs. Containment limits the next harmful action; recovery returns a service to trustworthy operation. Between them sits eradication: removing the access path and persistence that would make the freshly restored service merely a cleaner target. For Phishing, Email and Identity, keep those decisions separate in the timeline even if a small team performs them minutes apart.
Communication is also a control. Tell affected people what is known, what remains uncertain, what they must do and when the next update will arrive. Avoid both melodrama and false reassurance. “We are investigating” is useful only when followed by an owner and a time. The goal is to reduce secondary harm without teaching a possible attacker exactly what the team has discovered.
Handover
Make the result useful to the next person
Maintain two views of the incident. The working timeline should contain detailed events, evidence locations, hypotheses and technical actions. The stakeholder update should contain confirmed impact, current containment, material uncertainty, decisions required and the next reporting time. Do not copy speculative indicators into executive statements. Equally, do not polish away uncertainty merely because it looks untidy. Both records should use absolute times with a declared time zone and should identify the source of each important fact.
At shift change, hand over the current scope, trusted administration path, preservation status, active controls, failed actions, business priorities and the next three decisions. Read back the most consequential assumptions. For this case, ensure the record begins with “Capture the original message, headers, URLs, attachment hashes, and the user’s account of each interaction. Do not rely on memory later.” and does not finish until the team has addressed “Search for the message, sender, URLs, attachments, and related activity across the organisation; remove the lure while retaining an evidence copy.” A concise, accurate handover prevents the incoming team from repeating disruptive work or mistaking a quiet telemetry gap for successful containment.
Validate before you close
Close only when the user account and endpoint have been checked, related recipients are handled, malicious infrastructure is blocked where appropriate, and follow-up monitoring has an owner.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Resetting systems before preserving volatile evidence and audit logs.
- Treating the first visible symptom as the complete scope of the incident.
- Restoring service without verifying that the attacker’s access path is closed.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Does one suspicious event prove compromise?
No. Treat “Browser history, download records, endpoint alerts, and the exact destination URL and redirect chain.” as a reason to investigate and preserve evidence. Confidence should rise when independent identity, service, endpoint or network records support the same sequence.
Should we reset everything immediately?
Reset or revoke what the evidence and risk justify, but preserve the state you will need to understand the incident. Broad, undocumented resets can interrupt the attacker, the business and the investigation in one impressively efficient stroke.
When can the incident be closed?
Close only when the user account and endpoint have been checked, related recipients are handled, malicious infrastructure is blocked where appropriate, and follow-up monitoring has an owner. Closure also requires named owners for residual risk and follow-up work; “it seems quiet now” is an observation, not an exit criterion.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- Recognize and Report PhishingCISA
- SP 800-61 Rev. 3: Incident Response Recommendations and ConsiderationsNIST
- Responding to a Compromised Email AccountMicrosoft Learn
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.