B (3:05)

When you're talking about kind of, I guess, the gaps that might exist about ways that we've talked about this type of thing in the past and kind of where we're up to today, I guess, why does that matter? What's the consequence of that if there are gaps?

A (3:21)

Yeah, so I think mental models are a really helpful kind of framework or reference point to use as we're thinking about a cyber attack, which is a rather ephemeral thing, if we want to put that into more concrete, tangible terms in a way that we can talk about it and kind of think about it the same way. And more importantly, in a way that we can design detections and mitigations for that threat, that attack. If we're trying to design incident response playbooks or procedures, we lean on some of these mental models like the cyber kill chain or the attack cycle mitre, ATT and CK framework, this idea of defense in depth. These are all concepts that I think we've used for quite a long time now to help us plan and execute our defenses. So I think it's important to understand, whether you're a practitioner or a leader, what the limitations of those models are and where and how they might need to be updated and maybe extended. And I kind of think that's know what we've gotten to today is the need to update some of those.

B (4:30)

And where would you see that? Because I know that push. I think I had a. It was with Jacques a little while back talking about some of the work that the PUSH has done to basically open source the taxonomy for different browser attacks and try to, you know, bring that to the fight partly in terms of having a common understanding around kind of what kind of operational preparation might be needed, you know, obviously understanding the kind of bad things that can go down. But from my perspective as well, like building out a common language that you can use across the team, like when it's hitting the fan, you don't necessarily have time to get words wrong. And that to me, feels like a pretty practical implication of this kind of problem, right?

A (5:10)

Yeah, 100%. 100% clear communication, using the right words. I mean, these things are of course very important. And I think when we're talking about using some of these models for planning and I'll use the Mitre ATT and CK matrix as an example. Fantastic model. Still a very useful resource when I'm not doing my day job for push. I'm on the faculty at the SANS Institute and we still use Mitre ATT and CK matrix quite heavily in our leadership and cyber defense curriculum. But one of my favorite quotes is George Box, all models are wrong, but some are useful. And I think, as I said, it's important to understand where models like Mitre ATT and CK where they're useful and where they have limitations. One of the things that we've tried to do to your point is look for opportunities to improve on that kind of taxonomy and even extend it, because it is still, for all the benefits there, it's very focused on post exploitation activities. And even if you dig into the matrix and you look at things like credential attacks and phishing, it doesn't really take into account a lot of these newer techniques that we're seeing around in browser attacks. So we've published the SAS attack matrix to kind of extend, you know, use a similar model, but, you know, add to some of that taxonomy. We've published Phishing Detection Evasion Techniques Matrix where we've cataloged, you know, various types of phishing and defensive evasion techniques that, that we see in the wild. And so, you know, again, the idea is not to kind of rip up these models and replace them, but rather to extend and improve them.

B (6:55)

Yeah, yeah. I love what you said about the ephemerality of cyber attacks. It's definitely something that I've seen in a different context in terms of basically maintaining vulnerability taxonomies to establish this common language to have some degree of a Rosetta Stone that you can use to build operations on top of or use as a communication tool during a crisis. And the fact that, you know, those things are changing every five minutes because the bad guy behavior is changing, you've got changes in the attack surface. The browser attacker defender landscape, to me has always been really fascinating because it's been a thing for a long time, but it seemed to kind of blow up like crazy, you know, early, early this decade. And you know, with the, the advent of initial access brokers, you know, greater reliance on sas, all the different things that have facilitated that from a technology standpoint it's obviously become more like the velocity has increased a ton, I guess. So the idea of being able to do that and have users and folks from the community actually collaborate to that is a pretty powerful way to approach solving that problem.

A (8:05)

Absolutely. I mean, I'm old enough to remember and maybe you are too, when if you were talking about a sophisticated multi stage attack or exploitation of a zero day vulnerability, you were talking about a very specific kind of adversary that was probably targeting a very specific kind of organization. And now these days in the last decade, a lot of that has kind of gone by the wayside. And I think the upside of that is that there's a lot more awareness now of what a sophisticated attack is and how likely it is that you'll get hit with something like that. But again, the downside is kind of like you said, these things are changing so fast, so quickly. Just the velocity on some of this stuff, to your point, is mind blowing. So yeah, giving us a common kind of reference point, I think that's very helpful.

