Sponsored: Passkeys won’t stop authorisation phishing

0:03James Wilson: Hey everyone, I'm James Wilson from Risky Business and welcome to this sponsored interview with Push's VP of Research, Luke Jennings. Luke and I are going to be talking about how attackers are evolving their craft from what we used to know as authentication fishing to now authorization fishing. As Luke explains, this is because things like fishing resistant and MFA and passkeys are just increasingly becoming the norm. That's made it quite difficult for attackers to actually get you at the authentication stage. And so attackers need to move to post-authentication attacks and this poses quite some challenges for traditional detection methods.

0:44James Wilson: But nevertheless, this is all happening in the browser and that's exactly why Push's browser extension is an excellent solution for securing your identities. I'm going to drop be here into the conversation where Luke introduces the whole concept of authorization phishing and then we talk about how it works and how you can defend against it. Enjoy. Yeah, so I think as the authentication side's getting increasingly difficult, they're obviously looking to diversify and get other options for doing this. And authorization phishing is like an umbrella term I've been using to refer to a class of attacks that compromise an identity or an account, but they do it post the authentication step.

1:26So something like passkeys, for example, doesn't protect against it at all because it happens at the authorization layer. And so because of that, if you think, a huge amount of our controls and investment are always in the authentication side, increasing numbers of things that need to be ticked in order to pass authentication. And it's even the same on the user side, our security awareness training and phishing simulations tends to be very driven around don't enter passwords into things and be careful over your MFA codes. So I think all the investment on the defense side feels targeted in that way for good reason, but as a result, the attackers are moving away into an area that isn't covered by those things.

2:08James Wilson: Right. And so how does this actually look? Because if I take what you just said on face value, this is happening after the authentication, but I would just naively assume that once I've authenticated, I've established that secure channel. How does an attacker get in the middle if they've already authenticated? Like bring this to life for me. What does this look like? So yeah, like most of these effectively are attacks relating to the use of OAuth in some way. Shocking, shocking that it always comes down to OAuth. Yeah, sorry, keep going. So like there's three things I would say that fit into this mainly at the moment.

2:43There's consent phishing, which is the more traditional side. There's device code phishing, which has really taken off this year. And then there's ConsentFix, which is probably the more esoteric example, but pretty interesting too. So obviously, if you take something like the original ConsentFishing, you're basically asking for access into a user's account using OAuth and using an app you've registered. And it gives permission level access, which in ConsentFishing can actually be permanent as well. So the user's effectively asked to approve that level of API-driven access. And so, yeah, that happens after authentication.

3:20You're sort of saying, hey, give my app sort of programmatic level access into your account going forwards. The legit case, of course, is for legit integrations with other applications. It has lots of very good uses. And obviously, this side of things is obviously exploiting that trust to use it for malicious purposes.

3:40James Wilson: But am I right in saying that that was sort of like the, I guess, the version one of authorization phishing because that got pretty quickly locked down right you shouldn't be allowing wendy in accounts the ability to go and authorize a new app into the into the tenant yeah it's it's true so i i think we don't see consent phishing uh as often anymore and i think yeah it's because there have been other controls been in place that make it a little more expensive to conduct now it's not impossible but it's just it's it's harder to scale um and it's easier for people at Microsoft to lock down abused apps if they see them.

4:17I mean, the one that we saw really take off this year, device code phishing has been extremely successful. And the interesting thing about that is it's still using OAuth, but it uses the device code flow, which is normally used for approving other devices access into your account. It's normally used originally for things like smart TVs and that kind of thing, but it's actually used for lots of other developer flows now as well, command line tools. However, the key difference with it is that rather than the third-party app that you register yourself that can be controlled and locked down, you're generally impersonating first-party applications.

4:55So whether that's Microsoft or whether that's another vendor like GitHub, you're basically impersonating something that's generally pre-consented, pre-approved, that the vendors are not going to lock down. And I think that's one of the core differences with it as to why it's harder to defend against. And it comes down to whether you can support, restrict that authentication method in your environment or not. But obviously there are lots of legitimate users for it too. And it's enabled by default.

5:27James Wilson: Talk me through the actual mechanics of how this device code phishing attack works. Like who's presenting the code? How does that code get generated? Where is it entered? What's the plumbing of this? Yeah, sure. So what normally happens is a victim has clicked a phishing link somewhere. Often the lures are around things like protected documents that are being shared with them or some way that they need to verify their account to gain access to what's been shared. And it almost emulates something quite similar to traditional email verification. So the victim is presented with a code and never asked for anything secret like a password.

6:01They will end up on a screen saying, hey, here's your document. You just need to enter this code to verify your account before you go to the next step. and they are shown the code on the screen, and there'll be a button to click to copy it, and there'll be another button to do a pop-up, and that brings like a Microsoft pop-up. And the other thing that's interesting about that is that that pop-up window will be a legitimate URL as well. So if they look at that URL at that point, it's going to be legitimate on microsoft.com. And so then, yeah, like at that point, they copy the code in and click OK.

6:32And then most of the time, people are already logged in with their account too, right? So they don't need to re-authenticate. It will just provide them a dropdown showing their account and they'll click OK. And then that's basically it. That's the compromise. It's really that simple. And it really doesn't trigger your usual alarm bells.

