Protocol handler hijacking is an attack where a malicious application registers itself to open custom or standard URI schemes. When a user clicks a link, the operating system launches the attacker-controlled handler instead of the intended application, which can enable code execution, phishing, or token theft through abused deep links.
What protocol handler hijacking is
Protocol handler hijacking is a browser and operating-system trust failure, not just a web-link problem. The attacker abuses the handoff between a URI scheme, the desktop shell, and the registered application, so a click on a seemingly normal link can trigger the wrong program and shift execution into attacker-controlled code paths.
The practical danger is that the user still sees a familiar link click, but the real action happens in the local handler registration and launch flow. That makes the attack attractive for phishing, silent redirection, and token capture when application-specific deep links carry sensitive context or authentication material.
How the hijack works
Modern operating systems rely on protocol handlers to decide which application opens a scheme such as a custom app link or a standard URI. If a malicious application can register itself first, or replace an existing association, the OS may invoke the attacker’s handler whenever the user follows that scheme.
This technique is effective because the browser usually treats the URI as an external navigation target, while the operating system treats the same click as a local application launch request. The attacker exploits that boundary, often by presenting a legitimate-looking installer, wrapper application, or update flow that wins scheme registration.
In some cases, the handler only needs to capture the request and forward the user onward. In others, the handler can execute code, steal parameters from the deep link, or present a convincing fake login or consent screen before handing control back to the intended workflow.
Why protocol handler hijacking is dangerous
Protocol handlers are often trusted to bridge the browser, the desktop, and an authenticated application session, so abuse of that trust can turn a single click into code execution or session theft. The risk is highest where links carry one-time tokens, OAuth-style parameters, or other secrets in the URL itself.
The attack also weakens user assurance. Even careful users may not notice that the wrong application opened, especially when the malicious handler imitates the expected interface or relays the user into a real service after collecting useful data.
Because the exploit path is local and user-initiated, it can bypass some network-focused controls. That makes endpoint visibility, application control, and scheme-registration governance important parts of the defensive picture.
How organisations reduce exposure and detect abuse
Exposure starts with inventory: teams need to know which applications register URI schemes, which schemes are business-critical, and which deep links are used for authentication, support, or device onboarding. Internet-facing links deserve extra scrutiny because they are the most likely to be clicked from untrusted contexts.
Defensively, organisations should prefer explicit application associations, restrict unexpected handler registration, and review installers or updaters that can change URL scheme bindings. Security teams should also inspect browser and endpoint telemetry for unusual launches, scheme changes, and repeated redirects that suggest a malicious intermediary is sitting in the click path.
Post-incident review matters too. If a handler was hijacked, treat any tokens, session artifacts, or secrets carried in the affected link as potentially exposed and review whether the attacker could have captured authorization data before the intended application ever opened.
Risk and Threat Considerations
Protocol handler hijacking is dangerous because it abuses a trusted OS launch mechanism to redirect users into attacker-controlled code paths. The attack can convert a harmless-looking link click into credential theft, phishing, or execution on the endpoint, especially when deep links contain sensitive parameters.
Failure mechanism: A malicious application registers or replaces the URI scheme association, then intercepts the browser-to-application handoff and captures, alters, or executes the incoming request before the intended handler runs.
Impact: The attacker may gain code execution, steal tokens or other URL-carried secrets, harvest user input, or preserve access by impersonating the expected application flow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Controls the launch path between browser and application contexts. |
| SI-7 — Software, Firmware, and Information Integrity | Addresses malicious handler replacement and tampered application launch behavior. | |
| AU-6 — Audit Review, Analysis, and Reporting | Supports detection of unusual handler registration and unexpected launches. | |
| Recommendation — Enforce approved scheme handling to restrict which applications may receive URI-based launches. Validate application integrity to detect unauthorized changes that could hijack protocol handlers. Review endpoint and application logs for abnormal scheme registrations and suspicious link-to-app transitions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Covers hardening and review of software settings that control URI scheme associations. |
| Recommendation — Harden endpoint configurations to prevent unauthorized changes to protocol handlers. | ||
| MITRE ATT&CK | T1204 — User Execution | The attack depends on persuading a user to activate the malicious handler path. |
| Recommendation — Map suspicious link-click events to user-execution detections and investigate the launched process chain. | ||
Practitioner Guidance
What to watch for: Treat unexpected scheme associations, sudden changes in default handlers, and links that open a surprising application as security signals rather than UX glitches. Those symptoms often indicate that the handoff trust boundary has been changed.
Governance implication: Ownership of protocol registration should be explicit, because handler changes can affect authentication flows, support links, and enterprise application onboarding. Security review should cover installers, app launchers, and any product that relies on deep links or custom URI schemes.
Practitioner takeaway: If a business process depends on a protocol handler, assume the handler is part of the attack surface and monitor it like any other privileged integration point.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org