9.2 Advanced Indicators of Compromise in Phishing
Surface Tells Stop Working
Grammar mistakes and doubled letters used to be the tell. Machine translation removed them, homoglyph and IDN tricks make rn indistinguishable from m, free ACME certificates put the padlock on fraudulent hosts, and open redirects let a clean-looking URL land on anything. Training that stops at "look for typos" buys false confidence, so triage moves from surface inspection to semantic and operational verification.
Context Mismatch
Ask whether the referenced thing exists. Does the vendor named actually appear in your procure-to-pay system? Is that ticket number real in the ITSM tool? Does the "HR policy update" match the naming convention your HR team uses? Legitimate mail arrives inside your working context; phishing asserts a context you cannot corroborate. This check defeats most targeted attacks even when authentication passes, because attackers routinely send perfectly authenticated mail from a compromised or freshly registered domain -- authentication is orthogonal to legitimacy.
Manufactured Urgency and Authority Gradient
The payload of a phish is almost always an operational request with a deadline. Catalog the high-risk verbs: change remittance details or bank account digits, buy gift cards, approve an MFA prompt you did not start, wire before a "cutoff", download a quota-recovery form, or send from your personal account because the corporate one is "broken". The pressure mechanics are authority (an exec, legal, or a regulator), scarcity of time, and secrecy -- an NDA or "don't loop in anyone yet" clause that specifically disables the verification path. A request that becomes harder to verify the faster you must act is the single strongest indicator.
Cross-Channel Claims and Thread Hijacking
Watch for channel hops that break an audit trail: email saying "call this new number, our switch changed", a WhatsApp or SMS follow-up pushing the same task, or a thread reply quoting a genuine old message so the history looks inherited. Reply-in-thread attacks harvest real text from a compromised mailbox and attach a new ask, so prior legitimacy proves nothing about the current message. Treat a changed endpoint -- phone number, bank account, portal URL, MFA method -- as untrusted until confirmed out of band using contact data from a prior artifact, never the copy printed in the suspicious message itself.
A Repeatable Triage Protocol
Sequence it: authenticate (SPF, DKIM, DMARC alignment and originating host), inspect (rendered text against real href, attachment type and macro or script capability), corroborate (does the referenced entity exist), verify operationally (independent channel for anything touching money, identity, or credentials), then act. Report through the organization's report button rather than deleting, because the sample is the telemetry that blocks the next recipient.
Architecture Diagram
Key Takeaways
- Fluency is free now; verify semantics and operations, not spelling and kerning.
- Check that the referenced entity exists in a system of record before doing anything the message asks.
- Requests touching money, identity, or credentials plus a deadline plus a secrecy clause are the classic triad.
- Any changed endpoint must be confirmed out of band from a prior artifact, never from the suspicious message.
- Report rather than delete: the sample is the telemetry that protects the next recipient.