Episode 16: Special Guests Daniel Heinsen and Julian Catrambone

00;00;12;00 - 00;00;31;23
Jared Atkinson
Welcome back to the Know Your Adversary podcast. I'm Jared Atkinson, I'm Justin Kohler. And today we're joined by Daniel Heinsen and Julian Catrambone. They're going to talk with us about AWS and the new coverage that we have in BloodHound and BloodHound Enterprise. So welcome, guys. Thanks. Yeah, thanks. So I think maybe we could start off by talking about kind of the background.

00;00;31;24 - 00;00;51;14
Jared Atkinson
Daniel, I know you've been working on AWS, in particular for a few years now, and we're kind of culminating by finally with Open Graph and all of the different capabilities that we've added to BloodHound, the ability to integrate kind of a picture of the attack pass in U.S. into your overarching BloodHound graph. So maybe give us a little bit of a background of kind of where you started and how you've come where you come from.

00;00;51;15 - 00;01;11;03
Daniel Heinsen
Yeah. So a few years ago we looked into getting AWS into something like an attack graph, and we initially found that it's like quite a bit different and like pretty difficult. Mostly due to the way that like, you know, policies work and things like that. So the, the first step was this tool called Ape Man that we did a couple of years ago.

00;01;11;05 - 00;01;29;26
Daniel Heinsen
And that was a cool proof of concept because it did it, it effectively built an access graph. Not in the tech graph. And so we put it out and I think it's a great technical tool. But, you know, the the comments we always got back was like, great, but like, you know, how do I get my attack path?

00;01;29;29 - 00;01;48;03
Daniel Heinsen
And it's like, well, you got to run this query and you got to run that query. And it's it's not very user friendly. Yeah. Yeah. So it was it was a very in-depth technical tool. And I know we wanted to expand on that. So then I think we got into talks of how do we get this into BloodHound and how do we show actually like actual effective attack paths.

00;01;48;05 - 00;02;16;23
Justin Kohler
And Julian, how did you get your started. Like like how did you come into this? Yeah. So, I actually left SpecterOps three years ago and I did two years at Salesforce on their red team. And their stack is largely cloud based, largely AWS based. And all of our assessments were essentially starting from a low, privileged context and maneuvering through several different accounts to ultimately get to your end objective.

00;02;16;23 - 00;02;35;28
Julian Catrambone
And then coming back to SpecterOps is when I actually got to meet Daniel again. I think I maybe met you for a month before I left because. Yeah, yeah, yeah. And he had been working on Ape Man, which was incredibly interesting. And the, the level of expertise that they get, SpecterOps at that time was siloed with AWS.

00;02;35;29 - 00;03;02;18
Julian Catrambone
And so a lot of the when it would come up would come to the same few people. Which gave us a good, a good place to experiment in a lot of different environments to build this tool. And honestly, I think what's most interesting about it is the impact that you can have, right, in these cloud environments and mapping that out and the you see the the clients face, right when you show them some of these attack graphs or some of these paths that you were able to execute, but also makes it all worth it, right?

00;03;02;19 - 00;03;19;20
Julian Catrambone
Like, you can see it and try and close that. And we'll get into some of those examples. Right. When we talk about like, just like in this early phase of like getting with design partners and testing like this out with them, there's some really cool stories. Before we like, I remember the first internal discussion we had about this.

00;03;19;21 - 00;03;38;19
Justin Kohler
I mean, we always knew that we did stuff in AWS, but I think the biggest thing that we saw was like last fall when you guys had this really cool attack path from GitHub to AWS, and it was like, oh, this is severe, right? Like, and you could see it. And I think that, I mean, personally, it was like, wow, this could be really significant.

00;03;38;22 - 00;03;51;17
Justin Kohler
And I think it was just articulating things that like, honestly, you guys both knew although the whole time. But it was now was put it into a pretty picture for the rest of us to consume. So I'm not was that was that kind of when it clicked on and clicked in for you or was that just another example?

00;03;51;20 - 00;04;10;17
Julian Catrambone
Yeah, I think that was the first open graph had just come out and I had some free time because we had accomplished our impact objective, like right after finding the attack path. And honestly, I was just curious. I was how how far does this go? How many other principles are like, would be vulnerable to this style of attack?

00;04;10;24 - 00;04;21;25
Julian Catrambone
And I thought, well, hey, open graphs thing, let me just run the collection and get it in the right format and see what shows up. And what ended up showing up was quite scary. Yeah. And

