Risky Business - Risky Biz Soap Box: Push Security's browser-first twist on identity security

Episode Date: May 15, 2025

In this wholly sponsored Soap Box edition of the show, Patrick Gray chats with Adam Bateman and Luke Jennings from Push Security. Push has built an identity security platform that collects identity information and events from your users’ browsers. It can detect phish kits and shut down phishing attempts, protect SSO credentials, and find shadow/personal account that a user has spun up. It’s extremely difficult to bypass. That’s because when you’re in the browser it doesn’t matter how a phishing link arrives, or how a threat actor has concealed it from your detection stack – if the user sees it, Push sees it. There are solutions for protecting your users SSO credentials, like passkeys. But what about all the SaaS in your environment? Even if it’s enrolled into your SSO, are you sure that’s how your users are authenticating to it? What about the automation platforms your developers and admins use? What about data platforms like Snowflake? Are your using setting up passkeys for those accounts? How would you know, and what problems can it cause if those accounts are vulnerable? This is a fun one! This episode is also available on Youtube. Show notes

Hey everyone and welcome to this special Soapbox edition of the Risky Business Podcast. My name is Patrick Gray. For those who don't know, these Soapbox editions of the show are wholly sponsored and that means everyone you hear in one of these podcasts paid to be here. And today we are going to be chatting to the team at Push Security. Now I need to disclose right off the bat, I am an advisor to Push Security. So it's a product I spend a lot of time with and yeah, I really like it for reasons that will become clear.

So what is Push? Push is an identity security product that is essentially, I mean the core thing in this product is a browser extension that allows you to monitor the use of identities in an environment, right? So instead of just looking at SSO logs and saying that is the complete picture, Push can monitor the browser for all accounts that a user in your environment might be using.

You know, the browser is the ingress point for identity information these days. That's just how it is, right? And the fact we don't have visibility there is kind of nuts. So why would you want visibility in the browser? Okay, so it can do things like protect your SSO password. So if your user tries to enter a SSO password in anything that isn't your SSO, it will stop that. That is becoming a commodity feature and it's also becoming less relevant because Microsoft through Entra is doing things

like mandatory pass keys like that's all coming but that's not why you'd get pushed. The reason you would get pushed is for all of the other identities that are spun up by users in things like you know automation platforms, code repos, services like Snowflake, external SaaS, all sorts of external SaaS that your users are using, you might even find that you have some SaaS that you've procured through official channels and your users aren't actually signing into it with SSO. Push even identified an example where users were spinning up Google accounts so they could SSO into external SaaS

using their personal Google accounts that use their corporate email address. So, you know, there's just a lot there that you're not gonna see unless you're using something like this. And yeah, it gets messy real quick. There's a part in this interview where Adam points out that when people run Push for the first time,

it's sort of like doing a volume scan for the first time, back 10 years ago when people would do that and freak out at the results because yeah, there are accounts absolutely everywhere, people using all sorts of unsanctioned stuff, people using the wrong authentication methods, not using MFA, Push can help you with all of that. So it's no surprise that, uh, you know, this company is, is doing pretty well at the moment. Uh, so yeah,

let's kick into it. Now. Um, we're joined by Adam Bateman, who is a co-founder of Push and is the chief executive, uh, and also by Luke Jennings, who is the head of research at Push. And I'll drop you in here, uh, as Adam Bateman kicks things off. Enjoy. You've been in the industry at time to time just like we have and you see all the time right attackers go for the primary target and then as that gets more and more secure they'll go off to you know wherever the lowest friction is so attackers have been going after and fishing IDP creds.

Obviously it's the star prize because once you get access to that, you can then get access to every other application behind it. But as you're starting to see the introduction of pass keys and better MFA and MFA by default and all these other things, attackers are starting to move out to other applications on the side. So we're starting to see people directly fish things like postman directly, and then use that to get access to loads of API tokens and use those to go and access other applications. We've had some pretty interesting attacks recently, like different phishing