B (8:54)

Yeah. And it's fantastic for Push to be taking on that leadership position because I do think having a strong voice to try to lead that stuff is a really important ingredient in the mix there. So we talked a little bit ahead of the call about some research that you guys have just published. Do you want to double click on that?

A (9:12)

Yeah, absolutely. I mean, one of the things that we pride ourselves on and where I think you have to be if you are a solution provider or vendor in this space is we're research led. So if you're going to go out there and you're going to say that you can offer defense against these sophisticated evolving attacks that we're talking about here, if you don't have your finger on the pulse of what those attacks look like and how they're evolving, and I mean that in a very in the weeds, day to day basis, then I think it's very difficult to back up those claims. And so we're very much a research led organization. And in fact just today we published a post with some research that we've done around a new kind of variant of a browser based attack that we're seeing in the wild. We saw it because we blocked it, which is a great way to discover these kinds of things. But yeah, and we're calling it consent fix, kind of a play on consent, phishing and click fix attacks. And basically what it is, and I think I wanted to talk about it a little bit because I think it's A good example of the type of iteration that we're seeing.

B (10:25)

Let's go into that. How does it work?

A (10:27)

Yeah. So I think most listeners are probably familiar with, at least at a high level, how Qlik fix works, where the idea is that you're trying to elicit the user into doing something, trick them into doing something, and that something is usually copying and pasting a command into run dialogue and kind of do the attacker's work for them under the guise of, hey, you have a problem, you can fix it just by running this one command. Right. But obviously it doesn't do that. So I think that's been very effective. There are a lot of statistics out there around how prolific that has become. But I think what's starting to happen is as we get better at mitigating that or at least identifying it, anytime you do something on the endpoint, that's increasing your likelihood that you're going to get identified, maybe caught by EDR or something like that. In this new Consent fix dial attack, there are a couple of key differences from the Qlik fix style attack. The main one being that this is something that happens entirely within the browser context. So here's how it works. The lure gets delivered to the user, in this case the campaign that we're seeing. It's through malvertising. So you're sidestepping email delivery entirely. You're googling something that is most likely benign, like looking for sports equipment. You click on a link, happens to be malicious advertisement and the user gets then redirected through cloudflare turnstile. There are a number of defense evasion techniques, conditional loading that's happening where in this particular case the user is prompted to put in their email address. And if it's not, if that domain is not on a targeting list, you don't pass go, you don't get your next stage of the attack. You get redirected to the benign site, it doesn't load. So you have to pass kind of that check, you have to pass the turnstile check and then the user is essentially prompted or redirected, I should say, to the OAuth authorization dialog and it pops open another window with the authorization URL that contains that oauth like authorization key in the URL. And what's happening here is, you know we're targeting the Azure CLI app, right? So provided you have Azure CLI and you're authenticated to it, what's happening here is this new pop up that gets loaded, it's a localhost URL and Where that click fix style social engineering comes in is the user is tricked into copying and pasting that URL which contains the, you know, the authorization key into the phishing site. So kind of cool in the sense that again, it's happening entirely in the browser and it's sophisticated in the sense that very clear kind of intentional targeting of Azure CLI as like a first party application. Right. It can't be blocked, you're not going to delete it. You can get some pretty powerful permissions for that without admin approval. And since we're targeting kind of the authorization chain here and not doing credential harvesting or anything like that, you're not doing authentication. It not only sidesteps phishing resistant authentication mechanisms like Fido, but you're kind of evading any detection that would require a sign in or something like that. So pretty sophisticated in that sense and, and pretty widespread based on what we're seeing. We're seeing this in a few different environments. So it's things like that where if I'm kind of approaching that as a SOC analyst and I'm thinking about what does the kill chain or what does the attack cycle look like and I'm trying to figure out what's happening at the delivery stage, what's happening in exploitation and then privilege escalation and lateral movement and all these other things. Well, that's not what that chain looks like at all. Yeah, yeah, 100% maybe exploitation. Right. Which would be when you're getting, you know, phished or accessing that malvertisement, I guess, or you know, maybe even submitting that, you know, oauth like session material and then it goes straight to actions on objectives at that point, you know.

