Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: A phishing campaign abused Zoom’s own authentication flow and legitimate infrastructure to deliver a fraudulent support message that passed SPF and DKIM checks, according to Prophet Security. The case shows why intent-aware analysis matters when trusted services become the delivery layer for social engineering, not just the sender.
NHIMG editorial — based on content published by Prophet covering a Zoom TOAD phishing campaign: Zoom Phishing Email: Unmasking a Novel TOAD Attack Hidden in Legitimate Infrastructure
Questions worth separating out
Q: How should security teams handle phishing emails that pass authentication checks?
A: They should treat authentication as a delivery signal, not a trust decision.
Q: Why do authenticated emails still create phishing risk?
A: Because authentication proves who sent the message, not whether the message is trustworthy to the recipient.
Q: What do security teams get wrong about SPF, DKIM, and DMARC?
A: They often deploy them as isolated email settings instead of treating them as enforcement controls for domain identity.
Practitioner guidance
- Tighten detection for legitimate-service phishing Create detections for messages that come from trusted SaaS infrastructure but contain urgent callback language, payment pressure, or mismatched brand references.
- Add intent checks to email triage Require analysts to ask what the message is trying to make the recipient do, not just whether the sender authenticated successfully.
- Escalate callback fraud patterns Treat any email that directs the recipient to call an external number as a higher-risk social engineering event, even when the transport path is legitimate.
What's in the full article
Prophet's full article covers the operational detail this post intentionally leaves for the source:
- The exact message flow behind the Zoom-generated OTP and forwarding chain that allowed the scam to pass normal checks.
- The raw email content example, including the display-name text used to create callback pressure.
- Prophet AI's investigation workflow, including how it analysed the alert across multiple data sources.
- The vendor's description of why this case required escalation beyond a typical L1 phishing triage.
👉 Read Prophet's analysis of the Zoom TOAD phishing campaign and trusted-infrastructure abuse →
Zoom TOAD phishing: what SOC teams need to change now?
Explore further
02/08/2026 12:37 pm
Trusted infrastructure is now part of the phishing payload. This case shows that sender authenticity is no longer enough when attackers can use legitimate notification systems to deliver fraudulent content. The security problem has moved from domain spoofing to content abuse inside valid delivery paths. That means email security, SOC triage, and identity trust models must account for legitimate services being repurposed as attack infrastructure. Practitioners should treat trusted-service abuse as a first-class phishing pattern.
A question worth separating out:
Q: What should analysts do when a trusted sender includes urgent financial language?
A: Escalate it for semantic review before classifying it as benign. Legitimate infrastructure can still carry fraudulent instructions, especially when the message asks the recipient to call a number or act on a payment threat. That pattern deserves a higher-risk classification even if the sender is authentic.
👉 Read our full editorial: Zoom TOAD phishing shows how trusted infrastructure can hide fraud
