
Loading summary
A
Foreign.
B
Ellis for the Risky Business podcast. Today we're talking with Mark Orlando, who is the field CTO for Push Security. For those who don't know, Push is basically like EDR for your browser. They sit in the browser and they look for all kinds of badness. They've got the ability to block and report and do you know, all of the incredible kind of visibility of the badness that's going on within the browser, which, you know, is shaping up to be one of the modern battlegrounds for, for cyber defenders. So fantastic product and it's really great to talk to you today, Mark, I think kicking off like we've had a couple of conversations in the past with some of your peers, but I think it's the first time chatting with you, so welcome.
A
Thank you. Thrilled to be here. Thanks for having me.
B
Absolutely. Tell us a bit about yourself. What are you doing with Push?
A
Yeah, so as the field cto, it's mainly my job to make sure that customers get value out of Push, principally as a detection and response tool. So my background is in detection, response and security operations. So it's my job to make sure that the product is meeting the needs of our customers for all of those use cases and that they're getting a lot of value out of it.
B
Yeah. And I guess as part of that, you know, the role of a field CTO is seeing what's happening on the coal face and passing that back to the business, but also, you know, educating, I guess, the market around the actual problems that Push is here to solve and the actual problems that they might be dealing with. We're talking a little bit before the show about some of the kind of more outdated, I guess, ways of thinking about how attack and defense works in this sort of day and age and where the browser fits into that. Do you want to double click into some of that?
A
Absolutely. So, you know, one of the reasons that I joined Push is that as a longtime defender, you know, somebody who's, who's worked in and around security operations for a long time, I've come to feel like browser is not only kind of a big blind spot for security teams, but also increasingly a contested area, as we're seeing in a lot of these really high profile breaches where you've got in browser threats like credential phishing and account takeover and click fix style attacks. These things are prolific, very successful. And so, yeah, I think that one of the issues that I see and how I spend a lot of my time is that a lot of defenders are not really up to speed on, you know, what in browser threats mean for detection and response and how maybe some of the mental models that they use to build out operating procedures and playbooks and in fact, some of their tool set, they're starting to show their age a little bit and they don't quite cover some of these newer kinds of threats and how some of these attacks work. So I think we've got a little bit of work to do around, as you said, some education, maybe updating some of those mental models and kind of the way we approach detection and response.
B
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
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
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
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
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
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
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
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
Let's go into that. How does it work?
A
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
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
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
Of nihilist about it. Just assume it's going to happen.
A
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
Yeah, yeah, gotcha.
A
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
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
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
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
Thank you. Thanks for having me.
Date: December 14, 2025
Host: Risky Business (B)
Guest: Mark Orlando, Field CTO, Push Security (A)
This episode explores the evolving landscape of browser-based cyber attacks and the challenges defenders face in adapting their models and detection capabilities. The discussion centers around Push Security's research-driven approach, their open browser attack taxonomies, and the debut of a newly identified threat they call "ConsentFix," a sophisticated browser attack variant. The episode provides both high-level context and in-depth technical insight for defenders grappling with modern browser threats.
Blind Spots and Rapid Evolution:
Changing Attacker Tactics:
The Need for Updated Models:
Push Security's Contribution — Open Taxonomy:
Discovery:
How Typical ClickFix Works:
How ConsentFix Improves Upon ClickFix:
What Makes It Dangerous:
Impact on Defenders:
Legacy Security Stack Limitations:
Necessity for Browser Visibility:
On the Ephemerality and Velocity of Modern Attacks:
"Those things are changing every five minutes because the bad guy behavior is changing, you've got changes in the attack surface."
(B, 06:55)
On the Importance of Research-Led Security:
"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..."
(A, 09:12)
On Defending Against ConsentFix:
"If you're relying on... traditional security stack... none of those things are going to show up. 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."
(A, 17:19)
On the Need for In-Browser Detection:
"A great way to address that is by having a detection response capability in the browser to stop that."
(A, 16:16)
| Timestamp | Segment / Topic | |------------|----------------------------------------------------| | 00:45 | Mark's background and role at Push Security | | 01:44 | The browser as a contested area in cyber defense | | 03:21 | The need for new/extended security models | | 05:10 | The importance of a common taxonomy; Push's efforts| | 09:12 | Push Security's research-led approach | | 10:27 | Technical breakdown: How ConsentFix attack works | | 15:13 | Challenges to classic detection and response | | 16:32 | Legacy models failing to detect modern browser attacks| | 17:19 | The futility of legacy logs and controls here | | 18:46 | Summary and appreciation for Push’s research |
This episode highlighted both the necessity and complexity of modernizing browser security. Push Security, through open taxonomies and proactive research, advocates for evolving defender knowledge and tools as attacker methods shift deeper into the browser—beyond the reach of traditional detection. The debut of the ConsentFix attack illustrates this shift, serving as a stark reminder that defenders must look beyond established models and invest in browser-level visibility to stay ahead.
Links to further resources and the full research reports are indicated as available in the episode’s show notes.