Sponsored: Push Security on its new stolen credentials detection feature

Summary

Risky Business News: In-Depth Look at Push Security’s New Stolen Credentials Detection Feature

Release Date: December 1, 2024

In this episode of Risky Business News, host Catalyn Campano engages in a comprehensive discussion with Jacques Law, co-founder and Chief Product Officer of Push Security. Sponsored by Push Security, the episode delves into the nuances of identity-based cyber threats, the evolution of phishing techniques, and the innovative solutions Push Security is bringing to the forefront of cybersecurity.

---

1. Introduction to Push Security and Identity-Based Attacks

Catalyn Campano (00:06):
"Hello, this is Catalyn Campano and this is a Risky Business news sponsored interview with Jacques Law, co-founder and chief product officer of Push Security."

Catalyn sets the stage by introducing Jacques Law and Push Security, emphasizing the company’s focus on combating identity-based attacks through a browser extension designed to detect and prevent credential thefts and phishing attempts.

---

2. The Evolution of Phishing Kits and Identity-Based Threats

Catalyn shares a personal anecdote highlighting the evolution of phishing kits, specifically the transition to reverse proxy-based phishing kits like Modelshka, which can bypass multifactor authentication (MFA).

Catalyn Campano (00:25):
"The most read article I ever had was an article that basically described the researchers' work on a tool called Modelshka which was basically a phishing kit that could bypass multifactor authentication."

This story underscores the increasing sophistication of phishing attacks and the necessity for advanced detection mechanisms.

Jacques Law (02:27):
"Phishing kits today are very bespoke. They change the actual behavior of the source website significantly... they implement specific techniques to bypass existing controls."

Jacques elaborates on how modern phishing kits adapt to evade traditional security measures, making detection more challenging.

---

3. Push Security's Detection Methods and the Pyramid of Pain

Jacques introduces the concept of the Pyramid of Pain, explaining how Push Security prioritizes detection strategies that target user behavior over specific phishing kit signatures.

Jacques Law (02:27):
"From there you could detect specific signatures of the tool a little bit above. From there you can actually detect very generic things that the tool is doing."

By focusing on the fundamental behavior of phishing attacks—such as users entering credentials on fake login pages—Push Security enhances its ability to prevent breaches effectively.

---

4. Tackling Detection Evasion and Enhancing Prevention

The conversation shifts to the prevention-focused approach of Push Security, emphasizing proactive measures over reactive detections.

Catalyn Campano (06:19):
"So you're more like on the prevention side than the detection. Your product is more useful for the prevention, right?"

Jacques Law (06:28):
"Typically customers are rolling out the product inside very like a monitor mode for the first month... then you put it into blocking mode and you can actually block virtually all phishing attacks."

This strategy ensures that organizations not only detect but also prevent credential theft by enforcing unique SSO passwords and blocking suspicious activities.

---

5. Introduction of the Stolen Credential Detection Feature

One of the significant highlights is Push Security’s new Stolen Credential Detection feature, which enhances the accuracy of threat intelligence feeds.

Jacques Law (11:37):
"We're just calling it stolen credential detection. We like to be descriptive."

Jacques explains how this feature filters out false positives by cross-referencing leaked credentials against actual user data, ensuring that only verified breaches are flagged.

Catalyn Campano (09:52):
"Most of these breached password Databases are 90% are just old, very old stuff."

This acknowledgment of the limitations of traditional threat feeds reinforces the necessity for more precise detection mechanisms.

---

6. The Role and State of Multifactor Authentication (MFA)

The discussion turns to Multifactor Authentication (MFA), its effectiveness, and the challenges surrounding its implementation.

Catalyn Campano (12:50):
"I'm interested for a company that handles identity attacks at the browser level, what's your stance on the state of multifactor authentication..."

Jacques Law (12:50):
"There's very little one can disagree that it is a super effective thing to do... but user pushback against this as a control."

Jacques emphasizes the importance of implementing phishing-resistant MFA methods and highlights the complexity organizations face in managing MFA across numerous applications.

---

7. Push Security’s MFA Guardrails Feature

To address MFA challenges, Push Security has developed MFA Guardrails, a feature that enforces MFA across applications that may not natively support it.

Jacques Law (15:56):
"One of the new features that we've just launched is called MFA guardrails... enforce MFA on that app."

This tool prompts users to enroll in MFA when accessing applications lacking native MFA support, thereby enhancing overall security.

Catalyn Campano (16:25):
"I'm curious to know... can push help me at least secure it in some way?"

Jacques confirms that Push Security provides visibility and enforcement capabilities, even for legacy applications that do not originally support MFA.

---

