A (5:16)

Gerald, I just realized that, I think about the same time you released this, you also posted something on LinkedIn about how identities fall in two categories, identities addressed and identities in transit. Is this somehow related to the Open graph concept? Like, what are these two things? It's another concept to classify identities.

B (5:36)

Yeah. So SpectreOps started as a red team. So one of the things that I ran into as kind of like somebody who was observing this is we often run into this situation to where organizations will protect usernames and passwords, and they're very interested in that. They'll add different security controls like multi factor authentication, they'll do password vaulting, password rotation. And one of the things that I observed while watching my colleagues performing these red team operations was that they often didn't target the actual password itself. They often would target things like access tokens or Kerberos tickets or even browser cookies, kind of like in a more modern context. And it always seemed like when we were talking about what you should do to protect identities, the advice that we would give would not line up with the actual actions that I would watch red teamers take or that I would see in thread reports. And so then I started to think about how can we frame this so that it actually matches the experience that we're having. And I realized that we have this idea of data at rest and data in transit when we're talking about data protection encryption, right? So the manner in which you, you protect data on hard drive is different than the manner in which you protect data as it's transferring over, over the wire, right? And so we're over the network. And so then I was like, okay, well we have this well known kind of paradigm or dichotomy of at rest versus in transit. And then I realized that we could take that same idea that a lot of us in information security are already familiar with and apply it at the identity layer. And so the idea is that you have identities at rest this is like a user account that you establish. Maybe that's in your active directory domain, maybe it's in your intra tenant, maybe it's in your snowflake tenant. You've created an account, right? There's a Jared account and there's a password associated with that. And that account is kind of static. It's potential energy almost. And it has this idea of like, maybe it's assigned to groups, maybe those groups have different privileges or permissions or entitlements on different resources. But it's not being used, it's not active, right? When a user logs in, they go through this authentication process that may include things like multi factor authentication and may require password, so on and so forth. And then you establish a session and that session kind of takes a form differently depending on the system that you're interacting with. It might be in like a Windows AD perspective, it might be an access token, but when you're talking about GitHub, it might be something like a browser cookie or maybe some other type of token. And attackers can target those sessions differently, right? So it's a matter of figuring out where is this session established, what computer is that session established on, and then you can target that session and now you have access. You don't even need to know the password. You don't need to use multi factor authentication. You kind of bypass all of those different controls. And so one of the things in the Bloodhound graph is we want to represent both, like, what is if I steal this user's password and I log in, what do I have access to? But also where is this user logged in to? Where if I have control of a computer, who's logged in on that computer and what systems are they logged into and how can I steal their session so that I can access those systems in the same way that they would?

A (8:41)

So when you monitor these identities in transit, do they have a particular shape in your bloodhound result graphs? Do they help attackers broaden their attack in ways that compromising a static account credential password didn't before.

B (8:56)

The way that we represent that in the Bloodhound graph is through the has session edge. And so kind of the classic example that you would see would be you have a computer and then there's an edge that says a user has a session on that computer, so the user is logged in. And that implies that if I have administrative control over that computer, I now have the ability to take control of that user in active direct, like in the typical active directory context. That would be for Instance, I could do token impersonation, right? So if I'm an admin or system on that computer, I can impersonate any user that's logged into that. Another way that you might go about doing that is through process injection, right? So if a user has a process running on a computer, I can inject into that process and now I'm assuming their identity as a result of that. It's a little bit more complicated when we start talking about these higher level kind of systems or these cloud systems, because now we're talking about like browser cookies. And currently Bloodhound does not have like a generic way to collect browser cookies. And so that's something that, like on the research team we're constantly trying to find new ways to do that. But through Open Graph you would be able to use something like the has session edge to be able to represent the relationship between this user has logged into Snowflake on this computer. Now there's a Snowflake session, so there's a Has session relationship between the computer and a Snowflake user, for instance.

A (10:17)

So from what you've described here, there's a lot of attacks that are not particularly traditional in the way that they were before. Like you compromised an Azure identity and then you just pivoted to those systems. Related to Microsoft gear. How much of these hybrid attacks can you get from Bloodhound? Is there a point where Bloodhound can't see anymore and just you need to go into those applications logs? Is that something you recommend? Like, okay, our visibility stops here. You need to go check that system's logs.

B (10:49)