B (15:13)

Yeah, you've got your persistence, you've got all that, you've got everything stuff kind of sorted out at that point. Yeah, that's. And if you're, I mean, to your point, if, if you're kind of downplaying the initial access component as a part of that kill chain, then you're not necessarily looking at the front end of the, the attack, you know, as heavily as well.

A (15:30)

Right, exactly. I mean, effectively you're kind of seeding that ground and saying, well, I'm not going to know if somebody is just going to click on a malicious advertisement. I guess I'll just have to kind of play cleanup there and get kind.

B (15:41)

Of nihilist about it. Just assume it's going to happen.

A (15:43)

Yeah, that's, I mean, it's hard not to. Right, But I think that's Where a lot of these kind of detection response processes sort of fall down, which is if I just deploy multiple different detections or multiple mitigations in line, at some point that attack chain will get disrupted or at least slow down or at least create enough noise that I can see it and respond before they have the credentials or before they have an authenticated session that they can use. And here that's just not the case. You're not going to get that chance.

B (16:14)

Yeah, yeah, gotcha.

A (16:16)

You know, there are a lot of ways to address that. We think that a great way to address that is by having a detection response capability in the browser to stop that. But I mean, again, I just think that's where those models, they kind of fall down. They don't really line up to what the attack really looks like.

B (16:32)

Honestly, it's the first time I've heard of that attack. It makes total sense as an extension of the click fix kind of concept. I kind of love from the attacker standpoint, the fact that you're not asking a user to go down to the start menu, press, you know, command or run or whatever and do all the, the things that would feel like a lot less natural, I guess, for a phishing target to actually make click fix work. If it's all in browser, then that's going to feel like a little less weird, I guess, and probably be more successful as a result. And for you guys to be kind of identifying attacks like this from, from your vantage point and being able to, you know, get out there and spread the word, that's to me testimony of, of the fact that, yeah, the, the browser is very much an ignored battleground. That's, that's highly contest.

A (17:19)

Absolutely. And you know, this kind of thing, I mean, targeting an app that's, you know, where you've already maybe authenticated to entra, all you're doing is like selecting your account from that, you know, that kind of pop up window. It's not, you're not even typing anything in necessarily. So it's very convincing, very effective. And you know, again, that kind of thing, if you're relying on kind of the traditional security stack like network based defense or proxy controls or edr, none of those things are going to show up. Right. Even if you're being really diligent and looking at your IDP logs, all you're going to see is yeah, somebody's been authenticated. You've got to in this case look really closely at some of that kind of identity telemetry to figure out not even what's obviously malicious, but just what doesn't match all of the other normal usage patterns, that's kind of where you've got to be here. So, yeah, I think like you said, this is very much a contested area, very much a kind of opaque box for security teams. And most of the teams that I've worked in or around in the last 10 years, something like this, like I said, you're kind of just playing cleanup at this point. You're finding out months later that you've got a compromise and now it becomes more of a forensic investigation exercise and trying to figure out what happened and, and how bad is the damage.

B (18:46)

Well, that's, that's super interesting. And yeah, we'll put, we'll put the, the link to that report in the show notes as well as the, the link to the, the taxonomies that we talked about before. Yeah, look, Mark, I really appreciate your time. It's been, it's been fascinating kind of hearing what you guys are seeing out in the wild. It's something that I always like about chatting with the Push crew is that, you know, the amount of telemetry and just kind of insight on what the bad guys are up to in this particular part of, you know, the attack surface, I guess, is, is something that you've got eyes on and the amount of research that comes from that, I always find that really fascinating. So appreciate you sharing the, the new attack style that you guys have found. We'll put those in the show notes. As I mentioned before, thank you so much for, for joining us today, mate.

A (19:26)

Thank you. Thanks for having me.