00;04;21;27 - 00;04;36;08
Justin Kohler
And spoiler like, we can't go into details, obviously, but like blocks are short. Every employee of this company had the ability to write to a repo, and it was configured in a way that you could get into AWS, and then you could ratchet up through AWS and do nasty things in order.

00;04;36;09 - 00;04;51;18
Julian Catrambone
Yeah, it was essentially, every employee had pushed control to their S3 bucket that backed the Debian installer and the like brew installer, basically their whole CI CD pipeline for the their product. It's quite scary.

00;04;51;18 - 00;05;10;07
Jared Atkinson
And the cool thing was that during the red team, you found one path or maybe a few paths, right? And then you're able to say, this is a pattern that we want to like, kind of extrapolate and see throughout the entire, you know, configuration of GitHub and AWS. And it was significantly worse than just one path. But trying to find that manually step by step would have been very time consuming.

00;05;10;09 - 00;05;32;16
Julian Catrambone
And it's exactly what happened. It's, it's very complex, right. Because we're talking about multiple layers of policy evaluation and accounts and roles and, each step and each one of those layers has controls around it. And so finding the path manually took us over a week. And then actually building the collector, collecting the information that we knew we needed.

00;05;32;19 - 00;05;38;19
Julian Catrambone
We showed like 100 x paths in a matter of minutes because we knew what we were looking for.

00;05;38;20 - 00;05;58;08
Daniel Heinsen
Yeah. So back, back before we had a way to visualize this, we'd literally have like the JSON policies up in text editors in just manually looking at what principals can do. And then you cross-reference it with like, well, do they have any other policies attached? Is there anything that denies it? So you're you're doing like these kind of complex things in your head just by having all these text editors open.

00;05;58;08 - 00;06;23;18
Justin Kohler
So having a way to visualize it just just as we have like the origin of like BloodHound itself, all is it excels of it. Right? Like, yeah. You mentioned policies. Obviously that's like a big component is being able to parse policies, understand how they kind of like add to each other or how they take away from each other and, and how there's several different policy layers that you have to consider and then how that plays out into the overarching kind of like account or organization.

00;06;23;19 - 00;06;43;19
Jared Atkinson
Can you maybe talk about the different types of policies that there are maybe some of the complexities with kind of correlating them together and then how that plays out. So like there's a lot of documentation on AWS, like on how this works. And if you look they they have like this Gantlet like this policy evaluation pipeline, you know, this like, oh man, this is, this is this is a lot.

00;06;43;26 - 00;07;02;22
Daniel Heinsen
But so we don't we don't look at all of them. Like for example, there's like session policies and like there's some things we just can't know from a run audit standpoint. Yeah. Right. But the ones we do look at most importantly are like I am policies. And so those are attached to the principal itself. And unlike Active Directory.

00;07;02;22 - 00;07;23;23
Daniel Heinsen
So Active Directory by default you get to do all these things. I mean AWS you you can't do anything unless you have a policy saying that you can. Okay. And that's attached to the principal. But it's also unlike Active Directory, the the client often configures them themselves. So every environment just gets wildly different. And it's, it's free form text.

00;07;23;23 - 00;07;50;09
Daniel Heinsen
And so the ability to have these unique environments just just explodes. Right. And what it would also be fair to say that the it the uniqueness explodes, but also the error. Yeah. Oh yeah. Errors explode. Yeah. So ultimately what you're doing is you're basically telling a principal like you can do like for example, I can run any action that starts with S3, get on any resource that starts with A, B, C, right.

00;07;50;14 - 00;08;21;11
Daniel Heinsen
And then you could say, well, but I actually don't want you to do get on a bucket that is like the contains the word secret, right? So you start building out like these Venn diagram subsets of what you can and can't do. And that's where it gets like really complex to do by hand. Yeah. And that's all like I don't want to say all, but most of the misconfigurations we have are because of things like that where it's been bolted on policies over time, and then the human like ability to, to understand that is is pretty limited.

00;08;21;13 - 00;08;39;28
Jared Atkinson
This, this sounds like an entropy problem too, because you have like when you're designing a singular policy, it's relatively easy probably to understand the implications of that individual policy if it were in a vacuum. But like you don't actually know what the existing policy set is. And so then you're like aggregating like your new policy onto the existing policy set.

00;08;39;28 - 00;08;52;03
Jared Atkinson
And there may be conflicts or it's almost like conditional acts like people have like to talk about the cascading complexity of conditional access. Right. It's like we put all these rules in, and then you find out later that there's all these assets that fall outside of what rule set.