attacks that we've seen. Luke can probably talk through some of the things we detected there that are not against IDP accounts. Yeah, Luke. Luke Jennings joining us now as well. You're getting eyes on stuff that other tooling just doesn't see. So yeah, walk us through some nice examples, Luke, if you would. Sure. Yeah. So I think, yeah, we see a huge amount of that sandbox of Azure stuff now that's pretty default. Precision validated phishing is a new term that's been used for some of this too, where it's actually targeted specifically at the email, and it verifies the email address before going through,

so that if you don't supply the correct email address, it won't turn into a phishing attack. But we've also seen some sort of interesting hybrid attacks where email is technically the delivery vector, but there'll be other legitimate services involved. That can be as simple as just sharing a legitimate Google Doc with an account that can only be accessed with their account where the phishing then takes place once directed in there. But we've seen other services involved recently like JotForm is a really good example. I've seen a few instances of recently and quite clever emails of the trickery around that.

So we saw a case recently where someone had filled out a contact request for a website and that obviously engages the sales process and they set up fictional sort of people behind that. Then the salesperson ends up reaching out to the Fisher and they then share a JotForm with them. And And within job form, you can then redirect to another URL. So that eventually then leads to an attack of the little fishing server, but you've kind of gone through this convoluted route that got them there, which meant they reached out to you and some of it happened

over email, but for sort of email gateway looking at that, it's very difficult, you know, to go through all those phases and realise that the phishing happened at the end. Well, I mean, an email gateway is not looking for outbound mail going to people doing the phishing, right? If anything, that's a signal that that address is clean and can be trusted if the contact was initiated from inside the company. So yeah, woof. Yeah, that's true. I mean, and obviously, we also see things that completely, you know, avoid email entirely too, like malvertising has always been a thing, but we've definitely seen instances that in our states recently, like I spoke publicly recently about one that was targeting Onfido, which is like a digital identity verification company. And they'd spun up an evil jinx server emulating their dashboard

and just advertised it on Google and were taking people there. And in our case, we saw someone that normally accesses it by rocker, just Google for it, click on it, get taken to the malicious server. And in that case, actually, some of the aspects of it, combined with what's been in the news recently makes me think it might have even been scattered by the little behind it. But I spoke about it, so once it was public, it got taken down fairly quickly. But I think there's targeting of the non-IDP accounts and various trickery around sandbox

evasion and getting around the email filters is, is just becoming almost a default now through various different means. Yeah. I mean, I suppose some of the good news here though, like you spoke about, uh, what is it? Evilgenics. Is that how you actually pronounce it? Eviljinks.

Yeah. Eviljinks. Okay. Right. So Eviljinks, this is one of the fish kits. That's the, you know, the, the probably what the most popular at the moment. And it allows for one- passcode like pass through. You know, will successfully log in a user but also copy over the authentication token

to the attacker. I guess the reason I wanted to talk about that is because the good news here is once you are actually in the browser, that stuff is reasonably easy to spot. Yes. Yeah, we're in a pretty unique position there. We get to the point where everything's been decoded, the DOM's been decoded, all those things. And we can look at the interactions with the user

as well, so we can see when they're interacting with different components of the page, such as entering their password as well. So being in the browser puts you in a pretty unique position to inspect things at various different levels, which password as well. So being in the browser puts you in a pretty unique position to respect things at various different levels, which is just, is very difficult for other controls to do. Um, so, you know, I think it's a sort of, it's the difference of likes to some extent, static analysis versus dynamic analysis and what we saw with, you know, evasion techniques

in the malware world before. So Adam, uh, back to you for a moment. moment. Obviously you're the, you know, you're the chief executive, you're, you know, got your eye on the numbers and the sales and all of that. You know, what's the, where's the market at right now with regard to even understanding this because I spoke to you, I've spoken to you just recently actually about, you know, enterprise browsers popping up everywhere, right? And people are like, Oh yeah, rah rah rah, lots of buzz around enterprise browsers. But enterprise, and I look, I think enterprise browsers are good, but they don't do this. Right? So it seems

