 Coming up Dylan's going to be presenting on that. So please welcome him to the stage Thank you for the kind intro So my name's Dylan I'm relatively new to giving toxic cons and also knew before camp So in front of mine invited me to go to a hacker conference in the middle of the woods. I submitted a rather traditional Talk and after kind of coming through some of the other talks I'm not quite sure if I got the motif perfect. So I apologize. There won't be any creme brulee at this talk I'll work on that for next time though. I made a tool and I'm trying to give it back to the community and share it with folks That's basically what the talks on So that said Yes, so like about a year and a half ago. I Was struggling with this problem of basically Secrets being committed to source code secrets being passwords API tokens things like that It was something that a lot of developers. I was working with we're struggling with so I'm an application security engineer And I tend to work closely with developers But it's also a problem that I myself have been guilty of in the past So I wanted to just make a tool to basically be able to identify or quickly flag these secrets So that they don't get buried in a mountain of source code And so That kind of begs the question of like why is it bad to have the secrets in the source code in the first place? I'll list a couple reasons here, but really like there's there's a lot of reasons these secrets can often lead to Really bad problems and you want to be really careful and sensitive where you lock them up They can definitely the breaches they can help with lateral movement if you've Infected one host and you find the source code on that host and there's secrets in it You can move laterally to another host you can elevate privilege if you have a particular permission set on one machine You get easy access to secrets. You can move up to root or Move to another system with elevated privileges Workstations get lost all the time people's laptops get left on trains if you don't have full disk encryption And your secrets are just lying around in source code on the on the hard drive Even if you evoke access to the to the workstation There could be other secrets in there that you do you have to worry about And really the last bullet point here is one that I'm most worried about source code is like really leaky Even if you try to keep it like really locked down Ultimately in some capacity some of your source code is gonna end up on the internet Whether that's a insider that intentionally posts it an insider for convenience. That's just temporarily posting it over pay spin Or You accidentally expose a dot-get directory You know if you spend some time on an abseq team, you know that like give it enough time It happens and if you've got API keys and tokens in that source code You're basically giving an attacker access to systems directly after they get that source code so I have some public examples of When this has been a problem that I can speak to and then I have a lot more Non-public examples that I've reported through bug bounties and such that follow the same motif so this one is a pretty esteemed security engineer of hacker one read he's involved in the local security community in San Francisco Basically a security researcher came in and was like You know I went through your personal github repository and I found an API access token on your on your github And he submitted that to hacker ones hacker one program and read was really cool about it he paid out the researcher to brand and Ended up making that issue public so that we can bring some visibility to the problem but it kind of Helps illustrate how leaky these things can be where this was like a personal github and a personal account But it happened to have like an environment variable or a AWS token that was related to hacker one This is a little bit more of a public example, but basically Some researcher went through github searching for slack API access tokens and found more than 1500 live tokens And if you imagine slack that's another place where people potentially put secrets and passwords So if somebody posted an access token to their personal github for a work account for like a bot that working on or something like that or Maybe something was open sourced with a slack token and a attacker could use that to dump slack history and potentially get more keys And move laterally further from there and Then this is you know again stepping it up a little further These are AWS tokens that were committed to github. I hear a malicious actor stole these AWS tokens and use them to mine Bitcoin which ran up a bill of over two thousand dollars Which is kind of funny, but also kind of sad But also like if you work app sec, this is this is all really familiar like devs commit AWS tokens all the time stuff gets open sourced AWS tokens end up in places that they shouldn't and then last probably the most notable example that we're all familiar with the the time that accidentally committed an AWS token to public github and a researcher Found it and then maybe blackmailed them for a hundred thousand dollars The details on that are a little fuzzy, but it definitely made national news and the Uber CISO went and talked to front congress about it. It was it's a big deal for it You know a dev accidentally pushing an AWS token, which is again a really systemic common problem. We're all familiar with So that this is not a talk at all on how you should manage your secrets There are a ton of answers to that and a ton of tools for that I have a couple examples up on the board, but that's completely dependent on your environment Pick the secrets management solution that is best for for you and for your environment This this is more of just a talk of getting those secrets out of your source code So here you see that the secrets management solution is like the the fence and then Truffle hog is the border collie up there in the top left corner hurting the secrets into the secrets management solution It's it's designed to identify Secrets and get them moved into your secrets management solution So The interesting thing here like before I mentioned a couple of different ways that source code can get leaked It seems like source code lives in one place, right? It lives in version control But when you stop to think about it like we paste source code all over the place, right? It lives in package managers Your mobile applications every app you download you're downloading the whole source code of that app We paste snippets of source code in Slack When you go to a website you download You know tremendous amount of JavaScript and HTML and Then on the bottom there Revision history so not just the current incarnation of your version control But also the past incarnations of your version of your source code All of these places are places that I and other researchers have identified Secrets have have leaked it's kind of just like a law of large numbers If you have a if you have a large enough volume of source code Somewhere in there secrets are gonna make their way in AWS tokens it sounds crazy like who would package an AWS token in an APK mobile app and then put it on the public Google Play Store, but sure enough. It's it happens So, you know highlighting that last point there this is a pretty standard github repository It's actually the Facebook react one and on the top the screen It's all the source code that was added to the project that the red is kind of what I'm more interested in That's where source code was taken away from the project So as time goes on people are changing features. They're adding new code, but they're also taking code away But if you go to Facebook's react repository online all that code they took away is still there It's just buried in the version control Which for any other vulnerability isn't a problem because you bury a cross-site scripting in the past Nobody's gonna dig it up and become vulnerable to cross-site scripting But if you bury a secret in the past and that secret is live You can still use it and so that that to me Was was a problem like we could come up with some Rejects and greps to find the secrets in the current incarnation of the source code, but there's an equal amount if not more Red in the past source code that we're just completely ignoring if we take that approach and So this is an example of something that I pulled up recently But you can run the search today, and it'll be the same thing if you search removed password in github You'll just find In this particular instance, this is 300,000 results of Commits of people accidentally committing a password, and then the next commit committing over the top Pulling that source code out of the current incarnation But again, you could just click these links and get access to that token Right hopefully they changed the password Ideally they would have nuked that commit entirely as well But they they didn't end up nuking the password and it's a game of law of large numbers like if you Evangelicalize that you need to rotate your password given enough devs at least one of them won't and Because it's really easy to run these searches and an automate a tool to just go through and check which ones are live a Lot of them are gonna be live Yeah, well Yeah, well, that's another good point I'm gonna talk more about that later. This is a hard problem. It really is but Yeah, so this this is Again just sort of highlighting the scope and depth of this problem and again if you run through these You'll find some that are live and you'll find some that point to some pretty notable companies So so some reasons why you may have commits like this A developer may have Like I mentioned before removed it by mistake or like an entire feature may have been removed. Maybe you were using AWS SQS offering for storing large blobs of text and at some point you decided you wanted to switch to S3 So you delete a large swath of source code which includes an AWS token You're using for SQS and you replace it with an S3 source code token Maybe we catch the S3 one when we do our source code review But you're not going to carry that catch that SQS one that's buried And more often than not they end up still being live and the last one here is kind of a funny one that I've encountered a lot Basically, you know right before you go to open source something at a company typically You'll have like a whole approval process like legal security. You'll have to sign off on it They'll be like an open-source software review that the security team will quickly do just a prick cursory that they'll go through Look for any obvious vulnerabilities look for secrets in the source code. Well right before that review The developers are going to want to clean it up because they know it's not in a perfect state And so they'll go through and they'll just remove secrets and make it look better to try to get it through on the first try But often they don't purge it from the history. They don't rotate those credentials And so it's kind of ironic they go In going through the source code review the action that they do to clean themselves up Makes it such that the security engineer doing the review often doesn't catch the the hidden secrets They're only looking at the most recent carnation of the code So this is an example of like Basically when I first when I first got the the tool and I ran it I found this AWS Token in one of Netflix's repositories, and I got their permission ahead of time for using the slide But basically this is one of many companies where I found these tokens buried some of them live This one gave him permission some didn't And then this one was buried in an old incarnation But not in the current version of the code and that's still there by the way they rotated the cred But they didn't pull Access token probably worried about breaking force push and all that so you still do this in a very commit So we have to have this we have to solve this problem with being able to scandal commits And we can't run grep on the dot get directory because I'm not an expert in a get Protocol but the way these binary blobs are stored a dumb grep doesn't work on them Right, yeah, so basically Long story short, this was the problem that I was trying to solve of like we need to go back and find these keys and so truffle hog was the the solution that I came up with that and What's What's kind of interesting is I actually didn't spike on doing rejects is initially I'll get more on that later But I ended up adding rejects So it's what it's trouble hard. It's an open-source tool that specifically stands get repositories Doesn't currently have SVN or any other support Goes all the way through all the old revision history. It searches every branch And it's it just looks for for secrets. I made it as like a security audit tool But I've tried to pivot that lately to make it more of a DevOps tool to switch it to more of a proactive flow rather than a Reactive flow and I'll talk more about that a bit So, you know, like I mentioned, I didn't build this out with Rejects is initially because I didn't want to have to write a rejects for every secret on the planet Which later I realized I had to do But initially I just I just look for high sources of entropy More often than not if it flags in a high source of entropy it Is a secret or a key? This this won't get everything it won't get low low entropy passwords for example And it will false positive a lot so you'll get things like URLs YouTube URLs and stuff like that flagging But if you're just doing like a one-time open source review or like a pen test or using this for offensive security It it works really well on entropy mode But if you want to automate this and stick in a DevOps pipeline and deliver these results to a developer It's probably too much noise is what I found So like I mentioned before like it's it's great for pen tests great for doing like a one-time open source review Really good for bug brownies use trouble hog on every company. You can imagine you'll probably make some loot out of it I before open sourcing it. I definitely ran it on some big companies and did that But the cons are like I mentioned before like you can't stick this in a DevOps pipeline without it flaring on a ton of false positives There's an example in the same Netflix Repository where it flagged on a false positive. That's the a URL that just has a lot of entropy in it It's a gotta commit hash and the entropy there is interesting because it's a 32 character hex string Which is the exact same entropy source that say a Facebook access token is it's also 32 character hex string So, you know, there's a lot of false positives with this approach. It doesn't scale. Well, it's not very good with with Reactive it's it's pretty good with proactive or I said that backwards, but So, you know, I eventually I caved I was like, alright, I got to just write some some regular expressions for like the really sensitive stuff And so I built out the the the regex flag in travel hog And so that that's what this is. So basically I added explicit checks for RSA tokens for AWS tokens for slack tokens for a Bunch of different really common Tokens that people commit to repositories and it made it extensible so that you could run your own rules It's better for catching low entropy stuff If you've got a password that you know people are committing a ton of times you could write a regex around that particular password structure around the Particular topology of the source code that usually introduces the password It scales a lot better. It reduces the noise if you turn off the entropy mode And you just rely on the regex mode and you can customize it for your environment Which just makes it a lot better for putting in DevOps pipelines There's a question in the front row here Yeah, I'm gonna talk a little bit more about that later the question was basically is is there is there a way to run this before you even do the commit and Is there a way to reject commits if it looks like there's credentials I Have built out similar things and I'm gonna talk about how you can build out things like that but there's a lot of pitfalls that go with that approach and Trying to block on things that look like secrets if you haven't actually verified them More often than not becomes a huge blocker because things like URLs and stuff like that will flag up So I'll talk about how we kind of address that in a bit But one of the big disadvantages of the regex mode is you miss types of keys that you don't know about So if they're using a Twilio off key and you don't have a regex for Twilio You'll just completely miss that in this approach and it still does require some manual triage out of the box like I said sometimes even with these regexes, there'll be some false positives and More often than not a lot of these keys will have been rolled but often they're live and figuring out Which is which requires some manual triage? So this is kind of the initial pipeline that I had imagined you have an incoming get commit hook travel hog runs on the get commit hook and then you have to have some sort of triage process and that triage process I'll talk a little bit more about in a bit, but that At this stage has to be a little bit manual Somebody will have to go in figure out whether or not that token is live figure out the right approach and how they rotate it Figure out whether or not they want to block this commit or whether or not it was a false positive and then you have to remediate you have to Move that secret out of the source code. You have to rotate that secret You have to handle the instant appropriately figure out whether or not you want to purge it from from commit history So Like we talked about before it can be a little tricky to If you purge it from commit history With a tool like BFG repo cleaner, which is a really nice tool for doing that It'll go through and modify your history so that it removes that token You end up with problems where you're out of sync with all of your co-workers So they'll try to do a poll and all of a sudden their history isn't the same as your history and you get all kinds of merge issues and so You know, I don't have a good solution for addressing that I do recommend purging it from the history that way Tools like travel hog don't false positive all the time with the rotated token But it isn't a perfect solution. It does leave some pain points You should definitely rotate the secret because after you pulled it out. Like I said before there's so many other places source code ends up You don't know where else that secret is it could be in Payspin it could be in Slack And then you're gonna want to keep track of all the secrets that you pulled out of source code just to enforce that They've been rotated. So you'll need some sort of key value store for that Yeah, another question Yeah, that's a really good point The the point raises basically if we're creating a centralized store of all the sensitive secrets in the company like that's It's it's in itself Introducing a kind of a single point of failure and that's that's totally a good a good point These secrets were and get and anybody could have ran travel hog to extract them But putting them in a single central single point of failure makes it a little bit easier and that's you know It's a hard problem definitely So basically Yep, one more question Yes, the question is like why take it out of the repo if you're rolling it and my answer for that is basically If you run another tool like travel hog or like a static analysis tool It'll flag up as a false positive in the future And we we want to minify that basically Looks like there's another question. Can we kind of hold? We can yeah, we can talk about it when I get through the slides basically at least some time for Q&A at the end But if you remember earlier like I talked about all these other places that that secrets end up like not just source code and basically This tool only addresses one of those secrets and so recently I spiked on another one of those places that source code lives And that place is package managers and the two that I put my main focus on was npm and pi pi Which is no JS's package manager and Python's package manager So what's interesting about these is basically? When you package a package to npm or pi pi it doesn't pull from your git Source code it doesn't know it git is it pulls from your file system it in the case of npm I think it pays attention to your dot git ignore file But if you had a Testing script that had a secret in it that you didn't commit to source code And then you just package it up and sent it to npm or pi pi That testing script will end up in npm and pi pi with your secret And then people will pull down your package and they'll run them locally and not know that that secret is there And you've replicated this aws token distributed across hundreds of people running your open source package and With worse is like again when you do this open source Review they'll review the security teams will review the git code They probably won't pull down the package and and review that And similar to source code Package managers have history They have versions and each of those versions can have their own keys So an older version can have a key that a future version doesn't have but that were that version can stay up And that key can stay live and somebody can go in and find it later so Basically what I found from experimenting is if you publish to 80 up a to npm or to pi pi and the description of your package contains the string aws anywhere in it There is a 2% chance that your package will have a live aws token in it So You know I talked about one of the reasons testing scripts another reason is you may have an environment variable sourcing script in that same Repository that you you just source when you run your code And so when you do your packaging to npm or pi pi you may accidentally package up that environment for a variable script Even though it never ended up in version control And then the last version here the last reason here is like experimental code when I do experimental code Again, I struggle with the same problem. I put secrets temporarily in the source code and then pull them out later Well, you may think well that experimental code isn't tracked in my current version of get and then you may package a new version To npm or to pi pi Thinking that only the current version of your your get is what's getting packaged But actually the experimental code also gets packaged and your your secret gets sent up So I'm introducing this new tool and I'll just fold this closure ahead of time This is like a really dumb name that I gave it My that the thinking was basically like it's it's you got packages So it's Santa going going through packages and for consistency. There's a hog at that and it didn't it didn't make sense Basically what Santa hog does is That's that's true. It doesn't have a very memorable name What Santa hog does is it it goes through npm and pi pi specifically and you may be thinking what about all the other package managers? Yeah, I just didn't spike on those but I know for a fact they have secrets in them as well I don't have a tool for them, but any other package manager you think of probably has the same problem And it runs the same entropy regex checks that travel hog does on npm and python packages It's open source, and it's it's on my github And so I have a Sample here of it running. It doesn't have quite a pretty of an output as As trouble hog does currently but here I ran it on on an uber package And you can you can see it's flagged on an AWS token it flagged on a bunch of private keys What's interesting here is if you actually dig into it a little bit and you look at that full path for the token It falls in a directory called node modules And if you know anything about node js the node modules Directory is where all of your packages dependencies live and in some of these paths There's many different layers node modules. This basically means these keys are dependencies of dependencies of dependencies So uber went to package this package and they accidentally packaged up their node modules Instead of allowing that to get installed when you pull down their package And one of the dependencies that uber used happened to have a token in it that had nothing to do with uber It was just some random person that open source this thing and then uber ended up packaging that dependency and then sharing that Random strangers AWS token in their package So, you know, it kind of just goes back to like the source code is leaky and even if this random stranger on the internet ended up Removing that token from their version of the package uber has already Repackaged it and put it in their package and it's propagated and replicated across hundreds of people's machines at this point So here's my revised DevOps pipeline Basically the inputs to the triage are different depending on what you're scanning and I've two things here that I'm scanning get and and Package managers, but you can imagine building out a scanner for slack or for G suite or for anywhere else You may be worried about source code or secrets ending up And then that just funnels into the same triage step None of that's going to change somebody still has to verify whether or not that token is live and in the same remediation step of rotating that token So Basically, I've open sourced these tools and I'm kind of a one-man show. I've had a lot of awesome people submit pull requests Some of them I've been able to service quicker than others It's kind of backed up recently because I've been working on a lot of talks and stuff like that But I could definitely just help from the community I do get to pull requests eventually and there's more features that I want to add. I could definitely improve the regex's and add more I'd like to be able to improve its ability to scan a range of commits currently it clones the whole Get source code and then it does the scan on a range, but it'd be nice if it only fetched the subsection Just to improve on performance Currently, it's not multi-threaded single-threaded all this stuff that I could use community help for and then lots more features that I can't even think of It's it's not my github, but again like feel free to drop me a message ahead of time if you've got a feature you're thinking about And you want to work on we can collaborate And then I pulled those regex is out because I know people are going to be building other tools like Slack integrations or whatever else you want to run these regex is on So those are available in a separate repo now and just a JSON file that you can you can import for your own needs So the last step here that I want to highlight We talked about the triage step and the really gross part is it's manual like nobody wants to manually go through a pile of false positives That's a that's a really gross job that people would get fed up with and quit. It's like that was their full-time job And so like you may be thinking like we can automate this right like I've had that thought a lot of times And I've actually built out automators in the past of like if you know it's an AWS token Or it looks and smells like an AWS token. Just test it against AWS see whether or not AWS Returns back. Yes, this is a true token and then you can automate the triage You don't even need a human to come in and see whether or not that token is a is a true positive or a live token You just completely automate it Well, so this is an example Verifier that does just that it takes in a token tries to do a SES call with the AWS token and then returns true or false for whether or not that token is there It's really nice, but there are some drawbacks to that approach I'll start by saying I'm not a lawyer But if you if you think about that uber example like uber packaged a Subdependency of a subdependency that included a token from some stranger that built this package in some weird part of the planet Uber had nothing to do with that So let's say uber built a system that automatically triaged whether or not tokens were flying through their DevOps pipeline And let's say it ran on every package before they packaged it to npm or pi pi What would end up happening in that case is they would end up pulling down this random stranger's token and offing against AWS with it and Because that stranger hasn't given you consent or permission to do that You're probably violating the computer fraud and abuse act. You're probably authenticating to a system that you don't have access to So you have to be really careful with this approach Road keys can appear in your source code that didn't come from your environment And you probably shouldn't use this approach for bug bounties for the same reason like Most time bug bounties will set up, you know rules that are like you're not allowed to move laterally Or like if you've gained access to this system stop testing And so if you set up this automatic verifier system where you're pulling down their tokens and offing with it Number one you're gonna give them a big scare because they're gonna see that token was actually used by a random stranger on the internet But number two, they probably didn't give you permission. You're probably breaking the CFA if you do that So I'm not saying you can't use auto verifiers. I'm just not a lawyer and I'm not gonna There's some interesting components to that and Then before I mentioned like there are all these other things that I didn't build scanners for Fortunately, some folks on the internet have built them for some of these applications So this is a really nice tool That some folks may have used before you put an Android package name there and it'll just scan for secrets But again like systemic problem with people packaging secrets and source code And in the Android store you can get AWS tokens and other gnarly secrets from folks that have packaged Android apps to that the public Play Store So this is a link to you all the things I talked about Trouble log the most popular one Santa hog the relatively new one and then just the standalone regex is if you just want to write your own Infrastructure for Slack or whatever else And that's that's basically All I have but I know there were some questions, so I want to open it up to Q&A if we saw them some questions Yes Does Yeah, so let me go back to the specific call the question was whether or not AWS has a has a an endpoint that allows you to Basically without performing any state-changing actions see whether or not the token is live this STS token will Just tell you the identity of the token. I'll tell you which AWS account. It's associated with it's relatively non destructive But it does return information That is potentially privileged information like the AWS account. It's associated with You bring up a really another point that I didn't get a chance to talk about but like not every API has a nice friendly API endpoint that you can hit that tells you whether or not the token is live and Some of them depending on the scope you give that eight that that token It's not really easy to Test whether or not that token is live without trying a suite of endpoints because it was only scoped to these endpoints And you don't know what scope the token is has you have to kind of test its scope and it's kind of messy and requires multiple requests But yeah, it'd be really nice if people building APIs built an endpoint specifically Designed to see whether or not the token was live built in terms of conditions saying we allow strangers on the internet to hit the Send point but that isn't a feature that I've seen anybody build Yes question Yeah, so the question was basically Developers are commonly pushing over the top of these secrets and they're not like rotating them and they're not like Rectifying the problem. They're just kind of burying it Is that more of like a human problem that maybe you can fix with like training or something like that as opposed to like a Technical problem that we can solve with it with a tool I'm kind of of the approach like I'm an engineer and maybe this is a bias But I'm kind of of the approach that like if you have a human problem like No amount of training is ever gonna completely get rid of it like law of large numbers You'll always have some percentage of your engineers doing this mistake And that's kind of where I try to supplement that gap with technical tools. Yes Yeah Yeah, that's a good point basically she said like This could come out of like almost embarrassment of like if you if you push something and you want to commit over the top of it But you don't want to have to deal with merge conflicts It's just kind of a quiet way to make this go away without anyone noticing And that that's a good point And I think like our technical solutions should should be accommodating of that in some in some capacity Yes And you try to bring out So do you have some good automation or tools for how to do Instead of testing your ear like this you test the key instead have as part Your CI checks. Yeah, anything says hey, this is an issue If it's retroactive it's always gonna be contentious so the point of this is to is to put automated checks in place So that's never retroactive So one yeah one possible solution is to have this is like a pre-commit hooker to build it into the ID Ede so that it doesn't even make it in the version control in the first place Yes Who's that question Try to roll this into your DevOps pipeline when you have one DevOps pipeline, but when you have like 30 different dev teams or Who knows how many dev teams with who knows how many different CIC pipelines it becomes a lot more difficult Yeah, like detection detection to take responsibility for security that teams need to dev teams need to do house First Yeah, that's a good point I think like more on that like if you're first rolling something like this out you want to be super light-dutch If you like aggressively go in with hard blockers and stuff like that You're gonna end up with a lot of unhappy developers and breaking production more often than not Yeah question in French I said that I immediately regretted it So then here's a great tool to help you And I would love that It's non-blocking, but as soon as you're pipeline triggers I'm not confident up to say this with a hundred percent, but I'm almost of a philosophy that like If if you start building out an app sec team before you have a good Ops pipeline ops story It's just like what are you doing? It's like you're just like adding issues to You know when there's more systemic problems that should be addressed first, I think Yeah, that's true That's also true Question back Yeah, yeah, I would not have fired that engineer Engineer Yeah Any more questions yep The language support for Yeah, so right now what Santa hog is is basically it will pull down the regexes that I have abstracted out truffle hog and Then it just runs those dumb regexes on the unzipped versions of your MPM in your pi pi package And it hardcodes the MPM and pi pi hosts I should abstract that out so you can run them on internal MPM and pi pi stand-ups But it's not extensible in the fact that like you couldn't easily have it scan Yeah, exactly another package manager you'd have to build out API calls for that Yeah Yeah, I wondered whether or not I should spike on like maven or something like that and I just decided because it was Like there was some kind of compilation step there. I decided not to start with that just start with Situations that just have raw source code being uploaded But yeah, all those things should be explored and somebody should should help me build that stuff out I think did you have a your hand up or your hat? Anything in the rear and then Thank you Yeah, so actually I apologize to every hog farmer out there Because of you Google truffle hog on the front page of Google you get this tool So for all those poor people looking for a hog slop and end up with this weird tech stuff, I'm sorry But yeah trouble trouble hogs pretty easy to find out if you want to find Santa hog and all the other stuff Once you find trouble hog, they're all under my username And then the links are at the end Yep Yeah, yeah, we're open S3 buckets another one Somebody once told me about a tool that will like recursively go an S open S3 bucket and then find Tokens for more S3 buckets and then off to those look for more tokens and just Yes bet that supposedly works, so yeah lateral movement in the cloud Any other questions? Well, thank you everyone