WEBVTT 00:11.340 --> 00:12.180 All righty. 00:12.180 --> 00:18.100 Well, good morning, good afternoon, or good evening, wherever you guys may be today. 00:18.620 --> 00:20.100 I am Jura. 00:20.100 --> 00:20.800 Stand with me. 00:20.800 --> 00:22.540 I've got Patrick. 00:22.540 --> 00:30.840 And we are here to talk with Sean Metcalf about his talk, Hacking the Hybrid Cloud. 00:32.060 --> 00:33.900 We've both taken some time to watch this. 00:33.900 --> 00:35.460 Hopefully you guys have too. 00:35.460 --> 00:52.300 I thought it was an excellent talk, incredibly comprehensive, and did a great job of kind of giving everybody, even if you don't have a lot of knowledge about Active Directory or the way that some of these deployments work, of kind of bringing you up to speed. 00:52.300 --> 01:00.160 So if you are kind of joining and are looking for a talk to watch and you haven't caught this one yet, make sure you go back and check that out. 01:00.880 --> 01:04.140 Sean, why don't you take a moment to introduce yourself. 01:04.980 --> 01:09.840 Tell us where you are, how you kind of got into this, and how we got to where we are today. 01:10.340 --> 01:11.480 Sure thing. 01:11.480 --> 01:14.700 I'm Sean Metcalf, Pyrotek3 on Twitter. 01:14.700 --> 01:15.880 Hello everyone. 01:15.880 --> 01:18.660 I've spoken at a few DEF CONs in the past. 01:18.660 --> 01:24.360 I really enjoy the security research element of technology and IT. 01:24.360 --> 01:29.020 I've been working with Active Directory since pretty much when it came out in the year 2000. 01:29.020 --> 01:34.920 First as operations admin, engineer, designer, architect, what have you. 01:34.920 --> 01:41.000 And then pivoted pretty hard into the security aspect in say 2003, 2004. 01:41.000 --> 01:47.240 But I'd say probably the interesting thing to me was looking at the security aspects of these systems along the way. 01:47.240 --> 01:52.000 A lot of times you have people that are administrators and engineers and they understand the security elements of it. 01:52.000 --> 01:58.500 They understand the challenges, but they just don't necessarily have the backing to push in that direction. 01:58.500 --> 02:15.560 So certainly for me, since I was coming up through the Microsoft area, I didn't feel like the security space or InfoSec was really a space for me because I had worked with Microsoft Windows and most of the security people in 2000 to 2010 and certainly beyond are like, 02:15.560 --> 02:17.580 oh, Microsoft Windows, that's a toy OS. 02:17.580 --> 02:19.780 What do you know about security in that area? 02:19.780 --> 02:32.020 So after I had been working with Active Directory for a long time and I started seeing these attacks go from hypothetical to reality , I said, hey, there's really something here. 02:32.020 --> 02:36.480 And I started putting together some talks to help people better understand Active Directory security. 02:36.480 --> 02:44.400 And then in 2017, I did a talk with Taya about hacking the cloud and what that actually means. 02:44.400 --> 02:47.700 And at the time, Taya was working on the Azure Red team. 02:47.700 --> 02:53.080 And so I learned a lot from Taya about how these things interconnect. 02:53.400 --> 02:57.520 Certainly looked a lot at Azure AD and Office 365 at that time. 02:57.520 --> 03:06.000 As I was continuing that journey, in the past year, I identified some issues or concerns that I had with hybrid cloud. 03:06.000 --> 03:15.420 So these connection points between your on-prem Active Directory and Azure AD or Office 365 or Azure and beyond. 03:15.420 --> 03:26.620 And certainly Dirk-Jan Milema, he did a great talk last year at DEF CON and has been publishing some great information about doing just that from a comprehensive attack perspective. 03:26.620 --> 03:33.000 So certainly the research of others have been inspiring my research recently and things that I've been looking at. 03:34.700 --> 03:35.820 Excellent. 03:37.020 --> 03:50.120 Sean, so I guess also just for starters, can you kind of like explain in a nutshell what like the hybrid cloud... I think people kind of understand the cloud and people understand on-prem. 03:50.120 --> 03:53.700 Can you kind of talk a little bit about what you mean with the hybrid cloud? 03:53.880 --> 03:54.780 Sure thing. 03:54.780 --> 04:02.800 So it's good to have a good definition or it's good to have a solid definition of what it actually is because, like you said, it can be confusing. 04:02.960 --> 04:10.480 So for me, at least the definition I put together for this talk is hybrid cloud is when you have on-premises infrastructure. 04:10.480 --> 04:14.160 So you have something like Active Directory and then you have something in the cloud. 04:14.200 --> 04:22.240 It could be you've extended your on-prem environment into cloud IaaS infrastructure as a service. 04:22.240 --> 04:25.820 So you're using the cloud sort of as an extension of your data center. 04:25.820 --> 04:33.080 A lot of organizations are moving into the cloud and using the Azure or AWS or even GCP as their data center now. 04:33.080 --> 04:34.740 So that's one part of it. 04:34.740 --> 04:42.320 Another part of it is when you have all your on-prem infrastructure that's handling your typical things like Active Directory logons, things like that. 04:42.320 --> 04:44.380 But then you have services that are up in the cloud. 04:44.380 --> 04:47.060 So your SaaS side, so software as a service. 04:47.060 --> 04:55.500 You have things like Salesforce or you have Workday or you have Office 365 or things along those lines where you have some connection points. 04:55.500 --> 05:04.680 And so certainly from the Office 365 on-prem AD side, there's a connection point called Azure Active Directory Connect. 05:04.680 --> 05:10.620 And there's some interesting things that have occurred with that connection point between your on-prem and that cloud environment. 05:10.620 --> 05:16.500 I pointed out some back in 2017, Dirk Jans published a whole bunch of information about that. 05:16.500 --> 05:28.500 Others like Adam Chesters has identified some things where the additional connection points of what Microsoft's been doing to simplify this authentication flow between on-prem and the cloud. 05:28.800 --> 05:42.680 And I think that's really one of the things that I wanted to dive into as part of my talk was discussing the roles and how they're typically over permission and also looking at this authentication flow that gets very complicated. 05:42.760 --> 05:55.940 And that's why I closed out the talk with a bunch of different slides where you have three different cloud environments and you have your on-prem environment and you're working through the federation of it and how they all get interconnected in very interesting ways. 05:56.040 --> 06:02.600 The IAM story there, the Identity Access Management story is very complicated when you have multiple cloud environments. 06:02.600 --> 06:05.360 And it gets difficult to track what all these roles are. 06:05.360 --> 06:09.440 And typically they get over permission just like they do on-prem. 06:09.440 --> 06:15.460 So the other thing I wanted to establish as a narrative of my talk was that we have virtualization on-prem. 06:15.460 --> 06:18.680 We're using VMware primarily, predominantly. 06:18.760 --> 06:21.280 And then there's also Hyper-V to some extent. 06:21.280 --> 06:25.640 And then in the cloud, we have effectively virtualization writ large. 06:25.640 --> 06:39.200 Be it Amazon AWS, which started with Zen, uses more of Amazon's Nitro now, to Azure leveraging a custom version Hyper-V core, to GCP using Zen to straight up in their environment. 06:39.240 --> 06:47.680 So this concept of virtualization and the way that you attack or could attack virtualization on-prem is very similar to how you can do so in the cloud. 06:47.680 --> 06:50.300 And I think that was an important part of what I was talking about. 06:50.300 --> 06:58.960 And I even mentioned how you could attack on-prem AD domain controllers, as well as those on-prem AD domain controllers hosted in the cloud. 06:58.960 --> 07:01.400 So regardless of where they are, they're vulnerable. 07:01.640 --> 07:08.320 And then the attacks across those different platforms can have some similarities, but also some pretty significant differences. 07:10.760 --> 07:11.800 Excellent. 07:13.180 --> 07:24.120 Also, is there really any kind of difference or what should people think about if they have their AD environment in Azure or if they have it as an on-prem AD environment? 07:24.120 --> 07:26.020 Are there differences they should think about? 07:26.220 --> 07:27.040 Sure. 07:27.360 --> 07:33.420 So my friend and colleague Demetrius, his first question is, do you trust the cloud? 07:33.420 --> 07:35.600 Because everything starts with that trust. 07:35.600 --> 07:41.840 So we usually presume or assume that our customers trust the cloud because they already have things in it. 07:41.840 --> 07:47.060 But we still ask the question that to what degree or to what level do you trust the cloud? 07:47.060 --> 07:49.280 Because you have to have that trust. 07:49.460 --> 07:58.840 I have concerns certainly about placing on-prem Active Directory domain controllers into cloud environments, IaaS environments, regardless of what they are, because ultimately there's a significant amount of trust. 07:59.560 --> 08:00.740 With the cloud provider. 08:00.740 --> 08:09.900 The other part of that is oftentimes you'll set up your IaaS environment, AWS or Azure, where your server admins are the ones that manage that entire environment. 08:09.980 --> 08:16.280 Well, your server admins who manage that environment can run commands potentially on the domain controllers in those environments. 08:16.280 --> 08:23.900 So if an attacker can compromise one of those server admin accounts, then they can compromise your on-prem AD. 08:23.900 --> 08:36.200 I walked through for the scene of the talk with Amazon over Federation, a way that you can link your IAM role in AWS with your on-prem AD group. 08:36.200 --> 08:41.840 And then you can have an on-prem regular user that's a member of that group that gets compromised because he's a regular user. 08:41.840 --> 08:50.300 And then leverage that account in order to compromise the domain controllers hosted in AWS, just because that one account was compromised. 08:50.300 --> 08:53.640 It has that extended role access and privileges. 08:53.640 --> 09:00.200 And then because it's in the cloud, that can roll right back again and compromise the full on-prem Active Directory environment. 09:00.620 --> 09:03.780 So there's some very interesting things that happen with that. 09:03.780 --> 09:19.700 So I also talk about one interesting one from Azure AD to Azure, because of this sort of backdoor that Microsoft put into it and has talked about, but it wasn't clear that if you were a global admin in Azure Active Directory, that you could then go jump over to Azure and have full control of that environment. 09:19.760 --> 09:28.060 So I walked through that as well, because these sort of connection points are interesting, but a lot of times operations is like, let's go, let's get it done. 09:28.320 --> 09:31.760 And they're being told by the executives, we have to get into the cloud. 09:31.760 --> 09:34.260 Our number one goal right now is to get in the cloud. 09:34.260 --> 09:39.280 I mean, we've had a surge of interest and companies that have moved to the cloud. 09:39.280 --> 09:45.040 We've been very busy talking and consulting with customers that are moving to the cloud, because they're like, are we doing this right? 09:45.040 --> 09:50.460 Because operations gets pulled along and thrown in and say, you got to migrate all these systems in the cloud. 09:50.560 --> 09:55.420 And then you have security team going, I just don't know what I'm supposed to do with this. 09:55.420 --> 09:58.320 Like, what are we supposed to know? 09:58.520 --> 10:01.300 Because the thing is on-premise is well understood, right? 10:01.300 --> 10:03.880 We at least know what our egress ingress points are. 10:03.880 --> 10:05.900 At least we hope that they do. 10:05.960 --> 10:09.980 Pen testers and red keepers are good at helping to point out what those actually are. 10:09.980 --> 10:12.820 We have a decent idea of auditing and logging. 10:12.820 --> 10:17.680 And while things aren't great, at least there's some knowledge of where some of those weaker points are. 10:17.760 --> 10:22.880 In the cloud, we have to leverage whatever the cloud provider gives to us. 10:22.960 --> 10:26.960 So Azure, AWS, GCP, they have different capabilities. 10:26.960 --> 10:28.240 They have different controls. 10:28.420 --> 10:32.580 And then the nomenclature, the names for all these things are different across all of them. 10:32.580 --> 10:41.280 So one thing that may be called something in Azure, it may be called something different in AWS and something else in GCP. 10:41.280 --> 10:47.940 So what I find myself doing is saying, okay, a subnet, whatever that may be called in this cloud environment, that's what you need to do. 10:47.940 --> 10:54.280 Or let's have a zone where we segment off this one type of system from the others. 10:54.280 --> 10:58.960 And then we make sure that we can track and control what systems that can connect with it. 10:59.160 --> 11:09.340 I will say that one of the things that we have the opportunity with in the cloud now is the ability to actually implement network segmentation, which we've failed for years on prem, right? 11:09.340 --> 11:10.960 Because now we're setting everything up. 11:10.960 --> 11:13.200 We should be building these zones. 11:13.260 --> 11:20.340 A zone for domain controllers, a zone for servers, a zone for clients, a zone for other things, and then control the communication between them. 11:21.120 --> 11:28.340 There's some ways that that could be done on prem, but the cloud gives the capability and ability now to move forward in that direction. 11:30.220 --> 11:30.760 Cool. 11:30.760 --> 11:34.300 We've got some coming in from chat here. 11:34.720 --> 11:39.220 So Mugs asks, Azure services evolve quickly. 11:39.220 --> 11:51.340 Do you see AAD evolving rapidly, or is it pretty well baked at this point as a fundamental underpinning of PaaS and software as a service services, generally speaking? 11:51.880 --> 11:52.200 Right. 11:52.200 --> 11:59.340 So Azure Active Directory and the Office 365 cloud, that's kind of an extension of that, is evolving very rapidly. 11:59.400 --> 12:02.200 Microsoft keeps hiring developers and adding new features. 12:02.200 --> 12:14.280 And it's funny because Mark Morrow, who I did a talk with about the cloud last year at Black Hat, I was at Redmond with him earlier this year for an Azure AD identity event. 12:14.280 --> 12:20.000 And as Microsoft was talking about some of the new features, I looked over at him, I was like, yeah, so like Active Directory, right? 12:20.060 --> 12:21.120 He's not in his head. 12:21.120 --> 12:34.820 So I think there's going to be some more and more parity between the Azure AD side and the AD side, even though Azure AD is not Active Directory, at least not the same, because the authentication is very different, the management is very different. 12:34.820 --> 12:42.220 But when you look at the way that the features are being deployed and configured, MFA is getting baked into it. 12:42.220 --> 12:46.140 Conditional access I consider is kind of an identity-based firewall. 12:46.140 --> 12:53.760 You can control who can access from where with what sort of credentials, be it MFA or passwordless. 12:53.760 --> 12:56.580 So you have some of that control capability baked into it. 12:56.580 --> 12:58.180 So I see it just growing. 12:58.200 --> 13:01.580 And the challenge is that the cloud changes so frequently. 13:01.860 --> 13:05.720 I mean, myself trying to keep up with it, it's a lot. 13:05.720 --> 13:12.120 I mean, Microsoft sends out emails to Office 365 customers, I think every week, saying these are the new features. 13:12.220 --> 13:16.460 Azure Active Directory is growing and developing, maturing, and will continue to. 13:16.460 --> 13:27.740 I think on the IaaS side, so Azure, AWS, GCP, I think pretty much the platform is relatively stable from the perspective of hosting virtual machines, instances, whatever you want to call them. 13:27.740 --> 13:30.660 And the management of those will grow and develop. 13:30.660 --> 13:34.640 And the orchestration around that will grow and develop. 13:34.960 --> 13:37.720 The IAM, the ability to manage them will grow and develop. 13:37.720 --> 13:41.860 But I think the core hosting components are pretty static. 13:41.860 --> 13:47.640 I think that the security elements and controls will grow and develop and improve in that area as well. 13:48.340 --> 13:49.220 Excellent. 13:49.220 --> 13:59.900 So with regard to security or hardening, R0 wants to know, what's the best AD sync scenario direction for hybrid environments? 13:59.900 --> 14:03.400 Is it Azure to on-prem or on-prem to Azure? 14:03.400 --> 14:04.960 Or does it not matter? 14:05.360 --> 14:11.320 So typically, you're going to have your on-prem environment sync to a cloud environment. 14:11.580 --> 14:16.280 And last year, I identified that there were a lot of these sync tools. 14:16.520 --> 14:19.920 There's a different sync engine for just about every platform. 14:19.920 --> 14:26.100 I mentioned Azure AD Connect for the Microsoft Azure AD Office 365 component. 14:26.100 --> 14:32.800 But oftentimes, it's going to go that way because your core identity is going to be rooted in Active Directory on-prem, at least for most organizations. 14:32.960 --> 14:42.860 As organizations would go more cloud first, the challenge is that I've heard customers say, well, we're going to migrate from AD to Azure AD. 14:42.860 --> 14:45.020 And I'm like, it just doesn't work that way. 14:45.020 --> 14:47.220 So you don't have LDAP. 14:47.220 --> 14:48.340 You don't have Kerberos. 14:48.340 --> 14:51.180 You don't have NTLM for authentication. 14:51.180 --> 14:52.660 You don't have group policy. 14:52.760 --> 14:54.120 So everything's very different. 14:54.120 --> 14:55.920 So it's not going to work the same way. 14:56.040 --> 14:58.400 And there's different controls and capabilities there. 14:58.400 --> 15:12.000 So the identity is basically still going to be rooted in your on-prem AD unless you go with a large federation provider that then becomes your identity provider, your IDP for that identity for your users. 15:12.200 --> 15:14.580 At that point, then there's some other things you could do. 15:14.580 --> 15:25.420 But I think for the most part, we're going to see on-prem AD, at least for the next few years, syncing up to the cloud or some sort of weird amalgamation of combined identities. 15:25.420 --> 15:31.280 For years, there was this concept of like a metaverse sync engine where you have different identities in different places. 15:31.280 --> 15:38.780 You may have employees in your on-prem HR system, and you may have contractors in some other system. 15:38.780 --> 15:43.640 And then you have this kind of collected understanding of identity across those. 15:43.660 --> 15:46.100 I think that with federation, that gets simpler. 15:46.100 --> 15:51.880 And yet with the cloud, it gets more complex because the identities need to be managed even more so now. 15:52.000 --> 15:59.480 And it's already been talked about several times about how identity is the new vulnerability or the new attack surface for organizations. 15:59.640 --> 16:06.240 Because we've seen that when an admin identity gets compromised, then the whole environment can get compromised. 16:06.340 --> 16:16.120 And in the cloud, that gets even more complicated because you don't necessarily know what users on-prem could be mapped to other things in a cloud environment as far as what rights they have there. 16:16.120 --> 16:24.040 You can check them out in AD, and they're a member of the right groups, and they can do all these other things, but they may be configured as an admin in Workday or an admin in Salesforce. 16:24.040 --> 16:25.840 And that's not going to be clear. 16:25.960 --> 16:30.800 Of course, the same thing can be true for, we're said, for VMware on-prem or another application. 16:30.840 --> 16:31.900 But it just... 16:31.900 --> 16:36.140 that problem just gets exacerbated, so to speak, into the cloud environment as well. 16:40.600 --> 16:57.000 I'm curious, what do you think, for an organization that is kind of maybe thinking about moving towards more of a cloud strategy, do you think that, because like you said, you've got upper management kind of saying, hey, this is what we've got to do. 16:57.000 --> 17:00.040 We've got to move to the cloud, wave our hands around, say move to the cloud. 17:01.100 --> 17:09.240 Is that kind of move towards the cloud in any of these kind of different scenarios, do you that kind of move from a strictly security perspective? 17:09.240 --> 17:12.440 Is that more risky to do that than sticking with on-prem? 17:12.440 --> 17:15.840 And how much more risky do you think people are taking on by doing that? 17:16.340 --> 17:20.140 I think it's a balancing act, honestly, and it's a tough one. 17:20.140 --> 17:36.360 So the issue is that when this train, this cloud train is moving and operations and security in an organization just kind of has to get in line and just get on board with the cloud train, the challenge is that there's a knowledge gap. 17:36.360 --> 17:38.760 And with the cloud, there's a huge learning curve. 17:38.760 --> 17:39.800 I've certainly seen it. 17:39.800 --> 17:40.800 I'm sure others have. 17:40.800 --> 17:48.320 First of all, you can't just download some software or trial and run it on a VM on your existing system. 17:49.000 --> 17:53.580 You can get a trial for 30 days, but very often you're not going to learn what you need to. 17:53.580 --> 17:56.300 You're not going to learn what you need to in 30 days on a trial. 17:56.300 --> 17:57.840 So it's going to cost some money. 17:57.880 --> 18:03.040 And then you have to find the time to work with this new paradigm of an environment, whatever they may be. 18:03.200 --> 18:09.740 So there are some pretty big barriers for entry as far as I'm concerned with it. 18:09.740 --> 18:15.920 And so the challenges with the security of the cloud is you have to kind of understand the security capabilities of that cloud environment. 18:16.120 --> 18:24.220 The other thing I mentioned in the talk is that we've talked to a customer where their executive didn't want to have all their eggs in one basket. 18:24.220 --> 18:31.220 So they signed up with all of the big three cloud providers, Amazon, AWS, Microsoft Azure, and Google Cloud Platform. 18:31.240 --> 18:33.760 Now their eggs are in all the baskets. 18:34.000 --> 18:41.940 And it's even more challenging from that perspective, because operations and security, they've got to figure out what that looks like and how to normalize across all three. 18:41.940 --> 18:50.620 And of course there's programs or applications or systems that will help you kind of merge all that together in a way that makes sense. 18:50.620 --> 18:55.640 But then you have one system that overarches and controls or has control over all of these. 18:55.740 --> 18:57.800 So I think it's a complicated issue. 18:57.800 --> 19:04.960 I think that certainly there are a lot of security benefits that can be gained from the cloud, but you have to know what you're doing and know how to do it right. 19:04.960 --> 19:17.160 I mean, if you're going into Office 365 and Azure AD, you could absolutely, as a relatively new company or relatively small company, go cloud only and not have the on-prem AD, assuming that you don't have all the applications that are tied into it. 19:17.440 --> 19:33.080 I did an Active Directory security assessment in the last year where they had one Active Directory forest that had to stay around because the application they needed for whatever they were doing that was in that forest, it was hard-coded to the name of the Active Directory forest. 19:33.200 --> 19:35.860 And that application, the company that made it isn't around anymore. 19:35.860 --> 19:37.780 This is 10, 15 years old. 19:37.800 --> 19:45.140 So there's no way that they can move off that environment until they can figure out how to have someone else come in and recode that application potentially. 19:45.140 --> 19:55.060 But there's some weird scenarios like this that are challenges, but ultimately the migration from on-prem to the cloud, I think the challenges that are going to be applications and authentication flow. 19:55.060 --> 19:58.340 Some of the applications aren't going to support federation. 19:59.220 --> 20:06.900 I've told customers, look, telecontracting now, any new applications have to support federation because this is the time to actually get those onboarded. 20:06.900 --> 20:11.000 So that way you're not in a situation 10 years from now where you can't move things. 20:11.160 --> 20:20.560 Now, as I said, the managed AD for the major cloud providers, Azure, AWS, GCP, those are there to support those applications. 20:20.920 --> 20:34.140 But as I discussed in the talk, there's some interesting things there because now you're providing an AD environment managed by the cloud provider, but you're giving the application owner effectively the admin rights to that environment. 20:34.200 --> 20:40.560 And they're not going to be as cognizant of how well to protect those credentials potentially as someone else may be. 20:40.640 --> 20:44.480 So there's some interesting things with the managed AD environments as well from a security perspective. 20:44.480 --> 21:02.040 So I say the, my answer is it's complicated, but I think eventually it hopefully will get less complicated and be easier to actually onboard these security tools like Microsoft security defaults for Office 365, which are enabled or turned on by default now, 21:02.040 --> 21:03.940 once you have a new tenant. 21:04.960 --> 21:18.840 What do you, having given that you've now kind of taken a big picture look at all of the different platform options there, do you, is there one that kind of sticks out to you as one platform is doing it better than the others? 21:19.460 --> 21:26.660 I'd say from a managed AD environment, and I looked at Azure AD domain services, Microsoft managed AD in 2017. 21:26.660 --> 21:30.140 I looked at Amazon AWS as well in 2017. 21:30.580 --> 21:35.840 I like the fact that Amazon AWS had all the different delegation groups that they have had. 21:35.980 --> 21:39.580 The initial goals of those two environments were quite different. 21:39.580 --> 21:42.700 So that explained why they were, they were configured that way. 21:42.700 --> 21:53.480 There's some interesting aspects around Amazon or Azure Active Directory domain services, Microsoft's managed AD and how they sync, which could be some interesting things for pen testers or red teamers. 21:54.140 --> 21:57.220 I would say that there's, there's certainly elements of each that I like. 21:57.220 --> 22:00.160 I like how Amazon has delegated a lot of different things. 22:00.220 --> 22:08.500 I like GCP's approach to some of the delegation that they're doing as far as just saying, okay, we're just going to give you access to this component. 22:08.760 --> 22:19.040 For example, Azure ADDS and Amazon AWS both pre-create a fine-grained password policy and say, here, you have rights to modify this. 22:19.040 --> 22:22.980 GCP is just like, go ahead and create as many as you want, you know, kind of do your own thing. 22:23.160 --> 22:26.780 So there's definitely things I like about them, the different ones. 22:27.140 --> 22:41.860 But I'd say probably Amazon AWS is probably a little more mature from, from the delegation perspective and, and the, you can set this up and, and create a from your on-prem to, to this managed AD environment and leverage this as an extension of your on-prem AD. 22:43.820 --> 22:52.700 I was going to combine two of the questions that we got here, Gers, from both Mugs and CrunchBank. 22:53.280 --> 23:00.680 How much better off are we if we don't sync credentials from the on-prem to the cloud platform and rely on SSO? 23:00.680 --> 23:06.620 And if you're unwilling to do that, what would you be missing out on using something like the ADPTA? 23:07.680 --> 23:08.700 Good question. 23:08.700 --> 23:15.140 So the question really comes down to authentication and the risk profile of the customer themselves. 23:15.140 --> 23:27.820 So for your single sign on from your on-prem to your cloud, it's typically going to be federation, but that means you're going to have to manage and maintain your own ADFS servers, your Microsoft Active Directory Federation servers, which are a pain. 23:27.820 --> 23:29.260 They are not that easy to set up. 23:29.260 --> 23:31.300 It's, it's difficult to get right, get right. 23:31.300 --> 23:33.840 There's a lot of different things you need to get correct. 23:34.120 --> 23:40.420 So then you're looking at Ping or Okta or one of those companies that simplify that process for you, which is going to cost money. 23:40.420 --> 23:52.700 If you're a smaller company, you're probably going to do something like password hash sync, at least to the Microsoft platform where you're going to, it's Azure AD Connect is going to have the permissions and AD to pull the hashes for all the different users that are synced. 23:52.940 --> 23:55.600 Go ahead and hash those and send them up to Azure AD. 23:55.600 --> 24:10.400 And then when the user logs into Azure AD, it compares the password that the user has typed to the hash function that it runs through the on-prem AD hash function, plus the Azure AD hash function to see what that password actually is. 24:10.400 --> 24:20.960 The benefit of this password hash sync is that Microsoft gets a ton of password data from security researchers privately, law enforcement, dark web, stuff like that. 24:20.960 --> 24:26.680 So at least if you're doing password hash sync, you have a pretty good chance of knowing if that credential has been compromised. 24:27.080 --> 24:29.540 So that, that is a nice benefit. 24:29.540 --> 24:38.900 And if there's any sort of problem where like ransomware just crushes your on-prem AD and your users can't authenticate, you can flip a bit and the users can authenticate directly to Azure AD. 24:39.000 --> 24:42.200 So that way, at least they still have access to their collaboration environment. 24:42.580 --> 24:44.780 So a couple of nice benefits there. 24:44.780 --> 24:51.820 PTA is interesting from the perspective of providing access without having to do password hash sync or federation. 24:51.820 --> 24:56.940 I think that ultimately password hash sync is probably the direction that everything's going to be going in. 24:58.080 --> 25:04.820 There's certainly concerns, as I've highlighted, that other people have identified with the different options. 25:04.820 --> 25:08.880 Like I said, federation's hard and a federation server has to be available to the internet. 25:08.940 --> 25:14.640 So you have a federation server that's basically a web server that's listening to requests from the internet. 25:14.640 --> 25:21.480 We have customers that have been had denial of service attacks, basically, because accounts have been locked out with older versions of AD FS. 25:21.480 --> 25:23.740 So there's some challenges there. 25:23.740 --> 25:33.260 You got to get up to AD FS on server 2019 to enable smart lockout and really have that protect against this denial of service accounts are locked out. 25:33.260 --> 25:39.200 So I think it's definitely a complicated story and it's going to be per organization. 25:39.200 --> 25:44.240 I'd say the larger organizations pretty much already have federation because they have SaaS apps that they're using. 25:44.760 --> 25:50.960 And they pretty well understand that the smaller organizations are going to use password hash sync or PTA. 25:51.400 --> 26:00.420 Cool, I'm going to kind of combine maybe a little bit of a look forward along with with a fairly good question that we got from chat. 26:00.580 --> 26:16.520 You mentioned in your talk that, you know, cloud is in cloud security is a large area, it's growing area, and it's an opportunity for people that that are in security or looking to further specialize to see some success over the next few years. 26:16.520 --> 26:19.420 I think that the challenge for that is how do you how do you get in there? 26:19.420 --> 26:20.660 And how do you mess around with this stuff? 26:20.660 --> 26:22.780 How do you learn this kind of thing? 26:23.480 --> 26:30.340 Specifically, you've been asked if you're going to set up a hybrid training lab for red teamers of some kind. 26:30.460 --> 26:40.500 But you know, beyond maybe that, you know, if someone wanted to learn this in their spare time on the side, what's the best way for them to get into this kind of stuff? 26:41.300 --> 26:46.480 I would say that the best way to get into it would be to use a trial. 26:46.480 --> 26:50.700 I mean, that'll get you 30 days of experience, I would say read the documentation. 26:51.900 --> 26:57.620 There's videos out there as well, we're kind of walking through new features, that's a good way to learn and understand what's there. 26:57.620 --> 27:01.920 For me, there's nothing better than actually doing and playing around with it. 27:01.920 --> 27:16.760 I mean, for speaking specifically to Azure Active Directory and Office 365, you can get an account for about $20 a month, I think, that gives you Office 365, but they have cheaper ones than that, I think that you can use. 27:17.200 --> 27:24.000 But again, that is a barrier to entry, because there's a cost with the cloud, that's not there for a lot of the on-prem things. 27:24.480 --> 27:27.640 So you can, there's different trials that you can sign up for. 27:27.640 --> 27:33.380 So you could have one account that might be $8 or $10 a month, and then kind of have trials for the others. 27:33.680 --> 27:46.880 And from what I've seen with some of my testing, you can create a bunch of different accounts, and then have those kind of last for a period of time, a short period of time, before they kind of just get pulled out because they're not subscribed. 27:47.160 --> 27:50.020 So it is a challenge. 27:50.020 --> 27:54.280 I would say that every organization should have a test account. 27:54.300 --> 28:11.480 And if your job is dealing with the cloud in any way, shape, or form, ask your company to make sure there's a test account so you can better understand this, because if you're going in this direction, company's going in this direction, the most important thing they can do is to make sure that the operation security people understand the elements and ramifications of this. 28:11.740 --> 28:13.700 The cloud to me is the wild west. 28:13.700 --> 28:18.500 We just have not explored enough of it and gotten to the point where we truly understand it. 28:18.500 --> 28:22.940 We're not testing it as well from a security perspective, from a red team pen test perspective. 28:23.060 --> 28:31.660 And I think from the security perspective, I don't think the controls have been configured the way that they should be for most organizations, just because there's a lack of understanding. 28:31.660 --> 28:35.000 New things come out, new features are there, and they just don't get implemented. 28:36.000 --> 28:45.720 So given that, if you can't mitigate the risk technically and practically, here comes the lawyer to solve problems with lawyers and contracts. 28:46.580 --> 28:58.740 What kinds of things do you think that somebody could build into an SLA to protect the client in case you've got a compromise at the cloud service provider level? 29:00.860 --> 29:02.040 That's a great question. 29:02.040 --> 29:03.100 I'm not sure. 29:03.660 --> 29:07.700 That's probably above my head as far as what that would look like. 29:08.900 --> 29:11.440 And there's mitigations for that sort of thing. 29:11.440 --> 29:17.180 I mean, certainly from the IaaS side, Amazon AWS has some components around how you can configure your own encryption key. 29:17.200 --> 29:19.860 That would mitigate that pretty strongly, I would think. 29:19.860 --> 29:22.200 I believe GCP has the same capability. 29:22.800 --> 29:24.800 Azure probably has the same capability as well. 29:24.800 --> 29:26.880 So there are some options there. 29:27.080 --> 29:28.100 Encryption is easy. 29:28.100 --> 29:29.340 Key management is hard. 29:29.340 --> 29:32.420 So if you're managing your own keys, that makes things a little more difficult. 29:33.060 --> 29:36.200 But I think that those are some mitigations that could be done. 29:36.400 --> 29:39.680 There are certainly regulatory requirements based on things. 29:39.680 --> 29:45.340 But the thing is that these cloud providers have all said, we meet all these criteria. 29:45.340 --> 29:47.960 So it does make it challenging. 29:47.960 --> 29:49.820 I don't have a good answer for that. 29:50.460 --> 29:56.160 The cloud providers compromise at a pretty major level, which probably will happen at some point. 29:56.160 --> 30:00.260 I don't know that it'll be the big three, because they spend a tremendous amount of money on security. 30:00.260 --> 30:03.660 But a cloud provider compromise, I think, is going to happen at some point. 30:03.660 --> 30:09.800 It's just the nature of what we do, like the Intel processors were compromised, which I think is interesting in the past few years. 30:10.140 --> 30:17.240 So when you have hypervisors that are kind of the core to what you're doing, and then people are going to look at the hypervisors, which they have. 30:17.800 --> 30:26.100 And I think that's why Microsoft has something like $100,000 or $200,000 bug bounty for Azure core hypervisor bugs. 30:28.160 --> 30:28.760 Cool. 30:28.760 --> 30:30.820 I think there's kind of one last question. 30:30.820 --> 30:34.600 This kind of relates to how some of this stuff operates out of the box, right? 30:35.740 --> 30:52.000 Do any of these cloud services that you have taken a look at meet any of the kind of HIPAA requirements out of the box when it comes to using Active Directory creds to try to link those together with any electronic medical records programs that you know? 30:52.860 --> 30:56.560 So I don't look at the regulations per se. 30:56.940 --> 31:01.000 So I can't speak to that or really how they work across the different cloud providers. 31:01.000 --> 31:11.760 I can tell you that the regulations, there's always the regulation of how something's supposed to be because it's generally understood, that's the best way to do it. 31:11.920 --> 31:27.340 Based on Active Directory security systems that I've done on-prem and what I've seen customers do, which have been HIPAA compliant or PCI compliant, when you have a domain in an Active Directory force, which is a PCI domain, and then you firewall that off, 31:27.340 --> 31:35.860 but I can compromise a domain controller in one domain to jump over to a domain controller in that other domain, then that breaks the whole concept of PCI for that. 31:35.860 --> 31:38.340 So these things have to be separated. 31:38.340 --> 31:42.800 The security controls have to be better understood from the reality of it. 31:42.800 --> 31:45.600 And that's why pentesting and red teaming, I think, is important. 31:45.640 --> 32:01.980 And certainly security assessments like what we do, but the pentesting and red teaming, showing what these issues are and walking through how they could be compromised despite controls that people academically think are good, I think that's a big part of it. 32:01.980 --> 32:09.580 And I think that any aspiring or junior pentester or red teamer watching this right now should absolutely start learning the cloud as best they can. 32:09.660 --> 32:15.440 I mean, again, with the constraints of what it costs, but there's a lot of documentation out there, especially from Microsoft. 32:16.300 --> 32:30.900 And there's videos about walking through what these features are and what they do, and then start figuring out some ideas and some hypothesis of what this might mean, and then spin up an environment and see what it looks like in a trial and play around with it. 32:30.900 --> 32:36.020 And then your trial is going to expire and then give it a couple more months, set up another trial to play around with it. 32:36.020 --> 32:45.820 And hopefully the cloud providers will provide some sort of student or beginner access where they can actually just start playing around with these things and get a better understanding of it. 32:45.820 --> 32:51.780 I'm sure that there's some learning programs that I'm not aware of that someone will say afterwards, but that would be very helpful. 32:52.740 --> 32:53.300 Cool. 32:53.300 --> 33:08.960 Well, hey, we are just about out of time, but I want to thank you for putting together your talk and doing it pre-recorded, which I know is definitely a different experience than most of us are used to kind of getting up there and doing it live, but then also kind of playing around with this, 33:08.960 --> 33:11.720 with our kind of experiment of doing the live Q&A. 33:11.940 --> 33:13.880 I know I had a good time watching your talk. 33:13.880 --> 33:14.980 I thought it was great. 33:14.980 --> 33:19.740 And I hope everybody in the chat thought the same thing. 33:19.880 --> 33:27.540 If anybody needs to get ahold of you or, you know, kind of follow you for more of your developments, where can folks find you on the internet? 33:28.220 --> 33:34.300 Twitter's the best, at Pyrotek3, that's P-Y-R-O-T-E-K, number three. 33:35.340 --> 33:36.640 Good stuff. 33:36.820 --> 33:52.880 Well, thank you very much again, and everybody, everybody hanging out in chat, you know, we're going to take a 30-minute break so you can watch the next talk if you haven't watched it yet, and we'll have a new crew of goons and the next speaker up here in just a little bit. 33:52.880 --> 33:53.540 Thanks a bunch. 33:53.540 --> 33:54.740 We'll talk to everybody soon. 33:55.080 --> 33:55.760 Thank you.