like there's a lot of buzz around enterprise browsers, uh, particularly around some of the features, which you can kind of get elsewhere, like access control and whatever, which you can do through identity aware proxies and whatnot. I guess I'm curious, like when you're going out there and talking to CISOs, you know, are they coming to you already knowing that they've got a problem here or is it more a sort of sales process where people gradually figure it out as you're talking to them? Yeah, there's a couple of parts to that. I'd say identity attacks are front of mind for people now. When we first started this, people were very much focused on endpoint infrastructure. But I think there's been more and more attacks like the snowflake one has been a ton of different phishing attacks and groups like Scad Spider have been

bringing this front of mind. So people are definitely out there looking for solutions to solve identity security. I'd say the other thing is that when we first started being in the browser, it was just really weird to people. They were like, you know, we had comments like, really a browser extension, hadn't even considered that as being a security control. We're actually really grateful to the enterprise browsers because I'd say over time they've really normalized that

and it's now really accepted way. And it just makes a ton of sense to people to move into the browser and put security controls in there. But yeah, we're very different. We don't see ourselves competing with enterprise browsers at all. I think the moving into the, or being in the browser is, people are over indexing on the browser component of this at the moment, if you see what I mean. It's like, but once you actually get past being in the browser, there's a ton of different problems you can solve, right? You could solve inside of Threat, you could solve access control, you can solve detection response and stopping phishing. We happen to be solving identity attacks

because it's a big problem hitting the industry right now with a big, big focus on phishing just because of the amount of attacks that we've seen there at the moment. So yeah, so for us, we see enterprise browsers as like another operating system we support. And we work inside every browser, including enterprise browsers.

We very much complement them and add on top of them, I'd say. Yeah, but I guess the thing is people, as you say, they're sort of over-indexing on that side because it's the shiny new thing. And you can still get phished if you're an enterprise browser customer. Yeah, and it's also the ability to do investigations. We can dive a lot deeper. We can see what actually happened. You can see a timeline leading up to the event. There's lots of other information you can

do. You can also see things like the entire Identity Attack service. You can see every identity that passes through your browser. We can diff logins with stuff that's up for sale on the dark web, for example. We just go a lot deeper into that particular problem. I think ultimately, to your browser, we can like diff logins with stuff that's up for sale on the dark web, for example, we just go a lot deeper into that particular problem. I think ultimately enterprise browsers are there to protect the company from the employees. It's like who should access what, what kind of access control, DLP, should it be screenshotting and that kind of stuff. We're much more focused on how do we stop the company or how do we protect the company from attackers, specifically around identity attacks.

Now you just mentioned investigations, right? So this is, you know, you've kind of got some detection and response use cases. One thing that you've told me, our prospects really like is when you call it, it's like EDR, but for the browser. But what does that actually mean? Like, what does, what does that mean when you're doing an investigation into the sort of data that you collect? What are you going to be investigating? Yeah, so we built the product to be super easy to use. So you deploy it and it blocks. That's the main thing. Again, EDR example, you can get loads of raw telemetry out and you can feed it into your SIM and your SOAR and you can do lots and lots of clever rules, you can get loads of raw telemetry out and you can feed it into your SIM and your SOAR and you can do lots of lots of clever rules and you can augment that with other

logs in the environment. But 99% of the planet will deploy it and it just does the blocking. So we've very much followed that same approach where you deploy it, we can inspect the page and we can see how a user is interacting with it if they're entering a critical password and just block it. So a lot of people use that as set and forget. But the power of being inside the browsers, we can see things like, you can see network traffic,

you can see libraries like JavaScript libraries that are loading externally or inside the page. You can see what local storage looks like. You can see what cookies are being set and tons of different things. So what that means is that you can effectively hunt across the browsers in such a way that you could say, show me whoever's visited this particular domain that's

behind Cloudflare turnstile, which is a common technique we see for doing bot protection to do evasion, where local storage is empty, meaning that no one's ever visited this before and this has been done for the first time. You can also see things like whether it all came from a single tab, which might sound trivial, but actually if you think about doing that at the network level, it's quite difficult to tie the same multiple requests together because they could be coming out of multiple different websites and different tabs.

When you can see them as one, you know it's one fish kit actually behaving in a particular way, if that makes sense. So you can actually see a timeline. You can see, you know, you can get screenshots. You can see who actually clicked on a particular link on LinkedIn. You can see then what that opened, what people did after that event, and whether or not they typed a password into it or not. They could have just visited the site, for example, but you can actually see they've actually gone further on what they typed into the username password box as well. So are people actually doing like what you just described to, like some of it is like some searches