8. The Perception of Identity Security in the Cybersecurity Industry

Jacques addresses the broader perception of identity security, noting its critical yet often underappreciated role in the cybersecurity landscape.

Jacques Law (18:28):
"There is this kind of perception that identity security is not a very sexy area... it's the oldest security control there was."

He argues that despite being a cornerstone in preventing breaches, identity security lacks the spotlight and innovation seen in other areas like network security or application security.

Catalyn Campano (19:29):
"Exactly. It's either your networking gear or some phishing, but that's how they always get in."

This sentiment reflects a common industry oversight, where foundational security measures are not given due attention.

---

9. Conclusions and Future Insights

In wrapping up, both Catalyn and Jacques underscore the necessity for greater focus and innovation in identity security to keep pace with evolving threats.

Jacques Law (20:53):
"It's not dumb if it works. And it really is working today."

This concluding thought reinforces the effectiveness of Push Security’s approach and the importance of continual advancement in identity-based threat prevention.

---

Key Takeaways:

• Push Security is at the forefront of combating sophisticated identity-based attacks through innovative browser-based solutions.

• The evolution of phishing kits necessitates advanced detection and prevention strategies that focus on user behavior and credential management.

• The introduction of the Stolen Credential Detection feature significantly reduces false positives, enhancing the reliability of threat intelligence.

• MFA remains a critical, yet challenging, component of identity security, with Push Security’s MFA Guardrails offering a proactive solution for enforcement.

• Identity security is a fundamental yet underrepresented area in the cybersecurity industry, requiring increased focus and resources.

This episode provides invaluable insights for cybersecurity professionals seeking to enhance their organization's defenses against identity-based threats, emphasizing the need for proactive and intelligent security measures.

Transcript

[A]

Hello, this is Catalyn Campano and this is a Risky Business news sponsored interview with Jacques Law, co founder and chief product officer of Push Security. Push Security is a solution designed to work inside a browser as a browser extension where it can detect and stop identity based attacks.

[B]

Welcome Jacques, thanks for having me.

[A]

As a browser based security extension like there's a lot of stuff you can detect in the browser but probably the most prevalent threat you have to deal today is probably identity based attacks like credential thefts and phishing attacks. Now I'm gonna start with a short anecdote. Before I joined Risky Business I worked like for seven, eight years as a infosec security reporter. And my success, let's not say success. The most read article I ever had was an article that basically described the researchers work on a tool called Modelshka which was basically a phishing kit that could bypass multifactor authentication. And it's a reverse proxy based phishing kit which we now call attacker in the middle phishing kits. Even if Evil Jinx existed quite for a few years before Modelishka, the article basically popularized the concept of multi factor authentication bypasses through phishing the possibility of bypassing with factor authentication just through normal phishing. You go to a website, the kit is running underneath, it intercepts your login, it asks you for multifactor authentication challenges and then secretly records your authentication cookie and uses that to log into your account. I remember about two or three weeks after I published the article, someone from a threat intelligence company named Kela reached out and they were telling look, do you know that your article is like very, very popular on hacking forums and everyone's telling we have to implement this into our phishing kit. This is really smart. I remember about one year later most phishing kits have already started supporting multifactor authentication. And now if you're a threat actor and you're trying to set up a phishing kit, you'll probably get left off hacking forums if you don't have reverse proxy capabilities. Now I was wondering how are you dealing with stuff like this today? Because it looks like attacker in the middle phishing kits are the standard now.

[B]

That's so interesting man. So we have you to blame for this. Yeah, it's an interesting story because I think if you look at the detections we built very early on, those are really built around like detecting reverse proxy. The problem with the reverse proxy is that it actually is if a perfect reverse proxy leaves no signals. But all of these phishing kits implement some kind of changes to the website. And so those are some of the things that we detect. But I think for our product specifically, we try and not actually which phishing kit is this detection is kind of like a nice to have. It's something that like an interesting enrichment. But the thing is you don't actually care which phishing kit it is that is phishing your users or has successfully phished your users. You want to stop that. And so the thing we go back to is sort of this idea of the pyramid of pain. Right at the bottom of the pyramid of pain you have very dull detections like an IP address or a domain. Someone else has to make the detection first a little bit up. From there you could detect specific signatures of the tool a little bit above. From there you can actually detect very generic things that the tool is doing. So as an example, if you detect resources getting loaded by the Microsoft SSO page or an okta login page, just the images that are getting loaded or the structure of the HTML content, and you observe that same structure on a different domain, well, that looks objectively bad. Actually the kinds of attacks that we're seeing today, or the most phishing kits that are very prevalent today actually are very bespoke. They changed the actual behavior of the source website significantly. And actually when you look at the anti detection, the detection evasion techniques that they implement, you can actually see exactly what they're trying to bypass. So just as a few examples, we're seeing them use things like Turnstile very generically. So maybe it's worth just saying that pushes sort of, you know, when we started a couple of years ago, this was kind of like a bleeding edge thing to do. So most of the customers that have been with us for a while have really been interested in, you know, bleeding edge detection. So these are people that really care about identity security and really have implemented a lot of existing controls. So the stuff that we are seeing is basically the stuff that doesn't get caught in your email detection. It doesn't get caught by your secure web gateway. It bypasses all those things. So the phishing kits that we see basically falling through all those existing detections are the kinds of things that are implementing like real bypasses that are looking at what is this? You know, is this a bot user trying to like specifically detect that it's running in a sandbox? They're trying to do specific obfuscation of resources. So they'll do things like you have to display the Microsoft logo on the page. Well, let's embed that logo inside a Much bigger image. And then when we render the page, we'll crop that image and display it. So they're taking like very specific techniques to bypass these existing controls.