00;08;52;04 - 00;09;15;27
Julian Catrambone
But there's often misunderstandings as well about what policies do. For example, we've seen a lot of clients that will think that the SCP policies or service control policies will apply to your organization county it in that more than once, where they think they're protected because they restricted the ability to create access keys in the organization. Recap. But the reality is that Amazon documents this, but it does not apply to the organization account.

00;09;15;27 - 00;09;43;19
Julian Catrambone
It also does not apply to Amazon service roles. Right. And so if you have a mechanism to get into either of those, these protective layers that they thought applied do not. Yeah. And we try to expose that in the tool because we're considering all of these different layers as we know the attack paths. So we're going to evaluate service control policies, resource policies, identity policies and line policies permission boundaries.

00;09;43;22 - 00;10;07;07
Julian Catrambone
And at any layer right of this stack, a single deny removes the edge. And there are also weird implications when you talk about the source accounts versus being an external account. In some cases, a resource policy is enough right to access a resource without an associated identity policy, where in other cases it's not. And, the level of complexity here is just immense.

00;10;07;11 - 00;10;21;23
Julian Catrambone
And the level of flexibility that Amazon gives their customers is also immense. And I think this becomes an n times n problem, right? Where when you have infinite flexibility and infinite customization, you're going to see people make mistakes. Yeah, yeah.

00;10;21;25 - 00;10;53;02
Daniel Heinsen
You mentioned conditional access. Like remember at any point like we talked about like all this complexity, any single statement in any policy can also be conditional based on any mismatch of like variables and tags. So n times n times x complexity I mean I like we use AWS on the back end. Right. For, for internally. And I know it's funny because our lead over that infrastructure is always saying like, it's hard for him to just keep up with the constant new functionality in AWS.

00;10;53;03 - 00;11;16;04
Justin Kohler
And so like, how does that it's hard for him to keep up with. How do I use this stuff that I'm using today properly? There's probably a lot of problems with just that. Right? And then add new new things that we may or may not want to entertain. And how does that conflict with it? Basically what I'm saying is like, sounds like possible job for anybody to do in their head, by themselves, or even with a team, unless you can like, sort through it.

00;11;16;05 - 00;11;37;21
Daniel Heinsen
Yeah, it's just a matter. It's like it's own its own profession. At this point. I am engineers now, one of the one of the things that's interesting about AWS that I think is complicated and kind of overwhelmed us, when, when we were thinking about it originally is that there's so many different services. And so obviously you are saying that you cover AWS is there's a lot of interpretation on that.

00;11;37;21 - 00;11;57;20
Jared Atkinson
And so maybe if you guys could share kind of like your thought process on what's covered in your AWS coverage and then maybe like what your thought process was for, why you selected certain services. Sure. Yeah. So we started off with IAM obviously. So like I am is the core of it. So I am being I identity access management.

00;11;57;22 - 00;12;22;23
Daniel Heinsen
And then we just wanted to get the ones that we see the most common and maybe the ones that have identities associated with runtimes. Okay. So like Lambda EC2, the, the things that we typically beeline for as red tamers would be like SSN parameters. We wanted that a key vault things. Things like that. So for reference, there's when we talk about these things like when I say EC2 Lambda, those are services.

00;12;23;00 - 00;12;41;14
Daniel Heinsen
They're like, I don't know, 3 or 400 services. So like yeah, to your point. Like we can't get them all and they're not all created equal. Right. As far as like the attack path is conflated or there's a yeah, there's like a service for like satellite, something like that. Like we're not going to cover that if someone wants us to, like, maybe we could add it.

00;12;41;14 - 00;12;45;19
Julian Catrambone
But meanwhile we have the CTO in the room. We are looking for research project on the.

00;12;45;26 - 00;12;49;24
Jared Atkinson
On the satellite one. Without that, do we have to like, fund a satellite?

00;12;49;26 - 00;12;52;19
Julian Catrambone
Let us get the SpecterOps of satellite out open space.

00;12;52;19 - 00;13;20;12
Jared Atkinson
All right, I'll talk to. I'll talk to the bosses. Yeah, yeah. So. And you guys. So you guys have a suite of services that you add and then maybe prefacing a little bit for the end of this. But where do you, what's kind of something that you don't include today that you want to include. Yeah I think right off the gate ser select Elastic Container Registry and Elastic Container Services is one that we've seen in a few environments that I think we absolutely need to have.

00;13;20;14 - 00;13;30;16
Daniel Heinsen
Bedrock is really important. Like there's a lot of tradecraft coming out on bedrock and like, lateral movement and privilege escalation in there. So I obviously want to get that. I don't know, Julian.

