Sponsored: Push Security on ConsentFix attacks

Summary

---

Podcast Summary: Risky Bulletin – Push Security on ConsentFix Attacks

Host: Kathleen Campano (A), Risky Business
Guest: Luke Jennings (B), VP of Research and Development at Push Security
Release Date: January 26, 2026

---

Episode Overview

In this episode, Kathleen Campano interviews Luke Jennings from Push Security to discuss "ConsentFix"—a newly identified, sophisticated browser-based identity attack. The conversation explores what makes ConsentFix different from traditional phishing techniques, the mechanics and scale of the attack, how attackers evade detection, why users are susceptible, and the broader implications for browser security and identity-based threats.

---

Key Discussion Points & Insights

1. Introduction to ConsentFix Attacks

• Push Security's Focus: Push develops a browser extension for threat detection and response, focusing on browser-based attacks as more enterprise work moves to web apps.
• Early Detection: Push observed and researched the ConsentFix attack before it was widely reported, leading to their public warning and analysis.

2. What is ConsentFix? (01:06)

• Attack Mechanism:
  • Compromised legitimate sites display a fake Cloudflare turnstile (CAPTCHA-like) requiring an email entry.
  • Based on the email, users are selectively targeted.
  • Those targeted are directed (by video instructions) to interact with a legitimate Microsoft login page in a way that unknowingly authorizes the attacker’s app (Azure CLI).
  • The user, following instructions, copies and pastes URLs/tokens, ultimately passing OAuth tokens to the attacker.
• Critical Impact: The attacker gains access to the victim’s Microsoft account as that user, bypassing all authentication (including passkeys).
• Quote:

  “It was a pure like browser native identity attack that could even bypass passkeys in this case.”
  — Luke Jennings (02:38)

3. Scale and Targeting (03:17)

• Attack Spread: Widespread watering hole approach via compromised legitimate websites.
• Selective Targeting: Attackers filter by entered email—attacking only users of interest (by domain or individual).
• Quote:

  “It was a really interesting sort of combination, I think, of very widespread, but with some targeting at the filtering stage.”
  — Luke Jennings (04:17)

4. Difference from ClickFix Attacks (04:30)

• Traditional ClickFix: Requires users to run code on their endpoint after social engineering.
• ConsentFix: Purely browser-based; end user never runs code or enters a password.
• Quote:

  “Consent fix doesn’t touch the endpoint. That’s where it differs from traditional click fix. It’s fully, sort of fully in the browser, fully in the identity world.”
  — Luke Jennings (05:32)

5. Detection and Defense (05:44)

• Push Security Approach: Their browser extension flagged the attack due to abnormal Microsoft service use.
• Detection Challenge: Such attacks evade traditional endpoint and network security monitoring.
• Quote:

  “Ultimately, there’s very little you can see with traditional solutions there. So us being in the browser then meant we could see all these things occurring.”
  — Luke Jennings (06:23)

6. Proliferation and Threat Landscape (06:52)

• Current Status: The attack is not yet broadly copied, but similar OAuth attacks have been seen in targeted phishing.
• Potential for Widespread Exploitation: Attack could be reused with other apps or if incorporated into phishing/criminal kits.
• Quote:

  “If it ends up in a criminal kit or in an open source tool, then people will use it more or variate... there are other apps that it could be used with in Microsoft Tool."
  — Luke Jennings (07:56)

7. Why ConsentFix Succeeds (08:09)

• Social Engineering Power: ConsentFix manipulates users into doing things that aren’t considered risky (e.g., copying URLs, following instructions).
• User Training Gap: No warnings or training for these types of actions—users see legitimate domains and standard flows.
• Authentication Complexity: Modern identity systems’ complexity creates opportunities for attackers.
• Quote:

  “They're not performing actions that ordinary users have even been trained to think are malicious... We've not trained users to think of that as suspicious.”
  — Luke Jennings (08:34)

8. Broader Trends in Browser-Based Attacks (09:59)

