How to Use MITRE ATT&CK for Phishing Incident Investigation

Phishing investigations often begin with an email report and end with a much wider question: did anyone interact with the message, submit credentials, run code, or give an attacker access to another service?

Short answer: use MITRE ATT&CK to describe the supported phishing behavior, connect it to evidence and investigation questions, and track what happened after delivery, interaction, and any suspected account access.

ATT&CK should make the investigation clearer. It should not turn an unverified message into a confirmed compromise.

Start with the message and delivery evidence

Preserve the original message and record:

• Sender, recipient, reply-to, and authentication results.
• Message headers and delivery path.
• URLs, domains, attachments, and file hashes where available.
• Time delivered, opened, clicked, or reported.
• Other recipients of the same or similar message.
• Mailbox rules, forwarding, or account changes linked to the event.
• User statements about clicks, downloads, calls, or credential entry.

Keep the original message protected. Do not paste secrets or unnecessary personal data into tools that do not need them.

Map the phishing behavior carefully

MITRE ATT&CK identifies Phishing as T1566 under Initial Access, with sub-techniques for spearphishing attachment, spearphishing link, spearphishing via service, and spearphishing voice.

Choose the sub-technique that matches the delivery evidence:

• Spearphishing Attachment: T1566.001: a malicious or suspicious attachment was delivered as the access method.
• Spearphishing Link: T1566.002: a link was used to direct the victim to a malicious or credential-harvesting destination.
• Spearphishing via Service: T1566.003: a third-party service was used to deliver the phishing content.
• Spearphishing Voice: T1566.004: a voice interaction was used as the phishing delivery method.

Do not select a technique simply because a message looked suspicious. A reported spam message may be an event or alert rather than a confirmed incident.

Investigate the user interaction chain

The delivery technique is only the beginning. Establish what happened next:

1. Was the message delivered to one person or many?
2. Did anyone open the message or attachment?
3. Did anyone click a link, call a number, or visit a destination?
4. Did a user enter credentials, approve an MFA prompt, or provide information?
5. Did a file execute or cause a browser, script, or remote-access process to start?
6. Did the account, device, or mailbox show follow-on activity?

The answers may support additional techniques such as User Execution, Valid Accounts, Input Capture, or Multi-Factor Authentication Request Generation. Add them only when the investigation evidence supports them.

Use a phishing investigation ticket structure

This structure keeps the phishing technique connected to evidence and response rather than treating ATT&CK as a label added at the end.

Separate message containment from account containment

Removing the message can reduce further interaction, but it does not prove that the incident is contained.

Depending on the findings, the team may need to:

• Search for and remove related messages.
• Block a malicious sender, domain, URL, or attachment where appropriate.
• Revoke sessions and reset credentials.
• Review MFA changes and unusual authentications.
• Isolate an endpoint if a file executed or suspicious activity followed.
• Preserve relevant mail, identity, endpoint, and network evidence.
• Notify affected users and owners.

Use the incident containment validation guidance to define what must be checked before considering the incident contained.

Do not over-map the investigation

Common errors include:

• Treating every suspicious email as a confirmed attack.
• Mapping a link to credential access without evidence that credentials were targeted or entered.
• Treating a blocked attachment as proof of execution.
• Treating a user report as proof of account compromise.
• Adding several techniques because they are possible rather than supported.

Keep a mapping as a hypothesis when the evidence is incomplete. Record what would raise or lower confidence.

Turn phishing lessons into improvements

After closure, review whether the incident revealed weaknesses in:

• User reporting and triage.
• Mail filtering and message handling.
• Authentication and MFA controls.
• Browser or endpoint protections.
• Account recovery and session revocation.
• Incident ownership and response timing.
• Evidence retention and investigation access.

The MITRE ATT&CK mapping pillar explains how to carry mapping evidence into handoffs and lessons learned. For the broader improvement cycle, see How to Build a Security Improvement Loop from Incidents, Controls, and Evidence.

IncidentAI can support structured phishing incident records, triage, ownership, evidence, timelines, and ATT&CK context where relevant. It does not determine whether legal reporting is required or replace human investigation and approval.

Quick FAQ

Is every phishing report an incident?

No. A report may be spam, a blocked attempt, an event requiring review, or a confirmed incident. Classify it using evidence, interaction, impact, and risk.

What is the primary ATT&CK technique for phishing?

Phishing is T1566 under Initial Access. Use the supported sub-technique when the delivery method is known.

Does clicking a phishing link prove compromise?

No. Clicking indicates interaction and may require further checks. The investigation must establish what the destination did and whether credentials, code, tokens, or other information were exposed.

Sources

• MITRE ATT&CK Enterprise Tactics
• MITRE ATT&CK Phishing
• MITRE ATT&CK User Execution