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

Why This Matters for Security Teams

Static attachment scanners are usually tuned to catch known signatures, suspicious file types, and obvious embedded content. That works poorly when the malicious logic is deferred into JavaScript that only runs after a delay, after a click, or after the browser resolves a second-stage request. The result is not just an inspection gap, but a trust gap: the message passes automated review while the recipient later experiences a live redirect, credential prompt, or payload fetch. That is exactly the kind of blind spot NHI Mgmt Group has repeatedly seen in campaigns where initial artefacts look harmless until runtime, including the Shai Hulud npm malware campaign. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it reinforces that detection has to be paired with continuous assessment, not one-time inspection. In practice, many security teams encounter the malicious behavior only after a user opens the attachment, rather than through intentional pre-delivery validation.

How It Works in Practice

Delayed JavaScript breaks static scanning because the scanner evaluates the attachment as inert text or markup, while the browser later executes the logic in a live session. That means the security outcome depends on runtime context: timer-based execution, DOM manipulation, redirects, network beacons, and any second-stage fetches triggered after the initial open. A scanner that does not simulate that behavior will miss the true payload path.

Operationally, better validation usually combines static controls with sandboxed execution that preserves browser timing and request flow. Security teams should look for the following capabilities:

• Detonation in a browser-like runtime that can execute delayed scripts and inspect post-load behavior.
• Network observation for outbound requests, redirects, and newly resolved domains.
• Policy checks that flag obfuscation, encoded JavaScript, or unusual timer use when paired with attachment delivery.
• Reconstruction of the full chain, including any content fetched after the first interaction.

This matters for NHI exposures as well, because delayed scripts often exist to stage credential theft, token capture, or malware delivery after the attachment is trusted. NHI Mgmt Group’s Ultimate Guide to NHIs shows why runtime visibility is essential when secrets, service accounts, and API keys are the real target. The practical lesson is that static review can still be useful for triage, but it should not be the final decision point when executable content is deferred. These controls tend to break down when the attachment depends on user interaction or a live browser context because the malicious path never exists at scan time.

Common Variations and Edge Cases

Tighter runtime inspection often increases latency and operational overhead, so organisations have to balance stronger detection against mail-flow speed and sandbox cost. That tradeoff becomes more noticeable when attachments are encrypted, heavily obfuscated, or built to behave differently in virtualised environments than they do in a real browser.

Current guidance suggests treating these cases as confidence problems rather than simple malware yes-or-no decisions. A delayed script inside an attachment may be benign, but there is no universal standard for this yet, so policy should weigh file origin, user role, destination domain, and whether the script attempts asynchronous fetches or redirect chaining. The strongest practical pattern is layered: static heuristics for broad filtering, dynamic execution for high-risk files, and user-warning controls for anything that cannot be fully detonated. This is especially important when attachments are used to lure recipients into entering credentials that later unlock NHI pathways, as seen in incidents like the Schneider Electric credentials breach. Teams should also remember that some enterprise mail gateways strip scripts entirely, which can mask the original behavior and create a false sense of coverage.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on static vendor lists for fraud prevention?
• What breaks when organisations only rely on static phishing detection?
• What breaks when email security relies on static rules against AI-driven attacks?
• Why do static email rules miss some malicious attachments?