00;13;30;21 - 00;13;50;27
Julian Catrambone
Yeah. I think, our beta partnerships have been really helpful in this case. Right. And so, we're previously we didn't consider X maybe as important. We found one of our customers had an X container that they had privileged that it could take over their entire organization. Right. And it was a password scanning tool, as crazy as that sounds.

00;13;50;29 - 00;14;13;06
Julian Catrambone
Right. But access to everything to passwords, I guess. So as we look through our, our beta customers environments, we, we try and provide value for them. We're building these queries, finding unique attack paths. We're identifying these services. And and there's a pattern in AWS that's common where you have they like to associate identities with like executable contexts.

00;14;13;07 - 00;14;34;18
Julian Catrambone
Right. And so like and EC2 container is a system now that has its own identity. Right. Or an X cluster can have pods with their own identities. And so as an attacker that's super interesting because if you compromise the the running computer, right, or the service, then you now have this new identity where this is not a, this is not inherent in like everything else we do.

00;14;34;20 - 00;14;46;23
Julian Catrambone
Right. Like if you copper buys an ad computer, sure. Maybe you can have the identity of the user that is logged on if they're logged on. But it's not just this inherent thing that, you know, you have immediately with more permissions than the environment.

00;14;46;25 - 00;15;03;26
Jared Atkinson
When you when you're looking at SEO, I'm interested because the same kind of mechanism that people use for the DC connection from GitHub to AWS, I see a lot of GitHub actions that are configured to like register containers with KR, and so I don't I don't know enough about that to know kind of like what that would look like.

00;15;03;26 - 00;15;24;25
Jared Atkinson
But so there may be there may be attack paths from like you can manipulate the container that's being registered or something. Or maybe it's like authenticating and maybe the role, I don't know if it's a role that it's associated with, but like when you do the authentication now you if you control this GitHub repository, you now have control over a role that has more ability within ECA than it should or something like that.

00;15;24;25 - 00;15;26;29
Daniel Heinsen
I think that's yeah, absolutely. Yeah.

00;15;27;01 - 00;15;35;13
Julian Catrambone
And it it has like downstream effects. Right. Because your X cluster for example, polls its interests are on the right. So now your X cluster roles are.

00;15;35;13 - 00;15;57;19
Jared Atkinson
Exposed via GitHub PCR pushes out potentially. I think that's maybe one of the big stories about like the you mentioned access paths versus attack paths from ape from ape man. But the other cool thing about the like the full integration is as each of these individual platforms that we're covering in open graph becomes more powerful the more platforms you cover, right?

00;15;57;20 - 00;16;14;25
Jared Atkinson
So it's it's exponential. Right. So when you, you have by itself that's great. And it's probably really useful, but it's even better when it's connected to GitHub. And then GitHub is even better when it's connected to octa. Right. And so like the more coverage you have across different platforms, kind of like the more you realize that your exposure is just like out of control.

00;16;14;29 - 00;16;34;18
Daniel Heinsen
And that's going to get worse and worse. Yeah. Yeah. Well from a from a, a system ministry. Right. Like the the more the more plugins you install, the more exposed you're gonna. Yeah. The more you're going to realize how it's supposed you are. We actually we actually kind of battle this problem with, with customers to where it's like, as I collect things, my score actually gets worse, right?

00;16;34;24 - 00;16;50;12
Jared Atkinson
And it's not it's not that your score is actually worse, it's just that you have a better visibility of what your bad scores. And so then it's like the lights on. Yeah. Can I, can I like, show that you're continuing to make progress on what you, what your exposure was yesterday, but also show you what your exposure like your actual exposure is tomorrow.

00;16;50;12 - 00;17;17;10
Jared Atkinson
And so, like trying to manage those two different metrics is difficult for people. Yeah. Well, it's like a my son's room was always messy. I just now I'm turning the light on realizing it's. Yes. Yeah. So do you so we talked about axis graph versus attack graph. Maybe before we launch into some of the fun things that we found with customer emergence, can you guys explain like why like there's a lot of tools that look at AWS, like why do you think what we're doing here is interesting?

00;17;17;10 - 00;17;43;27
Daniel Heinsen
So I'm not aware of any other tool that does the policy evaluation that we do. So when we talked about like that pipeline conditions surpass all these things, I think some tools do some of them, but I'm not aware of one that does like all of it to give you, not just like a, you know, principle A can can call A, B and C on principle B, but just having a line same like A can assume B, right?

00;17;43;28 - 00;18;05;19
Daniel Heinsen
Like we distill all of that knowledge and emit what I consider pretty simple, easy to read graphs. So you don't have to be like an Im expert. You can go dig into that and be like, okay, well, like, why is this edge here? It's here because this condition evaluated like maybe it was like vacuous. True. Or maybe a tag was mismatched or something, but you don't have to go that deep.

