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.

Expanded Definition

A delayed redirect is a time-based evasive pattern in which a page, script, or payload waits before issuing the final navigation to a malicious destination. In NHI and agentic environments, that delay is often used to outlast sandbox detonation, short-lived scan windows, or browser-based reputation checks. The technique is not itself an identity control, but it frequently appears in attack chains that target service accounts, browser automation, webhook handlers, and other execution contexts with tool access.

Definitions vary across vendors on whether delayed redirects are treated as a malware evasion, phishing technique, or malicious client-side obfuscation. Practically, the security concern is the same: the redirect logic hides the true destination until after inspection has already concluded. That makes it relevant to URL filtering, script analysis, and NHI-enabled workflow security, especially where autonomous agents can follow links, execute callbacks, or process untrusted content. For governance context, NIST Cybersecurity Framework 2.0 frames the need for detect and respond capabilities that can keep pace with delayed execution tactics. The most common misapplication is assuming a benign initial domain means the request is safe, which occurs when defenders only inspect the first hop and not the time-delayed target.

Examples and Use Cases

Implementing detection for delayed redirects rigorously often introduces more inspection overhead and false positives, requiring organisations to weigh stronger threat detection against added latency and analysis cost.

• A phishing page loads a harmless-looking landing page, then uses a timer to forward the browser to a credential-harvesting site after the scanner has disconnected.
• A malicious email attachment or HTML payload pauses briefly before redirecting a user session, allowing the attacker to evade static link reputation checks.
• An agentic workflow opens a document or URL and follows an embedded redirect chain, unintentionally reaching a hostile endpoint after a delay.
• Security teams correlate these patterns with broader NHI abuse, because compromised service accounts can fetch or relay the payload that contains the delayed navigation path. The Ultimate Guide to NHIs is a useful reference for understanding how such identities expand the attack surface.
• Browser isolation, URL rewriting, and script emulation tools are often tuned to observe post-load behavior, since delayed redirects are designed to fire after the initial page render and scan window.

Why It Matters in NHI Security

Delayed redirects matter because they are a reliable way to convert a trusted execution context into a malicious one after the first layer of inspection has already passed. When an NHI such as an API-driven browser, bot, or service account is allowed to follow untrusted content, the redirect can become a delivery mechanism for token theft, session hijacking, or secondary payload retrieval. This is especially concerning in environments with weak secret hygiene, since Ultimate Guide to NHIs reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Operationally, delayed redirects expose a gap between content inspection and runtime behavior. Defenders need to treat timing as part of the attack surface, not just the destination URL. That means logging chained navigation events, inspecting post-delay behavior, and constraining which NHIs can browse, fetch, or execute externally sourced content. It also aligns with NIST Cybersecurity Framework 2.0 by reinforcing detection, response, and recovery practices around suspicious execution paths. Organisations typically encounter the real risk only after an agent, bot, or service account has already reached the malicious destination, at which point delayed redirect analysis becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between redirect URI validation and PKCE?
• What breaks when Google OAuth redirect URIs are not registered exactly?
• How do teams know whether redirect URI management is under control?
• Who is accountable when a redirect URI migration breaks sign-in?