In-browser attacks using bot protection to hide: 95% (Source: Push Security, 2026 browser attacks report, as reported by The Hacker News (September 30, 2026))
The guarded doors are not where the attack happens
Many traditional controls are built around two moments: the login and the inbox. Push Security's 2026 report on browser-based attacks argues that attackers have moved to the spaces between and after them.
The idea worth holding onto is this. A login is a checkpoint, and a checkpoint only protects what passes through it. If the attacker gets a valid session or a valid permission grant, the checkpoint has nothing left to check. This is an interpretation of Push's findings, not a claim the report makes in those words.
Push sells browser security, so it has a commercial interest in this argument. Its figures come from attacks its own product detected. They describe what Push saw, not all attacks everywhere. Even so, the mechanisms it describes are specific and checkable against your own controls.
What Push found
Push reports that about half of the payloads it intercepted arrived over channels such as search engines and social media, where email filters do not look. The rest bypassed email controls anyway.
The researchers say 95% of the in-browser attacks they detected used bot-protection services to hide. Those are the same kinds of tools legitimate sites use. They stop security scanners from analysing the page.
Push also says most phishing domains stay active for about two days before attackers rotate to a fresh one. The Hacker News, reporting Push data, frames it slightly differently: 89% of phishing domains active for fewer than two days. The two figures are not identical, but both point the same way. A blocklist of known-bad addresses is chasing targets that disappear.
How the newer attacks work
Three techniques show the pattern.
First, adversary-in-the-middle phishing. The attacker's page acts as a relay between the victim and the real login page. It passes along the password and the MFA prompt in real time, then keeps the session token that results. The victim logs in normally. The attacker walks away with the logged-in session.
Second, device code phishing. This abuses a standard sign-in flow, the OAuth 2.0 device authorization grant, designed for devices like TVs. The attacker generates a real code and persuades the victim to enter it. Once the victim approves, the attacker gets a valid access token without touching the victim's credentials. The Hacker News notes this route makes every form of MFA, including passkeys, irrelevant, because the login step is skipped entirely. This applies to techniques like this one and consent phishing. Adversary-in-the-middle kits still relay the password.
Third, ClickFix. A fake CAPTCHA or error page tells the user to copy and paste a command. The user runs it themselves. Push says this typically installs an infostealer or a remote access tool. Four in five ClickFix pages Push intercepted were reached from search engines through malicious ads, search poisoning or compromised sites.
Cheap to build, fast to spread
Device code phishing shows how fast a technique can spread. Push has logged more than 30 kits for it this year. It counted none the year before. It says AI-assisted development is what let phishing-kit vendors add the technique so quickly. It also says 90% of the phishing kits it analysed in 2026 show some sign of AI generation. Push's wording is an "AI-generated tell".
Push's summary of the economics is blunt: attacks on the browser itself are beyond most criminals, but attacks inside the browser are within reach of all. Buying stolen sessions or renting a phishing service costs less than finding a browser exploit.
Who carries the risk
Push says users cannot realistically be trained to spot these attacks. Think of the employee who clicks a normal-looking search result, or the help desk agent who takes a convincing phone call. Neither is careless. Both are working the way the job asks.
Push lists real incidents behind these patterns. Scattered Spider's help desk vishing (voice phishing) is tied to M&S and Co-op. ShinyHunters' device code campaign is tied to Qantas and LVMH. Push notes that publicly known breaches are a minority of what happens.
Extensions add another route. Push's page says malicious extensions either start out malicious or become compromised later, through ownership transfers and permission escalations. The Hacker News, summarising Push, reports that most malicious extensions did not start that way. Attackers acquire legitimate ones, wait for install counts to grow, then push a harmful update. The 46.76% figure comes from Push's customer base, so it is not a universal rate.
Questions to put to your security team
Which channels reach employees without passing any inspection? Search ads, chat apps and social direct messages are the ones Push highlights.
Do we log and review OAuth consent grants and device code sign-ins? Can we restrict them to the users who need them?
If a phishing page hides from scanners and disappears in about two days, what do we detect it with, other than a blocklist?
Do we know which browser extensions are installed, and who reviews an update after ownership changes?
How does our help desk verify a caller before resetting access?
Email filters and MFA still matter. But if the attack works after them, your controls need to cover what happens inside the browser session as well.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Push Security.
