Defending Against Identity Breaches: A Comprehensive Taxonomy of Attacker TTPs and How to Stop Them [Intermediate]

So this is going to be a pretty brief presentation. I'll try to keep short and entertaining. What I'd love to convey in this presentation is what are the current threats that target identities and why the work that we do as an industry is important to defend against breaches. So I'll skip this part because we don't have enough time, but just briefly, everything you're going to see in this presentation has more of a cyber security angle to it because that's my background, that's our collective background as an industry.

I used to do a lot of offensive security and then spent a number of years at CrowdStrike. And a lot of the data you're going to see in this presentation comes from global threat reports from companies like CrowdStrike. So let's start from the macro trend. CrowdStrike has started to track breaches since about 2018 and every year they release a report to show which breaches have malware used and which breaches happen without malware. And the trend has been clear over the years that increasingly the threat actors don't actually use malware to compromise environments.

Last year, sorry, 2023, it was 75% of breaches were malware-free. Today, this year, it's something around 80%. And this often means that if they're not using malware, they're generally using some identity-related technique. So the trope that attackers don't break in, but they log in, is definitely becoming more true by the year. So what other data points do we have to corroborate this? Verizon has a yearly report where they track internal investigations and breaches that they see in public. Historically, they've tracked about 33,000 breaches.

Of these 33,000 breaches, over 30% had an element of stolen credentials, which is by far the most common way in which companies get compromised according to the data that Verizon has. Again, from CrowdStrike, we're seeing almost a 6x increase in the number of Kerberos attacks. And then the last one, which I think is one of the most interesting ones, is the fact that AWS runs an internal analysis of all the breaches that they see. About 66% of all the AWS customer breaches happen because of stolen credentials. So this is roughly what a breach looks like.

You have some initial compromise, generally through phishing or some kind of credential leak. And then the next step that attackers tend to perform is to move laterally by harvesting credentials.

Now, one thing that I think is fundamental to talk about is, as an industry, we talk a lot about least privilege. And I think what's sometimes forgotten is the key reason why we need least privilege from a cybersecurity standpoint is the fact that once an initial breach happens, an attacker today has a super easy time moving laterally and escalate privileges because all these identities are overprivileged. And one of the best things we can do to reduce the blast radius of a breach is try to achieve least privilege.

Remove as many privileges as possible from the identities so that even if somebody gets phished or a credential is leaked, that doesn't lead to a full compromise of an environment. So some of this stuff is not necessarily new. People have been phished for years. What I think is interesting is how these techniques have evolved.

So again, in terms of how attackers get in, phishing has evolved from simple emails to something we're seeing a lot now around OAuth 2.0 consent phishing. And the idea there is that you get a legitimate looking email that asks you to click on a link. That link is actually a valid IDP link. So it could be like an Entra link or a Google Workspace link. And effectively what happens there is the victim gives access to a service account that is behind an application controlled by an attacker.

And by giving that access to their environment, the attacker is able to exfiltrate data, create privileged users, install ransomware, and so on. So phishing has definitely evolved.

And yes, MFA helps a lot, but it's by far still one of the most common ways in which people get compromised today. Even on leaked credentials, we're used to thinking about leaked credentials as leaked API keys in some GitHub repo. That has changed a lot over time, both in the number of sources that attackers look at. So it's not just source code anymore. It tends to be repositories like NPM. It tends to be Docker image files, crash dumps, and so on, as well as the type of credentials that they look for. So it's not just API keys anymore.

It's pre-authenticated URLs, any key material, certificates, and so on. And then lastly, one of the things that gets the most attention in public are supply chain attacks. You've all heard about SolarWinds, but most recently the TGA action breach. And generally, the idea here is somebody gets compromised, and that somebody is either an open source developer or a software vendor. And then the attacker installs some form of a backdoor in the source code that is then used to compromise customer environments by harvesting credentials in customer environments.

Again, this gets a lot of attention. It's not as frequent as some of the other stuff, but it's potentially very scary because once you compromise one open source library, you get to compromise a ton of people downstream. And these are the ways in which attackers stay in, especially for on-prem environments. There's a lot of token forging techniques that attackers use to generate long-lived, high-privileged tokens.

We've seen in the MGM breach and a bunch of other breaches how attackers have installed malicious IDPs and created malicious trusts between the customer IDP and an attacker-controlled IDP to maintain control over the customer environment. And the third is either malicious service accounts, again in the form of all two applications, or secondary MFA factors controlled by an attacker. So these are all persistence techniques that people use in the field today, and all of these are fairly hard to spot. So some statistics on attacks in general.

The average time it takes an attacker from initial compromise to breaking out in the environment is about an hour. The median number of days before a breach is discovered is 10. And quite concerningly, over 50% of breaches are not actually discovered by internal security teams, but they're generally reported externally or by attackers. So that's for normal breaches. When you look at identity breaches, the situation is much worse in two ways.

One, the wall time tends to be much longer. And then two, almost always the detection that happens is not at the identity layer. It always happens further downstream. We could talk about this for a long time, but I only have about a minute left, so I'm going to skip. Happy to talk about the details of some of these breaches. So what are the root causes for all of these attacks, and why are attackers moving to identity?

One, the traditional methods through vulnerabilities and ransomware have gotten harder to pull off and much easier to detect for EDR vendors. Two, identity has a set of very interesting properties for attackers.

One, generally, tokens are stateless and they're not bound to any machine. So once you steal a token, it's yours to keep.

Two, you have very complex protocols for authentication authorization, leading to all sorts of valid corner cases that can be used by attackers to exploit authentication flaws that are valid but dangerous. And then three, as we all know, over permission are a real issue because some of the permission systems and entitlement systems are so complicated it's too hard to get to least privilege. If you think about AWS, AWS has like 15,000 entitlements and they are far from being the only system with that problem. So very quickly, what we can do to protect ourselves against these breaches.

One, I think it's really important to have a posture management overview of your environment. What can identities have access to, both human and non-human, what sensitive data they have access to, what sensitive actions can they perform, and so on. Often these attacks go, as I mentioned, totally unnoticed from an identity layer detection perspective. And this is because the IDP logs are often not enough to actually detect attackers moving laterally, and so having ITDR capabilities becomes really important.

Both for phishing and for persistence, MFA and FIDO credentials are obviously lips and bound better than nothing, but they're still by far not, they haven't stopped attackers and they're not going to stop attackers. So ideally driving to a situation where on the remediation side we have device bound tokens and then we overlay those with a ITDR approach to monitoring your environment.

And then lastly, as I mentioned, by far one of the biggest problems that we have in identity is the fact that once an identity is compromised, moving laterally and escalating privileges is extremely easy, and the reason for it is that we have too many identities with too many permissions. So getting to automated resizing of permissions and ideally just-in-time access for human is another key factor that you can use to protect your organizations after the initial compromise happens. Sorry for rushing through the slides, but this is all I have.

I'm going to be around, we have a booth upstairs, happy to answer any questions. Thank you everyone.