00:00:00.133-->00:00:05.138 >> Hello and good afternoon, Def Con! I'm Gerald Steere. >> I'm Sean Metcalf. >> Uhm, brief 00:00:08.041-->00:00:12.713 background on me - I'm 'darkpawh' on Twitter, ten years - red teaming, pentesting, 00:00:12.713-->00:00:17.184 government, private sector. I've been on thee cloud enterprise red team at Microsoft since 00:00:17.184-->00:00:22.189 2014. Spoke at Blue Hat , BSides Seattle and I spend most of my day breaking Azure - one of the 00:00:24.558-->00:00:28.896 largest network in the world. It's a really fun thing to do and we're gonna talk a little 00:00:28.896-->00:00:34.234 bit about that today. >> Cool. I'm Sean Metcalf, founder at Trimarc Security company. A 00:00:34.234-->00:00:38.272 Microsoft certified master and active directory - one of about a hundred in the world. And I've 00:00:38.272-->00:00:41.909 spoken at a bunch of conferences, uh, as well as DefCon. And I'm happy to be back 00:00:41.909-->00:00:46.713 again, thank you! And security consultant and researcher and I post a lot of interesting 00:00:46.713-->00:00:51.718 Microsoft security stuff on 'AD Security dot org'. >> Alright, so, the cloud. Uhm, we're gonna 00:00:54.554-->00:00:58.892 go through a little bit of what you need to know about the basics. What's in it for you as 00:00:58.892-->00:01:05.465 an attacker? How do you read con in the cloud? How do you do some basic attacks? How do you get 00:01:05.465-->00:01:11.872 from on-premises to the cloud? How do you go back onto premises from the cloud? And some 00:01:11.872-->00:01:18.845 countermeasures. And then we'll walk through a bit of a demo scenario. So, really, what do 00:01:18.845-->00:01:24.751 attackers care about? What's in it for me? Well, as a security professional - whether you're 00:01:24.751-->00:01:30.090 internal red team, consultant, whatever - you're client is using the cloud whether they 00:01:30.090-->00:01:34.795 realize it or not. They might just be a third party application or what but they 00:01:34.795-->00:01:40.334 definitely are using it. Many of traditional techniques we know do not work in this environment. 00:01:40.334-->00:01:45.339 Con, concepts are similar - they both require a new way of thinking for a new environment. 00:01:48.308-->00:01:52.779 >> Yea.. >> Can I go after the client's cloud deployments? Well, we're not lawyers, uhm, if 00:01:52.779-->00:01:56.850 you're a professional, you should have some of those, definitely. But the answer is in 00:01:56.850-->00:02:03.557 general "Yes!". Scope and access is gonna be more limited in the cloud environment because it's 00:02:03.557-->00:02:09.029 somebody else's computer after all. So, you need to take that in mind when you're planning 00:02:09.029-->00:02:13.533 your operations; you need to spell it out in your reporting and how you're dealing with it. 00:02:13.533-->00:02:17.771 You need to make sure the customer understands. And, some providers require an approval 00:02:17.771-->00:02:22.476 process, we're gonna walk through some of the large providers and what they're 00:02:22.476-->00:02:27.481 requirements are. As you're AWS both require pre-approval via the account owner for attacking. 00:02:30.117-->00:02:35.489 Uhm, Google cloud do not require that - based on our re, research. We all have standard 00:02:35.489-->00:02:41.762 rules, uhm, we can only attack your client's assets - only the want and scope; not going other 00:02:41.762-->00:02:48.301 customer's things; limited in their ownership; no denial of service. Very typical for red 00:02:48.301-->00:02:52.806 teaming and penetration testing experts - so, it shouldn't too much of a surprise. Uh, one 00:02:52.806-->00:02:58.078 thing I like to call the 'Azure' - uhm, rules of engagement does allow attempts at breaking 00:02:58.078-->00:03:03.750 client isolation with the stipulation that any success is reported to their security team 00:03:03.750-->00:03:08.555 immediately. And there are bounty programs available as well, so, even if you're not a 00:03:08.555-->00:03:14.428 professional red team or pentester you might want to look into cloud bounties, uhm, for 00:03:14.428-->00:03:19.366 things like, uhm, isolation escape. And that, uh, can be pretty lucrative as well if you 00:03:19.366-->00:03:25.472 manage to find one. [pause] >> So, what do you need to know about the cloud to get started? 00:03:25.472-->00:03:30.410 Well, let's talk about accessibility modifiers - much like programming, clouds have 00:03:30.410-->00:03:35.348 accessibility modifiers as so far as what you can access. Public cloud is what most people 00:03:35.348-->00:03:40.187 is what most people think of with AWS Azure, Rackspace - any of the big project providers 00:03:40.187-->00:03:46.126 which are available to anybody who wants to pony up the money to run their code or run their 00:03:46.126-->00:03:51.131 environments in those. Private clouds are usually internal to a large company or organization. 00:03:53.633-->00:03:58.638 [coughing] >> Where they provide resources to only their internal organizations or partners within 00:04:00.941-->00:04:06.480 a environment that's usually charged by the hour, you know, cross-charge or whatever - but 00:04:06.480-->00:04:12.119 that's pretty typical. And hybrid cloud is really becoming the common, uhm, pattern 00:04:12.119-->00:04:17.224 nowadays where large companies will host some components on premises in their data center 00:04:17.224-->00:04:21.862 and then farm out others to public clouds or multiple clouds, even, uhm, for 00:04:21.862-->00:04:28.635 redundancy and uptime purposes. So, these are, uhm, hybrid clouds, uh, especially need to 00:04:28.635-->00:04:33.306 be considered by the attacker because these are gonna provide you opportunities to pivot back 00:04:33.306-->00:04:38.311 and forth between environments. [pause] Now, there's all the "As the service words" an, Albert 00:04:41.915-->00:04:46.253 Barron posted this, uh, pizza as a service chart in LinkedIn a couple of years ago and it's 00:04:46.253-->00:04:51.258 really a good description of what you have. You know, if you consider tradition, on premise, 00:04:51.258-->00:04:54.694 as a pizza - you're making it at home. You're buying the ingredients; you're making it 00:04:54.694-->00:04:59.599 yourself; you're making serving it up. You know, you are responsible for everything. And 00:04:59.599-->00:05:03.670 then you have infrastructure as a service or you're take-and-bake - you've picked up 00:05:03.670-->00:05:09.609 the pizza from somebody; they've made it for you. But, you're responsible for cooking it and 00:05:09.609-->00:05:14.614 serving it. Then you have platform as a service where everything is done for you; uh, 00:05:17.450-->00:05:23.290 delivery is handled, you know, everything's handled - you just need to enjoy it. In this case, 00:05:23.290-->00:05:29.296 in the cloud, this is where you provide code to run on somebody's else's server. Uh, 00:05:29.296-->00:05:34.067 very much, like, it's, it's called 'serverless' a lot of time or 'websites' or 00:05:34.067-->00:05:39.806 'functions' or 'app services' but all you are providing is the code. And that's what you're 00:05:39.806-->00:05:44.377 responsible for. And then they're software as a services where everything is outsourced 00:05:44.377-->00:05:49.382 and managed by the vendor, uhm, this is gonna be your Google Docs, your Office 365, your 00:05:51.451-->00:05:57.490 Salesforce. As an attacker this is the most limiting target because you can't go after the 00:05:57.490-->00:06:02.429 infrastructure that supports this in general. But it can be the most lucrative. Our goal is 00:06:02.429-->00:06:07.801 to prove risk to our clients - if we can do that by accessing their data and just dumping 00:06:07.801-->00:06:13.073 everything it doesn't matter that we can't access the infrastructure if we can grab an 00:06:13.073-->00:06:19.479 API key and pull that data anyways and we've succeeded in showing, uhm, the risks to the 00:06:19.479-->00:06:25.252 company. So, let's look at the cloud as an, an operating system unto itself. The same ideas, 00:06:25.252-->00:06:30.857 different words. Uhm, this slide, uh, particular set of slides came from an amazing talk 00:06:30.857-->00:06:36.696 by some of my coworkers, uh, Sascha Frost and Andrew Johnson. It was given at Infiltrate, it 00:06:36.696-->00:06:41.434 deals completely with post-infiltra- uh, post, uh, excuse me, exploitation in an 00:06:41.434-->00:06:45.639 cloud environment. I highly recommend watching that if you get a chance but let's look at 00:06:45.639-->00:06:50.844 this. Rather than a single server you have a service where everything is done for you - 00:06:50.844-->00:06:54.681 you're not considering about what box it's running on or anything - you're just asking 00:06:54.681-->00:06:58.351 for them to provide a service like a database and then everything behind it gets 00:06:58.351-->00:07:04.858 handled. Rather than a domain, you have an account or subscription and everything is 00:07:04.858-->00:07:09.863 contained within that container. So, rather than a domain admin you have subscription admins and 00:07:12.265-->00:07:17.737 this is a really key point I want you to take away from this: Subscription or account admin or 00:07:17.737-->00:07:23.677 root in the cloud environment is equivalent to domain admin in a traditional domain. If you can 00:07:23.677-->00:07:29.249 own the account at that level, you can own all of the resources within the account. And we often 00:07:29.249-->00:07:33.019 have a lot times with privilege assignment here where people who shouldn't have access like a a 00:07:33.019-->00:07:39.292 billing administrator is just added as a subscription admin so that they can handle the billing 00:07:39.292-->00:07:42.796 when they really should be handled as more of just administrative with no access. 00:07:42.796-->00:07:48.034 So, keep that in mind if you take nothing else away from this talk, is owning subscription is 00:07:48.034-->00:07:53.206 equivalent of owning the cloud domain. Rather than passing hashes we're looking for 00:07:53.206-->00:07:57.711 credential pivots. Uhm, we're gonna go into a lot more detail on this and various types of 00:07:57.711-->00:08:03.316 credentials used on cloud environments, But it's not just one type there's many different 00:08:03.316-->00:08:08.288 types you need to consider. Rather than private IPs we have public IPs. It's like Mac had 00:08:08.288-->00:08:14.160 never been invented. This is awesome for attackers! Not so great for defenders. Uhm, things 00:08:14.160-->00:08:18.198 are just out, open to the public because that's where they're designed to be. You know, they 00:08:18.198-->00:08:22.769 do implement VPNs and things like this but in many cases what you're after is a lot more 00:08:22.769-->00:08:27.807 accessible that it would be tucked into the crunchy center of some of these data, 00:08:27.807-->00:08:32.679 well-protected data centers. And then, rather than RDP and SSH, which you still have on IS boxes 00:08:32.679-->00:08:37.117 for remote admin; you're generally dealing with management APIs where you're 00:08:37.117-->00:08:42.889 making requests to the service to do something on your behalf. So, these are often your target 00:08:42.889-->00:08:49.229 when you want to make a service or cloud do something for you. But the real important questions 00:08:49.229-->00:08:55.402 is: Where is the data? All cloud services rely on some type of data storage for nearly 00:08:55.402-->00:09:01.174 everything. Cause whether it's a bucket or a storage account, when you have a virtual machine 00:09:01.174-->00:09:07.747 or a service - it's writing that data to a ser, to an account that you can access with just a 00:09:07.747-->00:09:14.487 storage key or API key. You might not need to attack, uhm, virtual machine at all if you 00:09:14.487-->00:09:18.858 could just dump the drive for that machine out of the storage account and pull what you need 00:09:18.858-->00:09:23.963 out of it. [coughing] So, as an attacker you've gotta learn what is your real goal? Do you need 00:09:23.963-->00:09:29.869 to get code executing on a box which might be well monitored? Or can you just download a copy 00:09:29.869-->00:09:35.241 of it and run it yourself? [pause] So, at this point I'm gonna hand it off to Sean to 00:09:35.241-->00:09:40.246 talk about ways to do some recon in the cloud. >> Hey, DefCon, how's it going? [coughing] 00:09:42.315-->00:09:47.086 [cheering] Excited to be back again. So, let's look at recon in a, in a cloud type 00:09:47.086-->00:09:50.790 environment. You have a customer that hired you to come in and pretest, redteam their 00:09:50.790-->00:09:55.695 environment. And they said "We wanna add cloud to the scope". So, what does that mean? How do 00:09:55.695-->00:10:01.167 we identify what sort of cloud services they have? Well, DNS is your best friend, just like it's 00:10:01.167-->00:10:07.474 always has been. It's there, people put a loot of things not to it to help services or 00:10:07.474-->00:10:14.280 resources and users find other services. Like MX records - we can find a lot of information 00:10:14.280-->00:10:18.651 from MX records..So, I did some scanning of DNS of a bunch of companies to see what I could 00:10:18.651-->00:10:25.024 find. And I discovered that you can find interesting information in DNS - which we've known - uh, 00:10:25.024-->00:10:30.029 but you can look for companies that are using Office 365, Google Apps, uh, they also have, 00:10:32.098-->00:10:37.103 uh, MX records for the specific security hosted email systems. So, Proofpoint, Cisco, Syren, 00:10:40.974-->00:10:45.845 CSC - all those we could find by those MX records. And what's interesting about this is when 00:10:45.845-->00:10:50.350 you find something like PP-hosted, which is Proofpoint, and then you find that there's a 00:10:50.350-->00:10:55.221 DNS txt record for Office 365 that give some interesting information about how their 00:10:55.221-->00:10:59.792 email security is configured. So, at this point you know that they have proof point or, or 00:10:59.792-->00:11:03.963 something else and so when the email comes in it's going through that security system and 00:11:03.963-->00:11:07.600 then it's being delivered through their mailbox. So, when you're designing you're, uh, 00:11:07.600-->00:11:11.638 you're phishing campaign you wanna take that into account. You can also find some other 00:11:11.638-->00:11:17.176 interesting things in the txt records within DNS such as if they're using Amazon, simple 00:11:17.176-->00:11:23.216 email or their MDM system. I found a bunch of symantec MDM that are configured and they 00:11:23.216-->00:11:28.121 actually point to what that system is running on. Or if they're domain, they're website 00:11:28.121-->00:11:32.525 is running as your websites. And then the things that I thought was really interesting was 00:11:32.525-->00:11:37.697 paychecks, Docusign, Atlassian; just to name a few of these cloud services actually get 00:11:37.697-->00:11:44.504 registered and configured in DNS to identify this domain as a customer of that cloud service. 00:11:44.504-->00:11:49.509 And then we can take it one step further and actually look at those SPF records. So, the SPF 00:11:49.509-->00:11:54.547 records are obviously the mail sending systems - those that are authorized to send on behalf of 00:11:54.547-->00:11:59.786 a domain. So, we pair this information with the MX records and the DNS, uh, text records 00:11:59.786-->00:12:03.590 that I've already shown and you get some good information about what cloud service providers are 00:12:03.590-->00:12:07.860 actually being used by this customer. And then you can look and see Salesforce; MailChimp, 00:12:07.860-->00:12:11.931 etcetera and some of these you can even leverage as part of your spear phishing campaign 00:12:11.931-->00:12:16.402 because, obviously, they're doing business with them. And if there's a couple of different 00:12:16.402-->00:12:21.441 subsidiaries in this company you can actually leverage this for one of the subsidiaries to send 00:12:21.441-->00:12:26.012 to the main one in order, uh, to make that part of the phishing campaign - depending on what's 00:12:26.012-->00:12:30.249 in scope. [pause] And then the other part of it which is pretty interesting is looking for 00:12:30.249-->00:12:35.054 federation servers because ultimately that is the key to authentication within the cloud. 00:12:35.054-->00:12:38.658 And since there's no standard naming for these for these federation servers what we can 00:12:38.658-->00:12:43.896 look at is we can do DNS queries for a bunch of different a-records. And what I found 00:12:43.896-->00:12:48.401 interesting as part of this scanning is that a number these actually are registered and are 00:12:48.401-->00:12:53.406 c-names and then point back to what the federation server actually is. And we can do DNS 00:12:53.406-->00:12:58.778 queries for a number of these - ADFS etcetera. STS seems to be one of the,. uh, the more legacy 00:12:58.778-->00:13:04.484 configuration for ADFS. And then we can go and look at this web server to see what the 00:13:04.484-->00:13:08.955 configuration is. We can look at the data in the webpage; we can can look at the headers which 00:13:08.955-->00:13:12.825 gives us information about what kind of server it's running. So, if it's running AS, it's 00:13:12.825-->00:13:17.764 probably an ADFS server or an ADFS proxy. And we can get some in, other information out of it 00:13:17.764-->00:13:22.135 as well such as how long those tokens are good for and some other things about what domains 00:13:22.135-->00:13:28.274 hook into that. And we can identify if they have exchange on premises - well, we can look 00:13:28.274-->00:13:31.844 at that through the MX record but we look to see where there auto discover sis - if they're 00:13:31.844-->00:13:36.315 using a Microsoft based email system - which a lot are. And then we can identify the OS 00:13:36.315-->00:13:40.620 server that's here and we can also identify what version of exchange OS is running by 00:13:40.620-->00:13:45.458 looking at this copyright banner. It's running, if it's copyright up to 2, 2006 then 00:13:45.458-->00:13:51.297 it's Microsoft exchange 2007. [pause] So, how does this tie together? We have cloud, we have 00:13:51.297-->00:13:55.368 federation, we need to combine these things somehow. And ultimately it all comes down to 00:13:55.368-->00:13:58.938 the authentication that's leveraged. So, the authentication and authorization 00:13:58.938-->00:14:04.444 just like we've always had. Authentication is identifying and confirming that who you say 00:14:04.444-->00:14:09.582 you are and who you actually are. And then the authorization part is that component that says 00:14:09.582-->00:14:13.319 that you should be able to have access or you're a member of certain groups or you have 00:14:13.319-->00:14:17.323 certain attributes. And you should be able to access this resource, or,or potentially 00:14:17.323-->00:14:21.260 access that resource. And ultimately how that authentication happens depends 00:14:21.260-->00:14:27.200 on the cloud provider and the protocols they support - like OAuth, openID, SAML, WS, - WS 00:14:27.200-->00:14:32.839 federation, WS trust. And so, in a federation world ultimately, the user authenticates locally 00:14:32.839-->00:14:36.743 within on, on the on premises environment - often in actual directory. They get their 00:14:36.743-->00:14:41.881 kerberos ticket, and they open up their web browser and the hit the link to go to that cloud app 00:14:41.881-->00:14:46.319 or those multiple cloud apps. And what end up happening is that cloud app bounces them back 00:14:46.319-->00:14:49.689 to their federation system because they don't have a token. Or they don't, they don't have 00:14:49.689-->00:14:54.427 that cookie with that information that the cloud app needs to actually determine 00:14:54.427-->00:14:58.331 whether or not they should have access and what level of access they should have. So, to hit 00:14:58.331-->00:15:02.769 that federation server. the federation server checks their identity, adds the information 00:15:02.769-->00:15:08.241 into that token so it claims to make some assertions about that user and since that cloud app 00:15:08.241-->00:15:13.012 trusts that token, because it's signed by that federation server, the cloud app's gonna 00:15:13.012-->00:15:18.451 make the decision as to what that user should have access to. And so I'll talk about ADFS for 00:15:18.451-->00:15:24.056 just minute here because Microsoft acted federation server is pretty common,, pretty 00:15:24.056-->00:15:28.795 widespread in environments that's leveraging Microsoft services like action directory 00:15:28.795-->00:15:34.901 and certainly if leveraging Office 365 or Azure. And so the ADFS servers are gonna be inside 00:15:34.901-->00:15:39.605 the network, joined to the domain.That's key - Azure gonna be a proxy server that's going 00:15:39.605-->00:15:44.076 to be out in the DMZ or directly connected to the internet. With the earlier versions of ADFS 00:15:44.076-->00:15:47.480 you're actually looking at an ADFS proxy. With the newer versions you're looking at, 00:15:47.480-->00:15:52.652 like, a web application proxy that handles those requests coming in. And so this ADFS 00:15:52.652-->00:15:56.622 server is going to have three different types of certificates installed. So, the service 00:15:56.622-->00:16:02.328 communication for that initial HTTPS communication into the system and then some tokened 00:16:02.328-->00:16:07.867 decrypting and signing certs. Now. these last two may actually be same certs. They're often 00:16:07.867-->00:16:13.573 internal certs whereas the service communication cert is often one from a CH trusted by 00:16:13.573-->00:16:17.443 the internet. And so, in ADFS the organization's going to set up a relying party trust which 00:16:17.443-->00:16:22.548 is set up a relying party trust which is that cloud service and application, uh, in that they 00:16:22.548-->00:16:27.453 wanna actually federate to and have a trust with. And then the claim rules are interesting 00:16:27.453-->00:16:33.526 because organizations can actually lock down how access occurs. So, they can say if we 00:16:33.526-->00:16:40.099 have Office 365 our users have to authenticate from within our network, on our domain and are 00:16:40.099-->00:16:44.704 not allowed to go to the internet at large, directly into that Office 365 environment. And 00:16:44.704-->00:16:50.443 we can force that through the federation environment. Often don't but it can be done. So, 00:16:50.443-->00:16:54.080 SAML is kinda what ties all of this together and most of the time this is what's used when 00:16:54.080-->00:16:58.951 we're talking about federation - 'Security Assertion Markup Language - and it's basically 00:16:58.951-->00:17:03.289 just to support this web browser - single sign-on. And there's three roles, this should be very 00:17:03.289-->00:17:07.727 interesting or very similar to what people are used to when you're going after an active 00:17:07.727-->00:17:11.731 directory environment, right? If you're a user your identity provider and your service 00:17:11.731-->00:17:16.302 provider - just like in AD you have your user , you have your KAC or your domain controller 00:17:16.302-->00:17:22.141 and you have service, some kerberos service running on a server. And so, what ends up 00:17:22.141-->00:17:27.246 happening is user goes into the federation server or the identity provider and proves 00:17:27.246-->00:17:31.284 their identity, gets those claims and that token and then can access that service provider 00:17:31.284-->00:17:37.957 - just like in kerberos. And so, SAML on this instance is specifying the assertions that 00:17:37.957-->00:17:41.427 are handling between these roles or what's required in order for that service provider to 00:17:41.427-->00:17:46.432 identity that user and know who they are. So, it's providing a, a broker type service. Now, SAML 00:17:48.968-->00:17:52.838 is authentication method diagnostics - it could be active directory, it could be LBAD - it 00:17:52.838-->00:17:57.209 doesn't really matter. But the key to this is the SAML messages are leveraging these 00:17:57.209-->00:18:01.714 certificates, these signatures. The SAML message itself is signed and there's a number of 00:18:01.714-->00:18:07.520 certificates are signing that, that occurs inside to ensure the, the trustedness of the 00:18:07.520-->00:18:12.858 whole system. And so, the key points here is that the certificates really matter. 00:18:12.858-->00:18:18.564 Civic, it's on their federation server matter because those are what are used to sign that token 00:18:18.564-->00:18:22.268 and the components in that token to prove to that service provider that "Yes, this user is 00:18:22.268-->00:18:26.005 who they say they are" and this is what, these are the attributes that they have; these 00:18:26.005-->00:18:29.175 are the claims that they have then you can use that to determine whether or not you 00:18:29.175-->00:18:34.280 should give them different types of access. And so, like I said, SAML is really, uh, what happens 00:18:34.280-->00:18:39.752 a lot on the internal network and the server that is going to be connected to it from the 00:18:39.752-->00:18:44.290 internet is running HTTPS - it has to be available in order for user that are connecting in from 00:18:44.290-->00:18:49.195 the internet in order to, uh, use federation and connect to these cloud resources. So, 00:18:49.195-->00:18:54.900 here's where it get's interesting - this federation is effectively as a cloud kerberos. 00:18:54.900-->00:18:59.972 And so, just like with the domain controller where the kerb DGT is the thing that signs all 00:18:59.972-->00:19:05.177 of those kerberos tickets. On a federation server those certificates is what sign those 00:19:05.177-->00:19:11.550 tokens that say that these users should have access. So, if it's possible to actually extract 00:19:11.550-->00:19:17.123 those certificates off of that federation server or potentially finding them elsewhere as KC 00:19:17.123-->00:19:21.293 mentions. So, that means that you can spoof access to any cloud service you want - 00:19:21.293-->00:19:27.767 provided that that organizations has trust for that. So, we're looking at, kind of, a golden 00:19:27.767-->00:19:32.505 ticket in a cloud environment. So, ultimately by sealing this and using manycast to actually 00:19:32.505-->00:19:39.445 export that certificate on the cloud server, we could get a lot of cloud access. And so, when 00:19:39.445-->00:19:43.082 we're talking about on premise cloud components we're looking at active directory, right? 00:19:43.082-->00:19:46.819 Provide single sign-on for users, they can then connect to the cloud services 00:19:46.819-->00:19:52.191 pre-intuitively, easily without having to log on again. But what's interesting about this is 00:19:52.191-->00:19:56.762 most of these cloud services provide or require some sort of synchronization from the active 00:19:56.762-->00:20:01.634 directory environment into that cloud service. And a lot of times they sync all of the users 00:20:01.634-->00:20:08.207 and all of the attributes into that cloud environment. And IT in that, for that organization 00:20:08.207-->00:20:13.212 may not even be aware of this because it just requires a regular user account. [pause] 00:20:15.414-->00:20:19.385 And, so, a lot of times many organizations don't even know all the cloud services that are 00:20:19.385-->00:20:24.090 actually in their environment. So, let's look at Azure AD connect which is used as a sync 00:20:24.090-->00:20:29.462 tool in order to synchronize user accounts in groups and etcetera into Azure. And what's 00:20:29.462-->00:20:32.832 interesting, what I wanna call out here is that a lot of organizations click the easy 00:20:32.832-->00:20:36.702 button - they click 'express permissions' which just runs through and sets everything in 00:20:36.702-->00:20:41.440 AD for them. Well, a part of this is there's a component here I wanna call out, called 00:20:41.440-->00:20:45.311 'replicate directory changes and replicate directory changes all'. Any, does anyone know what 00:20:45.311-->00:20:50.649 that's for? Or how that can b used for an attack? DC sync, right? Those are the rights that 00:20:50.649-->00:20:54.620 are required in order to do DC sync, so, that means the Azure AD connect service account 00:20:54.620-->00:20:58.724 actually has these rights if they've hit 'express permissions'. Even if that 00:20:58.724-->00:21:03.896 organization's not using password sync feature. With password sync feature where that 00:21:03.896-->00:21:09.635 password hash is hashed again and then sent up to the Azure AD environment and that way users 00:21:09.635-->00:21:14.573 can actually login without going through, uh, the on premise environment. Now, if they've 00:21:14.573-->00:21:18.144 clicked the 'customs permissions' group, uh, button then they can go through and 00:21:18.144-->00:21:23.182 select these individually. But even if they're maybe thinking about this password sync they 00:21:23.182-->00:21:27.520 may have these rights that are configured. So, as you're operating in an AD environment 00:21:27.520-->00:21:33.392 where they're looking at using Azure or Office 365 you may notice that that there's an 00:21:33.392-->00:21:37.997 Azure AD account that actually has these high-level rights. And so, when we're talking about 00:21:37.997-->00:21:43.035 cloud stuff we're still talking about PowerShell, all of the major cloud providers have their 00:21:43.035-->00:21:47.840 own PowerShell modules. And they're really useful for administrators, probably for 00:21:47.840-->00:21:52.978 other things. But once we have an account that we can leverage, cause remember those accounts 00:21:52.978-->00:21:58.150 inside that organization typically have, uh, cloud access, cloud permissions. We 00:21:58.150-->00:22:03.722 can get information about that company as configured - here I'm using Office 365 and, as an 00:22:03.722-->00:22:08.627 example and using that O 365 PowerShell module. We get information about how they're 00:22:08.627-->00:22:13.933 configured; what the directory synchronization information is; if they're actually doing 00:22:13.933-->00:22:18.971 password synchronization. So, if you find that their account actually has those replicated 00:22:18.971-->00:22:24.276 directory changes rights but this is not set then you can let them know that "Hey, you're over 00:22:24.276-->00:22:30.249 permissioning this account". We can can get those Office 365 roles; we can numerate what the 00:22:30.249-->00:22:35.588 membership is and then we can identify those user accounts on their on premises environment to 00:22:35.588-->00:22:40.059 identify what access they have to they're cloud environment. And the other thing we can do 00:22:40.059-->00:22:44.864 is, we can find service accounts in their cloud environment. And why this is interesting is we 00:22:44.864-->00:22:49.868 can start looking at these URLs that are identified as part of the service principal names. And 00:22:51.971-->00:22:56.775 we can identify that there's a dino DNA; 'dot engin dot co'; there's a 'secure dot engin tech 00:22:56.775-->00:23:01.714 dot co; and there's a 'unik systems dot engin tech dot com'. And there's associated groups 00:23:05.084-->00:23:09.388 with these and these groups have accounts in them. So, as we're looking at their cloud 00:23:09.388-->00:23:12.891 environment we can start looking at these applications that are configured within their cloud 00:23:12.891-->00:23:18.764 environment and see if there's some interesting information there. [pause] And, in Office 00:23:18.764-->00:23:23.769 365 and in Azure, Microsoft has rest API that allows access and it enables you to numerate a lot 00:23:26.505-->00:23:33.245 of data about Azure AD. So, on the on premises environment you have LDAP. In these Azure AD 00:23:33.245-->00:23:38.117 cloud environment you have a rest API and the graphics score on this, on this web page 00:23:38.117-->00:23:43.322 actually shows the type of information you can get. So, you can do like powerview type stuff 00:23:43.322-->00:23:48.961 in Azure AD through this website. [pause] And so, when we're talking about attacking 00:23:48.961-->00:23:53.766 cloud assets and looking to see what they have, it's important for organizations to understand 00:23:53.766-->00:23:57.736 that managing their VMs are still their responsibility. A lot of these cloud providers 00:23:57.736-->00:24:02.775 provide quick start installation scripts - things that set up the VMs ver quickly; configure them 00:24:02.775-->00:24:07.479 for that environment. But they may not be secure, they usually aren't. [audience noise] >And so 00:24:07.479-->00:24:11.884 you wanna check that and identify what those are. Get comfortable with what these 00:24:11.884-->00:24:17.423 scripts are and how Azure has them, AWS has them or any cloud provider has them. Look at those 00:24:17.423-->00:24:22.628 scripts; know what those are before you go into that environment. And so, Microsoft 00:24:22.628-->00:24:27.466 had 'docs dot com' where customers could actually upload and put data and documents in a 00:24:27.466-->00:24:31.870 'docs dot com' and then share them with col, with their employees; share them with 00:24:31.870-->00:24:36.842 customers. The problem was that a lot of people click too many times and allows it world 00:24:36.842-->00:24:41.714 readable., which meant that a lot of sensitive documentations were available here, uh, Kevin 00:24:41.714-->00:24:46.452 Bowman actually highlighted this in Twitter and said "Hey guys, there's a lot of information and 00:24:46.452-->00:24:51.490 guess what? It has a search feature! I can find all this through 'docs dot com'!". 00:24:51.490-->00:24:54.526 Microsoft said "Okay, we're going to remove the search feature..." [laughter] There's 00:24:54.526-->00:25:01.200 still Google... [laughter] Kevin says "Hey guys, I can still see this stuff!". So, Microsoft went 00:25:01.200-->00:25:06.004 back; did some changes; shut it down for a little while; brought it back up and said: "Customers, 00:25:06.004-->00:25:10.075 please check your stuff; make sure you're not sharing your sensitive documents with the 00:25:10.075-->00:25:15.881 internet!". [audience noise] But, it's not just Microsoft. Just a few weeks ago we had 00:25:15.881-->00:25:21.587 Amazon that had some issues with S3, right? And by these headlines we would think their 00:25:21.587-->00:25:28.260 cloud is a problem! Cloud security failure! Data exposure! You know, the, the sky is 00:25:28.260-->00:25:34.233 falling; the cloud is burning, right? Not really... So, some more reasonable headline is 00:25:34.233-->00:25:39.204 "Human error" - cause that's what it is. So, if you're hired to evaluate the environment in 00:25:39.204-->00:25:44.276 the cloud assets, definitely look at their Amazon S3 environment; looks at 'docs dot 00:25:44.276-->00:25:48.947 com'; look at these things to see what you can find and help them identify these potential 00:25:48.947-->00:25:53.819 exposures before they get exposed by someone else. And so, Amazon actually sent an email to 00:25:53.819-->00:25:58.223 customers that said "By the way, you have some data you're sharing on your Amazon S3, you 00:25:58.223-->00:26:03.529 probably wanna look at that." And there was a great blog article on 'detectify' uh, 'dot 00:26:03.529-->00:26:07.866 com' about how these configurations were configured and how to fix them. The most 00:26:07.866-->00:26:13.505 interesting part of this for pentesters is there's an API to actually look for this data. So, 00:26:13.505-->00:26:18.010 you definitely want to read this article and kind of dig into that. Now I'm gonna turn it back 00:26:18.010-->00:26:23.015 to Gerald who's gonna talk to you about how credentials are used in the cloud. >> So, we all 00:26:29.021-->00:26:34.026 know how to hack domains and grab hashes and get the... [audience noise] [pause] 00:26:36.395-->00:26:41.400 Alright, who turned my mic off? So, we have hashes... [audience noise] Nope... [pause] We have 00:26:46.104-->00:26:51.109 our... [cheering] Yea! There we are! [applause] Sound succeeded, alright... So, we've got all the 00:26:53.278-->00:26:59.218 hashes; we have the curb DGT but your cloud provider really doesn't care. As Sean was just 00:26:59.218-->00:27:04.122 talking, they speak a different language; they speak federation, you might be able to get in, if 00:27:04.122-->00:27:09.561 the federation server that provides that permission is on your domain but you might not. 00:27:09.561-->00:27:15.367 So, what do we do? Well, creds never change - they're always good! The type of cred changes 00:27:15.367-->00:27:21.373 though, in the cloud world where mostly interested in certificates and private keys 00:27:21.373-->00:27:26.778 and API tokens. So, what has this done? Well, it's made dev; it's made becoming developed 00:27:26.778-->00:27:33.652 more popular than ever. I pretty much made my career on stealing secrets off of devboxes for 00:27:33.652-->00:27:38.557 internal lateral movement. Because nobody else paid any attention to the web configs 00:27:38.557-->00:27:44.162 that were on open shares and networks a lot of times. Well, now we have all kinds of things 00:27:44.162-->00:27:48.467 - we have private certificates which might be checked in the repos and we have these API 00:27:48.467-->00:27:52.437 keys. They're even more of these secrets, and you do know that needs can export certificates, 00:27:52.437-->00:27:59.311 right? Uhm, the non-exportable flag in windows is more of a recommendation than a 00:27:59.311-->00:28:04.650 requirement and it's pretty easy to bypass that. Uh, if there's any of my Windows colleagues in 00:28:04.650-->00:28:09.054 the audience that I would really like to see this to the red guard secure boundary at some 00:28:09.054-->00:28:14.760 point, so people will stop exporting no-exportable certificates. And what is all 00:28:14.760-->00:28:19.798 this new again? Password spraying, hey, this is like for us old people almost like being 00:28:19.798-->00:28:25.437 back in the war dialing days of trying a few passwords and moving on. I mentioned earlier - 00:28:25.437-->00:28:29.875 everything's on the public network now; we can do a little bit of spraying across their 00:28:29.875-->00:28:35.447 account and come back and it's API. So, this is really easy to do, you write a 'for loop'; call 00:28:35.447-->00:28:40.252 the API - there's some tools in the references that do this as well. Uhm, we don't have 00:28:40.252-->00:28:46.158 personal experience with those; feel free to look it up. But this is a really good example of 00:28:46.158-->00:28:51.163 taking techniques you already know and reapplying them to new environments. Devops, uhm, they 00:28:53.865-->00:28:59.638 probably have what you're looking for. If you're not pillaging the internal source 00:28:59.638-->00:29:04.576 repos and the shares on developers workstations - you're doing a pretty poor job as a red 00:29:06.678-->00:29:13.585 teamer or pentester. Because they are usually loaded with juicy secrets. Or, maybe they 00:29:13.585-->00:29:19.057 just checked them in the public git as Sean's shown earlier. Uhm, that's not really good 00:29:19.057-->00:29:23.762 either. And how are the deployments done? Well, most cloud services are done through 00:29:23.762-->00:29:28.133 a continuous integration model where everything just get packaged up and published out 00:29:28.133-->00:29:33.939 constantly - every time somebody checks in a change. Well, if I'm on the developer's box, can I 00:29:33.939-->00:29:38.310 just ride along on that check in and just get myself into production without ever even 00:29:38.310-->00:29:43.582 compromising the secret? It's another way you can trade in network access for access 00:29:43.582-->00:29:48.587 somewhere else. Uhm, as I mentioned, keys are everywhere. Uhm, leaks in the GitHub have 00:29:51.623-->00:29:57.295 been super common; people leave their access keys on their desktops. Download folders are a 00:29:57.295-->00:30:04.202 great place to dump dev, uh, boxes. And then what do we do with all this though? What's 00:30:04.202-->00:30:09.908 our, what's our access? If we have on premises access but our real target is data , well, 00:30:09.908-->00:30:14.913 let's find a way to get cloud access and trade that in. Very similar, you have cloud access 00:30:18.850-->00:30:23.221 that need to talk to things on premises, well, there's probably a data path you can follow. This 00:30:23.221-->00:30:28.694 is one of the key things to being a good attacker - is identifying all the possible 00:30:28.694-->00:30:33.699 data paths. Uhm, ask yourself, you know, how is the system communicating? Because that is 00:30:36.001-->00:30:41.239 often going to tell you where you need to go to achieve your objective. And really, is their 00:30:41.239-->00:30:45.343 shared authentication methods. People still love sharing passwords if you have an account 00:30:45.343-->00:30:50.682 that provides cloud access - you've got their hash and you can crack their hash and, who 00:30:50.682-->00:30:55.821 knows, I'm gonna just reuse the same account for a live ID or an Amazon account that' they're 00:30:55.821-->00:31:01.393 using to manage their entire company' domain. That's something worth trying and it 00:31:01.393-->00:31:07.265 works more often than it should. [pause] But in the end of the day, we are here to provide 00:31:07.265-->00:31:13.138 value and service to the people that hired us to attack their stuff, uh, I love my job, it's 00:31:13.138-->00:31:17.743 fun but really my ultimate goal is making sure that things are more secure. So, what do we do 00:31:17.743-->00:31:23.882 about all this? First, and I think most important, when it comes to cloud environments as 00:31:23.882-->00:31:28.887 properly managing credentials and secrets. Most of the big clouds all provide some type of 00:31:30.956-->00:31:35.961 automated credentials store and if your clients are not using these you need to learn how 00:31:37.963-->00:31:42.567 because this is one of the best ways to handle it. There are so many different credentials in 00:31:42.567-->00:31:49.541 the cloud; make it easy for people to do the right thing. MFA is huge because a lot times 00:31:49.541-->00:31:54.546 your cloud identity is the same as identity for another account. Make it mandatory and for things 00:31:56.815-->00:32:02.087 like SPNs that can't have MFA, make sure that they have as little access as possible and 00:32:02.087-->00:32:07.092 that you monitor it as much as possible for any deviation. Review your permissions, like 00:32:09.694-->00:32:15.534 Sean mention, uhm, a lot of stuff gets made public that's never meant to be, that's a 00:32:15.534-->00:32:21.072 really big issue. Check your VPN access cause it, things being open on the network has become 00:32:21.072-->00:32:26.812 the default again - open on the internet. But that's not necessarily a good thing and a 00:32:26.812-->00:32:30.382 lot of times you can just ask "Does it really need to be open?" and the answer is "No". 00:32:30.382-->00:32:33.451 These providers provide ways to limit this but it's just ot used a lot of times. Least privilege 00:32:33.451-->00:32:38.456 and least access is still your best friend. All the clouds provide methods for managing 00:32:43.662-->00:32:47.933 these permissions which Sean will cover a little bit in a moment. And the idea of even, 00:32:47.933-->00:32:53.939 like, a secure admin workstation for your domain controllers and your privilege access. Just the 00:32:53.939-->00:33:00.011 same for your cloud admins, as I mentioned, they are functionally equivalent to domain admin in 00:33:00.011-->00:33:05.016 the cloud. So, they need to have the same sort of protections - if they're logging into their 00:33:05.016-->00:33:09.621 icloud account with the same account they check their email with , they're just a hish away 00:33:09.621-->00:33:15.126 from your entire cloud environment being under somebody else's control. And credential 00:33:15.126-->00:33:20.131 management is absolutely key because there are so many of them and you have to keep track 00:33:20.131-->00:33:24.002 of them; you have to roll them; you have to be able to do this in an automated way. This is a 00:33:24.002-->00:33:30.242 huge op, opportunity for attackers and it's not so great on defenders, uhm, because a lot 00:33:30.242-->00:33:35.247 of times they're not necessarily easy to handle even, even if you know they're been exposed. 00:33:38.116-->00:33:41.486 [pause] >> So, when it comes to federation there's a few things that are important to do. Uhm, 00:33:41.486-->00:33:46.157 we wanna make sure that federation servers are protected the level as domain controllers. 00:33:46.157-->00:33:49.928 Uh, the proxy server is important to prevent that communication form come, coming 00:33:49.928-->00:33:54.199 in from the outside. Uhm, auditioning that cloud authentication; getting that log 00:33:54.199-->00:33:59.271 in to make sure that, that environment that this info security team actually knows 00:33:59.271-->00:34:02.908 what sort of authentication is occurring and, and so if there's something that looks weird they 00:34:02.908-->00:34:07.112 know what that is. Uh, so I'm gonna couple, cover some more recommendations and then, uh, 00:34:07.112-->00:34:13.351 Gerald's gonna do a demo so we can see, kind of, what all this looks like put together. Uhm, 00:34:13.351-->00:34:17.322 and multi-factor authentication is important, certainly for these admin accounts. So, anyone 00:34:17.322-->00:34:22.160 that manages those federation servers probably should have MFA configured. And we can, as I 00:34:22.160-->00:34:27.365 mentioned we can con, we can protect and control that cloud authentication, uh, via 00:34:27.365-->00:34:31.736 federation rules. And so, in this instance we can Azure that users internally, maybe they're 00:34:31.736-->00:34:35.774 a little more protected - they can connect into their cloud services through a single 00:34:35.774-->00:34:39.110 sign-on. They don't need anything more than a username and password but if they're 00:34:39.110-->00:34:44.049 coming from the internet they have to use two-factor. And so we can also leverage those cloud 00:34:44.049-->00:34:48.353 provider security features. And definitely recommend to your customers that they do this - 00:34:48.353-->00:34:53.358 Azure and Amazon provide great ways to monitor what's going on to identify what, what resources 00:34:57.028-->00:35:01.733 are there and which keys have access to them. And you can actually restrict that, so even 00:35:01.733-->00:35:07.038 if an API key gets leaked out on GitHub nothing can be done with it because it's constrained in 00:35:07.038-->00:35:12.110 how it can be used and only from specific cloud assets. And then of course monitoring and 00:35:12.110-->00:35:16.548 learning is really important - we need to make sure what we tell our customers here are our 00:35:16.548-->00:35:19.651 recommendations you're monitoring. It's not your network but you still have to 00:35:19.651-->00:35:23.455 have a good understanding of it. And there's different tools from different cloud providers and 00:35:23.455-->00:35:28.560 how this can be done. Uh, amazon provides VP, VPC flow which is basically like net flow, except 00:35:28.560-->00:35:33.565 to another level. And so, defenders need to be familiar with all these tools as well and 00:35:36.001-->00:35:39.704 know that these events are gathered by the cloud provider can actually flow into their 00:35:39.704-->00:35:45.477 sim- their central uh, login tools. And of course asset inventory is even more critical 00:35:45.477-->00:35:50.015 on the cloud because new VMs can be spun up all the time. And of course every organizations 00:35:50.015-->00:35:55.820 should assume that there some sort of breach and that's about what we're gonna talk about now. 00:35:55.820-->00:36:00.759 >> Alright, so, We've been hired to hack SithCo, fairly easily got domain admin on one of their 00:36:05.530-->00:36:10.435 subsidiary domains for an offshore developer via some phishing but so far they're 00:36:10.435-->00:36:15.840 corporate network has actually been fairly well-protected. We did some recon and found that 00:36:15.840-->00:36:21.279 they host a bunch of websites out into the public cloud resource. So, how do we leverage 00:36:21.279-->00:36:26.284 this access to get to corporate? Well, we're gonna start with our internal access and do some 00:36:28.453-->00:36:33.358 recon; figure out where we are; pivot through the cloud and eventually end up inside the 00:36:33.358-->00:36:38.363 corporate network. Here's me running, uh, my favorite interpreter on a, uh, developer 00:36:41.633-->00:36:47.038 box. First thing I'm gonna do is pillage they're downloads directories because when you go 00:36:47.038-->00:36:53.178 to a website that has to download your keys or your which is basically a self-contained, 00:36:53.178-->00:36:59.150 all-in-one pawn Azure file which has your private certificate in it. Uhm, they just pump them 00:36:59.150-->00:37:03.755 into their downloads folder and usually forget they're there afterwards. So, let's go ahead 00:37:03.755-->00:37:09.360 and try that. Uhm, root key is the AWS very, very similar version and it's an API key that 00:37:09.360-->00:37:13.798 gets full access and it comes in a nice handy plain text file. So, yea, these, you know, these 00:37:13.798-->00:37:19.471 problems are not cloud specific, they occur across all clouds. Well, here's some publishing 00:37:19.471-->00:37:24.042 things I'm using - a really handy third party tool called Azure management studio that 00:37:24.042-->00:37:30.448 makes this easy to visualize. Normally I'd just be doing this all through the API but I dunno, 00:37:30.448-->00:37:36.020 this publish settings file is out of date, I no longer have access. But it's not a loss, 00:37:36.020-->00:37:42.127 they might have changed the certificate there but I gain a piece of information I'll need 00:37:42.127-->00:37:48.266 later which is a subscription ID which does not change. So, we're still on the developer box, 00:37:48.266-->00:37:53.671 let's see how they're communicating to Azure. Let's dump their certificate store. 00:37:53.671-->00:37:57.675 Well, they have a couple of Windows Azure tools encryptions, those are generated by visual 00:37:57.675-->00:38:03.281 studio. There's something called 'Azure Animation' which sounds pretty interesting. Uhm, they'll 00:38:03.281-->00:38:08.653 usually have common tools depending on what chain was used to make it, like, Windows Azure 00:38:08.653-->00:38:14.292 tools is a super common one. And like I said learning these for your cloud environment, what 00:38:14.292-->00:38:19.297 they look like is very important. So, I'm gonna elevate to system - go ahead and patch, 00:38:21.566-->00:38:26.571 uhm, the crypto APIs so I can bypass the, uhm, annoying no-export flag. And then I'm 00:38:30.008-->00:38:35.013 gonna dump the certificate. Here's a, uhm, a quick example of, in this case I Got the 00:38:37.682-->00:38:41.252 public key and then immediately following that the private key. If I hadn't done the patch step 00:38:41.252-->00:38:46.758 first I would only gotten the public key because that is a non-exportable certificate 00:38:46.758-->00:38:51.763 which, uh, like I said, is more of a suggestion. So, then I take that certificate, convert the 00:38:54.632-->00:38:59.637 base64 into a 'pfx' file and go back to Azure management studio. I got the subscription ID out of 00:39:05.276-->00:39:11.783 the, uh, publish settings file which was no longer valid. I now have a certificate on the box 00:39:11.783-->00:39:16.855 that may or may not work but if it's a current certificate on the developer's box there's a 00:39:16.855-->00:39:21.659 good chance it probably does. Let's go ahead and successfully authenticate to Azure and see 00:39:21.659-->00:39:27.465 their running a couple of system services. Uhm, Sythweb looks really interesting, let's take a 00:39:27.465-->00:39:33.671 look at this vm. As I mentioned before, a lot of times we don't need to compromise the vm to 00:39:33.671-->00:39:38.943 achieve what we want to achieve. Let's start with the storage, I'm gonna, uhm, this vm's 00:39:38.943-->00:39:42.580 running, I don't wanna interrupt things which might get detected. So, I'm just going to take a 00:39:42.580-->00:39:48.620 snapshot of the disk; download it to my local hard drive and start pillaging it like I 00:39:48.620-->00:39:53.825 normally would. If you're familiar with 'dot net' apps at all, uh, 'web config' is your 00:39:53.825-->00:39:58.763 favorite friend. I wanna pull the down and start looking for some interesting stuff. In this 00:39:58.763-->00:40:03.768 case it has access to a sql server 'as SA' in a private network space. Which indicates 00:40:07.005-->00:40:12.377 that there's probably a VPN involved somewhere. It could just as easily be do to a public 00:40:12.377-->00:40:18.182 IP, uhm, but a lot of times this one was at least partially set up correctly. They put a VPN in 00:40:18.182-->00:40:22.920 place so they didn't expose their SQLserver to the public but it is exposed to their cloud 00:40:22.920-->00:40:27.926 server. Uhm, thankfully, uh, they just ran the SA that makes our lives a little bit more 00:40:30.828-->00:40:37.435 easy. So, at this point we probably need code running on this box to access this VPN. A 00:40:37.435-->00:40:43.374 lot of bigger companies have direct VPN access to their cloud assets through a direct switch 00:40:43.374-->00:40:50.081 where they permanent link to their cloud environment. Uhm, if I wanna get code running on this 00:40:50.081-->00:40:55.586 box then I have subscription level access, which I said is basically equivalent to domain, 00:40:55.586-->00:41:00.525 I can hit up MSDN real quick and see there's an API for resetting the password on any vm I want. 00:41:02.860-->00:41:06.664 Well, that's great, uhm, there's a good chance this will get caught if the monitoring team's 00:41:06.664-->00:41:12.804 doing their job but if this was set up by some devOps that did not consult their developer, uh, 00:41:12.804-->00:41:18.109 defenders, there's a good chance nothing in the vm is being monitored. And that's really 00:41:18.109-->00:41:24.248 important considering that is what needs to be fixed in the cloud world - is taking these 00:41:24.248-->00:41:29.253 into account. So, I'll go ahead, enable RDP on that box; log in and here's just a, you know, I 00:41:31.489-->00:41:36.227 would normally, uhm, have gone and launch through interpreter thorough remote shell but I just 00:41:36.227-->00:41:42.367 wanna show real quick. I now have direct access to the corporate SQL server via the VPN 00:41:42.367-->00:41:47.338 link from this vm which we compromised from a domain that was completely untrusted by 00:41:47.338-->00:41:53.745 pivoting through their cloud assets. And this is going to be a fairly common practice in the 00:41:53.745-->00:41:58.116 future; it's a good example a hybrid cloud environment where they're sharing data back and 00:41:58.116-->00:42:04.789 forth. And it absolutely needs to be considered going forward and I'm just about out of time 00:42:04.789-->00:42:10.561 so I wanna there is going to be a lovely narrated video up on 'ad security dot org' following 00:42:10.561-->00:42:16.167 the presentation of the entire end-to-end attack chain. I hope you'll enjoy that; it would have 00:42:16.167-->00:42:20.371 been boring just sitting here watching it in the talk, uh, rather that us giving you 00:42:20.371-->00:42:26.110 advice. So... >> Right... So just to summarize what Gerald showed, is we had a subsidiary 00:42:26.110-->00:42:29.414 that was completely separate in their own active directory environment and they did 00:42:29.414-->00:42:35.720 development for this cloud environment. Gerald compromised that developer box; pivoted to 00:42:35.720-->00:42:40.992 the cloud; got onto one of the cloud assets; saw that that web server actually had credentials 00:42:40.992-->00:42:46.564 for the corporate SQL server inside their corporate network; pivoted from that subsidiary, 00:42:46.564-->00:42:51.335 untrusted environment, through the cloud into the corporation and has now moved into that 00:42:51.335-->00:42:57.141 corporation and continues to move and, and plunder. So...Great job, Gerald. 00:42:57.141-->00:43:02.080 [applause] >> Thank you all very much! >> Thank you all, appreciated. [applause]