and there's some logic around that that would make great seam alerts. Are people actually doing that yet? Or is this just more like the vision of the future and how people might use it? Because I mean, honestly, Adam, I get the impression people just are mostly buying this because it's a phishing control that works, that just you install it and it does stuff. But I, so that's why I'm asking, are people actually

doing that or is that just something you want them to do in the future? Yeah, like it's something we're building towards in the future, but it's the reason that we are doing it this way is because, as I said, the majority of people like the fact that we can hunt across the browsers and write detections quickly. Then later on, towards the end of the year, we're actually going to be putting that at the hands. They might want to do that themselves. Right. Yeah, yeah, yeah. Exactly. So more advanced teams are working with us in that way. But the way we're thinking about this at the moment is we have Luke is VP of research and he has his research team and they're constantly looking into new

phishing kits either across our customer base or ones that are just coming out in the wild from live attacks and we're taking those things apart. We were in a position where in order for us to get those detections out very, very quickly and so we can block those for our customers, we need to go through a process of actually building an indicator into the browser extension and then shipping it across the customer base. The thing is with detections, right, it's two sides of the coin.

You can test that your kit will detect a fish kit within a lab, but then you also need to make sure it doesn't detect legitimate stuff out in the wild. So you have to go through a process here where once you've written detection, you deploy it out across the customer base, you monitor for a while to make sure that it's just picking up the true positives, and then you get into production. And that length of time can be fairly long. So what we've been working on is effectively what's much more like you can consider like OS query in the browser. So the browser is effectively recording lots of different activities

like JavaScript that's being loaded, like network requests that are coming out the browser. So the browser is effectively recording lots of different activities like JavaScript that's being loaded, like network requests that are coming out of the browser, like the state of the DOM and cookies that are being set and those kinds of things, which effectively allows us to build those detections out in a no-code way. It just basically means that once we detect something we want to build a detection in, it could be done really, really, really fast. So at the moment, we're using that to actually go look back retrospectively to find indicators of attack, to ship detections much, much faster. And then later on towards the end of the year, we're going to be starting to ship that and putting it in the hands of more advanced teams so they can actually write their own detections as well.

Yeah, it makes a lot of sense. Now, Luke, I've got a question for you, which is we're talking about, okay, you've found something new, you want to write a detection for that new fish kit or whatever, roll it out to all of your customers. You know how are you alerting on new fish kits? Like is this the case that you might see some external research or you know one of your one of your buddies who's like in some underground marketplace managed to get their hands on some new fish kit that's being shopped around? Or is it the case that you are actually doing sort of, you know, forward hunting through your users telemetry and actually just looking for these things? And how do you begin to actually search for fish kits, like novel fish kits, new fish kits in those sort of data sets? How does that whole process work? Sure. I mean, it's a range of

methods really. Some fish kits are widely spread out there and we see new examples of them even from simple sources like URL scan coming online. So we're constantly evaluating changes and looking for increasingly better ways of finding things especially if they adapt and change. So we've got that sample set to go by. But also we have a control called SSO password protection where we can tell if someone enters their SSO password into any website and we can spot it, right? So this is like, I'll just, I'll just interrupt you there and explain to the listeners and viewers who, you know, cause I don't think we mentioned that previously, but like you,

once you're a push user, you cannot enter your SSO password into a website that is not your IDP. It just won't let you. So that makes so much sense that you basically wait for the phishing attempt to succeed when they're doing SSO-based phishing, they try to drop their password at that domain, and then that gives you a red-hot signal that that's a phishing site. Yeah, so we find new things that we don't have any other detections for that way too. I mean like 99% of the time it's a legit website, someone's issues that their password in, right? But then 1% of the time it's a phishing server.

I mean just the other day I saw a postman phishing server that I hadn't seen before and someone entering an SSO password into that. So yeah, like that's a great way of finding zero-day threats for us as well to then help build new better pre-auth Detections to put back in the funnel as well. So that's a great source for us I mean you could also do that with it wouldn't just need to be SSO passwords You could also alert when they're trying to you know, use their legitimate passwords from various which of course You're not storing like before anyone writes in and says why are they storing part? They're not, they're not, because they're not dummies, okay?

