AI Playbook for Phishing Campaign Attribution

A financial institution's email security gateway blocked 1,847 phishing emails in a 72-hour window. Fourteen employees clicked links before the campaign was blocked; two entered credentials. The campaign spoofed the institution's own domain. The security team suspects a targeted attack, not commodity phishing.

When to use this playbook

• Use this playbook when the decision looks like the situation above: A financial institution's email security gateway blocked 1,847 phishing emails in a 72-hour window.
• It is a fit when you have source files in hand and need a structured, reviewable analysis — not a generic chat answer about "Phishing Campaign Attribution".
• Do not use it as a substitute for licensed, legal, clinical, or authorized official judgment in the domain.

What you'll need

• Email gateway log (1,847 blocked and 14 delivered messages)
• Phishing email samples with full headers
• Credential entry log (2 employees who submitted credentials)
• DNS and certificate transparency records for the spoofed domain
• Threat intelligence feeds (ISAC, FS-ISAC)

Attachments: Documents (Documents)

You are a threat intelligence analyst attributing a targeted phishing campaign against a financial institution. I am attaching:

Work only from the attached source files. If a conclusion is not supported, say so.

Produce:
1. Analyze the email infrastructure: sending IPs, lookalike domain registration date, SSL certificate issuer, and MX records—does this match known threat actor TTPs?
2. Identify the 14 employees who clicked: their roles, access levels, and whether either credential-submitting employee has privileged access.
3. Assess whether the credential submissions have already been used: check for impossible travel, off-hours logins, or new MFA device registrations.
4. Determine whether this is a commodity campaign or targeted (spear phishing) based on email content, target selection, and infrastructure sophistication.
5. Tell me the immediate credential reset and MFA enforcement steps, and whether this requires FS-ISAC notification or regulatory disclosure.

Call out where independent models are likely to disagree, and list follow-up documents a reviewer should request.

What to expect

• Threat actor TTP attribution
• Privileged access exposure for credential-submitting employees
• Credential use analysis
• Campaign classification (commodity vs. targeted)
• Immediate response checklist and regulatory disclosure assessment

Review before you act

• Validate this output against source files before relying on it: Analyze the email infrastructure: sending IPs, lookalike domain registration date, SSL certificate issuer, and MX records—does this match known threat actor TTPs?.
• Validate this output against source files before relying on it: Identify the 14 employees who clicked: their roles, access levels, and whether either credential-submitting employee has privileged access.
• Validate this output against source files before relying on it: Assess whether the credential submissions have already been used: check for impossible travel, off-hours logins, or new MFA device registrations.
• Validate this output against source files before relying on it: Determine whether this is a commodity campaign or targeted (spear phishing) based on email content, target selection, and infrastructure sophistication.
• Confirm every cited figure, date, counterparty, or requirement against the attached originals — models compress and can drop a qualifier.
• Treat disagreement between models as a review item, especially on classification, materiality, and recommended next action.
• Do not authorize an operational, clinical, legal, credit, or enforcement action solely because the models agree.