• Shift Away from Traditional Exploits: Email and endpoint phishing controls are now stronger, causing attackers to pivot to identity and browser-based vectors.
• Browser & Identity as New Weak Points: Attackers exploit identity relationships and SSO—once an identity is compromised, lateral movement is possible without touching infrastructure or endpoints.
• Quote:

  “Once you've compromised their identity within their browser, you can then use that to laterally move to loads of other systems as well through SSO mechanisms. And all of this sits outside of what usual monitoring we tend to have in place."
  — Luke Jennings (11:17)

---

Notable Quotes & Memorable Moments

• On the Attack’s Novelty:

  "We realized it was actually a brand new attack technique... that completely circumvents everything as well. Like that even circumvents passkeys if you're using it and the user didn't need to enter a password."
  (B, 01:39)

• On Selective Targeting:

  "Depending on what email address was entered by the user... it would depend whether it bothered to execute an attack."
  (B, 03:39)

• On User Perceptions:

  "We haven't trained users to think of that as suspicious. And with consent fix in particular, it was actually on the legitimate Microsoft domain where the code was being copied from."
  (B, 08:43)

• On the Broader Threat Environment:

  "Ultimately, they hit people through the browser, and they compromise their identities, and they just circumvent most of the controls we take for granted now."
  (B, 12:27)

---

Important Segment Timestamps

• ConsentFix Explainer: 01:06–03:04
• Attack Spread & Targeting: 03:17–04:30
• ConsentFix vs ClickFix: 04:30–05:44
• Push Security's Detection: 05:44–06:52
• Developments & Potential Explosions: 06:52–07:56
• Why Users Fall for These Attacks: 08:09–09:59
• Broader Browser/Identity Threat Trends: 09:59–12:52

---

Summary & Takeaways

ConsentFix represents a significant evolution in identity-centric attacks, exploiting user trust and browser-based workflows without requiring endpoint compromise or password capture. The attack’s sophistication lies in its use of legitimate flows, selective targeting, and its ability to evade standard security controls. The growing complexity of identity and authentication systems, combined with a lack of user awareness and training for these new attack methods, amplifies the risk. As attackers bypass traditional controls, detection requires visibility at the browser level—highlighting a critical area for enterprise defense moving forward.

Transcript

[A]

Foreign. This is Kathleen Campano and this is a Risky Business sponsor interview with Luke Jennings, VP of Research and Development at Push Security. If you haven't heard of them, Push does threat detection and response for browser based attacks. They have a browser extension that watches authentication and identity flows that take place in the browser and alerts SOC teams when something is out of order. Sounds like a simplistic product until you realize that a lot of the enterprise work is being done in browser apps these days. So all of a sudden this sounds like the best product ever. Push is one of the companies that now sees and has to deal with a lot of the first contact attack, Surface, which naturally means they also see a lot of stuff and trends before anyone else. And basically they did, for example, look authored last month a blog post about a new attack he's calling Consent Fix, which they saw against some of their customers first. Welcome, Luke. And would you mind giving us a super simplified explanation of the consent Fix attack?

[B]

Sure. So yeah, this was a really interesting one because you know, we, we deal with a lot of different sort of identity attacks on a daily basis like attacker middle phishing and so forth. And this was something that triggered a few times for different customers hours. And some of our detections blocked it, but it was clearly different to usual and it wasn't even delivered via phishing or anything. What we were seeing was some detections occurring on some sites that were legitimate sites, but people had visited from organic Google searches. But it was triggering certain phishing detections of owls in the browser. And when we really dug deep into it, we realized it was actually a brand new attack technique. So effectively what the attackers were doing were they, they were putting in like a fake cloudflare turnstile. So when the victim would visit this legitimate website from having googled for something, in many cases it was something simple like an online store. Like a legitimate online store and they get a cloudflare turnstile pop up, they click the button and they'd be required to enter an email address. And depending on what they entered, they would either be targeted or not. So it's quite a clever watering hole attack. And if it triggered the actual attack, depending on what they entered, they would effectively be given video instructions and a link to go to a legitimate Microsoft login page. If they were already logged into their Microsoft account, it would just sort of create an error like a404 and the video instructions would tell them to copy and paste the URL back in to validate it. And what that was really doing was actually logging in as the Azure CLI app, which is very powerful. And they were unknowingly then copying the OAuth token across to the attackers and then in the back end they were using it to compromise their account. And that completely circumvents everything as well. Like that even circumvents passkeys if you're using it and the user didn't need to enter a password, they didn't need to run anything. It was a pure like browser native identity attack that could even bypass passkeys in this case. So it turned out to be a really sophisticated attack that definitely been put in place by some pretty clever attackers that put a lot of thought into it.

