A (16:25)

So SpectreOps kind of comes out of a group of red teamers. And one of the things that we noticed over time was that as you're conducting an operation in a network environment, there was kind of this guess and check kind of approach to how you would do things. You would gain initial access at some kind of arbitrary starting point that would be derived from phishing, or maybe you have some sort of poison link that you make available and you gain access and then you would have control over a user identity, whoever clicked on the phishing payload, for instance. And so in the process of doing that, we realized that if we collect all that information up front, we can build essentially Google Maps for the environment which says, I have this origin or starting point, I want to go to this destination. That's whatever my objective is. Can you show me the different routes that are available to me? And then that's kind of like the guide. It's almost like MapQuest for, for the attacker. And those, those routes we call attack paths, right? So it says, okay, you need to laterally move to this computer, you need to dump the credentials and take control of this user account. And then you, you move to this next computer, so on and so forth. Now, the attack path management component of that is if you could predict one route, then what would happen if we were to say, we don't know where you're going to start? Because the starting point, like I said, it comes through phishing and things, vulnerabilities, all that kind of stuff. Typically it's going to be relatively arbitrary, but the destination is usually somewhat predictable, or maybe even if the destination is not predictable, organizations can typically identify the things that they want to protect the most. Right. So not everything's kind of created equal on the how much security should we put in that? And so what you can do is you can say, show me all of the attack paths, all of the routes from any arbitrary starting point to some destination that I define. Right. And so you would say, show me all the attack paths to take over domain admins, and the attack path management component of that is. Okay, now that we know all of the routes, what configurations are creating the most kind of risk for us? Where can we make configuration changes that reduce the number of routes that attackers have to take control of those more protected users or computers or relationships or resources?

B (18:31)

Well, so help me understand, when we're talking about attack path management, why is identity such a central focus here?

A (18:39)

Yeah, so kind of an interesting thing that fell out of all this is that the attacker is always operating in an identity context. And actually the way that they traverse and gain access is they kind of context switch from identity to identity. So we typically use an active directory kind of like example, but this applies in Azure and AWS and all kinds of clouds or Even things like GitHub, these point solutions in the cloud. What we see is that when you phish a user, you typically will start in the context of two identities. You actually have two identities simultaneously. You have the user that clicked the phishing payload, right? That's John in accounting, for instance. And then you have the computer in which that phishing payload was clicked, right? And so you have these two identities. These identities are granted access to resources. Those may be computers, Those may be the ability to change the password of a different user. It may be the ability to add a user to a certain group membership, for instance. And what the attacker is doing is they're saying, does my current identity context have the ability to perform whatever action or have whatever action on objectives that I desire, so to speak? If not, is there another identity that I could take control of that would grant me the ability to get closer and closer to whatever my actual objective is? And so that's kind of like what they're doing constantly is trying to take control of different resources which grant them access to other identities, which then grants them access to more and more resources? This is the type of attack is called the identity snowball attack. The interesting thing is that as I'm changing from one identity to the next, right, I'm taking control of some additional identity. It's not that I'm losing access to everything that I had control of previously. It's in Addition to, it's an aggregation type of attack to where I take control of new identities, new. These could be users, they could be computers, they could be service principles, it could be all kinds of different things, non human identities, so on and so forth.

B (20:33)

Well, I know you've said that attackers don't go through your tools, they go around them.

A (20:37)

Yeah.

B (20:38)

Can you unpack that for us? What exactly does that mean?

A (20:41)

Sure, yeah. So this goes back to a little bit of the kind of red teaming background. Right. So for those that might not be familiar, a red team is kind of simulating an attacker for an organization to help them understand kind of where their security controls work, where they might not do what they expect, that kind of thing. And one of the things that we notice is that from the attacker's perspective, there's often the organizations that we're working with, the defenders, the security team, they often have expectations of the tools that they put in place that are not calibrated to what those tools were actually built for. And what we find as, as, as red teamers is that account, once it's logged in, maybe I can't steal the password. And even if I do steal the password, it might rotate around. But when I log in as my administrative account, the attacker comes to my computer and they can steal my, my token, my Kerberos ticket, so on and so forth, and then they have control of that account, even if the password changes. We go around your tools, which is basically the, the tactics and techniques that the attackers are using are essentially changing based on the types of tools that are in the environment and how those tools actually function.

B (21:49)

Well, help me understand here. So when we're talking about attack path management, how does that differ from traditional identity governance or things like least privilege?

A (21:59)

