Phishing Triage & Response — Email, SMS, Slack, Telegram
A practical, channel-by-channel knowledge base for triaging a reported phishing message: how to think about it, exactly what to check, what evidence to extract, and how to respond. Built for a SOC/IR analyst who just got a "is this phishing?" ticket. Pairs with the analyst-OPSEC guidance in ../malware/reverse-engineering-linux.md and the decision-making mindset in ir-psychology.md.
Last verified2026-06
The Mental Model First
Before touching any channel, fix the goal in your head. A phishing message is an attacker trying to make a human do one of four things:
1. CLICK → a link to a credential-harvesting page or a malware/drive-by host
2. OPEN → a malicious attachment (macro doc, ISO/LNK, HTML smuggling)
3. REPLY → social-engineering / BEC (wire transfer, gift cards, "send me the W-2")
4. AUTH → approve an MFA push, enter an OAuth consent, hand over an OTPYour triage answers three questions in order:
(verdict: phishing / spam / legitimate)
(credentials / malware / money / MFA approval)
(who else got it, did anyone act on it, what's now compromised)
Memory hookthe analyst's prime directiveTreat every reported message as live ammunition. Don't click links from your real browser, don't open attachments on your endpoint, don't reply, and don't authenticate from a corporate IP — every one of those tips off the attacker or infects you. Investigate in an isolated/sandbox environment, and pull on the message's metadata before its content.
Universal First Steps (every channel)
For email, get the original .eml/.msg with full headers — never a forwarded copy (forwarding strips headers and rewrites links). For chat/SMS, get a screenshot plus the raw link text and sender identifier.
Detonate links/attachments in a sandbox (any.run, Joe Sandbox, a throwaway VM on a non-corporate network), never on your workstation.
when recording them so nobody clicks by accident: hxxps://evil[.]com, 1.2.3[.]4.
sender address/number, reply-to, every URL (and its final redirect destination), attachment hashes, displayed vs. actual link, sending IPs.
Don't block-and-close — first find everyone who received it (see Blast Radius).
Channel 1 — Email Phishing
Email is the richest channel because the headers carry a verifiable trail. Check in this order: headers → authentication → sender → links → attachments → content.
A. Headers — the metadata trail
Read headers bottom-to-top: the bottom Received: line is the origin server, the top is the most recent hop. Look for:
| Header | What to check | Red flag |
|---|---|---|
Received: (chain) | The originating server/IP; does the path make sense? | First hop is a random VPS, residential IP, or a country unrelated to the claimed sender |
From: | The display-name vs the actual address | "IT Helpdesk <random@gmail.com>" — display-name spoofing |
Reply-To: | Where a reply actually goes | Differs from From: (BEC redirect to attacker inbox) |
Return-Path: (envelope sender) | The real bounce address | Mismatch with From: domain |
Message-ID: | Format and domain | Doesn't match the sending domain; malformed |
X-Mailer / X-Originating-IP | Sending tool / source IP | Bulk-mailer tooling for a "personal" email |
B. Email authentication — SPF, DKIM, DMARC
In the Authentication-Results: header, you'll see the verdicts. (Full mechanics in ../networking/dns-deep-dive.md.)
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of x does not designate 1.2.3.4 as permitted sender)
dkim=fail
dmarc=fail (p=REJECT)was this server allowed to send for the domain? (envelope sender check)
is the cryptographic signature valid and unbroken? (content integrity)
do From: and SPF/DKIM align, and what's the policy?
Memory hookauth pass ≠ safe; auth fail ≠ always phishing. A message can pass SPF/DKIM/DMARC and still be phishing — the attacker simply sends from a domain they legitimately control (
paypa1-security.compasses its own SPF) or from a compromised mailbox. Conversely, a legitimate newsletter relayed through a mailing list often fails DKIM. So treat auth results as one signal, not the verdict. The killer combo is lookalike domain + passing auth — it looks "verified" to users.
C. Sender & domain analysis
rn vs m, paypa1, .co vs .com, IDN homoglyphs (Cyrillic а), extra subdomains (microsoft.login.evil.com).
newly registered domains (days old) are highly suspicious — check WHOIS creation date.
the name says "CEO" but the address is unrelated.
D. Link analysis (do NOT click)
the real href vs the displayed text — classic mismatch.
expand bit.ly, t.co, and "safe-link" rewrappers (Proofpoint urldefense, Microsoft safelinks) to the true destination — use a URL expander or sandbox, not your browser.
is it a credential form impersonating O365/Okta/Google? Does it pre-fill the victim's email (a tell of targeted harvesting)?
embedding the payload in the page itself.
E. Attachment analysis
(SHA-256) and check VirusTotal — but mind OPSEC: uploading a targeted sample can tip off the attacker. Hash-search first; only upload if it's clearly commodity.
macro-enabled Office (.docm, .xlsm), .iso/.img/.vhd (bypass mark-of-the-web), .lnk, .html (smuggling), .zip/.7z (often password-protected to evade scanning — the password is in the email body, itself a red flag), .onenote.
watch for child processes (Office spawning PowerShell/cmd — see ../detection/endpoint-detection.md), network callbacks, dropped files, persistence.
F. Content / pretext
Classic social-engineering tells: urgency ("account suspended in 24h"), authority ("from the CEO"), fear, reward, and a request that bypasses process (gift cards, wire change, "don't tell anyone"). These map to BEC when there's no link/attachment at all — pure text asking for money or data.
Channel 2 — SMS Phishing ("Smishing")
SMS has almost no metadata — no SPF/DKIM, sender IDs are trivially spoofable, and links are always shortened. So you lean on the link and the pretext.
What to check
short codes, a number from an unexpected country, or an alphanumeric sender ID (spoofable). A "bank" texting from a random mobile number is a tell.
smishing always uses a shortener or a lookalike domain because of the character limit. Expand it in a sandbox. Watch for lookalikes (usps-tracking[.]top, dhl-redelivery[.]info) and odd TLDs (.top, .xyz, .info).
the big four smishing themes are package delivery ("reschedule your parcel"), banking/fraud alerts, toll/tax ("unpaid toll"), and job offers / "wrong number" pig-butchering leading to crypto scams.
many smishing pages detect non-mobile user-agents and show a benign page — analyze with a mobile user-agent in the sandbox or you'll miss the payload.
Memory hooksmishing strips your toolsNo headers, no auth, no attachments usually — just a number and a link. So the verdict rests on (1) does the link's true destination match the claimed brand, and (2) does the brand ever initiate this over SMS? Banks/carriers/governments almost never send actionable links by SMS. When metadata is gone, the link is the evidence.
Channel 3 — Slack (and Teams) Phishing
Internal chat platforms are increasingly abused because messages there carry implicit trust ("it's in our Slack, must be a colleague"). Two attack shapes:
External / inbound
from outside your workspace — a stranger reaching in. Check whether the sender is a workspace member or an external connection (Slack flags this).
messaging yours through a shared channel.
Internal / compromised account
- A taken-over employee account messaging colleagues — far more dangerous because the identity is real. The tells are behavioral, not technical: out-of-character requests, urgency, links to "the new HR portal," requests to install an app or approve something.
What to check
real member vs external (Slack Connect badge)? Account recently active from a new device/location? (Pull the Slack audit logs / access logs.)
malicious link to a credential page, or a request to authorize a third-party Slack/OAuth app (consent-grant abuse — see ../detection/itdr-identity-detection.md). Approving the app, not clicking a link, is often the goal.
same attachment analysis as email.
if it's an internal account, immediately check that user's recent auth events for compromise (impossible travel, new device, token reuse).
Memory hookin chat, trust is the vulnerabilityEmail phishing fights to look trusted; Slack/Teams phishing starts trusted because it's inside the walls. So the investigation pivots from "is this domain fake?" to "is this account actually behaving like this person?" — it becomes an identity investigation. A compromised internal Slack account is an ITDR case, not just a phishing ticket.
Channel 4 — Telegram (and WhatsApp/Signal) Phishing
Consumer messaging apps are used for scams, impersonation, malware delivery, and recruitment of insiders. There's effectively zero platform-provided trust metadata, and accounts are pseudonymous.
What to check
username, phone number (if visible), account age, profile. Telegram usernames are reassignable and impersonation of brands/executives ("Official Support") is rampant. A "support" account that DMs you first is a red flag — real support rarely initiates.
crypto investment ("guaranteed returns"), fake job offers, "verify your account" links to phishing pages, requests to move to another platform, or links to malicious bots / .apk files (Android malware).
Telegram bots are used as C2 and as phishing front-ends; treat any t.me/...bot or external link as hostile until expanded in a sandbox.
(relevant to corporate IR): attackers DM employees offering money to run a program, share access, or approve an MFA prompt. Treat any such report as a potential insider-threat + initial-access event, not just a scam.
Memory hookpseudonymous channels = identity is unprovableOn Telegram you cannot trust the displayed name or "verified" badge at all. The only solid signals are behavioral (unsolicited contact, urgency, a request that benefits the sender) and the destination of any link/file. Assume impersonation by default.
Cross-Channel: Safe URL & Attachment Detonation
| Goal | Safe way | Avoid |
|---|---|---|
| Expand a shortener/safelink | URL-expander service or curl -I from a sandbox VM | Pasting into your real browser |
| See the landing page | any.run / Joe Sandbox / browser-in-VM on non-corp network, with a mobile UA for smishing | Visiting from a corp IP (tips off attacker; timing correlation) |
| Check a file | Hash → search VT/MalwareBazaar first | Uploading a targeted sample blindly (OPSEC leak) |
| Observe behavior | Detonate in a sandbox; watch process tree + network | Opening on your endpoint |
(See the Analyst OPSEC Failures section in ../malware/reverse-engineering-linux.md for why each "avoid" matters.)
Blast Radius / Scoping
The reported message is rarely the only copy. Before you close the ticket:
search the mail gateway / Slack admin / logs for the same sender, subject, URL, or attachment hash across the org.
check web proxy/DNS logs for the malicious URL; check the URL-rewrite click logs (Proofpoint/Defender record who clicked).
if it was a harvesting page, assume clickers who reached it may have entered creds. Pivot to identity: force password reset and session/token revocation (a reset alone doesn't kill stolen tokens — see ../detection/itdr-identity-detection.md).
hunt the file hash and the spawned behavior across endpoints (EDR).
(BEC) — was a wire sent, data shared, or an app authorized?
Response Actions
CONTAIN
- Quarantine/purge all copies from mailboxes (e.g. mail-gateway search-and-purge)
- Block sender, domain, URL, and file hash at gateway / proxy / EDR
- For Slack/Telegram: report & remove the account/message; revoke malicious OAuth apps
ERADICATE / RECOVER (if anyone acted)
- Reset credentials AND revoke active sessions/tokens for affected users
- Re-image endpoints that ran a malicious attachment
- Revoke any OAuth grants the user approved
REMEMBER THE FEEDBACK LOOP
- Turn confirmed IOCs into detections (sender patterns, URL/domain, file hash, lookalike-domain monitoring)
- Add the lookalike domain to monitoring (CT logs, registrar alerts)
- If a control should have caught it, file the gap (see detection-engineering.md)Quick Triage Checklist (printable)
[ ] Got the ORIGINAL message (email: full headers .eml; chat/SMS: screenshot + raw link/sender)
[ ] Working in isolation (sandbox / non-corp network) — NOT my workstation
[ ] EMAIL: read Received chain bottom-up; checked From / Reply-To / Return-Path
[ ] EMAIL: SPF / DKIM / DMARC results read as ONE signal, not the verdict
[ ] Sender domain: lookalike? newly registered? display-name spoof?
[ ] Links: expanded shorteners/safelinks to TRUE destination (no clicking from real browser)
[ ] Landing page: credential harvester? pre-filled victim email?
[ ] Attachment: hashed; dangerous type?; detonated in sandbox (process tree + network)
[ ] SMS: expanded link w/ MOBILE user-agent; brand ever texts links?
[ ] SLACK/TEAMS: sender external (Connect) or internal? if internal -> identity compromise check
[ ] TELEGRAM/WhatsApp: unsolicited? impersonation? link/bot/.apk hostile until proven
[ ] IOCs extracted and DEFANGED (hxxp, [.])
[ ] VERDICT decided: phishing / spam / legit
[ ] BLAST RADIUS: who else got it? who clicked? who entered creds? who replied?
[ ] CONTAIN: purge copies, block IOCs
[ ] If anyone acted: reset creds + REVOKE SESSIONS/TOKENS; re-image; revoke OAuth
[ ] Feed IOCs into detections; monitor lookalike domainInterview Questions
First I get the original message with full headers, not the forward — forwarding strips the Received chain and rewrites links, destroying the evidence. Then I investigate from an isolated environment, never my workstation. I don't click from a real browser because (a) it can deliver a drive-by payload to my endpoint, and (b) it tips off the attacker — many phishing kits log visitor IPs and using a corporate IP reveals that the org is investigating, which can make them burn infrastructure or accelerate. Instead I expand the URL and detonate it in a sandbox on a non-corporate network. I read metadata before content: headers, SPF/DKIM/DMARC, sender domain, then the link's true destination.
No. Authentication only proves the message came from a server authorized for that sending domain and wasn't altered — it says nothing about whether the domain is trustworthy. An attacker who registers a lookalike domain like paypa1-security.com passes its own SPF and DKIM perfectly, and a compromised legitimate mailbox passes everything too. So auth results are one signal among many, not the verdict. The most dangerous combination is a lookalike or compromised domain that passes auth, because it appears verified to users and to naive filters. I'd still check domain legitimacy, age, lookalike patterns, link destinations, and intent.
SMS strips away most of your tools — there are no headers, no SPF/DKIM/DMARC, and sender IDs are trivially spoofable — so the link and the pretext carry the whole verdict. The link is always shortened or a lookalike because of the character limit, so expanding it to its true destination is the key step, and I do it with a mobile user-agent because many smishing pages serve a benign page to non-mobile clients. Then I ask whether the impersonated brand ever sends actionable links by SMS — banks, carriers, and governments generally don't. The themes are predictable: package delivery, bank fraud alerts, unpaid tolls, and job/"wrong number" scams.
The investigation pivots from "is this sender fake?" to "is this account actually behaving like this person?" First I check whether the sender is a real workspace member or an external Slack Connect contact. If it's an internal account, the likely scenario is account takeover, which is more dangerous because the identity is genuine and trusted. So it becomes an identity investigation: I pull that user's recent authentication events for signs of compromise — impossible travel, a new device, token reuse — and check the Slack audit logs. I also watch for the specific Slack goal of getting someone to authorize a malicious OAuth app, which is consent-grant abuse rather than a link click. Contain by disabling the account, revoking sessions, and removing the messages.
Blocking the sender handles one copy; it doesn't tell you the blast radius. Before closing I have to scope: find every recipient by searching the gateway for the same sender, subject, URL, and attachment hash; check proxy and URL-rewrite click logs to see who actually clicked; and if it was a credential harvester, treat clickers as potentially compromised and force password resets and session/token revocation, because a reset alone leaves stolen tokens valid. If it carried an attachment, I hunt the file hash and its behavior across endpoints. And I close the loop by turning the confirmed IOCs into detections and monitoring the lookalike domain — so containment, scoping, and detection improvement all happen, not just a block-and-close.