[A]

And since we're talking about avoiding detection and obfuscation and evasion. Did you ever see something that was specifically designed for your product instead of just classic email security gateways that work in the inbox?

[B]

Yeah, I mean, some of the evasions, it's hard to tell exactly what they're for. I think the interesting thing here is that we have to talk about which detections, because some of the detections we're building are like very generic and, you know, it gets bypassed just because it bypasses all the existing detections. I think the interesting thing to talk about is like the detection that we're actually relying on. The reason we're seeing new things that haven't been seen before is basically because we're relying on detecting a lot of the user behavior. So it's not really about the phishing kit. It is the one thing. What is the one thing that phishing kits have to do or any phishing website has to do? It has to get the user to put their password into a website that is not the actual login page. Right. So you have to put your Microsoft or your Okta password in a page that is not Microsoft or Okta. And so by tracking that behavior, we can actually see the phishing kit. So that, that's something which is a lot harder to bypass because if the user isn't putting their password into your phishing kit, like, whatever else you do hasn't, you know, like is actually pretty irrelevant. So. So that's really like the core feature we're relying on when we do these detections.

[A]

So you're more like on the prevention side than the detection. Your product is more useful for the prevention, right?

[B]

I think so, yeah. We like to think so. I mean, typically customers are rolling out the product inside very like a monitor mode for the first month. So a key thing here is that you'll see things like password reuse being a very common thing. Like as an ex pen tester, a red teamer, you kind of have in your head that people are reusing passwords everywhere, but you don't understand the scale of it. And it's crazy just to see where people are putting their SSO passwords into websites to order donuts, sports gambling, just any kind of random website. But when customers actually roll out this feature, typically for the first month, they put this into monitor mode and you build like an Automation, you take our signal and you just trigger a password reset on your SSO every time a user puts their SSO password into any other website. So after the first month, your SSO passwords are unique and they're not being reused anywhere. And then from there on you put it into blocking mode and then you can actually like very efficiently block virtually all phishing attacks.

[A]

Are there any kind of other types of these clever features that you have in your product that you run at the browser side?

[B]

Yeah, I think maybe one which is quite interesting, which is kind of related to the same thing, you know. So as part of this like tracking essence, so password reuse, one of the things we do is we take fingerprints of the passwords as we observe them being used. So if you do that, obviously you see attacks happening in the wild. Like post Snowflake. Everyone saw the Snowflake breach, which is really interesting. Customers immediately asked us. Being an identity security product, we're seeing these TI feeds getting the marketing is exploding for all these threat intel feeds, promising to detect the same kinds of things when our credentials for apps get leaked on the Dark Web, which is the best feed at the time, we didn't know. We asked them what's wrong with the feed you have today? They're like, oh, just everything we're looking to is a false positive. So we actually wanted to just answer that question properly. So the way we did that is actually realized that you can take the data in that feed and you can actually just check the password against the one that's actually being used. So we contacted like a dozen customers, asked them to help us with this experiment. We basically went through a couple, like a handful of these TI feeds. I think we had something like 10,000 users in scope. We found something like 40,000 compromised credentials. Those 40,000 compromised credentials, we took fingerprints of all the passwords, pushed it into the correct browser agent and then checked how many of these things were actually valid. So all these customers had been with us for sort of six months. So we had a full inventory of the passwords they were actually using to log in. And it was mind blowing, like how few of these credentials actually came back as matched and verified. So we weren't even just matching them against the application they were leaked for. So the infostealer log says this is a GitHub password. So we were just checking the same password against any app. And despite that, the number of results we got back as being verified this password is actually being used is a couple of dozen results across more than 40,000 unique stolen credentials, which is just mind blowing. So you get a really good sense of why people are struggling to use these feeds. So I think that experiment then obviously led directly into a feature which is something we just released, which helps you basically take the TI feed and get the actual value out of it. Rather than having to chase down the 40,000 potential events, you can now look at the sort of less than 1% that are actually verified as being stolen.

