Hi, everyone. My name is Josh Stella. I am the CTO and co founder of Fug. And what we do at Fug is we secure our customers cloud infrastructure and we spend a lot of time here picking apart how bad guys actually break in and steal stuff, how hackers exploit you in the cloud, which is a very common exploitation attack. Surface now is cloud misconfiguration. So what we're using to do today is first talk a little bit about what is cloud misconfiguration risk, and then iam going to break into one of my own cloud accounts and steal data out of it using the same techniques that we know a hacker used against a major bank last year by a DOJ filing. So I'm using to show you how a hacker thinks and how they go after your stuff. And it's a lot of fun and hopefully I won't fat finger anything because it's going to be a live, real demonstration. All right, then we're going to talk about some actionable steps to secure this as your customers to secure your cloud environments. And we're recording this so there won't be like live Q and A, but iam always happy to answer any questions offline or whatever mechanism we come up with. I'm just Josh at Fugue Co. I'll put my email address up at the end. All right. Not too many slides. Okay, we're going to have a few slides and then we're going to get into the fun stuff. But we do have a few slides. So what is cloud misconfiguration? Well, it's a major security risk. Cloud misconfiguration is having the cloud services in AWS or Azure or GCP, whatever cloud you're using configured in a way that bad guys can take advantage of and get to stuff you don't want them to get to. That's kind of our definition of misconfiguration and it is the main attack surface on the cloud. So every year we at fuge do a big survey of hundreds of organizations that are operating on the cloud. And the survey is just about how they're thinking about cloud misconfiguration and what their concerns are. So 84% this year, this was done in 2020, 84% are concerned they've been hacked and don't know about it. This is good that people are worried about this. It's not good that it happens, because it does happen a lot, but it's good that people are concerned about it. The simulation I'm going to do is based on the capital one breach of last year. And in that breach, the only reason anyone found out about it was because the hacker bragged about it on social media, like, months after, or at least a month after nobody had noticed it. Well, why is that? That seems crazy. I'm going to explain to you why that is when I simulate the breach. So 84% are worried that's happened to them and they don't know it. You should be in that 84%, you should believe that this has happened to you, because it quite possibly has. 92% are concerned they're vulnerable to a cloud breach. This is actually down 1% from the same survey we did a year before, where this is 93%. This should be 100%. You are almost certainly vulnerable to a major cloud breach. And I'm going CTO show you that the way hackers think. They don't care about your compliance policies. They don't care about the ways that you've predicted. They're going to come after you. They find ways. So you should be worried about it. Okay? They're clever. There's a reason we call hackers hackers. They are creative. The original term hacking meant, like, doing something really skilled on a computer. And now that means breaking into stuff. Because guess what? They're smart, they're clever, and it's also fun. All right, so misconfiguration risk will increase or stay the same this year. The 76% said increase. It is always increasing. Every time someone in your organization puts a resource in the cloud, that is additional attack surface. Every time a cloud service provider creates a new service type, that's new attack surface. So it is, by definition, objectively growing all the time. So this is an increasing problem, and it is not going to go away. All right, so Dave Lintecomb from Infoworld wrote an article in which he said, I'm seeing a lot of cloud misconfiguration in the real world, and it's scaring the hell out of me. It should be scaring all of us. We should be very concerned with this because it's really a new domain in security. Putting network monitors on your network endpoints and trying to create perimeters of defense and depth will fail you in the cloud. So the last 30 years of data center style security is going to help you only a little bit. There's a whole new way. You have to think about this, because the hackers are thinking about it a whole new way. Okay. In our survey, we asked the respondents, and these are all organizations operating at large scale and cloud. We asked them what kinds of misconfigurations are you worried about? And I was really impressed with the responses, actually. I didn't expect this, but I should have known. There's so many smart people in this field, it made me really happy. If you read the news who almost always get it wrong when it comes to cloud attacks, you would think that this object storage access policies, this third place contender would be number one. S three bucket gets breached. That's always what makes the news. What doesn't make the news is how they get breached. Okay, data got stolen, not usually because somebody just left an object storage bucket wide open, but because of things like misconfigured identity and access management. That was our number one answer from our respondents. So on point. IAM is itself a network in the cloud. It's not just about the identity of users, it's how the cloud resources talk to each other. And in the exploit I'm going to show you, I'm going to leverage IAM and our number two, bad security group rules. I'm going to leverage those two things to steal data out of s three. Okay, so it's all of them to do this hack. All right. Cloud misconfiguration is very often overlooked, and there are good reasons for this when I see cloud breaches in the news. But prior to founding fugue, I was at AWS as a principal solutions architect working in know national security stuff in the US. Okay. So my background for about a decade has just been around building functional and secure infrastructure in the cloud. And I'm really familiar with the whole evolution of it as a result, because I've been on the front lines and what I've seen is that many dangerous cloud misconfigurations are not recognized as misconfigurations at all. One of the reasons for this is the compliance frameworks that people rely upon, like NIST and Cis and HIPAA, GDPR. There's a long list. Soc two, they're behind the times, the bad guys. The hackers don't care about those things. They're really good to do. I mean, we at feud will let you see how you stack up against all those compliance frameworks. They're really good, but they're incomplete and they're losing the race with the bad guys. So the reason the security teams often aren't aware, or the engineering teams, DevOps teams aren't aware they have misconfigurations, is they're relying on experts building compliance frameworks to tell them what's dangerous. But those things are behind, and therefore these are exceedingly common in enterprise cloud environments. Neil McDonald at Gartner, we use this quote. I have mixed feelings about it. It's true. So the quote is, nearly all successful attacks on cloud services are the result of customer misconfiguration, mismanagement and mistakes. That sounds really kind of pejorative and punitive. Like, if you were smarter, you wouldn't have gotten breached. And while in theory that's true, in practice this is a vastly complex subject and people who are excellent at it, I mean, I have very good friends over at Capital one that are in their engine, and I know how good they are. They're very good, and they got breached. So this is nontrivial stuff. And yes, it is kind of glibbed to say a customer misconfiguration caused this, but when you have literally potentially billions of misconfigurations, it's really easy to miss them. Okay, a little bit about how hackers find you and find the door into your organization. So in the old days, in kind of the Hollywood version of a hack, right, the bad guys are the hackers. Like, okay, I want to go after this organization. I'm going to go after Acmecorp. And so I'm using to look at all of Acmecorp stuff and try to find a way in. And this does happen. It continues to happen. One famous example, a number of years back, know, Sony pictures made a movie that North Korea didn't like, and they used spear phishing and phishing techniques to steal all the email out of Sony and embarrass the executives. So that's like the classic, we're going to target Sony and find a way in and hit Sony. That is not how most of these happen anymore. That's mostly Hollywood, except for rare cases these days. What the bad guys do, what the hackers do is they have automation that's running twenty four seven, looking for any object that appears on the Internet, any IP address, anything with a DNS record. They're just hitting them all. Looking for anything they know is a misconfiguration, typically. Okay, well, John Breeden here in CSO online says skilled or well under hacker groups, or both, many are. Both are employing automation to discover and exploit misconfigured cloud assets within hours of their deployment. He's wrong. It's minutes. Typically somewhere around seven minutes is normal and it can be seconds. So you have basically zero time to react as a human being CTO, somebody finding and exploiting your cloud resources. So how it works now is the bad guys are running this automation runs 24/7 they get up in the morning, they grab a coffee, and they go look at the list of people's stuff they can steal and say, oh, that one looks good. And they already know the misconfiguration is there. Okay? So you have to be very concerned with this, not just being thorough, but using fast and being quick to breach, because that's what they're using. Okay? Therefore, your security strategy has to evolve. Before the cloud, the world worked roughly like this in the kind of data center world automation world, whatever you want to call it, pre cloud, pre API driven infrastructure. You would do procurements and you would go to vendors. You might talk to Dell and HPE and someone else for some servers or Cisco and someone else for some switches, and you would design something and you would build out your infrastructure. And that would run for somewhere around three to five years before any individual piece of equipment was recapitalized. So the network and security and operations teams would deliver this infrastructure to the application teams, right. And then they would live within it, and of course they would add to it or they would remove some things. But for the most part, that pre cloud is very slow moving. It takes weeks or months to go through these procurement cycles to build this stuff. And then apps are kind of stuffed into what was built. And so in this world, things like network analysis and threat detection tools were used as the primary mechanism to identify intrusions, and then humans would respond to them through some ticketing system that is totally inadequate to cloud. And here's why. In cloud, you don't go build all the infrastructure and then let your developers into it. The developers are building the infrastructure as they go. This whole thing is flipped on its head, right? Infrastructure is now or should be in cloud. If you're not doing it this way, you're losing a lot of the advantages of cloud. But the way it works now is when I go build an application, I'm a software developer, software architect for a long, long time, I'm going to, as part of building my app, build its infrastructure, or at least much of it. So that might be this morning. Earlier, I was building out a global network, and that took me a few minutes. To build a global network in the past would have taken large teams, months. Right? So this is a great thing because I can go really fast and I can deploy quickly, but it also means that I have to be worried about securing it along the way. So in this world, rather than there being this kind of network analysis and ids and all this stuff, you might want to do some of that still. But mainly what you're going to be worried about is checking the configuration of that cloud infrastructure. Remember those comments that most of these breaches are due to misconfiguration, not due to the traditional ways that hackers would get in. So you can use things like policy as code validation tools, okay? And you want automation on your side for detection and remediation as well. So what this really means is that cloud security is a software engineering problem. It's a computer science problem, not a security analysis problem in the traditional sense. All right, let's get to, I promise, not that many slides. That wasn't too many slides, but now we're going to break in and steal some stuff. All right, so this diagram is part of the product we make, and the reason I'm bringing it up is to show you what I'm going to do here. Okay, so over on the left is the Internet, and here are some VPC networks, virtual private cloud networks. I've got an Internet gateway. So this is a topology of a cloud infrastructure, and we at fuge like to automate the building of these diagrams so that you can understand what's going on, right? So what I'm going to do today is I'm going to break into a compute instance, in this case an EC two instance, and I want to steal data out of this s three bucket. That's my job. I want to get in and steal data, okay? If I'm a bad guy, I'm going to be using, and you can see I've given this EC two instance the very witty name. Not really. I've got a CVE. Okay, so what's a CVe? A CVE, I always forget what the e stands for, but it's a common vulnerability. There's a database of these, it means like this compute instance has vulnerable stuff on it. Remember, the bad guys are using automation to find vulnerabilities. Well, this server, this EC two instance, has one of those vulnerabilities. Now if I were doing 100% accurate hacking demo, I would use some exploitative software to take advantage of a CVE. Maybe that is, for example, running scripts against the HTTP endpoint of the web server that has a known vulnerability, and shoving some data in there that allows me to shell that isn't too uncommon. Iam not going to do that today, because having worked at AWS, I know those guys are watching all the time, and that's the kind of thing they notice. And they will shut you out if they catch you. And I don't want to risk that, because then I won't be able to do my demo. Okay, so the very first part of this hack, I'm just going to kind of simulate by shelling in just getting shell. All right, so I've now shelled into that EC two instance, and what you're seeing is my terminal. If you're not used to working in terminals, don't worry about it. Every single step I take I'm going to explain in a way that you'll be able to understand. But I want to show you what it's really like to be the hacker trying to get in. I showed you that diagram a second ago. The hacker doesn't have that diagram. They just know they got to one little place in your cloud infrastructure. And this is a theme I'm going to repeat over and again. You need to be aware of everything in your cloud infrastructure and you need to be denying the hacker knowledge of as much as you can. Because 80% of the job in hacking is gaining information, is doing discovery. Okay? So you want total visibility. That's why few gives you those diagrams. And you want the hacker to have zero visibility if possible. Okay? So here is an indication right away. This is just the banner for the Amazon Linux distribution. Perfectly good Linux distribution. It's actually quite a good Linux distribution, but I have forgotten to update it. Okay, and by the way, if you go scan your whole environment using fugue or something like us, you're probably going to find stuff that you've forgotten about. And that is not up to current patch levels. So here you can see that 22 packages need updating for security. Each one of those is a potential vulnerability. Okay? Out of almost 100 updates that are available. So this is why in the particular breach we're simulating, the bad guy first gets in. It's actually not a big part of the hack, it's a small part of the hack, but it's the first step in the door. There was an open ssh port, or an open dangerous port, an unpatched server with a known vulnerability. And now I'm into your account. I have no idea where your data lives. So I'm going to start exploring to see if I can find your data to steal. So iam a cloud hacker. So I know what I'm doing. So iam going to use the AWS command line interface command, which is AWS. I'm going to point to s three, which is where a lot of data is stored. That's what I want to get to. I want to get to s three and I'm just going to try to do a list of what s three buckets are out there. So AWS, s three. Ls is the command I'm going to run first. Interesting. So somebody did their job. I, as a bad guy have now run into a problem. I am getting an access denied on the s three list, so I don't have permission. CTO list s three from that Ec two instance. Now I'm going to switch back to my diagram here and show you why that is and how that works. Okay? If you notice, I just selected this Ec two instance, and the very first thing I see is that it has the IAM instance profile of maintenance role. Okay, just to explain what's going on here in AWS, remember we talked about IAm being a major attack service, being a dangerous service, and something that misconfigurations are really devastating if you have them in. A big part of the reason for that is IaM in AWS is more like a network than just identity. It determines when you assign resources, IAM roles, it determines what they're allowed to see elsewhere in the infrastructure. So this maintenance role here apparently does not have permission to see this s three stuff over here. So as a bad guy, I've got to start getting creative now. I don't know. I just showed you in the nice feud diagram, I'm copying some commands over here. I just showed you in the nice feud diagram that there is a maintenance role on that instance, but the hacker still doesn't know that. So Iam going to start exploring the infamous metadata service. This is another place where the press really gets things wrong. Okay? All I'm doing here is a command called Curl. Curl is like pointing your terminal at a website the same way you would type a web address into a browser. I'm going to do it at a terminal to get data back rather than to paint a web page. Okay? But it's the same thing. And I'm calling this special IP address one 6925-416-9254 that's the same on every EC two instance and what it is. So when you think about what is cloud, cloud is made of things like virtual machines and containers and functions, but they're living underneath what's called a hypervisor, okay? And a hypervisor is what manages those virtual compute instances of various forms. Now in AWS one 6925-416-9254 is the hypervisor, okay, you're asking the thing that's managing your compute instance for some information, and it knows some stuff about your compute instance. This is actually an awesome service and if used properly, will help your security. You should not be afraid of it, but you should know how to use it. Okay, so as a bad guy here, iam going to go look at this and I want to look at the latest metadata. Just give me a list. All right. There's a bunch of stuff here I can look at. The AMI ID, the machine image id, host name, whatever the Mac address, all kinds of data. Well, you can imagine how this stuff would be really helpful when you're building particularly immutable infrastructure, which is the only way to go on cloud applications, you have automatic access. You don't have to go figure it out. You don't have to go sending messages across services or anything like that. It's right there in the hypervisor. But what I'm looking for as the bad guy doing discovery is IAM looking for the IAM security credentials. And I happen to know where those live. Let me move my little zoom thing here. So again, one 6925-416-9254 latest metadata. We went there, right? But now we're drilling down into IAM and we're looking at security credentials, and this will tell us what role we are running at. And you can see here, we showed this in the feud diagram, but I said the bad guy didn't know. Well, now the bad guy knows. It's maintenance role. Okay? Now I know the role I'm running under, and I know from when I did my s three ls command that maintenance role ain't going to help me get to s three. But I want to show you one more thing, because the press has often gotten this wrong and I've been disappointed. A lot of people have gotten this wrong. They said, oh, my God, if you get into the metadata service, bad guys can attack you. Not if you do it right. So I'm going to drill in further. So iam going to go the same place I went before using curl, and I'm going to go into the maintenance role itself. Okay, here we go. This looks scary, right? I've got an access key. I've got a secret access key. I've got a token. This is everything I need as a bad guy to still not have access to s three. So what? Right? The danger is when you can traverse the IAM network to s three. Well, we can't. So these credentials, as scary looking as this is, aren't going to help me as a bad guy one iota. In fact, I need to take a completely different approach now. So I know, I don't have access cto s three using maintenance role, but maybe, just maybe, I can get to some other stuff that perhaps people left open for me. So here I'm again using the AWS command line, but I'm not pointing at s three, I'm pointing at IAm, and I'm going to list the policies and I'm going to search that list for any policy name that has s three in it. Okay, so I'm not querying s three. I know I'm using to get again, access denied. There I'm instead looking at Iam. And all I'm doing right here, by the way, I don't need write permissions to Iam, I just need list permissions to Iam. All I'm trying to do is list policies. If you think list permissions aren't scary and bad guys and hackers can't exploit them, you are very, very wrong. I am trying to do discovery and I'm going to do that through list commands. Okay, let's hit enter on that. By the way, this is all real and live, okay? So if I screw something up, I'll tell you and I'll go back. But so far so good. We just executed that command against the AWS APIs. And I'm looking at this s three read write as a pretty attractive looking policy. You can see here a list of policy names. S three read write sounds like it would do what I want to do. So now I'm going to change tack again. I started out trying cto get to s three. I got an access denied. So I started looking around and doing discovery and IAM, but now I know, okay, the thing iam trying to do now is change this to the s three read write from the maintenance role. Well, in other words, I want different permissions that this compute instance, this EC two instance has. I want it to change its permissions to be able to see s three. And so I need to change what IAM role it is associated to, and that is called an IAM instance profile association. So back at the command line, AWS, EC two don't need IaM permissions to see this. I just need EC two permissions. Very often people think a lot of EC two permissions on EC two instances are safe. They are not. And again, this is not a read, this is not a write, it's a describe. So there's a theme here. As a bad guy, as a hackers, I'm going to use lists and describes. I'm going to be doing discovery, okay? Let's go look at the instance profile associations. All right, so all I'm doing here, if you think about that EC two instance having that connection to maintenance role, I'm looking at the thing that is the connection here, okay? The association of these. And there's a little bit of data in here. So the instance id here is the instance id of the EC two instance I'm working from the state is that it is in fact associated, so it's connected. And then what I'm really going for here is this automation id. I want to be able to point to this association so that I can change it. Okay? So I'm going to grab this and I'm going to go over to my text editor here off screen, because this next command is really a mouthful. And I'm going to explain the whole is if you read the DoJ filing on the capital one breach, you'll see there's a part in there in which the hacker says that they do an IaM assume role. That's this, okay? That's what this is. So it's a mouthful and it gets really verbose, but I want to walk through it so you really understand what I'm about to do. So AWS ClI command, again, we're pointing at ec two. All I need is ec two. I don't need iam. Right. Remember that when you're granting EC two permissions, there are some scary ones. So the EC two command here, the action is called replace IAM instance profile association. It's a mouthful. It does what it says. It replaces that association with another automation. So I need to know the automation. That's why I looked this up. So I pass that in here under association id, replace that one and then replace it with the IaM instance profile, whose name is s three readwrite. So you can see here we're pointing at maintenance role. I want to point at s three read write role. Okay, let's see if this flies. All right, that looks like victory. This is how sad we are as hackers, whether we're white hats or black hats. This is like this moment right here. Okay, you've now got a new association id. You can see that doesn't end in the same thing, right, as this one. And it's pointed at s three read write. So I should be able to see s three now. So let's go back to the very beginning and do our aws s three list. Now I can see data. Now I can list the data. Okay, so remember I said I was going to exploit an open firewall port. I was mostly going to be exploiting iam to get to s three to steal from s three. Okay, and I can see here this important records is an attractively named s three bucket. Sounds like stuff I might want to steal in there. So I'm going to do an AWS. S three. Ls of s three important records. And if I could type properly, and I typed s two, too, I just switched keyboards. I shouldn't have done that. All right, so now we're getting an enumeration of the data that's in that bucket. Now, in this case, these are some pictures I took in Iceland. No big deal, right? This is me just hacking around with my own account, trying out hacking techniques. But in the real world, this was like a lot of customer data out of that bank. A lot. So what I've done here, back to the diagram I got into here, and by using different API commands, looking at doing discovery via the metadata service. But that was tiny part of this hack, right? The big part of the hack is doing discovery via EC two and IAM of other IAM roles, and then exploiting a misconfiguration in the IAM role on the EC two instance to change the IAM role. And now I can see important records here. And what I'm going to do next is I'm going to steal all the data out of important records into my own s three bucket, called all your base. All right, so we know from the DoJ filing exactly how this was done. It was done using a command called sync. Now. So aws s three sync. Sync is not part of the s three API. Sync is only a convenience utility that's built into the command line. So we know the hacker was using the command line. A lot of the news stories on that breach thought she was doing something on some remote server somewhere else. We know she got in. We know she used an IAM assume role, just like I did, and then used sync. Now, the beauty of sync. So I'm going to do important records. Let's see. I'll watch myself type this time so I don't have typos. I'm going from s three important records to I need an extra slash. I always thought that slash slash thing was kind of goofy in Uris of all forms, from s three important records to s three, all your base. All right, I just stole all your data, and none of it traversed your network boundaries. Not a single bit of that data theft traversed any of your intrusion detection systems, traverse any of your packet monitors, your firewalls, your VPC gateways, nothing. It went straight from s three to s three on the AWS backplane. Okay, so this is why so many s three breaches go undetected. Because what evidence do you have that this was taking place? Really, the only thing you have are the log entries of that sync command performing gets right behind the scenes. All sync is doing is it's using s three list. Another reason you should not have s three list turned on anywhere in production. It's using s three list to get a list of things, and then it's doing parallelized copies to another s three behind the scenes. So you'll have some API calls, you'll have some gets. But what's s three's job? In the world? It's like a fourth of the Internet. It's really good at handling lots and lots of gets. So, finding that needle in the haystack, even if it's stealing all of your customer data, because what those s three buckets are probably doing all day is serving customer data to legitimate actors. So what's another million calls against your s three infrastructure? When you're doing 200 million calls a day against it? It's very hard to see. And so this is why getting the configuration right to begin with and then keeping it correct through automated remediation is so important. If I had had fugue turned on in this account doing automated remediation, it would have caught when I did that IAM role change, and it would have reverted it. Okay, so instead of my being able to go and break into s three and steal all your data, I might have momentarily been able to see a list of s three. But then fugue would put it back to maintenance role and shut down my ability to do the copy of the data. Okay, so that's the demo today. I think we've got a few closing slides here. Yeah, just CTo recap. So, the misconfiguration attack and review. First, there was a firewall misconfiguration I could get to, and I could use my automation tools to discover a vulnerable EC two instance. Number two. I had a vulnerable Ec two instance. Second mistake. So, usually, in this case, I believe it was due to what we call orphan or zombie infrastructure stuff you've forgotten to patch anymore. So, I break in, right? I get my toe hold. Number three. I needed to find a way to get an IAM role that could access s three. And the permissions on the IAM role that EC two instance had were such that I could do that. And then four I had to discover the s three buckets and list their contents and sync and steal their data. So some recommendations monitor all your access point misconfigurations. You should really have full visibility into your ingress ports to the Internet, or even not just to the Internet, to any kind of broad external under block, right? A lot of people miss that. Obviously you want to use least permissive permissions on all this stuff, but really apply that to IAM. Don't use star in IAM ever. You can use things like different endpoints with different IAM roles for read and write operations too, right? And get rid of anything in the production environment that relies on lists. In s three, shove that data in a database and query it there. IAM list permissions in production are extraordinarily dangerous, as I hope I just showed you. And yeah, don't allow Ec two instances CTO have IAM roles that allow role assumption gets game over. Get rid of unused cloud resources, especially EC two instances s three buckets. But also think about things like EBS, volume backups, and if any of those are public and unencrypted, because often they contain secrets you need to constantly clean up behind yourself and only have out there in cloud what you need to operate your business. And that means you have to know everything you have out there. And I can almost guarantee you you have stuff out there you don't know about if you're operating at scale. Include cloud misconfiguration and pen testing. I don't even love the term pen testing. What we tend to do is use things like hacker one CTo just get as to put bounties on finding stuff in our non prod environments and getting the cleverest bad guys out there. Everything in the hack I just showed you, none of it. I never got rude on the operating system. I didn't do any of the traditional hacker stuff. I completely exploited cloud misconfiguration, and good luck finding that in a single team. So you have to be creative there and find people who really know how CTO do it. Use automation remediation again, if we had had fugue turned on in that environment, in remediation mode, in automated remediation mode, enforcement mode, I would have been prevented from stealing the data. You want something like that, we have a free version you can use up to a certain scale, but you can do it other ways too. Obviously we think our approach is best, but do something right and then you can use things like open policy. Agent and I've got another talk in this series of sessions on open policy agent for finding these problems, but you need some kind of policy as code to tell you. And we bake into fug. When we learn how one of these exploits happens, we add rules into fug. I told you, the compliance frameworks don't really think about things like IAM role assumption. Well, the fug best practices does because we saw that bad guys are using this. So we build in the rule. All right, we're not going to do live Q A, but here's our web address. That's my personal email address. Feel free to reach out. I love talking to folks about this stuff. And yeah, thanks very much for your time.