Oh, good question. Yeah. So I'll start with the identity governance idea. So identity governance is super important. So there's this, this idea of life cycle management, right? We need to make sure that when an employee leaves a company where we turn off all their accounts and we kind of get rid of those, we need to make sure that we're giving users the privileges that they need to do their job. One of the problems that we see between identity governance and attack path management is identity governance kind of has like a one hop kind of view of things, right? So it's like you have Bob in finance and Bob is going to, he needs access to some finance system to be able to write to a file share. For instance, maybe Bob needs access to log into a computer, so on and so forth. So you Kind of you're granting those that access in a way to where it's only one hop. You're not looking at kind of what are the downstream consequences? I grant Bob access to a file share. What can Bob do with that access that maybe was unintended? What are the unintended consequences or externalities of that access attack? Path management is taking the current access landscape so all the permissions that have been granted and then asking questions like if I have access to this file share and then there's a file on that file share that has a password in it that would allow me to compromise the user account or the identity that's associated with that password and that gives me access to additional resources that maybe the administrator that was operating from the IGA or identity governance perspective might not have considered. That's the idea of the difference. Right. What are the downstream consequences of I give you access to a computer? Well, there's other users that are logged into that computer. If I have administrative control of that computer, I can now steal those users accounts and do whatever it is in the context of those alternate identities. Now from the, the least privileged perspective, there's, it's interesting. I actually did some research on least privilege relatively recently and went back and tried to find the first reference to the phrase least privilege that I could in the, in the literature. And that actually came out in 1975. There was a white paper. So 50 years ago somebody was talking about least privilege and we're still struggling with it now. One of the things that I, I kind of make a joke about how we typically don't actually operate with least privilege. We, we operate with enough privilege, which is I identify that you need to do a operation A, B and C as part of your job and I give grant you permissions until I can validate that you can actually do A, B and C. It's often very difficult for us to know in advance what permissions you actually need to do that. And so I kind of like just ratchet it up a little bit and give you more and more permissions. And what we find is that most organizations don't do that second part, which is validating that you can't do things that are unnecessary for you to do your job. And that's actually very difficult. Just by the nature of kind of what default permissions are and the granularity with which permission granting is available and things of that nature is the whole.

B (24:50)

You can't disprove a negative.

A (24:52)

That's right.

B (24:54)

Well, let's talk about risk. I Mean, I've seen in some of your publications this phrase, visualize risk the way adversaries do. What does that mean?

A (25:04)

Yeah, so we have, we have a whole research team at SpectreOps where what we're doing is we're trying to identify what we call escalation primitives. Right. And so this is where a real simple example that, that's fairly obvious I would say, is if I have the ability to change a user's password, that means I have the ability to take control of that identity. Right. And an attacker, attacker would look at it from the same perspective. Right. And so what we're, what we're constantly doing is thinking about what are the ways that the different permissions that are being granted throughout the environment facilitate our ability to take control of additional identities and therefore access more and more resources. So we're thinking about it not necessarily as an administrator, which is how do I grant people access to do their job, but we're thinking about how does the access that's granted to people to do their job facilitate an attacker's ability, somebody that's acting in bad faith, to take control of additional resources that maybe were uninterrupted, unintentional. And one of the things that we, that we realized is that they were also using Active Directory as a input into Okta. So you create users in Active Directory, you set their passwords in Active Directory and that that is synchronized up with their OKTA server. And so that means that if I get control of your user account in Active Directory, I have control of your user account in Okta. But because they are using OKTA as a single sign on identity provider for GitHub, that also meant that I have control of your GitHub account and access to read or write to any of the repositories, code repositories that you have that you would have access to in GitHub. There's this weird thing to where you might have a GitHub administrator who understands that Okta is feeding that through SSO. But what they don't understand is that Okta is dependent upon Active Directory, for instance. And so there's this dependent, we call it a security dependency down downstream that the GitHub administrator is unaware of and therefore is not accounting for in their overarching kind of like security policy or security operations.

B (27:03)

Well, how does it work? I mean, when we're talking about the mapping and the prioritizing of these attack paths from a practical point of view, how do you go about that?

A (27:13)

Yeah, so one of the things that we run into is, in practice, large organizations will have hundreds of millions, if not billions of attck paths to take over, say, tier zero, which is this, this group that includes an active directory, domain administrators, domain controllers, other highly privileged accounts. There's a number of different kind of assets that fit into that category. So if you have a billion attack paths, one of the interesting things is we do red teams. And what we kind of would find is that you would perform a red team. And what a red team is doing is they're traversing or taking advantage of 1, 2, maybe 3 attack paths during the course of the operation. And you report that out, and the organization that you're working with goes through and fixes those three attack paths. The problem is that there's a billion attack paths. And so you imagine that there's. How many times you would have to conduct a red team and then do all the fixes before you would actually resolve those issues. What we try to do is we try to say, hey, there's a billion attack paths. So there's a billion different routes for any user to get control of your tier 0 assets, your domain controllers, but what are the individual permissions that kind of, that everything funnels into? And so we say that there are certain configurations that are choke points or the major players in facilitating these attack paths. And so we direct your team or your identity management team to those specific configurations and say, hey, did you know that the authenticated users group, which represents every user in your active directory domain, has admin access to this computer? And did you know that a domain administrator is logging into that computer? That means that every single user in your environment has the ability to become a domain administrator because of that one configuration. And so then we kind of point you in that direction and say, these are the steps that you should take to remediate that configuration and therefore reduce that risk.

