Playbook: reported phishing message
Triage the message, interaction, identity, endpoint, and recipient scope without detonating the lure or deleting the only evidence.
Scope
For help desks and security teams receiving a phishing report.
Start with the situation, not the slogan
A playbook is a decision aid for tired people working with incomplete information. Playbook: reported phishing message therefore names owners, evidence, containment and exit criteria instead of pretending every incident follows a flowchart. Read it before the incident, tailor the contacts and systems, and exercise the awkward branches.
The first objective is shared situational awareness: what is known, who owns the incident, what business process is at risk, and which decision is due next. A chat channel full of competent people is not the same as command. Assign a coordinator and a note taker, even when the organisation is small enough for both to use the same kettle.
The message alone does not define the incident. Response changes based on whether the user viewed, clicked, entered data, approved consent, downloaded, or executed content.
Composite scenario
How this usually reaches the desk
The playbook should activate when the team can establish its entry conditions, including: The original message with full headers and attachments is preserved. If the report remains ambiguous, open a low-severity record and time-box validation rather than ignoring it or declaring the end of civilisation. Escalate as evidence, privilege, spread or business impact increases.
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.
The original message with full headers and attachments is preserved.
Confirm this condition from an authoritative source and note who supplied it. Mark assumptions as assumptions; they have an unfortunate habit of becoming facts in copied status updates.
The reporter describes each interaction and approximate time.
Identify the decision that depends on the information and the deadline for obtaining it. Evidence is most useful when it changes action rather than merely decorating the timeline.
Search capability exists for sender, subject, URLs, attachment hashes, and recipients.
Check coverage and retention before containment. If a source is unavailable, record the gap and use independent evidence rather than silently treating absence as innocence.
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.
Response sequence
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
Run the playbook as a checklist with judgement, not as a spell. For Phishing, Playbook and Email, localise tenant names, log locations, provider contacts, legal thresholds, emergency credentials and business priorities. A generic document becomes operational only when the people on duty can find the required access without consulting the person currently on holiday.
Use a decision log separate from the task list. For each consequential action, note time, owner, evidence, choice, expected effect and observed result. This gives later reviewers something better than a reconstructed story and helps the next shift understand why a seemingly obvious action was delayed or rejected.
Handover
Make the result useful to the next person
Prepare the playbook package before an incident: primary and deputy owners, current contact routes, system inventory, evidence locations, delegated authority, provider escalation, legal and privacy triggers, secure communication, and emergency credentials. Keep a printable or otherwise independent copy where an identity or collaboration outage cannot hide it. Review contact details during exercises; telephone numbers appear to age faster than almost any cryptographic primitive.
For this playbook, the incident record should open with “Preserve the message and interview the user using a short interaction checklist.” and drive deliberately towards “Block appropriate indicators, monitor, document false-positive risk, and feed findings into mail controls and training.” A shift handover must state confirmed facts, open hypotheses, business impact, containment already applied, evidence at risk, approvals pending and the next scheduled update. After closure, turn lessons into owned changes to controls, documentation and exercises. A lesson without an owner and a date is simply a well-written regret.
Validate before you close
Exit when user and device risk are assessed, related recipients are handled, evidence is retained, controls are updated, and monitoring and communication owners are assigned.
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
- Running the playbook without assigning a decision owner and note taker.
- Containing too early or too late because evidence and business impact were not compared.
- Closing the incident without documenting recovery checks and follow-up owners.
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
Who may activate the playbook?
Define that locally before an incident. Help desk or monitoring staff should be able to open a record and escalate; containment authority may sit with incident command, service ownership or an executive depending on impact.
Must every step be completed in order?
No. Evidence, containment, communication and recovery often run in parallel. Keep dependencies explicit and do not let a later checkbox imply that an earlier decision was actually verified.
What is the exit condition?
Exit when user and device risk are assessed, related recipients are handled, evidence is retained, controls are updated, and monitoring and communication owners are assigned. Residual risk, communication and improvement actions still need named owners even after service is restored.
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
- Responding to a Compromised Email AccountMicrosoft Learn
- SP 800-61 Rev. 3: Incident Response Recommendations and ConsiderationsNIST
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.