The Marauder's Map: Revealing Identity Compromise in Your Network [Introductory]

Many thanks, everyone. It's a pleasure to be here.

Always, this is one of my favorite events of the year, me being from a very much a security background. I love surrounding myself with the identity community because it's a more positive people. It's always exciting and always great conversation. So it's great to be here. And absolutely, as you see, my session itself is called The Marauder's Map. And I hope there's Harry Potter fans in the audience because ultimately we have one, including myself. That's two. So I'm going to take you through a bit of a journey. And it's a bit of reality check.

Every now and again throughout my career, I have moments where all of a sudden I'm like, we need an evolution. We need a significant change in how we have done things in the past. And this session is going to hopefully bring one of those realities to you. Why am I here?

I mean, I've been in this industry for a long time, more than 30 years. I know I look very young and youthful, but this is what 30 years results in. I've architected government's entire identity systems to the largest banks in the world's identity rollouts to country's education systems. Over 2 million plus identities I've had to deploy, manage, update, put controls in place. And over that entire time, I've seen lots of different innovations and creativities. But over the time we have to realize is that we constantly still see breaches and data breaches, ransomware, extortionware, data theft.

We see it constantly. And this is coming from last year's rising data breach investigation report that if you accumulate all of the previous 10 years reports, over 30% of the incidents were from credential and identity compromise, over 30%. If you even look at the instance that had identity attribution, that had an identity component, not just directly related, it goes up to 80%. So quite significantly. And we have to understand about why is it happening?

We sit here, we go through lots of discussions around technologies and controls and putting things in place to make it difficult, but they're still happening at a massive scale. And this really begs the question is about why is this happening?

Why, what are we missing? What data are we not looking at? There's lots of, we're always talking about collecting more data, more metrics, more attributes in order to understand about how do we understand an attacker on the network? How do you understand that an employee is doing something malicious or abusive? And we've got lots of data points. And even today, it's actually got more complex today than it has ever been in the past. When I started off, everything was centralized. Everything was in the mainframe. Everything was in central location.

Today we live in one of the most complex IT environments that I've ever seen in my entire career. We went from cloud computing, virtualization, bring your own device to bring your own identity. Now we're moving to bring your own agent and it's across multiple cloud environments, hybrid cloud, IIS, PaaS, home edge devices. And we have to understand about out of all of those locations and all of those data and attributes, we have to correlate it and try to understand where is the threats? Where's the attacks coming from? And most cyber attacks, they target the credentials.

Majority of them, they look at privileged users from those who's doing administration tasks to security workers, to help desk, to third-party supply chain. We just saw this week with GitHub through a third-party supply check for an employee who installed a marketplace extension that exposed the GitHub code. We see it from apps and APIs, robotic process automation, service accounts, agentic agents, to basically privileged data. We also have to look at not just the users and the privileges, but also the data and the actually sensitivity of the data.

And I guess the point where I have to ask the question is that when I've worked in this environment for such a long time, we really have to change how we look at identity. Identity is no longer just an IT system or solution. If your identity doesn't work in your business, each of you could not access your phones today. How do you do your work? How do you live your life? If you all of a sudden you went in to log into your bank account, you couldn't access your money, what would happen?

It stops, your life will stop. We have to treat identity like critical infrastructure, not just in countries, but in the business. It is a critical entity. And it's absolutely, as Enrique mentioned this morning, there is no perimeter, but identity is the connective tissue between everything that allows us to do our daily lives. It allows us to work, to operate, to function, to make decisions, to access money, to travel, to do our jobs. We have to treat it like critical infrastructure. And it has become a vital piece of the business. We have to treat it that way.

And when we look at all of these credential identities, we continue to focus at the controls. We continue to focus at secrets, passwords, passcodes, PINs, ephemeral tokens, all the different controls that we want to put in place to make sure only the authorized people can do the actions and entitlements that they're allowed to do. So we focus a lot on the controls. And I believe, after doing a lot of research, I've been working on a recent book, and last year I decided to look at all the previous data breaches that I worked on and what was common across all of them.

