How should security teams detect phishing that does not use malicious payloads?

Why This Matters for Security Teams

Phishing without a malicious payload is harder to catch because the message often looks harmless at the content layer while the real risk sits in identity, timing, and relationship cues. That means filters tuned only for attachments, links, or signatures will miss business email compromise, vendor impersonation, and account takeover attempts that rely on trust, not malware. Current guidance from the NIST Cybersecurity Framework 2.0 and NHIMG research both point toward broader detection signals that extend beyond content inspection.

This matters even more because modern attacks frequently blend into normal collaboration patterns. A message can be technically clean and still be malicious if it arrives from a newly delegated mailbox, uses unusual urgency language, or targets a recipient who does not normally interact with that sender. NHIMG’s Top 10 NHI Issues underscores how often identity weaknesses, not payloads, drive compromise, while the Ultimate Guide to NHIs — Key Challenges and Risks shows how over-privileged identities and weak visibility amplify downstream damage. In practice, many security teams encounter these attacks only after a finance approval, vendor payment, or mailbox takeover has already occurred, rather than through intentional pre-exploitation detection.

How It Works in Practice

Effective detection combines message telemetry with identity telemetry and behavioural context. Security teams should score messages based on who is contacting whom, whether that relationship is normal, and whether the sender’s authority claim matches the organisation’s actual communication patterns. That means correlating email metadata, mailbox delegation, OAuth grants, collaboration platform activity, and authentication events rather than relying on content alone.

A practical workflow usually includes:

• Flagging sender-recipient pairs that have little or no prior business interaction.
• Detecting authority language such as payment pressure, secrecy, or urgent policy exceptions.
• Checking for unusual timing, such as off-hours requests or sudden same-day escalations.
• Reviewing delegated access, forwarding rules, and newly consented third-party apps.
• Comparing the message against known collaboration norms for that team, vendor, or executive.

This is where identity governance becomes part of phishing detection. If a supposedly trusted mailbox suddenly starts sending requests after a delegated login, a valid token grant, or a suspicious OAuth consent, the message may be a symptom of account compromise rather than a standalone email event. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which helps explain why these attacks are easy to miss. Aligning detection with NIST Cybersecurity Framework 2.0 also supports the broader move from content filtering to identity-aware monitoring. These controls tend to break down in heavily outsourced environments because vendor communication patterns are variable, shared mailboxes are common, and legitimate exceptions blur the line between normal and suspicious behaviour.

Common Variations and Edge Cases

Tighter identity-aware detection often increases alert volume and investigative overhead, requiring organisations to balance precision against operational load. That tradeoff is real, especially where executives, finance teams, and external partners exchange urgent requests as part of routine work.

Best practice is evolving for shared mailboxes, mail forwarding, and delegated approval flows. There is no universal standard for this yet, but current guidance suggests treating these as high-risk context because a legitimate-looking request can still originate from a compromised account or abused delegation path. The strongest signals are usually behavioural, not lexical: a familiar sender asking for an unusual action, a vendor message arriving from a new domain variant, or a request that bypasses standard approval channels.

Teams should also be careful not to overfit on static keywords. Attackers can avoid obvious terms and still create pressure through phrasing, timing, and relationship manipulation. For environments with heavy third-party access, the Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that visibility into non-human access is often incomplete, which weakens both detection and response. Where vendor approvals, automated workflows, and email-based exceptions overlap, false positives rise quickly because the same behavioural patterns can be both normal and abusive.

Related resources from NHI Mgmt Group

• How should security teams defend against TOAD phishing campaigns that use phone callbacks?
• How should security teams detect phishing that comes from legitimate Microsoft identity workflows?
• How should security teams detect phishing when attackers mimic normal business communication?
• How should security teams use phishing reports to improve detection quality?