HTML and JavaScript phishing bypasses static email defenses

At a glance

What this is: This is an analysis of three phishing campaigns that hide malicious behavior inside HTML and JavaScript to evade email security controls.

Why it matters: It matters because IAM, email security, and identity teams must account for authenticated-looking phishing that bypasses static scanning, sender reputation, and user suspicion.

By the numbers:

• 17 minutes and as quickly as 9 minutes

👉 Read Abnormal AI's analysis of HTML and JavaScript phishing campaigns

Context

Phishing has shifted from simple malicious links to active HTML and JavaScript payloads that behave differently once opened. In this article, the primary security problem is that static email controls cannot reliably judge content that delays, loads, or rewrites itself after delivery.

For identity and access teams, the issue is not just message filtering. Legitimate-looking sender infrastructure, authentication passes, and dynamic rendering now create false legitimacy that can mislead users and weaken response processes across human identity and email security programmes.

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. Static scanning alone misses attacks that only become malicious after a timeout or browser interaction. Security teams should combine sandboxing, URL analysis, and sender context so the decision is based on what the message does, not only what it contains.

Q: Why do authenticated phishing emails still fool users and filters?

A: Because SPF, DKIM, or even legitimate email infrastructure only prove that a message was sent through a valid path, not that the sender is trustworthy. Attackers can borrow that legitimacy while still delivering malicious content. Security teams should treat authentication as one signal among several, including Reply-To consistency, domain reputation, and the behaviour of any attached HTML.

Q: What breaks when static scanners do not execute delayed JavaScript in attachments?

A: The scanner sees inert content, while the user’s browser later sees a live redirect or payload. That creates a false negative window in which the message appears safe at inspection time but becomes malicious after delivery. Teams should validate attachments in a runtime environment that preserves timing, script execution, and network requests.

Q: Who is accountable when phishing uses trusted infrastructure to deliver malicious email?

A: Accountability sits with the organisation's layered email and identity controls, not with transport authentication alone. Security teams need shared ownership across messaging, identity, and endpoint functions because the threat spans all three. Governance should define how authenticated delivery, brand spoofing, and user exposure are jointly evaluated before the message reaches the inbox.

Technical breakdown

Delayed redirects and scanner evasion

A delayed redirect uses JavaScript timing to hide the malicious destination until after the email or attachment has been opened. Static scanners often inspect content at rest, so a 3-second or longer wait can place the real action outside the scanner's observation window. That makes the attack appear harmless during ingestion while remaining fully functional in the browser. The practical effect is that detection depends on execution-aware analysis, not signature matching alone.

Practical implication: inspect rendered behaviour, not just file content, before allowing HTML attachments through.

Iframe-based payload delivery and lookalike interfaces

An iframe can load remote content inside a page that visually resembles a trusted service such as Microsoft Teams. Attackers use loading states, fallback logic, and non-standard URLs to keep the user engaged while the malicious destination loads in the background. This works because the visible interface and the underlying destination are separated. The browser shows trust cues while the page quietly pulls content from attacker-controlled infrastructure.

Practical implication: review embedded iframe destinations and block trust transfer from visual branding alone.

XOR obfuscation and indirect execution through legitimate APIs

XOR encryption with hex encoding hides the payload from signature-based inspection because the malicious code is not present in plain text until decryption happens at runtime. The article also describes indirect execution through Intl.RelativeTimeFormat and the Function constructor, which avoids obvious eval patterns. That combination defeats basic sandbox rules that look only for known dangerous functions. The real issue is that benign APIs can be repurposed as execution triggers.

Practical implication: flag chained decoding plus indirect execution as a high-risk pattern in attachment analysis.

Threat narrative

Attacker objective: The attacker aims to persuade the recipient to trust the message long enough to deliver credentials or continue into a fraudulent web workflow.

