Spencer Gietzen, IOMs vs. IOAs in AWS | KringleCon 2020

hi my name is spencer keatson and today i'm going to talk to you about ioms versus ioas in aws um first a little bit much about myself i'm a cloud security researcher at crowdstrike and previously did pen testing over at rhino security labs you can find me on twitter at spangeets pretty much just tweet about the cloud so come check it out first we're gonna talk about ioms or indicators of misconfiguration they're signs of a potentially risky configuration in an environment essentially they help prevent bad guys some examples of indicators of misconfiguration are like public aws s3 bucket uh that could be data exfiltration overly permissive policy applied to a user that could be privilege escalation uh an im role trusts an unknown principle that could be some actor establishing persistence a lot of different examples or a lot of different things that this could be the reason they're indicators instead of just misconfigurations is because they're not always wrong a public s3 bucket might be supposed to be public if overly permissive policies apply to a user maybe they're the administrator of the environment so you can't just assume things are misconfigurations because they seem risky it's more of an indicator and needs to be looked into so discovery of ioms and environment there's a few different ways to do it you could do it natively in aws through something like aws config there's third party tools like cspm tools such as falcon horizon by crowdstrike there's open source scanning tools as well such as scout suite by ncc group so now we're gonna dive into ioas or indicators of attack signs that something suspicious is going on and it helps us detect the bad guys once they're in some examples i always like to start the examples with git caller identity because that's basically the who am i of the cloud and a lot of attackers do it just to figure out where they landed in an environment you know test the credentials see what the name of my user role is etc so that followed by something like a data exfiltration attempt might look like s3 list buckets they list out the buckets in the account and then they use put bucket policy or put bucket acl to make a bucket public and steal data through that it could be followed by a spam or a phishing attack through something like simple email service so you might see ses get send quota across each region in an account to identify regions that are outside of the ses sandbox meaning that they can send mass amounts of emails whether that's for spam or phishing or something else another example would be a bad ip address so this could be any api really it's just that a api call coming from a malicious ip address is definitely an indicator there is something going wrong and something suspicious going on so it's important to kind of check those things out discovery of ioas it's a lot different than ioms although there are cloud native services like aws cloud trail aws guard duty to monitor logs that might be flowing through cloudtrail and other sources um amazon event bridge just to build your own detections and respond to events and patterns that you might see in an environment that is are it's not already built into something like guard duty uh and then there's other open source hunting tools like trail scrapers one uh i have some links to that at the end but there are not many third-party tools or open source tools that really monitor and take care of this stuff even though they're just as important or maybe possibly more important than ioms but it's hard to say because they tie together so much so for example i'm going to do a case study on s3 data exfiltration and how the ioms compare to the ioas in this situation so we're gonna have an attacker and we're gonna have cloud trail logs of what the attack's doing essentially they're gonna start off with aws sts get caller identity we're gonna see a get caller identity log they're gonna run aws s3 ls we're going to see a list buckets log they're going to list objects in the target bucket that they enumerated we might see s3 list objects depending whether or not you have object level logging enabled aws s3 api put bucket acl and they're applying a public read acl to make that bucket publicly accessible we'll see a put bucket acl log and then maybe they finish up with aws s3 sync from the target bucket to a local folder or another s3 bucket to exfiltrate all that data that they have just found so we might see lots of s3 get objects lots of s3 head objects things like that but again this relies on object level logging so it's possible to miss it so in this scenario there are both ions and ioas that are applicable so we will say that the keys got compromised originally through a web application vulnerability um and that's an iom on its own then there's an overly permissive im policy applied which allowed the user to enumerate objects and buckets in s3 and exfiltrate that data all from one account and change the permissions by making it public non-existent or overly permissive s3 bucket policy applied kind of the same as number two just on the s3 bucket side they were able to perform actions that they shouldn't have been able to and then we'll say s3 object level logging was disabled so they actually missed out on some of the logs of this pattern or of this ioa these here are the kinds of things that con config falcon horizon scout suite etc detect and assist with remediation and findings and all that but there are also ioas taking place here so we're going to assume they're all coming from the same ip address and user agent because this is the same attacker and all these calls are going to be in a row so for that entry point which said it's a server-side request forgery in a web application so basically they steal the credentials from the ec2 instance metadata service following that they run who am i figure out who they are and what they can do or well not what they can do but maybe find hints about what they can do in the environment then they're going to list all s3 buckets and objects uh they made an s3 bucket public and then they exfiltrated all those objects and these are things that cloudtrail guard duty eventbridge trailscraper etc can help you find and identify and if they're all coming from the same ip address each one of these steps from a through e are going to be more risky or something we need to pay more attention to it's like in ssrf in a web application exploitation of that is bad news but exploitation of that plus then the im role on the ec2 instance is being used to run get caller identity that's a little more scary then if their listing has three buckets in the account and objects in those buckets that's even more scary then they make something public and it gets real scary at that point and by then they're stealing all your objects so these kinds of patterns and ioas can be built up or the confidence in them can be built up over time by adding steps to the process but it doesn't mean you need all the steps maybe you just have b c e maybe that's all you see but that's potentially lower confidence than a through e um for the same attack so it's you have to build around the patterns and detect what's likely what's not likely etc so through together a little uh just exercise for the viewer for anyone interested do it or not i won't know um but build an ioa pattern for an aws attack tool this tool we're going to use is paku it's an open source aws attack tool by rhino security labs so what you should do go to the paku github which is linked at the end identify one attack module in paku that you'd like to profile run it against your environment check out the cloud trail logs see what's unique see if you can iden or associate those logs with paku in particular or something like that can you identify the next time someone uses paku against you can you tell when cert these set of actions are scarier than other times such as if you can associate them with paku and you know that is being used that's much scarier than if you maybe saw the same actions being taken from just a regular user uh so this is just something kind of fun but again i won't know if you don't do it so have fun or don't um so thanks for listening and i wanted to shout out a few different people here uh the sans and kringlecon staff uh my team at crowdstrike daniel greslack the og aws security expert cloud security forum slack uh trail scraper scout suite and paku and check out holidayhackchallenge.com for for some some fun and uh thank you for listening to my presentation

Channel: KringleCon

Views: 745

Rating: 5 out of 5

Keywords: Holiday Hack Challenge, KringleCon, SANS, InfoSec, CTFs, CyberSecurity, Cyber Security

Id: KliCQbJT6YQ

Length: 10min 26sec (626 seconds)

Published: Wed Dec 09 2020