[A]

So basically the attacker got the Auth token and just enrolled itself into the. Org.

[B]

Yeah, like once you got that token you could just access the Microsoft account as that user and go and access whatever other services you want to there.

[A]

Can you tell me if from your side of the of that data if this was a very targeted attack or was it like more generic, more mass sprayed at everyone? Is this something that was aimed at IT teams or like anyone.

[B]

The interesting thing here is that it's a bit of a mix because it was a watering hole attack. Obviously it was spread out very widely on the Internet. Just the fact that we saw it so many times across different customers means it must be much more widely spread than we even saw. You've got legitimate sites being compromised and then users just stumbling across on it. So in that sense it's very widespread. But I think the key component was depending on what email address was entered by the user in the verification step. It would depend whether it bothered to execute an attack. So at that point it's quite hard to say exactly who was being targeted and how what level of targeting was done at that point. But there was some level of filtering being put in place to only launch the attack properly when it was at least an email domain that the attackers were interested in, if not down to individual levels. So it was a really interesting sort of combination I think of very widespread, but with some targeting at the filtering stage because it was a watering hole attack.

[A]

So unlike the old, like not like the old like the existing click fix attacks which just relies on copy pasting malicious code onto your computer and running it. This was different because the attacker wasn't interested in compromising the endpoint at all, was just was looking for the identity.

[B]

Definitely. Yeah. So I think we saw like traditional click fix attacks really explode over 2025, but they were always, you know, it's a browser delivery vector. But they'd always been conducting an endpoint attack themselves and those things were definitely not targeted. All the examples we've seen of that are just widespread. They will go after anyone that comes across them. But it's a similar social engineering vector, often involved compromised sites in a similar way. This one was very much a sort of browser native, fully identity native attack. Doesn't touch the endpoint, doesn't go through any of those things. It was something we'd actually predicted happening just like a month before when we'd done an entire webinar on on click fix attacks. And we said the next step here is going to be an identity native version of this. And unbeknownst it had already happened and then the next month we were speaking about this consent fix. But yeah, consent fix doesn't touch the endpoint. That's where it differs from traditional qlik fix. It's fully, sort of fully in the browser, fully in the identity world.

[A]

So because it's fully in the browser, I presume you're in a very good position to block this. You're using just your extension to block this or how exactly are you dealing with all of this?

[B]

So it's interesting that this is quite different to a lot of other things we see. But ultimately we're a browser extension so we gain visibility into everything happening in the user's browser. We have a range of telemetry and detection methods we use for that for dealing with lots of browser native attacks. This triggered a few different detections we have that related to the sort of strange use of Microsoft services that were in place when we first discovered it. We didn't realize the true significance of how new and how sophisticated it was on the first time. But after a couple of times coming up and investigating further, that's when we got to the point of uncovering that it was a brand new attack technique and was very sophisticated compared to the sort of usual criminal kits we see out there. But yeah, ultimately there's very little you can see with traditional solutions there. So us being in the browser then meant we could see all these things occurring and see that they were strange and, and that's where the whole investigation unraveled at that point.

[A]

So from your data this was a sole attack or have you seen variations of this like going after other Microsoft apps in a similar way? What I'm asking basically is the usage of this technique just a one off attack from a very specific threat actor? Or have you seen this explode and becoming even more sophisticated and more Broad, broadly used compared to last year.

[B]

We've seen, as far as we're aware, we've seen some other compromised sites that have the original attack on them. Since I'm not aware that I've seen other threat actors engaging in it yet. It's not to say it's not happening, but we have seen other like there's definitely other reports of similar things out there in the past. So there's been sort of more targeted phishing attacks that also have made use of similar sort of oauth attacks on Microsoft first party apps in the past as well for specifically consent fics. You. Yeah, like we haven't seen an explosion in use yet, but I have no doubt there are people out there trying to make more use of it for sure.

