What evidence may exist after a phishing incident?¶

A phishing incident may create evidence across the communication, device, website, account and provider layers.

Avoid the dangerous assumption¶

The dangerous assumption is that the phishing message itself contains the complete evidence.

It rarely does.

Relevant evidence may include:

• the original email, text or message
• message headers and delivery records
• attachments and file hashes
• links and redirect chains
• browser history and downloads
• DNS, proxy and network records
• endpoint alerts and process activity
• fake login pages and hosting records
• account authentication and session logs
• multi-factor prompts
• password resets
• mailbox rules and forwarding changes
• payment or account-change records
• reports made by the recipient
• incident-response notes.

Start with the investigative question.

If the issue is whether a message was delivered, email or messaging records may be central.

If the issue is whether credentials were entered, browser and website evidence matters.

If the issue is account takeover, identity and session records become more important.

If malware may have executed, endpoint and forensic evidence may be required.

Preserve identifiers that allow records to be linked, such as message IDs, account IDs, device names, session IDs, URLs, domains, IP addresses and timestamps.

Do not assume that one missing record disproves the incident. Logging may not have been enabled, retention may have expired or the activity may have occurred outside monitored systems.

Also preserve legitimate communications used for comparison. They may help show how the impersonation was constructed or why the victim trusted it.

Operational takeaway¶

Map the phishing event across communication, device, website, identity and organisational records, and prioritise the sources that answer the specific investigative question.