Why did those breaches happen? And it was one of those critical moments where the light bulb comes on, and I believe we've been looking at things the wrong way. And we have to have a fundamental change. We all in this room, I'm hoping that this is the start of an evolution that we have to realize that this is a wake-up moment, that we have to start looking at our organizations and identity in a very different light. Most organizations can tell you how many vulnerabilities they have. They've done vulnerability scans. They look across the network. They look at context.

They look at unpatched systems, systems where they haven't been rebooted, systems where there are misconfigurations. They can tell you quickly, when I go into a room with executives and CISOs, and I ask them, how many vulnerabilities do you have? They can tell you immediately. They can tell you when their patch window's gonna be. But when I ask those organizations, especially when it gets to identity, how many risky identities do you know that's in your environment? They don't know. Zero. They don't know. They can go to incidents.

They can look at incidents and tell you how many identity-related incidents they have, but they can't tell you how many risky identities they have. It's a very fundamental, different way of looking things. And most organizations, we've looked at traditional identity metrics. How many users do we have? How much MFA have we deployed across the environment? To how many number of public accounts, shared accounts? How many machine identities, service accounts, certificates do we have? How many inactive sessions? How many account lockouts do we have? We focus at very much traditional metrics.

And unfortunately, we look at it from an operational perspective. How is our identities operating? And a lot of these measurements is measuring the tools, not measuring the actual impact of the business, the operation of the business. It's measuring the tools themselves. Very traditional metrics. And I believe that we focus too much on failure. We look at the alerts and metrics and notifications and errors, and we focus it. I grew up in this industry for a long time. So when I look at, we had red light, green light, yellow, and that's what we, we looked at dashboards.

I remember, I was actually, this morning, looking at one of my old dashboards from CA Unicenter TNG, and I'm looking at that dashboard, and it was red light, green light. Red light meant, you know, something was a problem. Green light, everything's good. And that's how we're programmed, especially in SOCs, analysts. They're trained the same way to look at the color coding, to determine whether something they should respond to. So we focus too much on the failures. We focus on authentication failed, account lockouts, access denied. We focus a lot on the alerts.

And I can guarantee, every time, when I went through the logs and events in the metrics, it was an employee who was trying to do their job. And that's what we're stopping. We're not stopping the attacks. We're actually making it difficult for employees. That's why employees come back, and that's why we're seen as the team of friction, the team of no, because we're stopping them from doing their jobs. We focus on all these noisy metrics, the number of logins, failed login attempts, password resets, access requests, application account errors. We focus on a lot of what's red.

But once an authentication has been successful, an authorization has been approved, do we see that as a risk? Do we have trust issues with that? Because our job has been done. We got the employee access. We got them accessing the system. So I thought, let me take you through an incident. And I want each in this room, I've got four challenge coins. If you're familiar with challenge coins, I'll give challenge coins out. And challenge coins are very much not an identity-centric thing, but more of a security element.

I've got four challenge coins to give to people that can actually tell me what things to look for. So let's go through an incident. This is a real scenario, re-creation of a ransomware attack. And let's go through all the different scenarios. And hopefully in this room, many of you can tell me what things we should be actually identifying as potential malicious things that organizations should be looking for. So first thing is a phishing attack has happened. The accountant has had their password compromised. That password goes into a password list.

The attacker access broker validates that the credential actually does work. So we have a login successful attempt. The next thing, that credential sold onto the dark web. We now have a hands-on keyboard attacker who goes on to the public facing, basically login. They use that credential that they just purchased on the dark web. They log on successfully. I'll get there. I have to go through after it, once we finish it. Now they have access to an accountant's desktop. And on the accountant's desktop, what the people love to do, make their lives easier.

They store the credentials sitting in a text file on desktop. So now they're doing basically credential theft. They now have access to more credentials. What the browsers love?

Cookies, session tokens, and passwords. But by default, do they have security enabled? No. So now the attacker can simply go to the browser on this accountant's laptop, look at all the passwords and credentials and access to all of those other systems with the passwords in clear text.