But you know, you could take a secure hash of like a selection of the accounts, you know, across a user base and then just see where they're popping up where they shouldn't. And you're right, it's gonna be mostly people misremembering their passwords and entering the wrong one into the form.

But you know, you could write some exclusions for that pretty easily for, you know, you could, you could sort of just block list the legitimate services from the, from the alerting logic there. And you'd be, you'd be pretty good to go. Sorry. My mind's just spinning with like how, how easy, you know, it's easy fishing, fish in a barrel. There you go.

That's what you need to call that, that feature. Adam, you wanted to jump in there. You, I was just going to say, keep in mind that we are observing logins and app usage for the entire company. So we can kind of tell and build up an inventory of all the apps that are being used inside that company.

So if we see someone entering their SSO password outside of that group of applications, then that's different to it being used inside that group of applications, right that's different to it being used inside that group of applications, right? So we can distinguish- That's kind of what I meant with the block list there. But, you know, but I guess the question is, like, if you see a user trying to put their LinkedIn password into some weird Russian domain that was registered three days ago,

like, you know, that would be a fairly solid indication as well. That's where I was going with that. Yeah, totally. And we've been careful not to go too far ahead of the market. We focused on protecting SSO passwords being re-entered into other sites initially, because that's where attackers were going. Now we're seeing increasingly, as you said,

Entra adding pass keys by default soon, and people getting better at enabling MFA by default on their accounts. We're starting to see attackers move off of SSO and targeting things outside of that. So we're just now adding more and more and more support into protecting password reuse for those other applications as well. Yeah. So what are the most commonly targeted sort of applications that you're seeing at the

moment? Like what are attackers really loving? What are they going after that's not, you know, their Entra or their Octa creds? I think the big ones recently have been like Jira, because there's just lots of interesting information now. It's like Hellcat. We saw a huge increase of attacks there. And we caught an attack recently against like Postman.

I think you saw, what are some other ones you can think of Luke? Yeah I mean the Onfido one was an interesting one because they're a digital currency verification company and you know that I think would have been after their customers that would be fairly interesting sort of fintech customers and so forth. I saw an automation platform be a spoofed just the other day. I forget which one it was now, but obviously workflow automation systems often have very privileged access via Oauth to other systems. So they're a great, great target for lateral movement to other sensitive systems. So that's, yeah, that's one I saw.

Yeah. All of that makes sense. And obviously we're seeing certain classes of attacker really focus on supply chain. You know, I just published a podcast with a couple of the Sentinel One people talking about attackers going after their suppliers, for example, and also, you know, trying to get North Korea, North Korea, trying to get workers hired in there and whatever. Mostly they think because they have a fairly decent customer base within the sort of crypto ecosystem. But it's certainly where we see those sort of attacks like targeting the crypto exchanges and you know, defies and and whatever. I'd imagine that, well, I'm curious, Adam, like are you finding you're

getting traction in that space because it seems like the, the crypto world is one that really sort of understands the risks that can be posed from these sort of external services, external SaaS. We do have some crypto customers, but I mean honestly at this point we have customers across pretty much every sector. And that actually surprised us because initially when we started to build the company we felt like the place we were going to target were like completely SaaS native type companies, right? Like startups that were all SAS orientated, they were much more like modern tech companies

because we're like the primary control for that sort of company. If you think about it, you know, they're probably Mapbooks, they do all their work in the browser. It makes sense. We do have a lot of those sorts of customers and crypto exchanges would fit into that profile. We even have charities and local tourist centers and we have a regional US airport, for example,

that just signed up for this stuff as well. I think ultimately just because everyone that gets that phishing is a problem, everyone gets that you can click on phishing links in multiple places and you're starting to see that expand out. Even so, people want to understand what satirications people are using, they want to understand what accounts are out there, which one's vulnerable, I think inherently people just understand that it's an easy attack to execute, right? You basically just log into the account and you do your thing.

