>> Hello and good afternoon, DefCon! I'm Gerald Steere. >> I'm Sean Metcalf. >> Uhm, brief background on me - I'm 'darkpawh' on Twitter, ten years - red teaming, pentesting, government, private sector. I've been on thee cloud enterprise red team at Microsoft since 2014. Spoke at Blue Hat , BSides Seattle and I spend most of my day breaking Azure - one of the largest network in the world. It's a really fun thing to do and we're gonna talk a little bit about that today. >> Cool. I'm Sean Metcalf, founder at Trimarc Security company. A Microsoft certified master and active directory - one of about a hundred in the world. And I've spoken at a bunch of conferences, uh, as well as DefCon. And I'm happy to be back again, thank you! And security consultant and researcher and I post a lot of interesting Microsoft security stuff on ‘AD Security dot org’. >> Alright, so, the cloud. Uhm, we're gonna go through a little bit of what you need to know about the basics. What's in it for you as an attacker? How do you read con in the cloud? How do you do some basic attacks? How do you get from on-premises to the cloud? How do you go back onto premises from the cloud? And some countermeasures. And then we'll walk through a bit of a demo scenario. So, really, what do attackers care about? What's in it for me? Well, as a security professional - whether you're internal red team, consultant, whatever - you're client is using the cloud whether they realize it or not. They might just be a third party application or what but they definitely are using it. Many of traditional techniques we know do not work in this environment. Con, concepts are similar - they both require a new way of thinking for a new environment. >> Yea.. >> Can I go after the client's cloud deployments? Well, we're not lawyers, uhm, if you're a professional, you should have some of those, definitely. But the answer is in general "Yes!". Scope and access is gonna be more limited in the cloud environment because it's somebody else's computer after all. So, you need to take that in mind when you're planning your operations; you need to spell it out in your reporting and how you're dealing with it. You need to make sure the customer understands. And, some providers require an approval process, we're gonna walk through some of the large providers and what they're requirements are. As you're AWS both require pre-approval via the account owner for attacking. Uhm, Google cloud do not require that - based on our re, research. We all have standard rules, uhm, we can only attack your client's assets - only the want and scope; not going other customer's things; limited in their ownership; no denial of service. Very typical for red teaming and penetration testing experts - so, it shouldn't too much of a surprise. Uh, one thing I like to call the 'Azure' - uhm, rules of engagement does allow attempts at breaking client isolation with the stipulation that any success is reported to their security team immediately. And there are bounty programs available as well, so, even if you’re not a professional red team or pentester you might want to look into cloud bounties, uhm, for things like, uhm, isolation escape. And that, uh, can be pretty lucrative as well if you manage to find one. [pause] >> So, what do you need to know about the cloud to get started? Well, let's talk about accessibility modifiers - much like programming, clouds have accessibility modifiers as so far as what you can access. Public cloud is what most people is what most people think of with AWS Azure, Rackspace - any of the big project providers which are available to anybody who wants to pony up the money to run their code or run their environments in those. Private clouds are usually internal to a large company or organization. [coughing] >> Where they provide resources to only their internal organizations or partners within a environment that's usually charged by the hour, you know, cross-charge or whatever - but that's pretty typical. And hybrid cloud is really becoming the common, uhm, pattern nowadays where large companies will host some components on premises in their data center and then farm out others to public clouds or multiple clouds, even, uhm, for redundancy and uptime purposes. So, these are, uhm, hybrid clouds, uh, especially need to be considered by the attacker because these are gonna provide you opportunities to pivot back and forth between environments. [pause] Now, there's all the "As the service words" an, Albert Barron posted this, uh, pizza as a service chart in LinkedIn a couple of years ago and it's really a good description of what you have. You know, if you consider tradition, on premise, as a pizza - you're making it at home. You're buying the ingredients; you're making it yourself; you're making serving it up. You know, you are responsible for everything. And then you have infrastructure as a service or you're take-and-bake - you've picked up the pizza from somebody; they've made it for you. But, you're responsible for cooking it and serving it. Then you have platform as a service where everything is done for you; uh, delivery is handled, you know, everything's handled - you just need to enjoy it. In this case, in the cloud, this is where you provide code to run on somebody's else's server. Uh, very much, like, it's, it's called 'serverless' a lot of time or 'websites' or 'functions' or 'app services' but all you are providing is the code. And that's what you're responsible for. And then they're software as a services where everything is outsourced and managed by the vendor, uhm, this is gonna be your Google Docs, your Office 365, your Salesforce. As an attacker this is the most limiting target because you can't go after the infrastructure that supports this in general. But it can be the most lucrative. Our goal is to prove risk to our clients - if we can do that by accessing their data and just dumping everything it doesn't matter that we can't access the infrastructure if we can grab an API key and pull that data anyways and we've succeeded in showing, uhm, the risks to the company. So, let's look at the cloud as an, an operating system unto itself. The same ideas, different words. Uhm, this slide, uh, particular set of slides came from an amazing talk by some of my coworkers, uh, Sascha Frost and Andrew Johnson. It was given at Infiltrate, it deals completely with post-infiltra- uh, post, uh, excuse me, exploitation in an cloud environment. I highly recommend watching that if you get a chance but let's look at this. Rather than a single server you have a service where everything is done for you - you're not considering about what box it's running on or anything - you're just asking for them to provide a service like a database and then everything behind it gets handled. Rather than a domain, you have an account or subscription and everything is contained within that container. So, rather than a domain admin you have subscription admins and this is a really key point I want you to take away from this: Subscription or account admin or root in the cloud environment is equivalent to domain admin in a traditional domain. If you can own the account at that level, you can own all of the resources within the account. And we often have a lot times with privilege assignment here where people who shouldn't have access like a a billing administrator is just added as a subscription admin so that they can handle the billing when they really should be handled as more of just administrative with no access. So, keep that in mind if you take nothing else away from this talk, is owning subscription is equivalent of owning the cloud domain. Rather than passing hashes we're looking for credential pivots. Uhm, we're gonna go into a lot more detail on this and various types of credentials used on cloud environments, But it's not just one type there's many different types you need to consider. Rather than private IPs we have public IPs. It's like Mac had never been invented. This is awesome for attackers! Not so great for defenders. Uhm, things are just out, open to the public because that's where they're designed to be. You know, they do implement VPNs and things like this but in many cases what you're after is a lot more accessible that it would be tucked into the crunchy center of some of these data, well-protected data centers. And then, rather than RDP and SSH, which you still have on IS boxes for remote admin; you're generally dealing with management APIs where you're making requests to the service to do something on your behalf. So, these are often your target when you want to make a service or cloud do something for you. But the real important questions is: Where is the data? All cloud services rely on some type of data storage for nearly everything. Cause whether it's a bucket or a storage account, when you have a virtual machine or a service - it's writing that data to a ser, to an account that you can access with just a storage key or API key. You might not need to attack, uhm, virtual machine at all if you could just dump the drive for that machine out of the storage account and pull what you need out of it. [coughing] So, as an attacker you've gotta learn what is your real goal? Do you need to get code executing on a box which might be well monitored? Or can you just download a copy of it and run it yourself? [pause] So, at this point I'm gonna hand it off to Sean to talk about ways to do some recon in the cloud. >> Hey, DefCon, how's it going? [coughing] [cheering] Excited to be back again. So, let's look at recon in a, in a cloud type environment. You have a customer that hired you to come in and pretest, redteam their environment. And they said "We wanna add cloud to the scope". So, what does that mean? How do we identify what sort of cloud services they have? Well, DNS is your best friend, just like it's always has been. It's there, people put a loot of things not to it to help services or resources and users find other services. Like MX records - we can find a lot of information from MX records..So, I did some scanning of DNS of a bunch of companies to see what I could find. And I discovered that you can find interesting information in DNS - which we've known - uh, but you can look for companies that are using Office 365, Google Apps, uh, they also have, uh, MX records for the specific security hosted email systems. So, Proofpoint, Cisco, Syren, CSC - all those we could find by those MX records. And what's interesting about this is when you find something like PP-hosted, which is Proofpoint, and then you find that there's a DNS txt record for Office 365 that give some interesting information about how their email security is configured. So, at this point you know that they have proof point or, or something else and so when the email comes in it's going through that security system and then it's being delivered through their mailbox. So, when you’re designing you're, uh, you're phishing campaign you wanna take that into account. You can also find some other interesting things in the txt records within DNS such as if they're using Amazon, simple email or their MDM system. I found a bunch of symantec MDM that are configured and they actually point to what that system is running on. Or if they're domain, they're website is running as your websites. And then the things that I thought was really interesting was paychecks, Docusign, Atlassian; just to name a few of these cloud services actually get registered and configured in DNS to identify this domain as a customer of that cloud service. And then we can take it one step further and actually look at those SPF records. So, the SPF records are obviously the mail sending systems - those that are authorized to send on behalf of a domain. So, we pair this information with the MX records and the DNS, uh, text records that I've already shown and you get some good information about what cloud service providers are actually being used by this customer. And then you can look and see Salesforce; MailChimp, etcetera and some of these you can even leverage as part of your spear phishing campaign because, obviously, they're doing business with them. And if there's a couple of different subsidiaries in this company you can actually leverage this for one of the subsidiaries to send to the main one in order, uh, to make that part of the phishing campaign - depending on what's in scope. [pause] And then the other part of it which is pretty interesting is looking for federation servers because ultimately that is the key to authentication within the cloud. And since there's no standard naming for these for these federation servers what we can look at is we can do DNS queries for a bunch of different a-records. And what I found interesting as part of this scanning is that a number these actually are registered and are c-names and then point back to what the federation server actually is. And we can do DNS queries for a number of these - ADFS etcetera. STS seems to be one of the,. uh, the more legacy configuration for ADFS. And then we can go and look at this web server to see what the configuration is. We can look at the data in the webpage; we can can look at the headers which gives us information about what kind of server it's running. So, if it's running AS, it's probably an ADFS server or an ADFS proxy. And we can get some in, other information out of it as well such as how long those tokens are good for and some other things about what domains hook into that. And we can identify if they have exchange on premises - well, we can look at that through the MX record but we look to see where there auto discover sis - if they're using a Microsoft based email system - which a lot are. And then we can identify the OS server that's here and we can also identify what version of exchange OS is running by looking at this copyright banner. It's running, if it's copyright up to 2, 2006 then it's Microsoft exchange 2007. [pause] So, how does this tie together? We have cloud, we have federation, we need to combine these things somehow. And ultimately it all comes down to the authentication that's leveraged. So, the authentication and authorization just like we've always had. Authentication is identifying and confirming that who you say you are and who you actually are. And then the authorization part is that component that says that you should be able to have access or you're a member of certain groups or you have certain attributes. And you should be able to access this resource, or,or potentially access that resource. And ultimately how that authentication happens depends on the cloud provider and the protocols they support - like OAuth, openID, SAML, WS, - WS federation, WS trust. And so, in a federation world ultimately, the user authenticates locally within on, on the on premises environment - often in actual directory. They get their kerberos ticket, and they open up their web browser and the hit the link to go to that cloud app or those multiple cloud apps. And what end up happening is that cloud app bounces them back to their federation system because they don't have a token. Or they don't, they don't have that cookie with that information that the cloud app needs to actually determine whether or not they should have access and what level of access they should have. So, to hit that federation server. the federation server checks their identity, adds the information into that token so it claims to make some assertions about that user and since that cloud app trusts that token, because it's signed by that federation server, the cloud app's gonna make the decision as to what that user should have access to. And so I'll talk about ADFS for just minute here because Microsoft acted federation server is pretty common,, pretty widespread in environments that's leveraging Microsoft services like action directory and certainly if leveraging Office 365 or Azure. And so the ADFS servers are gonna be inside the network, joined to the domain.That's key - Azure gonna be a proxy server that's going to be out in the DMZ or directly connected to the internet. With the earlier versions of ADFS you're actually looking at an ADFS proxy. With the newer versions you're looking at, like, a web application proxy that handles those requests coming in. And so this ADFS server is going to have three different types of certificates installed. So, the service communication for that initial HTTPS communication into the system and then some tokened decrypting and signing certs. Now. these last two may actually be same certs. They're often internal certs whereas the service communication cert is often one from a CH trusted by the internet. And so, in ADFS the organization’s going to set up a relying party trust which is set up a relying party trust which is that cloud service and application, uh, in that they wanna actually federate to and have a trust with. And then the claim rules are interesting because organizations can actually lock down how access occurs. So, they can say if we have Office 365 our users have to authenticate from within our network, on our domain and are not allowed to go to the internet at large, directly into that Office 365 environment. And we can force that through the federation environment. Often don't but it can be done. So, SAML is kinda what ties all of this together and most of the time this is what's used when we're talking about federation - 'Security Assertion Markup Language - and it's basically just to support this web browser - single sign-on. And there's three roles, this should be very interesting or very similar to what people are used to when you're going after an active directory environment, right? If you're a user your identity provider and your service provider - just like in AD you have your user , you have your KAC or your domain controller and you have service, some kerberos service running on a server. And so, what ends up happening is user goes into the federation server or the identity provider and proves their identity, gets those claims and that token and then can access that service provider - just like in kerberos. And so, SAML on this instance is specifying the assertions that are handling between these roles or what's required in order for that service provider to identity that user and know who they are. So, it's providing a, a broker type service. Now, SAML is authentication method diagnostics - it could be active directory, it could be LBAD - it doesn't really matter. But the key to this is the SAML messages are leveraging these certificates, these signatures. The SAML message itself is signed and there's a number of certificates are signing that, that occurs inside to ensure the, the trustedness of the whole system. And so, the key points here is that the certificates really matter. Civic, it's on their federation server matter because those are what are used to sign that token and the components in that token to prove to that service provider that "Yes, this user is who they say they are" and this is what, these are the attributes that they have; these are the claims that they have then you can use that to determine whether or not you should give them different types of access. And so, like I said, SAML is really, uh, what happens a lot on the internal network and the server that is going to be connected to it from the internet is running HTTPS - it has to be available in order for user that are connecting in from the internet in order to, uh, use federation and connect to these cloud resources. So, here's where it get's interesting - this federation is effectively as a cloud kerberos. And so, just like with the domain controller where the kerb DGT is the thing that signs all of those kerberos tickets. On a federation server those certificates is what sign those tokens that say that these users should have access. So, if it's possible to actually extract those certificates off of that federation server or potentially finding them elsewhere as KC mentions. So, that means that you can spoof access to any cloud service you want - provided that that organizations has trust for that. So, we're looking at, kind of, a golden ticket in a cloud environment. So, ultimately by sealing this and using manycast to actually export that certificate on the cloud server, we could get a lot of cloud access. And so, when we're talking about on premise cloud components we're looking at active directory, right? Provide single sign-on for users, they can then connect to the cloud services pre-intuitively, easily without having to log on again. But what's interesting about this is most of these cloud services provide or require some sort of synchronization from the active directory environment into that cloud service. And a lot of times they sync all of the users and all of the attributes into that cloud environment. And IT in that, for that organization may not even be aware of this because it just requires a regular user account. [pause] And, so, a lot of times many organizations don't even know all the cloud services that are actually in their environment. So, let's look at Azure AD connect which is used as a sync tool in order to synchronize user accounts in groups and etcetera into Azure. And what's interesting, what I wanna call out here is that a lot of organizations click the easy button - they click 'express permissions' which just runs through and sets everything in AD for them. Well, a part of this is there's a component here I wanna call out, called 'replicate directory changes and replicate directory changes all'. Any, does anyone know what that's for? Or how that can b used for an attack? DC sync, right? Those are the rights that are required in order to do DC sync, so, that means the Azure AD connect service account actually has these rights if they've hit 'express permissions'. Even if that organization's not using password sync feature. With password sync feature where that password hash is hashed again and then sent up to the Azure AD environment and that way users can actually login without going through, uh, the on premise environment. Now, if they've clicked the 'customs permissions' group, uh, button then they can go through and select these individually. But even if they're maybe thinking about this password sync they may have these rights that are configured. So, as you're operating in an AD environment where they're looking at using Azure or Office 365 you may notice that that there's an Azure AD account that actually has these high-level rights. And so, when we're talking about cloud stuff we're still talking about PowerShell, all of the major cloud providers have their own PowerShell modules. And they're really useful for administrators, probably for other things. But once we have an account that we can leverage, cause remember those accounts inside that organization typically have, uh, cloud access, cloud permissions. We can get information about that company as configured - here I'm using Office 365 and, as an example and using that O 365 PowerShell module. We get information about how they're configured; what the directory synchronization information is; if they're actually doing password synchronization. So, if you find that their account actually has those replicated directory changes rights but this is not set then you can let them know that "Hey, you're over permissioning this account". We can can get those Office 365 roles; we can numerate what the membership is and then we can identify those user accounts on their on premises environment to identify what access they have to they're cloud environment. And the other thing we can do is, we can find service accounts in their cloud environment. And why this is interesting is we can start looking at these URLs that are identified as part of the service principal names. And we can identify that there's a dino DNA; 'dot engin dot co'; there's a 'secure dot engin tech dot co; and there's a 'unik systems dot engin tech dot com'. And there's associated groups with these and these groups have accounts in them. So, as we're looking at their cloud environment we can start looking at these applications that are configured within their cloud environment and see if there's some interesting information there. [pause] And, in Office 365 and in Azure, Microsoft has rest API that allows access and it enables you to numerate a lot of data about Azure AD. So, on the on premises environment you have LDAP. In these Azure AD cloud environment you have a rest API and the graphics score on this, on this web page actually shows the type of information you can get. So, you can do like powerview type stuff in Azure AD through this website. [pause] And so, when we're talking about attacking cloud assets and looking to see what they have, it's important for organizations to understand that managing their VMs are still their responsibility. A lot of these cloud providers provide quick start installation scripts - things that set up the VMs ver quickly; configure them for that environment. But they may not be secure, they usually aren't. [audience noise] >And so you wanna check that and identify what those are. Get comfortable with what these scripts are and how Azure has them, AWS has them or any cloud provider has them. Look at those scripts; know what those are before you go into that environment. And so, Microsoft had 'docs dot com' where customers could actually upload and put data and documents in a 'docs dot com' and then share them with col, with their employees; share them with customers. The problem was that a lot of people click too many times and allows it world readable., which meant that a lot of sensitive documentations were available here, uh, Kevin Bowman actually highlighted this in Twitter and said "Hey guys, there's a lot of information and guess what? It has a search feature! I can find all this through 'docs dot com'!". Microsoft said "Okay, we're going to remove the search feature..." [laughter] There's still Google... [laughter] Kevin says "Hey guys, I can still see this stuff!". So, Microsoft went back; did some changes; shut it down for a little while; brought it back up and said: "Customers, please check your stuff; make sure you're not sharing your sensitive documents with the internet!". [audience noise] But, it's not just Microsoft. Just a few weeks ago we had Amazon that had some issues with S3, right? And by these headlines we would think their cloud is a problem! Cloud security failure! Data exposure! You know, the, the sky is falling; the cloud is burning, right? Not really... So, some more reasonable headline is "Human error" - cause that's what it is. So, if you're hired to evaluate the environment in the cloud assets, definitely look at their Amazon S3 environment; looks at 'docs dot com'; look at these things to see what you can find and help them identify these potential exposures before they get exposed by someone else. And so, Amazon actually sent an email to customers that said "By the way, you have some data you're sharing on your Amazon S3, you probably wanna look at that." And there was a great blog article on 'detectify' uh, 'dot com' about how these configurations were configured and how to fix them. The most interesting part of this for pentesters is there's an API to actually look for this data. So, you definitely want to read this article and kind of dig into that. Now I'm gonna turn it back to Gerald who's gonna talk to you about how credentials are used in the cloud. >> So, we all know how to hack domains and grab hashes and get the... [audience noise] [pause] Alright, who turned my mic off? So, we have hashes... [audience noise] Nope... [pause] We have our... [cheering] Yea! There we are! [applause] Sound succeeded, alright... So, we've got all the hashes; we have the curb DGT but your cloud provider really doesn't care. As Sean was just talking, they speak a different language; they speak federation, you might be able to get in, if the federation server that provides that permission is on your domain but you might not. So, what do we do? Well, creds never change - they're always good! The type of cred changes though, in the cloud world where mostly interested in certificates and private keys and API tokens. So, what has this done? Well, it's made dev; it's made becoming developed more popular than ever. I pretty much made my career on stealing secrets off of devboxes for internal lateral movement. Because nobody else paid any attention to the web configs that were on open shares and networks a lot of times. Well, now we have all kinds of things - we have private certificates which might be checked in the repos and we have these API keys. They're even more of these secrets, and you do know that needs can export certificates, right? Uhm, the non-exportable flag in windows is more of a recommendation than a requirement and it's pretty easy to bypass that. Uh, if there's any of my Windows colleagues in the audience that I would really like to see this to the red guard secure boundary at some point, so people will stop exporting no-exportable certificates. And what is all this new again? Password spraying, hey, this is like for us old people almost like being back in the war dialing days of trying a few passwords and moving on. I mentioned earlier - everything's on the public network now; we can do a little bit of spraying across their account and come back and it's API. So, this is really easy to do, you write a 'for loop'; call the API - there's some tools in the references that do this as well. Uhm, we don't have personal experience with those; feel free to look it up. But this is a really good example of taking techniques you already know and reapplying them to new environments. Devops, uhm, they probably have what you're looking for. If you're not pillaging the internal source repos and the shares on developers workstations - you're doing a pretty poor job as a red teamer or pentester. Because they are usually loaded with juicy secrets. Or, maybe they just checked them in the public git as Sean's shown earlier. Uhm, that's not really good either. And how are the deployments done? Well, most cloud services are done through a continuous integration model where everything just get packaged up and published out constantly - every time somebody checks in a change. Well, if I'm on the developer's box, can I just ride along on that check in and just get myself into production without ever even compromising the secret? It's another way you can trade in network access for access somewhere else. Uhm, as I mentioned, keys are everywhere. Uhm, leaks in the GitHub have been super common; people leave their access keys on their desktops. Download folders are a great place to dump dev, uh, boxes. And then what do we do with all this though? What's our, what's our access? If we have on premises access but our real target is data , well, let's find a way to get cloud access and trade that in. Very similar, you have cloud access that need to talk to things on premises, well, there's probably a data path you can follow. This is one of the key things to being a good attacker - is identifying all the possible data paths. Uhm, ask yourself, you know, how is the system communicating? Because that is often going to tell you where you need to go to achieve your objective. And really, is their shared authentication methods. People still love sharing passwords if you have an account that provides cloud access - you've got their hash and you can crack their hash and, who knows, I'm gonna just reuse the same account for a live ID or an Amazon account that' they're using to manage their entire company' domain. That's something worth trying and it works more often than it should. [pause] But in the end of the day, we are here to provide value and service to the people that hired us to attack their stuff, uh, I love my job, it's fun but really my ultimate goal is making sure that things are more secure. So, what do we do about all this? First, and I think most important, when it comes to cloud environments as properly managing credentials and secrets. Most of the big clouds all provide some type of automated credentials store and if your clients are not using these you need to learn how because this is one of the best ways to handle it. There are so many different credentials in the cloud; make it easy for people to do the right thing. MFA is huge because a lot times your cloud identity is the same as identity for another account. Make it mandatory and for things like SPNs that can't have MFA, make sure that they have as little access as possible and that you monitor it as much as possible for any deviation. Review your permissions, like Sean mention, uhm, a lot of stuff gets made public that's never meant to be, that's a really big issue. Check your VPN access cause it, things being open on the network has become the default again - open on the internet. But that’s not necessarily a good thing and a lot of times you can just ask "Does it really need to be open?" and the answer is "No". These providers provide ways to limit this but it's just ot used a lot of times. Least privilege and least access is still your best friend. All the clouds provide methods for managing these permissions which Sean will cover a little bit in a moment. And the idea of even, like, a secure admin workstation for your domain controllers and your privilege access. Just the same for your cloud admins, as I mentioned, they are functionally equivalent to domain admin in the cloud. So, they need to have the same sort of protections - if they're logging into their icloud account with the same account they check their email with , they're just a hish away from your entire cloud environment being under somebody else's control. And credential management is absolutely key because there are so many of them and you have to keep track of them; you have to roll them; you have to be able to do this in an automated way. This is a huge op, opportunity for attackers and it's not so great on defenders, uhm, because a lot of times they're not necessarily easy to handle even, even if you know they're been exposed. [pause] >> So, when it comes to federation there's a few things that are important to do. Uhm, we wanna make sure that federation servers are protected the level as domain controllers. Uh, the proxy server is important to prevent that communication form come, coming in from the outside. Uhm, auditioning that cloud authentication; getting that log in to make sure that, that environment that this info security team actually knows what sort of authentication is occurring and, and so if there's something that looks weird they know what that is. Uh, so I'm gonna couple, cover some more recommendations and then, uh, Gerald's gonna do a demo so we can see, kind of, what all this looks like put together. Uhm, and multi-factor authentication is important, certainly for these admin accounts. So, anyone that manages those federation servers probably should have MFA configured. And we can, as I mentioned we can con, we can protect and control that cloud authentication, uh, via federation rules. And so, in this instance we can Azure that users internally, maybe they're a little more protected - they can connect into their cloud services through a single sign-on. They don't need anything more than a username and password but if they're coming from the internet they have to use two-factor. And so we can also leverage those cloud provider security features. And definitely recommend to your customers that they do this - Azure and Amazon provide great ways to monitor what's going on to identify what, what resources are there and which keys have access to them. And you can actually restrict that, so even if an API key gets leaked out on GitHub nothing can be done with it because it's constrained in how it can be used and only from specific cloud assets. And then of course monitoring and learning is really important - we need to make sure what we tell our customers here are our recommendations you're monitoring. It's not your network but you still have to have a good understanding of it. And there's different tools from different cloud providers and how this can be done. Uh, amazon provides VP, VPC flow which is basically like net flow, except to another level. And so, defenders need to be familiar with all these tools as well and know that these events are gathered by the cloud provider can actually flow into their sim- their central uh, login tools. And of course asset inventory is even more critical on the cloud because new VMs can be spun up all the time. And of course every organizations should assume that there some sort of breach and that's about what we're gonna talk about now. >> Alright, so, We've been hired to hack SithCo, fairly easily got domain admin on one of their subsidiary domains for an offshore developer via some phishing but so far they're corporate network has actually been fairly well-protected. We did some recon and found that they host a bunch of websites out into the public cloud resource. So, how do we leverage this access to get to corporate? Well, we're gonna start with our internal access and do some recon; figure out where we are; pivot through the cloud and eventually end up inside the corporate network. Here's me running, uh, my favorite interpreter on a, uh, developer box. First thing I'm gonna do is pillage they're downloads directories because when you go to a website that has to download your keys or your which is basically a self-contained, all-in-one pawn Azure file which has your private certificate in it. Uhm, they just pump them into their downloads folder and usually forget they're there afterwards. So, let's go ahead and try that. Uhm, root key is the AWS very, very similar version and it's an API key that gets full access and it comes in a nice handy plain text file. So, yea, these, you know, these problems are not cloud specific, they occur across all clouds. Well, here's some publishing things I'm using - a really handy third party tool called Azure management studio that makes this easy to visualize. Normally I'd just be doing this all through the API but I dunno, this publish settings file is out of date, I no longer have access. But it's not a loss, they might have changed the certificate there but I gain a piece of information I'll need later which is a subscription ID which does not change. So, we're still on the developer box, let's see how they're communicating to Azure. Let's dump their certificate store. Well, they have a couple of Windows Azure tools encryptions, those are generated by visual studio. There's something called 'Azure Animation' which sounds pretty interesting. Uhm, they'll usually have common tools depending on what chain was used to make it, like, Windows Azure tools is a super common one. And like I said learning these for your cloud environment, what they look like is very important. So, I'm gonna elevate to system - go ahead and patch, uhm, the crypto APIs so I can bypass the, uhm, annoying no-export flag. And then I'm gonna dump the certificate. Here's a, uhm, a quick example of, in this case I Got the public key and then immediately following that the private key. If I hadn't done the patch step first I would only gotten the public key because that is a non-exportable certificate which, uh, like I said, is more of a suggestion. So, then I take that certificate, convert the base64 into a 'pfx' file and go back to Azure management studio. I got the subscription ID out of the, uh, publish settings file which was no longer valid. I now have a certificate on the box that may or may not work but if it's a current certificate on the developer's box there's a good chance it probably does. Let's go ahead and successfully authenticate to Azure and see their running a couple of system services. Uhm, Sythweb looks really interesting, let's take a look at this vm. As I mentioned before, a lot of times we don't need to compromise the vm to achieve what we want to achieve. Let's start with the storage, I'm gonna, uhm, this vm's running, I don't wanna interrupt things which might get detected. So, I'm just going to take a snapshot of the disk; download it to my local hard drive and start pillaging it like I normally would. If you're familiar with 'dot net' apps at all, uh, 'web config' is your favorite friend. I wanna pull the down and start looking for some interesting stuff. In this case it has access to a sql server 'as SA' in a private network space. Which indicates that there’s probably a VPN involved somewhere. It could just as easily be do to a public IP, uhm, but a lot of times this one was at least partially set up correctly. They put a VPN in place so they didn't expose their SQLserver to the public but it is exposed to their cloud server. Uhm, thankfully, uh, they just ran the SA that makes our lives a little bit more easy. So, at this point we probably need code running on this box to access this VPN. A lot of bigger companies have direct VPN access to their cloud assets through a direct switch where they permanent link to their cloud environment. Uhm, if I wanna get code running on this box then I have subscription level access, which I said is basically equivalent to domain, I can hit up MSDN real quick and see there's an API for resetting the password on any vm I want. Well, that's great, uhm, there's a good chance this will get caught if the monitoring team's doing their job but if this was set up by some devOps that did not consult their developer, uh, defenders, there's a good chance nothing in the vm is being monitored. And that's really important considering that is what needs to be fixed in the cloud world - is taking these into account. So, I'll go ahead, enable RDP on that box; log in and here's just a, you know, I would normally, uhm, have gone and launch through interpreter thorough remote shell but I just wanna show real quick. I now have direct access to the corporate SQL server via the VPN link from this vm which we compromised from a domain that was completely untrusted by pivoting through their cloud assets. And this is going to be a fairly common practice in the future; it's a good example a hybrid cloud environment where they're sharing data back and forth. And it absolutely needs to be considered going forward and I'm just about out of time so I wanna there is going to be a lovely narrated video up on 'ad security dot org' following the presentation of the entire end-to-end attack chain. I hope you'll enjoy that; it would have been boring just sitting here watching it in the talk, uh, rather that us giving you advice. So... >> Right... So just to summarize what Gerald showed, is we had a subsidiary that was completely separate in their own active directory environment and they did development for this cloud environment. Gerald compromised that developer box; pivoted to the cloud; got onto one of the cloud assets; saw that that web server actually had credentials for the corporate SQL server inside their corporate network; pivoted from that subsidiary, untrusted environment, through the cloud into the corporation and has now moved into that corporation and continues to move and, and plunder. So...Great job, Gerald. [applause] >> Thank you all very much! >> Thank you all, appreciated. [applause]