Okay, next thing that this actually attacker does is it'll go and basically open up a command prompt and it'll now say, what types of privileges do I have? I'm an accountant. I'm an important person. I need to do my job. I need to access databases. I need to go and do transactions. I've got local administrator rights. So I'm not a local administrator because I'm an important person. The executive team, they want to get their salaries paid. I need to pay them. So now I'm a local administrator. What does that allow me to do? Download different scripts.

I can basically download this miscellaneous scripts. I can go to disable security. I can create backdoors with sticky keys. And all I'm doing is making registry changes. That's all I'm doing at this point. I'm just making registry changes with an administrator account locally on the system. Next thing, of course, sticky keys allows you to create backdoors, run as administrator. All I'm doing is making registry changes. Is that a bad thing with an authorized user? Next thing I'll do is now I've been able to disable security for a little bit. I'll actually go and make another registry edit.

This time I'm going to change the configuration of Windows that allows me to capture passwords and clear text or other hashes. So now I'd simply merge those registry settings. I'll now download a malicious application, run it. And now I'm able to extract passwords, both the clear text and also the hash itself. So you can scroll down here after running this for a while. The great thing is that while I'm showing a user account, a service account was running in the background, taking a backup of the database. And ultimately that backup exposed the domain administrator account.

So now if I want to be able to find that, I can do a remote RDB session, log on to the main controller with an authenticated user. And now I can create another user as a domain administrator as a persistent backdoor. So you can see here the login to the domain controller is working. And I now have access to users and groups. So I can create another user. And now if ever the accountant that I've actually compromised changes the password and locks me out, I have another path into this environment. And of course we can go back and we can say, okay, what else can we do here?

If I shut down the Windows RDP session, I can go and do psexec, run a command, just like the IT team do to do maintenance in environments, get access to the actual target system. I can do pass the hash. I don't even need the password. I can just have the hash and log into that system. In this entire example of an attacker using compromised credentials through phishing, what do you think was the indicators of compromise here? Your challenge coins are not up for grabs for anyone who gives the answer. What's your suggestion? Okay.

Are you monitoring every change to the registry in your organization? No, but a good thing to look at. I'm coming from a unknown or unique location. Okay. You get a challenge coin. How many of you look for every identity, authorization, authentication, and connect it back to all IEP addresses connected with that identity? First time, the first connection. Anyone else? Any other suggestions? It's an authenticated user. Those credentials revolted, those credentials revolted, but they're sitting on the desktop as well. Multiple locations.

So, let's go through. As we go through, there's still a few more challenge coins. We've got three more. Let's go through. This is what the log file looked like.

Success, success, success, approval, authorized. Approval, authorized. It was a stolen credential. Everything that that actually attacker did appears in all the logs as authorized, authenticated actions. And that's the problem. We're looking at failures. We've trained the teams to go and look for errors here, to look for application failures. The only thing, there was actually a couple of things in this entire process that identified that this was a malicious actor. And you got the first one is the originating IP address.

There was three logon attempts, two coming from Tor exit nodes and one from a NordVPN. That was the only things that indicated that this was coming from a malicious location. The second thing, of course, so we're looking at IP addresses. One of the most critical things that we can do if we capture and associate all authentication authorization requests, not just at the origin, but at lateral moves and in every pop along the way, we had to connect those together. It's one of the few things we can do in order to identify malicious abuse of authorized credentials or stolen credentials.

Context is key here. Because I mentioned, we focus too much on the failures and alerts. So it really means we start having to look at location. We had to tie location, proximity.

Yes, you can spoof it. There's many ways of spoofing it. You can do lateral moves internally. But we have to connect authentication, identity connections to the IP address. The next element is the processes associated with that execution. We have to create baselines of normal usage. Because in this case, what we're finding here is there's a couple of processes that have spawned up, which are typically known associated with IT team accounts, but not accountant accounts. So why is the accountant launching PS exec processes when it's not something they commonly do?

We have to look at suspicious process behavior from identities and credentials that commonly don't do those tasks. The next thing we have to look at is browser agents and browser associations and common browser context.