[A]

All it needs is to be embedded in one of those phishing services, right?

[B]

Yeah, yeah.

[A]

And it's game over practically.

[B]

Yeah. I think if it ends up in a criminal kit or in an open source tool, then people will use it more or variate, you know, or similar variations of it. Like in this case it used the Azure CLI app. But there are other apps that it could be used with in Microsoft Tool.

[A]

What do you think makes these constant fixed attacks and browser social engineering attacks so successful? Is it the overly complicated systems that are now used for authentication in the browser? Is the login process these days too complicated with all the second factors and secure procedures that normal day to day humans can keep up? Did we do this to ourselves by making authentication so complex?

[B]

Yeah, I think part of that, I think at least with consent fix and also with more traditional click fix, the interesting thing with these is that they are, they're not performing actions that ordinary users have even been trained to think are malicious. So we tend to tell our users in particular, don't put your passwords into strange websites. Right. And yet still huge numbers of users fall for that because it's a hard problem to solve. But particularly in the case of consent fix and click fix attacks too, that's not what's happening. You're not asking for a password, you're just asking them to perform some common instruction. And with clickfix are normally told to enter a certain keyboard combination. With consent fix, you know, they were given instructions to copy and paste the code. We haven't trained users to think of that as suspicious. And with consent fix in particular, it was actually on the legitimate Microsoft domain where the code was being copied from. So if they became suspicious at any point and looked at the domain, it would have been a legitimate Microsoft.com domain too. So really it completely bypasses even the things we tell users to be suspicious of. And yes, obviously it does tie into the general complication of how complicated authentication authorization with things like OAUTH become now too. So I think it's a combination of different reasons as to why it's so successful.

[A]

What your end of year webinar that you mentioned about last year's phishing trends and the thing that stood out to me was the number of attacks that rely on reaching out from the browser to other apps on the Same system like ClickFix, ConsentFix and the others. My takeaway is that the old form of phishing is incredibly hard to pull off these days. Browsers are harder to exploit. Online accounts are much more secure now, so threat actors are attacking the user for social engineering. Is that a success really? Like yeah, the browser is more secure, but we're now seeing attacks that are far more sophisticating and outside the reach of security solutions.

[B]

Sure, yeah. So I mean, I think, you know, what's obviously happened over the last decade or so is that endpoint attacks originally were so successful either through exploiting the browser or other endpoint attacks normally delivered through email phishing, that we've got a whole suite of different controls out there like EDR and email based controls to deal with that. So that's become much more difficult. It's hard to exploit the browser with traditional browser exploits now. Endpoint attacks are much harder. There's loads of things inspecting email. So what we've really seen the change from our perspective is non email delivery vectors for phishing, things like LinkedIn, things like Teams Slack even through malvertising or organic search, just various other ways of getting to the user. And the common point being the browser. But rather than exploiting the browser itself with a memory corruption exploit, we're seeing identity based attacks within the browser. So we're seeing attacker in the middle phishing attacks for example, or things like Consent fix that compromise the user's identity. And once you've compromised their identity within their browser, you can then use that to laterally move to loads of other systems as well through SSO mechanisms. And all of this sits outside of what usual monitoring we tend to have in place. When I'm talking about lateral movement there, I don't mean moving between servers like the infrastructure and the endpoint side is just never touched. So once you've got that identity, people just don't have good visibility in their browsers very often. They don't have very good visibility at all the connected system SaaS services. So, yeah, it's just become a much weaker point to attack. And the truth is, I see this every day now. It's just like attacker in the middle phishing attacks, bypassing MFA hosting themselves on legitimate services to evade other controls. There's so many different techniques that are in use now. Ultimately, they hit people through the browser, and they compromise their identities, and they just circumvent most of the controls we take for granted now. It's just the naught that I see this every day in, day out now. So, yeah, I think, you know, it's working for attackers. So they're all moving this way, and that's why we're seeing such an explosion of attacks in this space.

[A]

Luke, thank you very much for your time today.

[B]

No problem. Thank you for having me.