[A]

No, that's actually a problem I had with threat intel analysts in the past because I actually many times saw them. Every time there was a breach, they would immediately say, okay, we found this company's employees, had passwords leaked online. And then you dug deeper and you saw that, okay, they were phished and their password was added to a info stealer store in 2011. How is that relevant today, 14 years later? So something that I kind of understood that most of these breached password Databases are 90% are just old, very old stuff.

[B]

Yeah, I mean, so much of it is just repackaged and sort of combo lists. Just all the old parsers that just get put together and recombined with newer and bigger lists as we go. The problem with these things is even though there is so much there that isn't useful, there is definitely a couple of compromise credentials in there that are valid and are incredibly useful. And it's so hard to just say, like, oh, we're going to throw everything out, right, because there's some noise in the system. We can't trust any of this. I can see why there's frustration there. Everyone recognizes the potential value of this data, but if you can't eliminate the false positives, then you can't actually use it. There's no point spending 80% of your SOC teams, your IR teams availability to investigate something which just constantly turns out to be false positive. False positive. So, yeah, having the ability to actually get rid of all that work and just have something that tells you like, okay, this password is currently still in use. It is. It has been observed. This is definitely not a false positive. Yeah. I think that is something that actually makes that data from a. What do we do with this? To. Yeah, okay, this is now actionable.

[A]

Do you have a name for this new feature? Like customers can search for it?

[B]

Yeah, we're just calling it stolen credential detection.

[A]

Okay, well, that's good enough.

[B]

We like to be descriptive. Yeah.

[A]

So they know what to look for. Now, another thing that I've recently noticed in the community and open discussions is that more and more people are dogpiling on multifactor authentication that it's not good just because a few of them are not absolutely perfect at securing identities, you shouldn't bother using it and blah blah blah, unless you're using passkeys or security keys, you shouldn't even bother. Which I'm obviously not in favor of that kind of advice given out by security professionals. But I'm also interested for a company that handles identity attacks at the browser level, what's your stance on the state of multifactor authentication and how you advise customers to Are you telling them, look, enable even the weakest form or stay away from this and only enable that? I'm curious how actual professionals in this field deal with multifactor authentication compared to what infosec superstars post on social media.

[B]

I think when you look at the efficacy of MFA as a control, I think there's very little. There's almost no one that's going to disagree that it is a super effective thing to do, but there's also going to be like user pushback against this as a control. So I think when it is an absolutely core platform like your idp, you know, like your Microsoft okta login, that there's very little argument that this is like an absolutely essential thing to do if you're going to do it on those core platforms. Making sure that you put the time and effort in to make sure that the MFA method is phishing resistant. So something that's device bound, something like web authentication I think makes a lot of sense. I think the and almost more interesting and a much less discussed area is like what happens with everything else. So I think a lot of customers when they just join push for the first time, they have this kind of mental image that everything is on SSO and they sense that they've got MFA enabled on all those accounts and it's pretty good and then don't actually realize how many other apps there are that they haven't that they don't know about yet. Many of those apps don't even offer you the ability to enroll MFA or to enforce MFA or to do anything about this. So even if that app is IT managed, a lot of the apps don't even show the IT administrator like the admin on the app, which of the users on that tenant have MFA enabled. So you know when you get out of this sort of like core SSO integrated app list, it degrades very quickly and the complexity goes extremely high. So I think like an almost more important question is not even what is your overall policy, but is having the visibility and the ability to even see what the real world situation is. Because I think you can have this idea that everything must have mfa, but until you get a sense for what the world looks like and what your current state is, you know, the distance between making that policy practical is often huge.

[A]

Now how do you deal with these customers? Let's say that they don't have a good view of their network and where they can enable nfa, are there features and push that you can help with this?

[B]

