What evidence may exist after a phishing incident?¶
Usually more than the message itself.
A phishing incident can leave evidence across the communication, device, browser, website, identity, provider and business-response layers.
The quickest way to avoid missing useful material is to ask: which stage of the incident am I trying to prove?
Match the source to the question¶
| Question | Useful evidence may include |
|---|---|
| Was the message delivered? | Native email/SMS, headers, provider trace, mailbox records |
| Was the link opened? | Browser history, proxy/DNS, endpoint telemetry |
| Was data submitted? | Browser/form artefacts, network, server/hosting records |
| Was malware run? | Endpoint/process/file evidence |
| Was the account taken over? | Authentication, sessions, MFA, recovery/security changes |
| Was money lost? | Payment instructions, approvals, bank records, communications |
One message cannot prove all of those stages.
Build the incident as a linked sequence¶
A useful reconstruction might look like:
The strength comes from the sequence agreeing across independent systems.
Use shared identifiers¶
Useful pivots include:
- message ID;
- account ID;
- device ID;
- session ID;
- URL/domain;
- IP address;
- file hash;
- exact timestamps.
These let you test whether records from several sources really describe the same incident.
Record missing evidence too¶
You may find that:
- browser history was cleared;
- provider retention expired;
- endpoint logging was disabled;
- the phishing page has been removed;
- identity logs were never enabled.
That is part of the evidential picture.
The practical point is: build phishing evidence stage by stage. Use the source that can answer the specific question, then join the stages with identifiers and time.