6:50James Wilson: Yeah, it doesn't have that smell. And even if it did make you do a step up or author a pass key, you're going to allow it because it looks so legitimate that you're opening that dock in that scenario. Okay, so, but the thing that I was struggling to wrap my head around before we recorded was, okay, but what tokens does that get them for what, how long, what can they do with it? And I think that's where the other element of this comes in, which is it's not just that you're enrolling this device and yay, it's off to the races. It's got access to everything. It's a specific, you know, again, it's OAuth, so it's got to be a grant that is scoped to a specific thing or acting on behalf of.

7:26James Wilson: And so that's where these first party apps come in. And how does the attacker pretend to be that first party app in this scenario? Yeah, as I say, the thing with OAuth is you've got confidential client apps and you've got public client apps. And for native applications that can't protect their secrets, effectively, they are public apps and anyone can emulate them. So you pretend to be the right GUID that refers to that app as an attacker and you will gain the privileges of that application. And the end result is you get authentication tokens, you'll get refresh tokens, so they can be long lasting.

8:07And you'll get whatever permissions that that application has access to. And particularly with first party apps, they're obviously, you know, very sensitive ones. If you pretend to be the Teams application, then of course, it's going to have access to all the graph APIs for reading messages and emails and files and all those kind of things. So yeah, it depends what app you want to emulate. But in general, they have very significant access into the user's account. But it's a non-interactive form of access. But it can be long-lasting. I mean, you think if you were signing into your smart TV, you don't want it to expire an hour later and have to keep entering the code, right?

8:40It's designed to last for a long time too. So yeah, that's kind of how it works.

8:44James Wilson: So taking a step back for a second, why isn't this as simple as just go and disable device code authentication? and bad news, you can't sign in with your smart TV anymore. But that's got to be better than exposing you to these risks, right? It just doesn't add up to me why this esoteric login method is still a legitimate and seemingly, like the stats on this that I saw are wild. Like it's so popular now and increasingly popular in 2026. But why? Why? Yeah, I think it's a classic case of it was a neighbor waterfall and it hadn't been abused yet. so it stayed that way but I think you know like you can go and disable device code flows and Microsoft are doing work in at least for it on their side it doesn't only apply to Microsoft but but the thing is you know there's legitimate use cases for it still it might not be that every user needs to use it but at the end of the day like for many people if you just go and block it overnight you might find you introduce problems so although it was designed for sort of smart TVs and these things you know they're obviously not as relevant to businesses but you know it became used for things like VoIP phones it became used for things like conference room kits there's lots of other scenarios but in particular there's the use cases that weren't originally anticipated is that it's become used as part of a lot of developer tooling flows so sort of integrations for like command line tools for Azure and PowerShell and for like IDEs and those kind of things so So, you know, it has sprung up as a legitimate use case in quite a lot of sensitive scenarios.

10:20So certainly the larger an organization you are, the more dangerous it would be to just say, I'm going to turn that off tomorrow. Like you would need to, you know, investigate, investigate it a lot. But ultimately, you know, it's just been it's enabled as default for any vendors that support it, of which Microsoft has been a long supporter, you know, and there are other vendors too. But yeah, that's that's where we are.

10:40James Wilson: What's what's the so what of this? What's the advice, right? We've painted a picture of how, or you've painted a picture of how phishing and social engineering has moved from the authentication phase, now we're operating in post-authentication, it's now authorization is the vector here. And the current growing and rapidly adopted method we're seeing here is this combination of device code phishing combined with, and that granting access to these first party apps. So, you know, 9am Monday morning, what is a defender to do with this knowledge in hand? Yeah, I mean, I think the most important thing for these attacks is to start doing purple teaming of your environments with them and to actually try them out.

11:24Particularly in a Microsoft environment, things like conditional access fit into this, but they can be so dependent on people's configuration environment. So I think the first thing is to actually test them out and see how they impact you. And maybe also then find some of the latest phishing kits doing this and see how that fits into your detection response as well. Like, are you detecting them or not? Or the vendors you're using detecting them. On the conditional access side, you'd want to be reviewing policies there. But I think the other aspect is things like security awareness training and phishing simulations.

12:06Now, I would normally be someone that's very critical of these activities, not to say that you shouldn't do them, but there's only so far they go as an effectiveness. But I think the interesting thing with some of these authorization attacks, like device code phishing and consent fix in particular, are quite strange things for most users. They might not use them. and the problem we have with conventional security awareness training and that is that we're trying to tell people don't enter a password when that's something that actually they need to do legitimately all day every day and we're trying to get them to understand that that tiny percentage of scenarios when it's a bad thing to do whereas the problem at the moment with authorization phishing is the scenarios are not overtly malicious to someone that's not familiar with them without it unless they've been educated but if you show them it it's not something that they should be doing every day outside of certain um certain limited use cases and therefore i think it's it's more obvious then that if they've seen it before to be like ah i was told about that because you're not trying to get them to differentiate between the good and the bad as often as you would be with conventional password logins that are just the norm so i i do think you know working those things into security training official simulations things is worth our exercise too.