Yeah, so actually one of our oldest features is to just do MFA detection. So when a user logs into an app, we check whether they're going through mfa, whether they've got an MFA enabled on that account. I think how you manage the situation is a very different situation. So when you see that the average employee for new customers has 13 identities, so the SSO account they have is one identity and all the apps they use, they access using that. But then there is Normally on average 13 other apps. Some users we see have 80 identities who uses at apps. But yeah, that's not uncommon. So I think for us the next question is then like giving people the ability to enforce these controls effectively is quite difficult today because a lot of these apps aren't it managed, they don't have built in controls that allow you to turn on MFA or to enforce mfa. So one of the new features that we've just launched is called MFA guardrails. And so what this allows you to do is choose an app or a set of apps, choose a user, a set of users, and basically enforce MFA on that app. So when the user goes to the app, we show them a banner in the browser immediately that tells the user, okay, you don't have MFA enabled for this account, please go and enroll that right now.

[A]

Like I'm also asking this as someone who's curious, like I don't know your product in and out, so I was curious to know, okay, what do you tell customers that have issues with detecting where they have mfa, where they, how they could add some sort of artificial layer like okay, I can't have MFA on that app that was created in 2005, but can push help me at least secure it in some way? Like I'm not, I'm not going to find someone who can recode that 20 year old app to support MFA.

[B]

Yeah, for sure. I mean like not even 20 year old apps, like modern apps that exist that went live yesterday are going live without having MFA in them. So it's like it's A wild situation. And the app kind of has to grow to a certain size before anyone has the pressure to push on, you know, to like, put enough pressure on them that they actually build like proper security controls, allow them to enforce mfa to put all these things in place. So, yeah, having something that gives you at least visibility of where this is in place and having something that can sit over the top of that is obviously a crucial. Obviously this feels like a very proactive control. But we've got more and more customers actually using this kind of feature reactively. So once they think there is a problem with an app in sort of a snowflake style incident, where you realize, oh, we have some credentials that have been breached to then have the ability to quickly respond and say, like, okay, we actually have much more sensitive data in this app than we thought we had there. Okay, let's use this in a kind of response capability and start rapidly enforcing and writing out MFA on that app, even though the app doesn't even support the ability to enforce MFA yet.

[A]

You want to talk about anything yet?

[B]

I did want to sort of talk about the perception of identity security because I think it's such a. It's such a crazy situation that we have.

[A]

I actually had a question prepared on that earlier today when I was preparing the interview. I was talking with Patrick, my boss, like Patrick Gray, the main show host. And he was telling me, like, every time he has either you or island on the show, he asks you why hasn't CrowdStrike acquired you yet? And basically like, he's like obsessed with. Why are they. Aren't these big companies buying companies like yours, like, do security in the browser? Like, I have this theory that they're basically underestimating your capabilities. Like they're, they're either misinformed or they don't know the exact nature of your product or just, they might not care about identity attacks because they just, they're just focused on their stupid DDR that works at the file disk level, that's it.

[B]

Maybe I don't know the answer to that exact question, but I can talk a little bit about how I see the industry in general because there is this kind of perception that identity security is not a very sexy area. Right? It's not a. It's not a super sexy topic. You know, it's kind of was. It's. It's in a sense the oldest security control there was. Like, before there was anything else, there was passwords and it's. There's never been the kind of thing that like really Hardcore technical people want to focus on that. You know, there's. Everybody says very quickly, like, identity is the new perimeter, but we don't actually act on that. We don't change anything we're doing based on that. There's no pwn to own for phishing. There's no buffer overflows, no rob chains in this world. No one gets celebrated for doing something really new in this area. So, I mean, even if you look at major security conferences, there's no identity security track at most major security conferences. So even though it is kind of the single attack technique or attack category that is probably responsible for more breaches than anything else right now.

[A]

Exactly. It's either your networking gear or some phishing, but that's how they always get in.

[B]

Exactly. And yet we.

[A]

Nobody seems to care.

[B]

It's bizarre, but I think it is because if you look at how much it's changed, it's kind of becoming clear. Because back in the day, I mean, like when we started pen testing, it was very much about like, okay, what is a password? Right. It's a local password on a machine or it's an active directory password. There isn't like much complexity or much interest in there. The internals of active directory, very interesting. But just the actual part of getting the password, reusing the password, it's kind of a limited space. But the complexity has changed so much today. Like modern identity security, when you see all the interactions between IDPs, different multiple IDPs getting used to get access to the same app, the same account, even on the same tenant, it's wildly. Yeah, the complexity is going wildly up. So it's gone so far. It's kind of this intersection where it's not quite web app security, it's not quite sort of SSO security. It's kind of falling in between all of these things and you're starting to see these like, already weird logic bugs and things starting to creep into this. So, you know, like, what's the thing you guys always say is it's not dumb if it works. And it really is working today. And I think, yeah, having a lot more offensive, offensive interest and offensive effort going into this area is the thing we really need.

[A]

Okay, well, Jack, thank you very much.

[B]

Cool. Thanks, Carlin.