 Hello and good afternoon DEF CON. I'm Gerald Steer. I'm Sean Metcalf. Brief background on me. Dark Paw on Twitter. 10 years red teaming, pen testing, government private sector. I've been on the cloud enterprise red team at Microsoft since 2014. Spoke at Blue Hat beside Seattle. And I spend most of my day breaking Azure. One of the largest networks in the world. It's a really fun thing to do and we're going to talk a little bit about that today. Cool. I'm Sean Metcalf, founder of Trimark, security company, a Microsoft certified master in active directory, one of about a hundred in the world. And I've spoken at a bunch of conferences as well as DEF CON. 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 80security.org. Alright, so the cloud. We're going to go through a little bit of what you need to know about the basics. What's in it for you as an attacker? How you do recon 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, your client is using the cloud whether they realize it or not. It might just be a third party application or what, but they definitely are using it. Many of the traditional techniques we know do not work in this environment. Concepts are similar but require a new way of thinking for a new environment. Can I go after the client's cloud deployments? Well, we're not lawyers. If you're a professional you should have some of those, definitely. But the answer is in general, yes. Scope and access is going to 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 and make sure the customer understands. And some providers require an approval process. We're going to walk through some of the large providers and what their requirements are. Azure and AWS both require pre-approval via the account owner for attacking. Google cloud did not require that based on our research. They all have standard rules. You can only attack your client's assets, only the ones in scope, not going after other customer's things, limited to their ownership. No denial of service. Very typical for red teaming and penetration testing experts. Those shouldn't be too much of a surprise. One thing I like to call out, the Azure 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 for things like isolation escape. And that can be pretty lucrative as well if you manage to find one. 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 far as what you can access. Public cloud is what most people think of with AWS Azure Rackspace. Any of the big public 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 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 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 for redundancy and uptime purposes. So these are hybrid clouds especially need to be considered by the attacker because these are going to provide your opportunities to pivot back and forth between environments. Now there's all the as a service words and Albert Barron posted this pizza as a service chart on LinkedIn a couple of years ago and it's really a good description of what you have. You know, if you consider traditional on premise as a pizza you're making it at home, you're buying the ingredients, you're making it yourself, you're serving it up. You know, you are responsible for everything. And then you have infrastructure as a service or you're taken big 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. Delivery is a 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 very much like it's called serverless a lot of times or websites or functions or app services but all you're providing is the code. And that's what you're responsible for. And then there's software as a service where everything is outsourced and managed by the vendor. This is going to be your Google docs, your office 365, your sales force. As an attacker, this is the most limiting target because you can't go after the infrastructure that supports us 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 attack the infrastructure if we can grab an API key and pull that data anyways and we've succeeded in showing the risk to the company. So let's look at the cloud as an operating system under itself. The same idea is different words. This particular set of slides came from an amazing talk by some of my co-workers, Sasha Faust and Andrew Johnson. It was given an infiltrate. It deals completely with post-exfol- post- excuse me, exploitation in the 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's 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 route in the cloud environment is equivalent to domain admin in a traditional domain. If you can own the account of that level, you can own all of the resources within the account. And we often have a lot of times with privilege assignment here where people who shouldn't have access like a billing administrator is just added as a subscription admin so 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, owning subscription is equivalent to owning the cloud domain. Rather than passing hashes, we're looking for credential pivots. We're going to go in a lot more detail on this and various types of credentials used in 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 Matt had never been invented. This is awesome for attackers and not so great for defenders. 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 than it would be tucked into the crunchy center of somebody's data, well protected data center. And then rather than RDP and SSH, which you still have on IaaS boxes for mode 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 question is where's the data? All cloud services rely on some type of data storage for nearly everything. Whether it's a bucket or storage account, when you have a virtual machine or a service, it's writing that data to a account that you can access with just a storage key or API key. You might not need to attack a virtual machine at all if you can just dump the drive for that machine out of a storage account and pull what you need out of it. So as an attacker you've got to look at 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? So at this point I'm going to hand it off to Sean to talk about ways to do some reclown in the cloud. Hey Defcon, how's it going? Excited to be back again. So let's look at reclown in a cloud type environment. You have a customer, they've hired you to come in and pentest, red team, their environment and they said we want to 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 always has been. It's there. People put a lot of things into 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, 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. But you can look for companies that are using Office 365, Google Apps. They also have MX records for the specific security hosted email systems. So Proofpoint, Cisco, Siren, CSC. All of those we can 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 text record for Office 365, they give some interesting information about how their email security is configured. So at this point you know that they have Proofpoint or something else and so when the email comes in it's going through that security system and then it's being delivered to their mailbox. So when you're designing your phishing campaign you want to 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 semantic MDMs that are configured here and they actually point to what that system is running on. Or if their domain, their website is running Azure websites. And then the things that I thought was really interesting was Paychex, 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 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, et cetera. And some of these you can even leverage as party or spear phishing campaign because obviously they're doing business with them. And if there's a couple of different subsidiaries in this company, you could actually leverage this for one of the subsidiaries to send to the main one in order to make that part of the phishing campaign depending on what's in scope. And then the other part of it would be pretty interesting is looking for Federation servers because ultimately that's the key to authentication within the cloud. And since there's no standard naming 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 of these actually are registered in our SC names and then point back to what the Federation server actually is. And we can do DS queries for a number of these, ADFS, et cetera. STS seems to be one of 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 web page. We can look at the headers, which gives us information about what kind of server it's running. So if it's running IIS, it's probably an ADFS server, ADFS proxy. And we can get some 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 can look to see where their auto discover is if they're using a Microsoft-based email system, which a lot are. And then we can identify the OS server that's there. And we can also identify what version of exchange O is running by looking at this copyright banner. It's running, if it's copyright up to 2006, then it's Microsoft Exchange 2007. So how does this tie together? We have cloud, we have federation, we need to combine these things somehow. And ultimately it comes down to the authentication that's leveraged. So we have authentication and authorization just like we've always had. Authentication is identifying and confirming that who you say you are, 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 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 Federation, WS Trust. And so in a federation world, ultimately the user authenticates locally within the on-premises environment, often an active directory. They get their Kerberos ticket and they open up their web browser and they hit the link to go to that cloud app or those multiple cloud apps. And what ends up happening is that cloud app bounces them back to their federation system because they don't have a token. Or 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 they hit that federation server, the federation server checks their identity, adds the information into that token, such as claims, and makes some assertions about that user. And since that cloud app trusts that token because it's signed by that federation server, that cloud app is going to make the decision as to what that user should have access to. And so I'll talk about EDFS for just a minute here because the Microsoft Active Directory federation server is pretty common, pretty widespread in environments that are leveraging Microsoft services like Active Directory and certainly if they're leveraging Office 365 or Azure. And so the ADFS servers are going to be inside the network joined to the domain, that's key. And there's going to be a proxy server that's going to be out in the DMZ or directly connected to the internet. With 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 HDBS communication into the system and then some token decrypting and signing search. Now these last two may actually be the same search. They are often internal search whereas the service communication search is often one from a CA trusted by the internet. And so in ADFS, the organization is going to set up a relying party trust which is that cloud service and application that they want to 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 from 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 kind of what ties all this together. And most of the time this is what's used when we're talking about federation. Security assertion mark up language. And it's basically just to support this web browser single sign on. And there's three roles. They should be very interesting or very similar to what people are used to when you're going after an active directory environment. Right? You have your user, your identity provider and your service provider. Just like in AD of your user, you have your KDC or your domain controller and you have some service, some Kerberos service running on a server. And so what ends up happening is user goes to the federation server or the identity provider and proves their identity, gets those claims in that token and then can access that service provider. Just like in Kerberos. And so SAML in this instance is specifying the assertions that are handling between these roles or what's required in order for that service provider to identify that user and know who they are. So it's providing a broker type service. Now SAML is authentication method agnostic. So it could be active directory, it could be LDAP, 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 occurs inside to ensure the trustedness of the whole system. And so the key points here is that the certificates really matter. Certificates on the 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 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 what happens a lot on the internal network and the server that is going to be connected to from the internet is running HTTPS. It has to be available in order for users that are connecting in from the internet in order to use federation and connect to these cloud resources. So here's where it gets interesting. This federation is effectively like a cloud Kerberos. And so just like with the domain controller where the Kerb TGT is the thing that signs all of those Kerberos tickets. On the federation server those certificates are 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 find them elsewhere as Casey mentions then that means you can spoof access to any cloud service you want provided that that organization has a trust with that. So we're looking at kind of a golden ticket in the cloud environment. So ultimately by sealing this and using many cats 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 provides single sign on for users they can then connect to the cloud services pretty 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 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 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 those user accounts and groups and etc into Azure and what's interesting what I want to 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 part of this is there's a component here I want to call out called replicate directory changes and replicate directory changes all does that anyone know what that's for or how that could be 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 is not using password sync feature with password sync feature is where that password hash is hashed again and then sent up to the Azure AD environment and that way users can actually log in without going through the on-premise environment. Now if they click the custom permissions button then they can go through and select these individually but even if they're maybe thinking about this password sync they might 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 might notice that there's an Azure AD account that actually has these very 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. Well once we have an account that we can leverage because remember those accounts inside that organization typically have cloud access cloud permissions we can get information about that company as configured here I'm using Office 365 as an example and using that O through 65 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 replicate directory changes rights but this is not set then you can let them know that hey you're over permissioning this account. We 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 their cloud environment and the other thing we can do is we can five 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 principle names and we can identify that there's a dino-dna.engine-tech.co there's a secure.engine-tech.co and there's a unix-systems.engine-tech.co 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 and in Office 365 in an Azure, Microsoft has a REST API that allows access and enables you to enumerate a lot of data about Azure AD. So on the on-premises environment you have LDAP. In this Azure AD cloud environment you have a REST API and the Graph Explorer 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. 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 QuickStart installation scripts, things that set up the VMs very quickly, configure them for that environment but they may not be secure. They usually aren't. And so you want to 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.com where customers could actually upload and put data and documents into docs.com and then share them with their employees, share them with customers. The problem was that a lot of people clicked too many times and allow it world readable, which meant that a lot of sensitive documentation was available here. Kevin Beaumont actually highlighted this in Twitter and said, hey guys, there's a lot of information here and guess what? It has a search feature. I can find all this through docs.com. Microsoft said, okay, we're going to remove the search feature. There's still Google. 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. 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 the cloud is a problem, cloud security failure, data exposure, like, you know, the sky is falling, the cloud is burning, right? Not really. So some more reasonable headline is human error, because that's what it is. So if you're hired to evaluate the environment and the cloud assets, definitely look at their Amazon S3 environment. Look at docs.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 emailed their customers and said, by the way, you have some data you're sharing on your Amazon S3. You probably want to look at that. And there was a great blog article on detectify.com about how these configurations were configured, how to fix them. The most interesting part of this for pen testers 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. And now I'm going to turn it back to Gerald who's going to talk to you about how credentials are used in the cloud. So we have hashes. We have our home succeeded. All right. So we've got all the hashes. We have the KERP TGT, 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, we're mostly interested in certificates and private keys and API tokens. So what has this done? Well, it's made dev, popping dev boxes more productive than ever. I pretty much made my career on stealing secrets off of dev boxes 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. There's even more of these secrets. And you do know MemeCats can export certificates, right? The non-exportable flag in Windows is more of a recommendation than a requirement. And it's pretty easy to bypass that. If there's any of my Windows colleagues in the audience, I would really like to see this move to the cred guard secure boundary at some point so people stop exporting non-exportable certificates. And what is old is new again. Password spraying. Hey, this is like for us old people, it's 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 accounts 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 and references that do this as well. 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, they probably have what you're looking for. If you are not pillaging the internal source repos and the shares on developers workstations, you're doing a pretty poor job as a red teamer in pentester because they are usually loaded with juicy secrets. Or maybe they just checked them in the public get as Sean showed earlier. 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 gets packaged up and published out constantly. Every time someone checks and it can change. Well, if I'm on the developer's box, can I just ride along on that check in and get myself into production without ever even compromising a secret? It's another way you can trade in network access for access somewhere else. As I mentioned, keys are everywhere. Leaks into GitHub have been super common. People leave their access keys on their desktops, download folders are a great place to dump dev boxes. And then what do we do with all this though? What's our access? If we have on-premises access but our real target is data, well, let's find a way to get a cloud access and trade that in. Very similar. You have cloud assets 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 and 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 there 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 might just reuse the same account for a live ID or an Amazon account that they're using to manage their entire company's domain. That's something worth trying and it works more often than it should. In the end of the day, we are here to provide value and service to the people that hired us to attack their stuff. I love my job, it's fun, but really my ultimate goal is making sure things are more secure. So what do we do about all this? First, and I think most important when it comes to cloud environments is properly managing credentials and secrets. Most of the big clouds all provide some type of automated credential store and if your clients and you 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 of times your cloud identity is the same as 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. Reviewing permissions, as Sean mentioned, a lot of stuff gets made public that's never meant to be, that's a really big issue. Check your VPN access because 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 and these providers provide ways to limit this but it's just not used a lot of times. Least privilege and least access 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 you in like a secure admin workstation for your domain controllers and your privileged 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 cloud account with the same account they check their email with they're just a fish away from your entire cloud environment being under somebody else's control. And credential management is absolutely key because there's 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 opportunity for attackers and it's not so great on defenders because a lot of times they aren't necessarily easy to handle even if you know they've been exposed. So when it comes to federation there's a few things that are important to do. We want to make sure that federation servers are protected at the same level as domain controllers. That proxy server is important to prevent that communication from coming in from the outside. Auditing that cloud authentication getting that logging to make sure that environment that this info security team actually knows what sort of authentication is incurring. And so if there's something that looks weird they know what that is. So I'm going to cover some more recommendations and then Gerald's going to do a demo so that we can see kind of what all this looks like put together. And multifactor 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 protect and control that cloud authentication via federation rules. And so in this instance we can ensure that users internally maybe they're a little more protected. They can connect in to their cloud services through a single sign on they don't need anything more than their username and their 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 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 that when we tell our customers here are 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. Amazon provides 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 they can do that. And know that these events that are gathered by the cloud provider can actually flow into their SIM or their central logging tool. And of course acid inventory is even more critical on the cloud because new VMs could be spun up all the time. And of course every organization should assume that there's some sort of breach. And that's about what we're going to talk about now. All right. So we've been hired to hack SysCo. Fairly easily got domain admin on one of their subsidiary domains for an offshore developer via some phishing. But so far their 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 going to start with our internal access, do some recon, figure out where we are, pivot through the cloud and eventually end up inside the corporate network. Here's me running my favorite interpreter on a developer box. First thing I'm going to do is pillage their downloads directories because when you go to a website and ask to download your keys or your publish settings file which is basically a self-contained all-in-one PON Azure file. It has your private certificate in it. They just dump them into their downloads folder and usually forget they're there afterwards. So let's go ahead and try that. Rook Key is the AWS very similar version. It's an API key that gives full access and it comes in a nice handy plain text file. So yeah, these problems are not cloud specific. They occur across all clouds. Well here's the publishing settings. I'm using a really handy third party tool called Azure Management Studio to make this easy to visualize. Normally I'd just be doing this all through the API. But oh no, 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 gained 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 Automation which sounds pretty interesting. 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 and what they look like is super important. So I'm going to elevate to system. Go ahead and patch the crypto API so I can bypass the annoying no export flag. And then I'm going to dump the certificate. Here's a quick example of, in this case I got the public key and then immediately following out the private key. If I hadn't done the patch step first I would have only gotten the public key because that is a non exportable certificate which like I said is more of a suggestion. So then I can take that certificate, convert the base 64 into a pfx file and go back to Azure management studio. I got the subscription ID out of the 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 developers box there's a good chance it probably does. Let's go ahead and successfully authenticate to Azure and see they're running a couple of system services. Synth web 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 going to, this VM is running. I don't want to 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 .NET apps at all web config is your favorite friend. I'm going to pull this 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 there's probably a VPN involved somewhere. It could just as easily be to a public IP. 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 SQL server to the public. But it is exposed to their cloud server. Thankfully they just ran as SA. That makes our lives a little bit more easy. So at this point we probably need to get 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 set up a permanent link to their cloud environment. If I want to get code running on this box and 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. There's a good chance this will get caught if the monitoring team is doing the job but if this was set up by some DevOps team that didn't consult their defenders there's a good chance nothing on the VMs being monitored. And that's really important to consider is 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 you know I would normally have gone in through launch some interpreter through remote shell but I just want to 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 of 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 what I want to say is 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 rather than us giving you advice. So just to summarize what Gerald showed is we had a subsidiary that was completely separate in their own active director environment. They did development for this cloud environment. Gerald compromised that developer box, pivoted to the cloud, got onto the 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 now has moved into that corporation and continues to move and plunder. So great job, Gerald. Thank you all very much. Thank you all. Appreciate it.