Like there's no trying to bypass some, you know, like MDR service and having to like persist on an endpoint and move out to the network, you just log into an account. So something that people just get, which is why we're just seeing such a, I guess, a wide customer base from different sectors. Yeah. So I just want to go back to something you mentioned, Luke, which is people were going after this, was it like an automation platform or something? And the reason they were doing that is because they could then use that access to OAuth, authorize entry into a bunch of other different services. But that brings up the topic of like OAuth

grants in the browser. So we've been, we've been just focusing this conversation on phishing, but another thing that is really taking off in terms of popularity is like OAuth phishing because that gets you an awful lot, right? If you can put an OAuth grant to a malicious application in front of a user and they approve it, um, that is a compromise, right? So what are you guys doing currently around OAuth? Because I know that you've been thinking about it. You've been talking like, but I'm not actually clear on what it is that you're actually doing

to prevent malicious like OAuth grants. Yeah, I mean, we, so we're not covering that in the, in the browser for detection right now. We have backend integrations with, with Google Microsoft where we analyze that and we get all of the integrations that we see and new ones and we analyze the permissions and we highlight ones that are risky. So we've got that from backend integration perspective, but, um, you know, I think we'll probably do more in the browser as well with that in future. Um,

Well, I mean, you know, but that is one case where you don't strictly need that. You don't strictly need to be in the browser. You know, if everybody's using like an enrolled device, if everybody's using a, you know, edge or whatever, and it's through their 365 account, you could just poll an API and get that list. That's fine, but I guess one area where it might be handy to see it in the browser is the context through which that user wound up having that grant put in front of them in the first place.

I mean, is that sort of the thinking there? Yeah, so I think in the browser, yeah, we would definitely see more context around it. So that's one reason. I think also, until now, probably 99% of OAuth-related grants are something connecting into Microsoft or Google. But over time, we're getting more and more SaaS apps

that are offering OAuth in the other direction. So we're seeing OAuth connections between apps that don't involve the major IDPs. So I think that sort of sprawl of the OAuth side is increasing too, and we'll get visibility there through the browser. Why are they doing that? That sounds just, I mean, I get it. I mean, I'm sure there's a reason, but what you just described sounds like it's not gonna be a fun time.

What can go wrong? Except, unless you're exactly right. you just described sounds like it's not going to be a fun time. What can go wrong? Unless you're exactly right. But like, so, okay, so, you know, how do you even begin to tackle that? Because Adam, previously we've talked and you're like, look, OAuth grants are easy to see in the browser because it's all going through your major IDP, right? So like it's a, you know, an OAuth grant, if you're a Google shop, it is actually going to be a Google thing that pops up in front

of the user. It's not like a fake page. It's always a legit page from the actual, you know, authorizing, you know, from the point of trust, right? But I suppose if every Tom, Dick and Harry starts offering, well, you have a valid session token for this, you know, Pat's risky business web application. And now you can OAuth grant access to that one over here. Like I don't know, man.

It's sort of hurting, hurting my brain. Like is it going to be easy, I guess is the question, to come up with generic ways to understand when an OAuth grant is happening, when it's happening across multiple applications. Like when it, when it, when the user could be doing an OAuth grant across happening when it's happening across multiple applications, like when the user could be doing an OAuth grant across like 10 different apps. Yeah, so like, because it's a standard or standardish protocol, what we see is that there's a very small variation in the way that it's implemented in terms of protocol requests. So yes, you can actually pretty generically track or the cross anything in the in the browser I've only seen like a very small number of different types of it in terms of names of params and all that sort of stuff

So like separately I already do this inside of push. I have my own research extension. I track the whole of push I found things that we didn't know what happened in just fire that what sort of things I'm curious So like this is not a malicious example, but it's just another case of the complexity of modern identity. But say we use Loom, for example, for sharing videos, right? And we log into everything, ideally, with SAML-based logins for Google, if not OIDC Google

logins. And that's how we would access Loom normally. But we've got Slack integration for it, which we knew about. But if what happens is we realize if someone just posts any Lume video on Slack, which is how we normally share them, when someone clicks it to view it, it was auto log in with Slack rather than with Google. So this is what I mean is that like Slack then is becoming like a pseudo IDP for logging into Lume. And that's I mean, that sounds like a relatively benign example, but it's just like with all of these developer tools and you know, and cloud and SAS, I keep saying it's kind of the same thing these days, right? Like what are those relationships look