In particular, there's, that's a, that's a great question. There, there's some aspects to where, so I, I come from like a detection background and there's, there's this weird dichotomy to where you often will observe activity either on the client side or the server side and there's value from one or the other, right? So like from the client side a lot of times you can see like the command line parameters that cause the activity to occur. And that's really useful. But it's. The attacker has control of the client side and so that it's, it's more prone to obfuscation or manipulation. And so it's maybe more likely that an attacker will fly under the radar if they, if they know what they're doing. As opposed to the server side, you're going to have kind of a more trustworthy source that's telling you this is what happened, but you're losing A lot of context of what actually came through. The same kind of exists in the context of these hybrid attack paths to where a lot of times you can start to see from the. Let's say I'm using intra as single sign on for. Single sign on for. I'm just going to use GitHub again, just as an example, but I'm using intra as single sign on for GitHub. The relationship is that GitHub or Entra is the provider for GitHub. And I'm going to be able to see different bits of information or detail depending on what side of that relationship I'm observing. So for instance, on the intro side I'm able to see these users are registered for single sign on into GitHub. And so now as an attacker I might be able to say, okay, well, I want to target those users because I know that they have some relationship with GitHub, let's say GitHub, you know, there's some ultimate objective of mine that's in GitHub. I'm going to, I'm going to look at who has the single sign on relationship into GitHub. But often, and this is not always the case, but often I'm not going to know what type of access they have on the other side and the GitHub side I'm going to know that they have some relationship, but I'm not going to, for instance, know which repositories in GitHub they have write access to, for instance. And so from that perspective, I'll have to go into GitHub and do the enumeration there and say, hey, can you tell me about all your users? Can you tell me about what teams or groups they belong to? Can you tell me what permissions those teams and groups and roles have, have access to on which repositories? And, and so it's, it's beneficial to collect both sides of the relationship. But if you start on kind of the provider side, you're able to say, you're kind of able to narrow down who you should be interested in, maybe what computers those users are logged into. So that gives you this path that you should, you should target a certain computer. But then you're going to kind of do this. I think of it as like the fog of war in these strategy games to where you're constant, like I have access to, you know, Justin's compute, Justin's GitHub identity. I don't know what Justin has access to on the GitHub end, but what I'm going to do is now that I have control of that user, I can go and enumerate and say what do I have access to? And it'll give you this idea and maybe it'll give me a more clear understanding of what, not only what Justin has access to, but what these other user accounts are. And that will allow me to kind of like go back down into intro and say, okay, I need to readjust. Maybe it's more beneficial for me to target Ravi as opposed to Justin. Right. And that gives me an opportunity to kind of adjust and gain more information each time that I go over that hybrid relationship. So it's kind of like a guessing without the full picture from GitHub. It's kind of like this guess and check type process, but it's an educated guess and check as opposed to kind of like a completely random process.

A (14:08)

And with the addition of Open Graph in your product, now you cover even more Attack Surface. How do you tell your customers and companies what attack paths to prioritize and remediate first? Because I understand they're going to receive the results of a bloodhound scan. They're going to have some issues highlighted in the report. Depending on the size of the company, it's going to be a long report. Like the larger the company, I understand the larger the attack service. How do you tell them, look, this is important. Patch this now. Tell them first about to remediate cookies and SSO tokens or to apply the proper permission to specific cloud systems. What's the tier list of the danger tier list in your results?

B (14:54)

Yeah, it's a great question. I think maybe it's worth kind of explaining to the listeners. Maybe the difference between the Community Edition, which is our open source version, and the Enterprise Edition. In the Community Edition, you have the ability to ask questions in the form of cipher queries or maybe like kind of a point A to point B attack path search. But you don't get findings that say these are the problems that you need to actually fix. Right. And in the Enterprise Edition, what we're doing is we're identifying by default your tier 0 assets. And tier 0 is kind of this idea that exists in all the different platforms of who has the keys to the kingdom. So in an Active Directory context, that would be like your domain administrators, your domain controllers and some adjacent groups and resources. The idea is that if I get control of a domain administrator account, I have access to anything within the context of that domain. And so it doesn't matter how well you protect those individual resources, because once I get domain admin control, I now have access to those resources. The same exists in intra with global administrators. The Same exists in GitHub, for instance, with, with your organization administrator. So this is kind of just a common concept across all these different platforms. And so what we do is we identify findings. And these findings are kind of the attack paths that facilitate control over these Tier 0 assets. And we tried to identify what are the different ways that attackers can get there and then how would you clean those up? Now your question kind of was very interesting because it's in a large organization there's going to be several findings. We're talking, it could be thousands of findings. And so the question is, how do you prioritize which ones you should pay attention to? We have this metric which we call exposure, and that is basically what number of principles a principle would be a user, a group, a computer, so on and so forth. Which principles in the environment have the ability to take advantage of this attack path? Right. And so in some cases it's going to be 100% attack of users have the ability to take advantage of this attack path. In other cases it might be 1% of users. And so we generally tell people we should prioritize those attack paths that have 100% exposure, because that's kind of like the biggest attack surface that you can start to control. The next question is how do you, let's say you have multiple hundred percent exposure attack paths, how do you prioritize between those? And the answer is there's certain attack paths that we have experience with that just seem easier for people to have the confidence that they should clean up. One example would be just as a kind of a throwaway would be if domain users, which is a group that controlled, that includes everybody in the domain, has admin to a domain controller. That would be something that's very easy for us to get rid of. A lot of. These attack paths originate from kind of like the domain users or authenticated users groups. And those are going to be a little bit easier for us to clean up. After that, there's some logging and some different kind of investigation that has to go into determining how we clean these up. Now a really interesting kind of development in how we're looking at findings is this inclusion of something that we call privilege zones, which is where you can identify any arbitrary group of assets and say these assets are really important to us. And so we want to kind of look at what are the attach paths into this particular privilege zone. One example that kind of comes to mind is we had done a red team with an airline, and they had asked us to target their loyalty system. And so we did that, and we were successful in gaining access to that system. But the interesting thing would be, what are all the different ways that attackers can gain access to this loyalty system? Maybe even more importantly, what is the loyalty system? Is it just a server, like a web server, or is it a database? Or are there certain users and groups that are associated or affiliated with that loyalty system that these organizations should protect? And privilege zones gives you the ability to kind of identify what those. Those different resources are, whether it's a database, a web server, user, so on and so forth. Kind of wrap those into a group, into what we call the zone, and then you can start to map out the attack paths that target that as kind of like the endpoint. And then you would be able to reduce the exposure of that as well as, like, this Tier 0 in addition to that Tier 0 kind of cell.

A (19:05)

Okay. That's the perfect way to end it.

B (19:07)

Awesome.

A (19:07)

Thank you, Jerry.

B (19:08)

Yep.