Notifications
Clear all
Topic starter
12/06/2026 9:08 pm
TL;DR: Modern phishing now bypasses many email, network, and endpoint controls by operating in the browser, where dynamic pages, obfuscated links, and real-time proxying can steal credentials and session tokens before blocklists react, according to Push Security. The key shift is that identity compromise is unfolding at the point of interaction, not the inbox.
NHIMG editorial — based on content published by Push Security: browser-native phishing defence and identity attack visibility
By the numbers:
- 17 minutes and as quickly as 9 minutes, cly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams defend against phishing that happens inside the browser?
A: They should move from message-only filtering to point-of-interaction controls that inspect the live login flow, page behaviour, and session context.
Q: Why do adversary-in-the-middle phishing attacks bypass MFA so often?
A: Because MFA may validate the user at login while the attacker captures the resulting session artifact and reuses it.
Q: What do security teams get wrong about modern phishing risk?
A: They often treat phishing as an inbox or URL reputation problem when the real compromise occurs in the browser session.
Practitioner guidance
- Inspect browser login flows directly Evaluate controls that can see page structure, script behaviour, and form destinations at the moment of authentication, not just the message that delivered the link.
- Treat session tokens as compromise indicators Correlate successful login events with unusual token reuse, impossible travel, new device context, and unusual SaaS access paths to catch session hijack early.
- Contain cross-app pivot risk Map which connected apps inherit browser sessions from the primary identity provider and define containment actions for Jira, Confluence, cloud consoles, and other high-value targets.
What's in the full article
Push Security's full post covers the operational detail this post intentionally leaves for the source:
- Browser-native detection workflow details for live phishing interception
- Examples of what telemetry the browser can capture during suspicious login flows
- How in-browser warning and block pages are presented to end users
- Use cases for session interruption and post-click containment
👉 Read Push Security's analysis of browser-native phishing defence →
Browser-native phishing defense: what IAM teams need to know?
Explore further
12/06/2026 11:01 pm
Browser-native phishing is an identity control problem, not an inbox problem: The attack succeeds at the point where users authenticate, not when they receive the message. That shifts the relevant control plane from email reputation to identity session visibility, which is where many enterprises still have blind spots. The implication is that phishing defence has to be judged by what it can see at login time, not by how many malicious messages it quarantines.
A few things that frame the scale:
- 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%, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: How can organisations reduce the blast radius after a phishing click?
A: They should combine browser-level interruption with rapid session revocation, application access correlation, and targeted monitoring of connected SaaS services. The goal is to stop the first valid session from becoming a broader identity compromise across multiple systems.
👉 Read our full editorial: Browser-native phishing defense exposes the limits of email security