1. Entry begins with HTML email attachments and phishing messages that impersonate voicemail, internal meetings, or payment workflows to get the recipient to open the file.
2. Credential or trust abuse happens when the message passes sender checks, uses self-spoofing or Amazon SES, and then executes delayed or obfuscated JavaScript to reach the malicious destination.
3. Impact occurs when the victim is redirected to attacker-controlled pages that collect credentials or reinforce fraudulent legitimacy for later compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Email trust is now an identity problem, not only a content-filtering problem. When attackers can pass SPF and DKIM through legitimate infrastructure, the trust signal is no longer whether a message authenticated, but whether the identity behind it deserves that trust. That shifts the governance question from message acceptance to sender intent and delegated legitimacy. Practitioners should treat authenticated delivery as necessary but never sufficient.

Dynamic phishing creates a visibility gap that traditional email controls were not designed to close. Static scanning assumes the malicious action is present at inspection time, but delayed execution and runtime obfuscation break that assumption. The result is a detection gap between delivery and behaviour, which is where these campaigns operate. Email security programmes need behaviour-aware inspection to match the attack model.

Authentication passes can become false legitimacy when threat actors borrow trusted infrastructure. Amazon SES delivery in a phishing campaign shows that infrastructure reputation and protocol correctness do not guarantee benign intent. That weakens the assumption that authenticated mail is low risk and forces security teams to separate transport validity from sender trust. Identity teams should re-evaluate how much weight is placed on domain authentication alone.

Dynamic execution in phishing emails is a governance blind spot because it crosses email security and endpoint trust domains. The same message can look inert in a gateway, then become active in a browser session after rendering. That means ownership of the control gap cannot sit only with secure email gateways or only with endpoint controls. Practitioners need shared detection logic across both layers.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap makes layered identity governance and visibility essential, as explored in NHI Lifecycle Management Guide.

What this signals

The practical signal for programme owners is that email security and identity governance are converging. When phishing uses trusted infrastructure and runtime obfuscation, the control plane has to extend beyond the inbox into identity context, reputation, and behavioural inspection.

Trust transfer gap: authenticated delivery can still produce malicious user exposure when the sender's infrastructure is legitimate but the message intent is not. Teams should measure how often trusted pathways are being used to deliver content that only becomes dangerous after execution.

The governance priority is to reduce blind trust in authenticated mail and increase the correlation between message handling, identity signals, and browser-level behaviour. That is where the next false negative will surface if controls remain siloed.

For practitioners

• Inspect rendered behaviour before delivery decisions Run HTML attachments and embedded scripts in a controlled environment that executes delayed actions, iframe loads, and redirect chains for long enough to expose hidden payloads.
• Treat sender authentication as a trust input, not a trust decision Correlate SPF, DKIM, DMARC, Reply-To consistency, and infrastructure reputation before deciding whether an authenticated message deserves user exposure.
• Block deceptive attachment patterns that mimic common file types Flag filenames and extensions that imitate audio, meeting, or invoice artefacts, especially when the extension does not match the real file behaviour.
• Monitor for obfuscation chains that pair hex, XOR, and indirect execution Create detection logic for encoded payloads that unpack into runtime calls through APIs such as Intl.RelativeTimeFormat, Function, or similar indirect execution paths.

Key takeaways

• HTML and JavaScript let phishing payloads hide until after delivery, which makes static scanning an incomplete control.
• Authenticated transport and legitimate infrastructure can create false legitimacy even when the message is malicious.
• Behaviour-aware inspection, sender-context correlation, and runtime analysis are the controls that matter most here.

Key terms

• Delayed Redirect: A delayed redirect is a script that waits before sending the user to a malicious destination. The delay helps attackers bypass static analysis because the harmful action happens after the initial scan window rather than during delivery.
• Iframe Manipulation: Iframe manipulation embeds external content inside a page so the user sees a trusted-looking interface while the browser fetches attacker-controlled material. This technique separates visual trust from actual destination control and is common in phishing pages that imitate business software.
• Obfuscated JavaScript: Obfuscated JavaScript is code intentionally written to hide its real behaviour through encoding, indirection, or misleading structure. In phishing, it slows analysis and can defer execution until a runtime trigger makes the payload visible.
• Sender Spoofing: Sender spoofing makes an email appear to come from a trusted person or system. In identity terms, it exploits user expectation and mail trust cues, especially when the attacker can also borrow legitimate delivery infrastructure or self-spoof the recipient's address.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: HTML and JavaScript phishing campaigns that evade static email defenses. Read the original.