B (29:06)

Well, when we're talking these kinds of numbers, things that are literally in the billions, I suspect there must be collaboration at play here. I mean, people have to, this isn't. You can't silo these things. The teams have to be in good communications.

A (29:23)

That's right, yeah. So vulnerability management is a discipline that a lot of security organizations kind of have a good grasp of. There's kind of a, an organization structure that facilitates that program. We find that a lot of times this attack path management kind of falls into that same process where you need to have organizational visibility of who's responsible for what environment. This gets even more complicated when we start venturing out. We have a new capability called Bloodhound Open Graph. And what that allows you to do is expand the attack graph to account for different Systems, things like GitHub, things like Snowflake, things like VMware, VCenter for instance. And this allows you to see these attack paths through all these different systems and how they're interconnected and that kind of thing. And so there needs to be kind of a central organization that understands attack path management, but then knows who they need to talk to to direct these kind of like remediation steps to. Right, because the Active Directory administrators might not have access to make the changes in GitHub that are necessary to reduce the exposure of your code repository. That's for your enterprise app, for instance.

B (30:33)

Where do you suppose we're headed here? I mean, where is attack path management going in the future? What's the horizon look like?

A (30:41)

Well, I think the thing that we are really interested in are what we call hybrid attack paths. So these are these attack paths that go across system boundaries, right? So the kind of the classic example would be this user synchronization from Active Directory to Microsoft Entra, for instance, to where if I compromise your Active Directory user, I now have control of a user in your Entra account. And sometimes we would see to where an unprivileged Active Directory user would be synced with a privileged Entra user. And so now there's this disconnect between the relationship there. What we're finding is that in these large organizations the interconnectedness between these systems is tremendous. And so the interconnectedness is where all of this gets really interesting. Because attackers, they could get access to GitHub, not have the ability to do the thing that they want to do, and then they could go back to Active Directory, move around within Active Directory to find a different user that has more privilege in the context of GitHub and go back up into GitHub. And so there's this, this ability to kind of like traverse through all these different systems, typically going back to whatever your system of record is. Right? So that's a lot of times it's going to be Active Directory, but in other cases, maybe more modern environments, these Silicon Valley startups that have like a Mac based environment, maybe they're using JAMF instead as kind of like their system of Record or Okta as their system of record. And so you're constantly trying to figure out how do I get back to the system of Record so that I can have more access to more users and then go back into the systems that actually hold the data and then you. You kind of go from that perspect.

B (32:18)

That's Jared Atkinson, Chief Technology Officer with our N2K knowledge partner, Spectrops. What's your 2am Security worry? Is it do I have the right controls in place? Maybe? Are my vendors secure? Or the one that really keeps you up at night? How do I get out from under these old tools and manual processes? That's where Vanta comes in. Vanta automates the manual work so you can stop sweating over spreadsheets, chasing audit evidence and filling out endless questionnaires. Their trust management platform continuously monitors your systems, centralizes your data, and simplifies your security at scale. And it fits right into your workflows, using AI to streamline evidence collection, flag risks, and keep your program audit ready all the time. With Vanta, you get everything you need to move faster, scale confidently, and finally, get back to sleep. Get started at vanta.com cyber that's V-A-N-T A.com cyber.

A (33:40)

This episode is brought to you by State Farm.

B (33:43)

Listening to this podcast Smart move Being.

A (33:47)

Financially savvy Smart move Another smart move Having State Farm help you create a competitive price when you choose to bundle home and auto bundling. Just another way to save with a personal price plan. Like a good neighbor, State Farm is there. Prices are based on rating plans that vary by state.

B (34:03)

Coverage options are selected by the customer.

A (34:05)

Availability, amount of discounts and savings and eligibility vary by state.

B (34:17)

And finally, at a lakeside bitcoin conference in Lugano, a handful of jittery investors ended their weekend not with price forecasts but with a lesson in chewing through zip ties. Their instructor, former Royal Marine Pete Kale, assured them that teeth beat plastic, though it will bloody well hurt. Such is life in crypto's wrench attack era, where kidnappers no longer bother with elaborate hacks when a simple threat of violence does the trick. With Bitcoin's surge minting flashy nouveau riches, abductions have climbed to more than one a week, prompting entrepreneurs like Alina Vranovo to host €1,000 counter kidnapping workshops, complete with grim PowerPoints and stern admonitions. No Lambos, no bragging. And beware beautiful strangers who find Crypto Bros. Irresistibly fascinating. Between tips on ditching obvious bodyguards and turning umbrellas into weapons, the trainers reminded attendees of one final truth no digital fortune is worth a shattered clavicle or worse. And that's the CyberWire. For links to all of today's stories, check out our daily briefing at TheCyberWire.com we'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to cyberwire2k.com N2K's senior producer is Alice Carruth. Our Cyberwire producer is Liz Stokes were mixed by Trey Hester with original music by Elliot Peltzman. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher and I, Dave Bittner. Thanks for listening. We'll see you back here tomorrow. Sam.