Notifications
Clear all
Topic starter
12/06/2026 12:40 am
TL;DR: URL schema obfuscation still lets attackers disguise phishing and malware links by abusing browser URL parsing, bypassing common domain checks and evading basic detections in the wild, where the technique has been observed since at least February 2022, according to Push Security. Browser-enforced blocking shifts the control point from network inspection to execution time, which is where link trust must now be decided.
NHIMG editorial — based on content published by Push Security: URL schema obfuscation blocking in the browser
By the numbers:
- VirusTotal shows abuse of this technique dating back to at least February 2022.
Questions worth separating out
Q: How should security teams handle URL obfuscation in phishing links?
A: They should validate the destination the browser actually resolves, not only the text shown to the user or the domain reported by an upstream scanner.
Q: Why do perimeter phishing controls miss some malicious links?
A: Perimeter tools often inspect the URL string before the browser finishes parsing it.
Q: What breaks when URL parsing does not match browser execution?
A: The security stack can no longer assume that the visible link, the filtered link, and the executed link are the same object.
Practitioner guidance
- Block schema-obfuscated URLs at execution time Apply browser-side controls that inspect the resolved destination after parsing, not just the visible URL string or its apparent domain.
- Harden phishing detections against parsing tricks Review any control that depends on URL string matching, domain extraction, or threat intel lookups so it can handle username-at-sign obfuscation.
- Link browser events to identity telemetry Correlate blocked link activity with sign-in attempts, token use, and OAuth consent events so suspicious clicks can be investigated as identity-risk signals.
What's in the full article
Push Security's full post covers the operational detail this post intentionally leaves for the source:
- How the browser-side toggle is enabled in the Push dashboard and how the control behaves at execution time.
- Examples of URL schema obfuscation variants that the platform is designed to intercept.
- The broader browser-based protection stack used alongside schema blocking to stop phishing and session compromise.
- The vendor's live product guidance for teams that want to validate deployment in their own environment.
👉 Read Push Security's analysis of browser-based URL obfuscation blocking →
URL schema obfuscation: what it means for phishing defence?
Explore further
12/06/2026 10:05 am
Browser-resolved destination is the real trust boundary for phishing defence. URL schema obfuscation shows that a visible URL is not necessarily the URL a browser will execute. That breaks any security model that treats string inspection as equivalent to navigation control. The implication is that identity security teams must think in terms of execution context, not just link text or domain reputation.
A few things that frame the scale:
- 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, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: How do teams reduce identity risk from deceptive links?
A: They should combine browser enforcement with session protection, sign-in monitoring, and OAuth consent review. The point is to stop a deceptive click from becoming an account event. If the browser is the execution layer, then identity controls need to watch what happens after the link is resolved.
👉 Read our full editorial: URL schema obfuscation blocks phishing detections in the browser