13:26But ultimately, you know, you don't want to rely on your users completely. So I think that sort of purple teaming side of understanding these attacks and the technological implications on your organization is the most important step.

13:37James Wilson: And what necessitates a purple teaming operation there versus like go find a playbook or a runbook or just, you know, take these steps and you're mostly remediated. Like why is there not an off the shelf? I can get this done in half an hour and we're sorted out. here sort of solution for this yeah well i mean i think um it like if you was for example with device coefficient if you were going to be able to fully disable it and it didn't cause you problems then maybe it's a little simpler but i think the reality is in most complicated organizations it's not always going to be that simple and you need to understand are your controls effective are they working and particularly with things like conditional access they can get so complicated in large organizations it's checking they're actually applying the way you think they are and you never do that without real testing but the other point is you know this goes outside of microsoft 2 like for example you could lock down that cyber conditional access but for example you can do the same attack against github if you're using github even if you're sso into it from a microsoft account the device code auth is separate and it's controlled by github and you may then be vulnerable there so i think that's why it's always good to take the um the attacker's side of it and i know we haven't gone into detail about consent fix but that one is much trickier to lock down uh with with conditional access and so forth too so like that one would definitely need sort of testing and understanding and then looking at the logs that are generated and so forth to understand what you can do right and that's am i right in saying that's because in a consent fix literally i think every step is a legitimate authentication and authorization procedure it's just that someone gets tricked in the in the middle of it to copy out the url or the the bit of the url that has the actual token grant in it and that's what they sort of snatch away right so it's so it's it it's it's almost legitimate end to end is that is that right yeah effectively um you you are you're effectively tricking the the victim into yeah copy and pasting a valid auth code and then using it and so that is much harder to block there are things you can do but a lot of the common controls out there don't actually apply to it so that's yeah it's a particularly tricky one and you know that it's something we discovered that first in the wild end of last year it was effectively a zero-day threat at that point being used in in pretty interesting attacks we haven't seen it like go criminal widespread yet though the same way we saw with device code phishing that exploded like zero to 100 overnight this year but there are criminal tools for consent fix for sale at the moment um so i think it's only a matter of time i mean they must be being used to some extent i'm sure if they're for sale they're being used right but we we aren't personally seeing them like widespread at the moment but that's i think that's a when not an if okay so you know what how does push help here right we've talked about how a lot of this is happening within the browser your specialty is being that secure browser extension that's helping to keep your identity safe and secure.

16:39James Wilson: So give me a bit of sort of a product flavor here of like what's Pusher's role in helping a defender here. Sure, yeah. Well, I mean, the thing is, obviously all these attacks happen inside the browser. And so that's where we've got the visibility. So like my day-to-day job, like a large part of it is I'm investigating all these new phishing kits and these attacks we see in the wild. And then I'm actually just building a lot of detection and response rules and features for our product into those things so ultimately you know think of us like edr and a browser in that sense you know for our customers any of these kits we've seen before the user doesn't get the chance to interact with them because the moment we see something that looks like it in the browser um and we've got a lot of power to do that with the telemetry we have access to we're just blocking blocking the site so like you know it doesn't matter what your conditional access policies are or any of the other things it's like we're doing the edr side of that so that's where we fit in and that's where i I spend a lot of my own research time is staying on top of all those things.

17:39James Wilson: And like, can you even get down to in that consent fix situation, detecting that the user's gone to like the address bar or copied out a part of the flow? Like, do you actually get down to that level of detection? Yeah. So like, one of the interesting things about being in the browser is we actually see, you know, interaction telemetry. So it's not like we can only see network based telemetry like you might see on a firewall or a proxy something it's like you can actually see those interaction level events and we have an entire deep telemetry system that running all of our browsers that enable us to like hunt for new threats as well as running our detection rules and that includes things like that you know we can we can write queries that say hey find anything where you know a password field popped up and these and the user interacted with it and there was these other things or they copy and paste it from this field and do those things so we can do deep level hunting for that but also we can write detection rules around lots of aspects of things going into the browser for things we see so yeah we've got a lot of flexibility there that's just not possible with traditional controls and you know and bear in mind that also happens kind of post decryption and deobstication and things as well right so it's like if something comes down as obfuscated javascript and whatever it doesn't matter to us because we just instrument the entire javascript process and browser and we we get everything from the network to the scripting to the dom to the to the interaction events so that is the the real power of the browser and why whether it's push or not everyone needs to be in the in the browser today like it's been a black box and once upon a time it was the same before edr right the endpoint was a bit of a black box for these detection things then we made edr because endpoint attacks were so common now it's the same thing with a browser everyone's moved to browser attacks and we need to stop treating the browser as a black box and everyone needs to have deep visibility into it so that's the approach we take yeah makes a lot of sense right if all the work's been done in the browser the browser has to be the ultimate vantage point to be able to secure that work being done well luke uh listen thanks so much for dropping by for the chat this has certainly uh lifted my understanding of where attackers are going the move away from just simple authentication phishing to now authorization phishing but yeah thanks so much for spending the time with me no problem Thank you for having me.