We’re launching a new Detections capability to provide deeper context and fine-grained data points on attacks that Push intercepts in the browser — enabling security teams to more effectively investigate and triage alerts, and build more effective workflows.
We’re launching a new Detections capability to provide deeper context and fine-grained data points on attacks that Push intercepts in the browser — enabling security teams to more effectively investigate and triage alerts, and build more effective workflows.
Oh, look! A time capsule from 2010. Wonder what’s inside …
Listening to: “Like a G6” by Far East Movement (on a Nokia C7 — hey, it even had a touchscreen).
Major news event: Eyjafjallajökull volcano erupts in Iceland, disrupting air travel.
Worried about: Exploitable Flash browser plugins and static HTML phishing sites.
How to be a hero? Roll out the latest AV, implement a web proxy, and add a “report phishing” button to your email solution.
We’re halfway through 2025, and the time capsule for this year may need to be an XL when it comes to how much has happened in the world of browser-based attacks. (Yet fittingly, Drake’s “Nokia” is a pop hit.)
While at least we don’t have to worry about Flash anymore, the browser is now the new battleground, and workforce identities are the most common target. Security teams are struggling with approaches and tools that attackers have outpaced.
In this article, we’ll cover how browser-based attacks have evolved, and how Push is taking a new approach with the release of our Detections capabilities, now generally available to all customers.
Push Detections use real-time telemetry to help you understand context, user behavior, and attacker techniques, and then respond — a modern tool for modern browser-based attacks.
The old world vs. the new world
In the early 2010s, the typical attack path involved sending a user an email with a link to a static HTML webpage (most commonly a generic Exchange Web Access clone) that tricked them into giving you Active Directory creds. These could be used to log in to an exposed remote desktop service or the victim’s mailbox, giving the attacker a foothold to install malware. Anyone who’s done “red teaming 101” will recognize this scenario.
A compromised identity was once just part of a system compromise. That meant the scope of detection and response was focused on the organization’s Active Directory domain, correlated with endpoint and network logs.
But now, identity attacks happen beyond traditional on-premises networks, impacting cloud identities that are created, used, and attacked in the browser. What was once the familiar backbone of business IT — internal apps and thick clients — has been replaced with a sprawling cloud and SaaS ecosystem that can be targeted directly via identity, without touching the endpoint.
Why detection and response hasn’t kept up with threat evolution
This shift in attacker TTPs is forcing a change in how we handle detection and response.
But a lot of organizations are still applying the same old playbooks to this new world where identity attacks are the leading cause of breaches, with uneven outcomes.
This isn’t because of a lack of effort or skill on the part of security teams. It’s a reflection of the tools that have been available.
Let’s look at some of the ways detection and response hasn’t kept up with the evolution of browser-borne threats in this new landscape.
Incomplete identity visibility
Today’s cloud identity providers see a fraction of the overall logins your users make to online apps, compared to the comprehensive visibility of Active Directory in the old world. You don’t know where users are logging in, how they’re logging in, or whether these logins are securely using phishing-resistant methods.
And even if your users are using phishing-resistant login methods, attackers are routinely using downgrade attacks to take advantage of less secure backup login methods — which they’re achieving using Adversary-in-the-Middle phishing kits that are the standard choice for attackers today.
This means that identity attacks are routinely bypassing preventative, account hygiene-based controls, putting the strain on detection and response.
Limited detection coverage
Email and network security tools got pretty good at intercepting old-school phishing attacks like the ones from our proverbial time capsule: static HTML pages delivered over email that could be intercepted and analyzed when entering the mailbox or being loaded by the user.
But with modern phishing attacks dynamically obfuscating the code that loads the web page, implementing custom bot protection, and using runtime anti-analysis features, they’re increasingly difficult to detect using conventional tools.
Of course, email-based detections aren’t much use if attackers are using legitimate services to camouflage their links, or bypassing email altogether by switching to alternative delivery channels like messaging apps (such as Slack and Teams), as well as public services like LinkedIn and Reddit.
More recently, groups like Scattered Spider have even been seen using malvertising techniques, delivering phishing links masquerading as paid Google ads.
Inadequate security logs
If you fail to spot the attack pre-account takeover, you’re reliant on being able to detect and investigate suspicious or malicious activity resulting from the compromise.
This was more straightforward (if not easy) when you had the luxury of a typical on-prem network to fall back on. But with cloud exploitation taking place in a matter of minutes, you don’t get much warning — and your endpoint and network-based alarms can’t help you.
The situation is further complicated by the fact that you simply don’t have the logs you need because of the huge variability in how cloud and SaaS services provide logs (with many failing to provide security logs with relevant data points at all). So chances are you’re flying blind when it comes to large chunks of your business app suite.
Ultimately, you’re stuck with what you can observe — typically network traffic. But even with a TLS-terminating proxy, extracting fine-grained identity data points isn’t really achievable. You’re looking from the outside-in at malicious activity that’s happening in the user’s browser and trying to infer what happened.
Spotty control enforcement
And in the case that you do identify that a user clicked a malicious link and maybe entered their credentials into the page — now what?
You can reset the account in the affected app, ideally terminating active sessions — which may or may not be possible, depending on the app. This might take a while if you don’t centrally manage the app, and involve some painful emergency phone calls to employees.
What about apps where the same password is reused?
Or if it’s an IdP account used for SSO, what about the other apps that might be accessible now?
If the attacker has created stealthy backdoors that persist through credential changes (like creating an API key or a malicious OAuth integration) they could still be lurking in your environment.
Suddenly, you’re not dealing with one possible control point, you’re dealing with several.
And if you can’t trace the attack back to a source — because your email solution missed it, or it didn’t come via email, how can you triage the impact to other users?
It’s no wonder that security teams are struggling to adapt.
How Push is solving modern identity investigations in the browser
The good news? We’ve seen this phenomenon play out before: In the early 2010s, in fact, when AV evolved into EDR. What was the big innovation then? Getting inside the data stream, in real time, and detecting and responding from a much higher-fidelity source of telemetry.
This time around, security teams need tools that take them inside the browser layer.
This approach gives you the right vantage point to defend against and investigate browser-based identity attacks, providing access to:
Full decrypted HTTP traffic — not just DNS and TCP/IP metadata
Full user interaction tracing — every click, keystroke, or DOM change
Full inspection at every layer of execution, not just the initial HTML served
Full access to browser APIs, to correlate with browser history, local storage, cookies, etc.
With this data, teams have the information they need to respond to and investigate browser-based attacks. But to become valuable, this data needs a translation layer that turns it from raw logs into actionable information.
That’s where Push’s Detections capability comes in. With it, you can:
Get alerted in your platform of choice (via the Push admin console, Slack integration, or your SIEM/SOAR of choice) whenever Push detects a browser-based attack, such as AiTM phishing or a cloned login page.
Review a curated timeline of the incident: Where a phishing link originated; whether a user entered their credentials on the page; what kind of phishkit was used; and whether the attack was blocked by Push.
See all the other impacted accounts and apps that shared a password with the phished account so you can remediate them.
See a screenshot captured by the Push browser extension of the phishing page, so you can see exactly what the user saw before the page disappears.
Get additional context from urlscan.io about the domains connected to the incident, helping you understand whether a domain has been reported as malicious by other users, when it was registered, and how many times it’s been scanned.
Interrogate and send this telemetry to your SIEM for you to operationalize it as part of SecOps workflows and hunt across events for similar incident characteristics.
Browser context
With Push, there’s no more:
Waiting (and hoping) that a browser-based attack gets recognized and reported by a user.
Guesswork as to exactly what happened on the phishing page.
Struggling to get your hands on a live version of the page to see if it was actually malicious and getting thwarted because the attacker used a one-time phishing link.
Manually tracing the attack to see if it arrived by email so you can quarantine the messages.
Trawling through voluminous proxy logs for scraps of information (who else visited the link; where did it originate; etc.).
Spending precious time on urlscan or VirusTotal to get basic context on a domain or IP address.
Instead, Push gives you all the information you need in one place to investigate and respond.
The foundation for these detections is the Push browser agent, which can be silently installed in all major browsers in your environment to begin streaming information about a user’s entire identity footprint.
This valuable telemetry, combined with Push’s out-of-the-box controls and detections, gives you a seat on the user’s side of the equation, capturing reliable information about network requests, scripts loaded by a malicious website, and what a user clicked and navigated to: the ingredients for showing you how a browser-based attack unfolded, start to finish.
Push raises a detection when it observes a phishing attack or when a user attempts to visit a blocked URL. You can view detections in the Push admin console, or send them to your SIEM or SOAR for correlation and analysis.
Screenshot capture
The Push extension can also capture a screenshot at the time of a detection firing. This means security teams can see the visual characteristics of the page even if it’s since been taken down (and no more looking at bot protection screens like Cloudflare Turnstile on urlscan).
Blast radius analysis for all impacted accounts & apps
With Push’s knowledge of your workforce identities — based on observing logins in the browser that use corporate credentials — the platform can also provide an analysis of the blast radius of an attack by showing you where other accounts and apps are impacted or at risk.
This information helps you understand the true impact of an incident so you can remediate all affected accounts.
Push is able to provide this blast radius analysis by securely fingerprinting users’ passwords when a login is observed; analyzing them for security posture issues such as missing MFA, or stolen, weak, or reused passwords; and then raising that relevant context for a given detection.
Correlated context from urlscan.io
Finally, through an integration with urlscan.io, Push is able to provide additional context about the domains involved in a detection event, including:
When they were created
How many times they have previously been scanned
When they were last scanned
If urlscan has marked them as suspicious
Check out our latest webinar for practical guidance in real-world scenarios
For practical advice and applied examples of how to use Push data in incident response — as well as some bonus examples of automated response and remediation use cases — join us live on August 13 for our webinar, “Identity attacks have changed — have your IR playbooks?”
Learn more about Push
Push’s browser-based security platform provides comprehensive identity attack detection and response capabilities against techniques like AiTM phishing, credential stuffing, password spraying, and session hijacking using stolen session tokens.
You can also use Push to find and fix identity vulnerabilities across every app that your employees use, including ghost logins; SSO coverage gaps; MFA gaps; weak, breached and reused passwords; risky OAuth integrations; and more.
If you want to learn more about how Push helps you to detect and defeat common identity attack techniques, request a demo.