like in five years from now? And that's why I've been sitting here like kind of, you know, with my brain on fire a little bit, cause I just think, Oh God, what are we doing? Yeah, it's definitely increasing. And yeah, the ultimate target for these is automation platforms, like the makes the Zappiers, all those kinds, because they are like full NoCo platforms. When you see people doing that, it's not just having like data access, it's the ability to write code effectively that runs and does anything you want with that access in the future. So like, you know, that's the really powerful target and it's an amazing persistence technique

as well if you compromise an account and you go and do the grants yourself as an attacker. So it's a huge attack surface. Yeah, yeah. Well, look, we're going to move towards wrapping this up, but I guess back to you, Adam, just for a couple more questions about like the adoption side of this. I mean, you mentioned, Hey, we've got a charity. We've got a few people in crypto. We've got people sort of everywhere. You've also got the InfoSec bread and butter type customers, which are gigantic mega banks. Um, I you're probably seeing some pretty good adoption in banking and financial services.

Would that be accurate to say that? Yeah, we're across all sectors, but financial has been a really big one for us. I think generally they just care a lot about security. They invest a lot in security and there's a lot of attacks. Well, that's why I called them the InfoSec. They're everybody's favorite payday is like the big banks, right? Yeah. So we have some more traditional banks, like up to 300,000 employees all the way down to companies that are like 20 employees and they've just signed up on their own free trial.

Because we have like 10 free licenses, people will just sign up and they'll deploy the browser extension out to even just their VIPs or like their highly privileged users inside the company and bang, they've got out of the box fish kit protection. So we sometimes see smaller companies just signing up and deploying for that reason and then they'll just gradually grow and add more licenses as well. So yeah, we literally have all the way up from huge, huge enterprises right down to smaller companies. So I guess the reason I was asking that is now that we've established that, you know,

your tech is in some pretty important places, can you think of like a really great save that a customer's come to you and said, my God, like one of our users tried to enter X into Y and if they had have done that, Z would have happened. We see everything that evades absolutely everything else and then we catch it at the end. So we see a ton of stuff like the things we've been talking about in this podcast, right? We see all the different things that have evaded all the other controls and they've got around in different places. But we also see stuff like people have found things like, we've had people reporting

bugs to us saying, hey, there's a bug in the platform right now because it's saying that there's 60 people missing MFA on our GitHub, for example. And we dug into this and we're like, actually, this isn't a bug. Is this real? I was like, nope, can't be possible. It turned out to be a big configuration issue where someone has sort of dragged someone into a different OU and then it disabled MFA through a ton of different accounts. So we've had, you know, missing MFA with stolen credentials on people's CMS that managed the entire website, which is really important to that particular company, like lots and lots of different things like this all the time.

I think the way I think about this is like, it's just, it's very much like a new attack surface. And so how I'm feeling about it at the moment is you know how when we used to have this external network perimeter, it's like you'd have a network diagram of how pretty things looked. And it looked like my firewall was configured like this, and it had three or four ports through.

And then you do a Vaughan scan. Then you actually do a bunch of end maps. Yeah, exactly. And then it looks completely different. It's very similar to that. Right now people have this view of what their identity attacks of us looks like and they feel like they have Okta with everything behind that. And actually the reality is that when you actually get the visibility, you realize that there's not just Okta as your IDP, but GitHub's an IDP and like, you know, Sage is an IDP and just like there's just IDPs hanging off of IDPs hanging off of IDPs, we have different local accounts and there's people making mistakes and all those kinds of

things in one go. So we just see so much stuff at this point. It's, yeah, it's interesting. All right. Adam Bateman, Luke Jennings, thank you so much for joining me to talk about, I guess, how phishing sadly is still a problem even in the age of pass keys and how the sprawling identities that your users generate and the relationships between them, I promise you, we all promise you, you do not understand. Yeah, great to chat to you, Adam. Great to see you, Luke. Cheers.

Thanks, man. Cheers, bye.