TL;DR: Attackers are using delayed redirects, iframe loading tricks, XOR obfuscation, and legitimate infrastructure such as Amazon SES to make phishing emails look normal while evading static detection, according to Abnormal AI. The lesson is that email security now depends on behavioral analysis and authentication context, not link filtering alone.
Editorial analysis by NHI Mgmt Group, based on content published by Abnormal AI: “How HTML and JavaScript Fuel Modern Phishing: 3 Real-World Examples”.
Key questions
Q: How should security teams detect phishing emails that hide behaviour behind HTML and JavaScript?
A: Use behaviour-aware inspection that executes the attachment, waits for delayed redirects, and evaluates iframe loading and script deobfuscation.
Q: Why do valid SPF and DKIM checks not make a phishing email safe?
A: SPF and DKIM only tell you that the message was authenticated at the transmission layer.
Q: What are the signs that a phishing email is hiding malicious JavaScript?
A: Look for delayed redirects, obfuscated strings, unexpected iframe loading, encoded payloads, and attachment names that mimic legitimate files.
Practitioner guidance
- Inspect rendered email behaviour Test attachments and embedded HTML in a detonation environment that executes scripts, follows redirects, and waits long enough to observe delayed payloads.
- Correlate authentication with content signals Treat SPF and DKIM as necessary but insufficient, and combine them with reply-to analysis, sender reputation, and suspicious HTML markers.
- Block risky active content in mail flow Apply policy controls to HTML attachments, script-bearing content, and embedded iframes that can trigger browser-side execution after delivery.
Bottom line: HTML and JavaScript phishing defeats static email controls by hiding malicious behaviour until after delivery and initial inspection.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Email authentication is no longer a trust verdict: SPF and DKIM can confirm that a message passed transmission checks, but they do not confirm that the content is safe. Attackers now pair valid authentication with HTML payloads that become malicious only after rendering or delay. Practitioners should stop treating transport-layer legitimacy as content safety.
A few things that frame the scale:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
A question worth separating out:
Q: How should security teams handle phishing that arrives through trusted email infrastructure?
A: Treat trusted infrastructure as a delivery path, not a guarantee of legitimacy. Security teams should inspect the full message path, apply post-delivery analysis where needed, and correlate sender trust with content risk, user interaction, and domain reputation. If the control model assumes trusted transport equals safe mail, attackers can bypass it without stealing credentials.
👉 Read our full editorial: HTML and JavaScript phishing bypasses static email defenses