TL;DR: Identity-based attacks rose 32% last year, 97% were password-based, and ClickFix accounted for 47% of observed initial access, according to Microsoft and CrowdStrike data cited by Push Security. Browser-native phishing, malicious extensions, and help desk scams now target identity controls directly, not just endpoints.
NHIMG editorial — based on content published by Push Security: browser-based identity attacks, ClickFix, stolen credentials, and help desk scams
By the numbers:
- Identity-based attacks surged by 32% over the last year.
- ClickFix was the most common initial point of access for adversaries in the past year, accounting for 47% of observed attacks.
- In the last year-plus, 79% of detections were malware-free, up from 40% in 2019.
Questions worth separating out
Q: How should security teams reduce browser-based account takeover risk?
A: Security teams should treat the browser as an identity enforcement point, not just a user interface.
Q: Why do browser-based attacks bypass traditional identity controls so often?
A: They succeed because many controls were built for the login event, while the attack happens around the login event.
Q: What breaks when organisations rely on passwords and MFA alone?
A: Passwords and MFA reduce some risk, but they do not stop credential reuse, session theft, malicious browser extensions, or help desk social engineering.
Practitioner guidance
- Govern the browser as an identity control plane Inventory which authentication, password entry, clipboard, extension, and help desk actions happen in the browser, then decide which of them must be centrally observed and blocked.
- Remove ghost login paths from critical apps Find apps that still accept local credentials, especially where federation should be mandatory, and eliminate direct login options where possible.
- Treat clipboard execution as a security boundary Block malicious copy-and-paste patterns before code reaches the endpoint, and capture the clipboard payload for investigation when a ClickFix-style lure is detected.
What's in the full article
Push Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Detections logic and browser telemetry fields for triage and SIEM ingestion
- Step-by-step examples of phishing tool detection, cloned login page detection, and malicious copy-and-paste blocking
- Browser extension visibility, user-group controls, and suspicious installation method handling
- Help desk verification codes and the workflow details behind employee identity checks
Browser-based identity attacks: what IAM teams need to change?
Explore further
Browser-based identity attack is now the right category for this problem. The article is not describing isolated phishing or endpoint malware trends. It is showing that the browser has become the place where identity trust is created, abused, and extended across apps, sessions, and help desk workflows. That makes browser security an identity governance issue, not just a user protection issue. Practitioners should treat the browser as a governed control surface, not a passive client.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a help desk scam leads to account takeover?
A: Accountability is shared across identity, support, and application owners. The help desk owns the verification process, IAM owns the policy for resets and MFA changes, and application owners own whether direct login paths and recovery flows are too permissive. If any one of those layers is weak, a scam can turn into an enterprise-wide access event.
👉 Read our full editorial: Browser-based identity attacks are reshaping enterprise IAM