00;18;05;20 - 00;18;31;16
Daniel Heinsen
Right. And I'm not aware of any other tool that does that. I think something else too is the scale. So being able to scale, like our largest, beta customers of 520 counts in their organization, we're talking well over 1.5 billion principles. And that graph had these like 30 million edges, I think I remember, yeah. So it's just an absolutely insane scale, even covering nine services.

00;18;31;18 - 00;18;52;03
Julian Catrambone
You can see that. And I'm not sure if another tool that can handle that type of scale. The only reason that we can is because of the back end being BloodHound. Right? That that all that hard work has been put into the analysis engine, that you can build these paths, through that large of an environment. The other thing that makes me really excited is that it's free as well.

00;18;52;04 - 00;19;13;13
Julian Catrambone
Right. Like so there's an open source version. It is can be released. You can run it on your own. It will work on BloodHound C, and then you can do this without you don't even have to pay us for it. Whereas, other services do exist, like paid services without they'll give you a similar level of information. Like Amazon itself has the access analyzer.

00;19;13;15 - 00;19;29;10
Jared Atkinson
Yeah. You tried to use that, and you found out that it was very expensive. It is quite expensive. Yes, but access analyzers can principle A do action B on resource C in context D, right. It's like one call. Yeah. And you get a yes or no. I see what we're trying to do is like simulate all of that.

00;19;29;11 - 00;19;49;12
Daniel Heinsen
Right. To to some degree. So yeah, you could rack up a huge bill. He wanted to. Yes. That was a hard lesson learned all been there. Well, but it also be fair to say that, like this. This is my naive read on it, like a lot of tools are really good at finding like individual misconfigurations or maybe maybe like a stacking a couple of them together.

00;19;49;12 - 00;20;11;28
Justin Kohler
So internet exposed thing and has access over over this. Right. Versus ours are just far deeper and probably each each link could not be a misconfiguration but the entire chain is a problem. So it's like I it's okay that our developer had access to this lambda function, that lambda function called this other thing. So like if you look at any of them in silo, they're fine.

00;20;12;00 - 00;20;29;14
Justin Kohler
But you look at all of them in totality. You're like, oh God, that's a huge problem. Yeah. And that's where it gets really sticky because we can like show a path and I'll talk to the like a client and I'll be like, this is kind of like an interesting path and like, well, is it a finding? Is it pushed to say, right, like this.

00;20;29;14 - 00;20;52;09
Daniel Heinsen
That's up to you, man. And so that's been kind of a difficult distinction is, is this you're basically comparing against once attended. Right. Is this intended or is this not intended. And trying to deliver that information in a digestible way can be pretty difficult. Yeah. Yeah I mean maybe intended is on different. There's different layers of intention like yeah do the just a play off Justin's example.

00;20;52;09 - 00;21;07;18
Jared Atkinson
It's like this developer has control over this lambda function that might be intended. But then there's like some downstream consequence that's five hops away that you're like okay, well that means that you have control over like the root account and AWS. Right. And so it's like, yeah, that's not intended. And we have seen that exact pattern actually with our customers.

00;21;07;18 - 00;21;26;07
Julian Catrambone
There was a a small developer account that had maybe ten resources in it. And I don't know if anyone else is like me, but I have absolutely made a lambda function and gave that little functions roll star, star because I was frustrated because you started. Right. And so this, it works this developer and did that in his, in this developer accounts that he thought was fine.

00;21;26;11 - 00;21;47;29
Julian Catrambone
Turns out there was an assumed role that I trusted the root principle of this account, which means anyone from that, but how it's going to swim in there. And then that path extended another five hops through SSM. You had the chain between two different systems. It's ultimately getting into the context of the Terraform provider. And Terraform had everything so you could as it shown via organization.

00;21;48;03 - 00;22;14;03
Julian Catrambone
All because this developer got frustrated that his land probably could read this through double God, that sounds familiar. It's also a least privilege. So I. I always joke about least privilege. Being what we really do is enough privilege. So it's like I give myself enough privilege until I can do the thing that I want to do. But at least privilege implies like a negative testing framework, which is where like I have to be able to do the thing I want to do, but then I have to make sure that I can't do anything else because you want to be at least privileged and nobody does that second part because it's kind of like a you

00;22;14;03 - 00;22;30;04
Jared Atkinson
assume you start at nothing and you're kind of like working your way up. But yeah, I don't want to make this developer feel too bad. Yes. He he couldn't have possibly known this other account, trusted the root principle of his right. Maybe that was. Yeah, that that might be a really interesting point to is that like a lot of times we work in silos.