Yes, they can be spoofed. But if a user has been using Firefox and a specific agent, and you can look back and maybe they have different versions, we can assume that maybe it's upgrades, but all of a sudden they come back and they've got Chrome or Opera or whatever other browser type or agent. We should be basically seeing that as a potential context trigger that allows us to investigate. Time is one of the critical things here. Users tend to do things at certain times of the day, their work times, when they're traveling, when they're having meetings and association.

The only other trigger in those event logs was the time of the action. We also had to correlate time, browser, processes, and origin source of IPs to the context of the identity to create baselines. We had to deal with applications. One of the things I launched onto that accountant identity was a command. That's not a common action that that accountant does. We have to correlate that back to, is this a common application association? Is this the first time that accountant has ever done it? Is there a way we can go and re-verify, re-authenticate that this action should be trusted?

The next important thing is data, associating the data attributes and data assets to the identities as well. We need to create context. And just like in the world of Harry Potter, when an identity is compromised, it's just like somebody having polyjuice potions. They take the polyjuice potion and they turn into the person that they're trying to basically pretend to be. And that's what we're basically facing. In the attack world, the attacker has polyjuice potions and they've got lots of it and they're using it. So that means our defense, we need a marauder's map of indicators of compromise.

So I've created this marauder's map, which is the ideal thing of all of those contextual associations. Meaning when an attacker takes the polyjuice potion and steals the accountant's identity, we need to correlate all of these. We always look at them as individual pieces of data. We look at ITDR as failures, but we need to start thinking about things as what success is suspicious success.

To time, to location, to applications, to the actually common paths that they take, not just across the castle worlds of on-premise, but also to the magical clouds as well, up in the right-hand side. We have to start looking at this as suspicious activities. And it really means we have to start asking the right questions of why is this successful and is it truly doing the actions and behavior that it should be doing? We have to start questioning all of these because context matters. And really the basis of what I'm talking about here is zero trust. Just doing it for a photograph here.

It's really the foundation of zero trust, but we've always taken the approach of zero trust as something that is creating problems for the business. We also have to look at this as how to make sure while we're approaching zero trust, it should also be zero friction. It should be usable. It should be something that we can all leverage. So it should be something that empowers the user and ask the right questions to make sure that their actions should be trusted. Ultimately, our goal here is to reduce risk, not to stop the employees from returning to their job. And that brings me to an end.

I know we're right at the end of the session. If you would like to hear more from me, I'm the Chief Security Evangelist and Advisor at Cizut Segura. I've got lots of white papers and eBooks that if you want to go and download. And I'm also the host of the Security by Default podcast, which this month is one year old with 30 plus episodes now and over 6,000 downloads and amazing guests, including Vlad and Martin and others who's been on the podcast. So I do recommend going and take a listen. If we have time for questions or probably not, are we going to move it to the panel session?

We'll leave it to. Thank you very much, Joseph. First of all, round of applause, please. Thank you. I have a rhetorical question for you. You don't have to answer it and we can continue. But is it still the scope of identity security or is it just the whole of security? It is the scope of identity security. The reason why is identity has the information. Security has the knowledge about what to look for. And that's why it's important that we can bring those both together. Because identity, it's where all the data is. It's about all the connections and attributions and context.

It provides me the context. I need to overlay that with the attacker techniques and also create the understanding about what is normal behavior of an accountant's account versus what's an attacker abusing that account. And we have to overlay it. So I believe this is a convergence and not just within identity security, but also AI. We have to bring all of this together because we're no longer here protecting IT systems, we're protecting the business. And to do that effectively moving forward means the convergence of all those teams into one collective.

Does it mean we have to replace our socks with eye socks or something, AI socks? Not necessarily. I believe that more AI helps us do, I actually use AI in a lot of the gathering of the research of the indicators of compromise. And what I find is that it helps me go faster. So I believe that what an AI sock is, is an extension of an analyst to help them move at AI speed. So it means empowering the user in order to use their intellect and use their experience in order to make them operate like a junior analyst with AI will operate like a third level senior analyst.

So it's empowering the person to move faster, but also give them, we should be looking at AI sock as a skill rather than an agent. That means that it's what skills am I enhancing the analyst to be much more extensive and much more valuable.

Right, great. So let's continue our panel.