phishing report triage: what to check first

phishing report triage: what to check first

TL;DR

When someone reports a phish, first confirm what it is and who else got it. Pull the full headers, expand every link, and check whether anyone clicked before you spend time on the pretty parts of the message. Speed matters more than completeness in the first 15 minutes.

phishing report triage: what to check first

Use this when

• a user reports a suspicious email to the security team
• your phishing report mailbox gets a submission and nobody knows if it is real
• you need a consistent triage order instead of ad-hoc digging
• a reported phish might be an active campaign hitting many mailboxes

Not for this skill when

• the report is about a smishing text or a vishing call (different channels, different checks)
• you are building a phishing awareness training program
• the email is confirmed spam with no malicious payload (just delete it)
• you need to do full malware analysis on the attachment (escalate that)

Steps

1. Get the original message with full headers, not a forwarded copy. Forwarding strips the headers you need. Ask the reporter to use "forward as attachment" or pull it from the mail gateway logs yourself.

1. Check the sender. Compare the display name against the actual address, look for reply-to mismatches, and watch for lookalike domains (rnicrosoft, paypa1). The From header tells the story more often than the body does.

1. Expand every link. Follow shortened URLs to their final destination and compare the real domain against the brand the message claims to be:

curl -s -o /dev/null -w "%{url_effective}\n" -L "[shortened link]"

Expected: the final landing domain. If it doesnt match the claimed brand, it is a phish.

1. Check attachments without opening them. Get the file hash and look it up in your sandbox or threat intel platform:

sha256sum [downloaded attachment]

Expected: a hash you can search. A known-malicious hash answers the question in seconds. Dont open the file on your workstation.

1. Find the blast radius. Search the mail gateway logs for the same sender or subject across all mailboxes in the last 48 hours. Count every recipient, not just the ones who reported it. Most people delete phish silently.

1. Check for clicks. Search proxy and DNS logs for the link domain from internal IPs. Everyone who resolved or visited it goes on the follow-up list for credential resets and endpoint checks.

1. Check for credential submission. If it was a login phish and anyone entered credentials, treat those accounts as compromised right now and run the account-containment skill. Dont wait for confirmation.

1. Block and clean up. Block the sender domain and URLs at the email gateway and web proxy, delete the message from all mailboxes, and add a detection for the campaign pattern so the next wave gets caught automatically.

Variant: triage of a smishing or vishing report

Same order, different artifacts: capture the phone number and message text, check the number against spam-reporting databases, expand any links the same way, and check whether anyone called back or clicked. Report the number to the carrier if your process includes that.

Variant: phish targeting executives

Whaling gets the fast lane: skip straight to blast radius and click checks, notify the executive's assistant out of band, and assume any clicked link means a compromised mailbox until proven otherwise. Executives' mailboxes are high-value targets.

Variant: internal-looking phish from a compromised vendor

When the sender is a real vendor whose account got hijacked, domain blocks wont help and the message looks legitimate. Focus on the link destinations and the requested action, warn anyone who does business with that vendor, and ask the vendor to confirm the compromise through a known channel.

Why this happens

Phishing is still the top initial access method because it targets people, not software. Triage order matters: headers and links confirm it fast, blast radius and click checks decide how bad it is, and every minute of delay is another chance for someone to enter credentials.

Edge cases and pitfalls

• The user already deleted the email. Pull it from the gateway logs or the report mailbox instead of asking them to find it.
• A forwarded copy lost the headers. Ask for the original or reconstruct the sender path from gateway logs.
• Unicode lookalike domains are hard to spot by eye. Copy the domain into a punycode decoder when something looks off.
• A reported phish is sometimes legit marketing mail. Verify with the supposed sender through a known channel before you block their domain company-wide.
• Dont reply to the phisher or click "unsubscribe." Both confirm your address is live.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7aUH-BVgAalxNLLfQ4BOJA