00;22;30;05 - 00;22;48;22
Jared Atkinson
And so a cool thing about the BloodHound graph in general. And this could be across platforms from GitHub to or like Okta to GitHub to AWS. Or it could be apparently within individual. What would it be? An account. Individual accounts to where it's like you might have control over account A like you said that organizations might have hundreds of accounts or thousands of accounts.

00;22;48;24 - 00;23;20;15
Jared Atkinson
And so you have control over account A, and you have literally no visibility into what account B is doing. And so it's like you don't know what the downstream implications of your configurations are. Yeah. Yeah. You mentioned that one story like when we were leading into the, this discussion, we were talking about, it's the, the things that you guys have been finding seem eerily familiar to early conversations when we talk to like, people who either didn't know what BloodHound was, never ran it themselves, and then they would hear the kind of the reason for it and they'd be like, well, I don't think I need that because I separate my users from my admins.

00;23;20;15 - 00;23;40;24
Justin Kohler
Right? And it's like, if you do, you'd be the first one that we've ever seen to do that, right? Because like, you can't see if you're actually doing it. And it seems like another one that we've heard at least in these beta conversations, is we don't trust external organizations. It's like, you don't think you did. Yeah, we've seen quite a few like and and it depends on how you define external organizations.

00;23;40;24 - 00;24;12;16
Daniel Heinsen
So like we mentioned like if you consider GitHub to be external organization, that's something even the the organization itself controls. But we see pretty intense attack paths the hop that can take full account compromise. But even then from an external standpoint, you might have like third party vendors, right? As another external and, you know, in, in similar fashion, like third party vendors ask for a lot of permissions because they probably don't want to be asking you for like additional tidbits here and there.

00;24;12;17 - 00;24;40;15
Daniel Heinsen
Like there's like they want to over over permission a little bit so that they can like, update and do the things they need to do. But oftentimes, yeah, we'll see that third party trust come in and that can just take over your not just your AWS account, but the entirety of your AWS organization. And so we've had some pretty interesting conversations where he said, like, I know this is like intended, like, I know you, configured this, but have you considered the fact that if this third party organization gets compromised, you will also be compromised?

00;24;40;18 - 00;24;57;06
Daniel Heinsen
Like, or you could be compromised, right? Especially in a world where we're seeing that every month. Right. It's, Oh. At least these third parties get compromised and supply chain attacks, and then suddenly, I mean, we got hit the actions. Right? I think that, the repos that it was running on dynamic Prudential. So it ultimately was a non-issue.

00;24;57;06 - 00;25;15;08
Julian Catrambone
But, it's really hard to control for it. Right. And so having that insight of, hey, you have this account ID that could assume into your refinement and this allowed to update its own permissions is like a very scary premise. Well, when we we made it, I don't know what 20 minutes before we use the word AI, but now we're here.

00;25;15;08 - 00;25;32;13
Justin Kohler
So like I mean, whether it's like the trivia beach or just like just footholds in the front door or coming up everywhere all at once, it's like you need to understand where these paths exist so you can at least work to shut them down, or at least understand the exposure that you have with it. And then it could just be a conversation with vendor, right?

00;25;32;14 - 00;25;48;24
Julian Catrambone
Like, yeah. Can we scope this down a little bit? Right. You can start to do that evaluation before you even enable it to. Right. So it's like you have a you have a vendor that says I want to attach my account. I want to I want to create a role that you trust to have these permissions. I may not be saying that correctly, but conceptual you get it.

00;25;48;24 - 00;26;10;21
Jared Atkinson
Yeah. And and then you can say, okay, well what would be like based on my existing AWS configuration, how does that actually play out? Does it play out the way that they're expecting it to, or is there some, you know, rogue policy that's going to cause it to just be completely out of control? Yeah, absolutely. So like specifically, you can create a role, do all the like permissions, not create the trust and simulate it.

00;26;10;23 - 00;26;29;23
Daniel Heinsen
Yeah. Yeah. And then you can, you know, do a do an AWS collect and and literally see it before that trust goes into effect. And then the key is is that the vendor side once you do the trust now it's opaque. You have no idea what's happening over there right. Yep. That's often but I think you have a dream of like, seeing the whole AWS ecosystem.

00;26;29;26 - 00;26;51;24
Daniel Heinsen
Yeah. Grab the planet. We have I, I guess as a as a Segway, like one of the things that's interesting about the AWS collector itself and you hinted at this is where multi account. Right. And so when or when we ingest some organization we have to like ingest the entirety of all like basically their entire universe because everything comes down to like string matching.

00;26;51;24 - 00;27;17;10
Daniel Heinsen
So to your point, like if we could somehow just like look everything into one analysis, that would be one very expensive computationally. Yeah. To really cool. Yeah yeah, yeah. Also like mergers and acquisitions. Right. And this ahead of time and see what the like what connecting these two organizations actually means. I know you had one example, at least with a customer where there was a trust and it was like it was a was this because of a old acquisition?

00;27;17;10 - 00;27;34;24
Justin Kohler
Was this because of a something like we couldn't answer the question, but you understood the impact. Yeah. It's like, yeah, those are scary. Answer. Yes. When. So like all right. So if, if, if you're not familiar like when you're looking at trusts, it's just a, a policy. It's called an assumed roll policy on a roll. And like you could put comments.

00;27;34;24 - 00;27;52;20
Daniel Heinsen
But really the trust is just an account number. Like it's like a 12 digit number. And and there's really like no great way to like look up who owns that number. So there's been a couple of times where we come to someone and like, who is this? And I go, I don't know. Yeah. The one that the guy that made that was fired five years ago or.

00;27;52;25 - 00;28;08;22
Daniel Heinsen
Yeah. Yeah. It's the answer is usually hand wavy. Something like, you know, someone selling like someone's personal account or, or maybe it was a merger, but the fact that you don't know is really scary. Not a good thing. Yeah. Here. Your chief information security officer probably doesn't assume that risk or want to assume that risk. Well, just doesn't scale, right?

00;28;08;24 - 00;28;13;10
Julian Catrambone
I mean, how does one person review the trust policies of 520? Yeah, right.

00;28;13;13 - 00;28;26;09
Jared Atkinson
We do we do run into people that you're like, you know, what's this account? And they're like, oh yeah, that's this. Like they just look at the numbers and they have like 500 accounts memorized. And you're like, yeah, how do you do that, you silly? They just spotted like a 12 digit number. Like I know that one.

00;28;26;10 - 00;28;51;08
Justin Kohler
Yeah. Yeah. Well what a any other like war stories or do we kind of cover most of them. I mean, I feel like so many of them are end up in organization compromise. So I think one of the ones that I liked recently was we have a meta edge for the graph, which is like, if if there's any trust relationship between two AWS accounts, we draw it.

00;28;51;08 - 00;29;11;15
Daniel Heinsen
So it's not like a, like a physical. I said, it's just like a metric that we can visualize it. And this last, it was like a, an organization where the copilot accounts was like, just show me the graph of all the trusts. And first of all, it took like 30s to load. And then it's like thousands of edges and it's just this big, like big mesh.

00;29;11;18 - 00;29;32;09
Daniel Heinsen
You know him all all. Yeah, yeah. And, we showed that on a I call it the client and they just. Yeah, I think they, they kind of, died inside a little bit. Reality. Yeah. Cuz it should be something like a hub and spoke. Yeah. For the most part. So if you have something like that, it's just you can't possibly keep that, keep track of that kind of trust.

00;29;32;10 - 00;29;50;01
Justin Kohler
Hop. Well, step one is admit you have a problem. Right. So. Well, yeah. Now they know that they have the problem. They can now go and say like, well, if we intended on a hub and spoke design. Yeah. How do we actually go about, you know, what's our hub. Yeah. Right. Right now it's all yeah, yeah. There's no spokes.

00;29;50;03 - 00;30;07;21
Jared Atkinson
Maybe, maybe one thing we could talk about to you said that there's these organization takeovers and that kind of fits into the the BloodHound paradigm, I guess, of like, Cure zero isolation. That's like the traditional paradigm. But one of the things that we've experienced with GitHub, but we also is present in AWS, maybe, maybe not to the like GitHub.

00;30;07;21 - 00;30;25;24
Jared Atkinson
It's all about resources. AWS. There's some like tier zero takeovers, but there's also a lot of focus on like resources. It's all about saying like, what are the resources that you care about most? Right. So you talked about the S3 bucket. That's like delivering software to customers, right? That's probably really important. But there's there may be myriad important resources left.

00;30;25;25 - 00;30;46;20
Jared Atkinson
Yeah. So yeah, maybe talk about like that philosophy I guess, of how like there's a difference between tier zero and the resources that you care about most that are critical to your business. Yeah. Well, when we map out Active Directory like that, that notion is pretty clear because Active Directory is is an identity provider, right. So our path is always to get to like the most control of the entity.

00;30;46;20 - 00;31;12;29
Daniel Heinsen
But when you go to AWS, AWS is not an identity provider. It's a resource cloud resource provider. And and like if I have tier zero and an account that has no resources and no just, okay, you have to do right. Like at like the the impacts. The final question is, well what does this affect? Does it affect my S3 bucket with all the sensitive secrets and or does it affect my, my, you know, production.

00;31;13;02 - 00;31;39;20
Daniel Heinsen
Work like my production platform. So we're trying to come up with like, nice ways to, to segment those, those like critical resource of critical resources often say like these are your paths to the resources you care about, not just to the identities that can take them over, but like to the resources themselves. Yeah. And that requires a little bit of a different thing, too, because there's like, there's, let's say attack edges, what we would call traversable edges, which is to where you have full control over the resource.

00;31;39;20 - 00;31;49;19
Jared Atkinson
But maybe the resource, like a, a key vault, is sensitive enough to where read. You don't have control over it, but you can't change it. Maybe. But you can read it. And that's maybe just as bad as you do.

00;31;49;23 - 00;32;04;01
Julian Catrambone
Absolutely. You definitely see this. And I think we see it in our on our assessments. Right? All of our impact objectives are often resources. Yeah. Whether it's, you know, find the model weights, create those. They're not going to be identities. They're going to be in a resource.

00;32;04;01 - 00;32;27;29
Julian Catrambone
Somewhere or yes. Two things from experience or here if you. Yeah. No comments. Right. But it's nice to have a definitive answer. Right. As a, as an organization, you can run this tool and and build a query. Yeah. I'll tell you, these are the principles that can get to this resource, at least in this our defined list of attack edges.

00;32;27;29 - 00;32;51;14
Julian Catrambone
Right. Which is not obviously not completely encompassing of everything AWS has to offer. But yeah, we like to think that it at least shows a good amount. Yeah. And it's not just standard identity. Can't assume role like we're also considering. You could run an SSM command on another EC2 instance, or you're allowed to update a CloudFormation stack that has a privileged identity attached to it, or Lambda functions like so.

00;32;51;16 - 00;33;13;07
Julian Catrambone
There's this wide array of different ways to pivot through these accounts to ultimately get to your target resource. About 4040 traversable edges, something in that ballpark. Okay. So, yeah, a lot of them are like identity related, but they're not just assume, all right. Like that's we're doing a lot more than I said. And Julian, you just you just gave a heuristic that I think is super useful.

00;33;13;07 - 00;33;34;26
Jared Atkinson
So a lot of times customers are overwhelmed, like, the people that are interacting with BloodHound, they might not they might not be administers administrators over GitHub. Right. And so you're like, okay, what's your important GitHub repository? And they're like, I don't know. But like what you, what you just kind of like articulated is this idea that it's just the first question you should ask is, if I were having a red team, what are the things I would tell the red team to go after?

00;33;34;27 - 00;33;51;17
Jared Atkinson
Like, that's the first layer of things that you should care about. And then like, we could work on being more specific after that. Yeah, absolutely. Well, so we talked about, why it's cool. We talked about the services covered and where you want to take it. Some more stories, I guess. Anything else that we want to talk through on this?

00;33;51;19 - 00;33;57;08
Julian Catrambone
Happy to be here. Glad to be on I think that we're still looking for more data customers. Right.

00;33;57;09 - 00;33;58;01
Jared Atkinson
So yeah.

00;33;58;02 - 00;34;01;11
Julian Catrambone
To try this out and you open source version will.

00;34;01;11 - 00;34;23;02
Julian Catrambone
Shortly be released. Right. So, can't wait to see what the world does with the tool it's used or what paths become identified. Yeah. So you want to talk about the. Yeah. The the beta. The beta. Yeah. So the R we just released a beta. Not just for this, but Azure Agent ID and then an agent kind of access to BloodHound itself.

00;34;23;02 - 00;34;41;29
Justin Kohler
So, we calling it an MCP servers and maybe a little bit of oversimplification, but all three of these are betas that we just announced. And so if you're interested, especially if you're a BloodHound enterprise customer, we can work with you very closely on like a deploying, and always looking for more feedback that will only make our release that much more powerful than good.

00;34;42;05 - 00;35;02;05
Daniel Heinsen
Yeah, every environment is unique and different, and the more we do this, like, the better that's going to get. Yeah. And from a personal note, if there's, something we're not covering that scares you, make it known. Yeah, we'll try and get it in. Yeah, well, that's a good place to stop. Thanks, guys, for joining us again. We got Julian and Daniel talking about AWS and we'll see you guys next time.