[00:11.340 --> 00:18.100]  All righty. Well, good morning, good afternoon, or good evening, wherever you guys may be today.
[00:18.620 --> 00:26.120]  I am Jura. Stand with me. I've got Patrick. And we are here to talk with Sean Metcalf
[00:26.120 --> 00:33.900]  about his talk, Hacking the Hybrid Cloud. We've both taken some time to watch this.
[00:33.900 --> 00:39.020]  Hopefully you guys have too. I thought it was an excellent talk, incredibly comprehensive,
[00:39.020 --> 00:45.320]  and did a great job of kind of giving everybody, even if you don't have a lot of knowledge about
[00:45.320 --> 00:51.860]  Active Directory or the way that some of these deployments work, of kind of bringing you up to
[00:51.860 --> 00:56.900]  speed. So if you are kind of joining and are looking for a talk to watch and you haven't
[00:56.900 --> 01:02.820]  caught this one yet, make sure you go back and check that out. Sean, why don't you take a moment
[01:02.820 --> 01:08.580]  to introduce yourself. Tell us where you are, how you kind of got into this, and how we got to where
[01:08.580 --> 01:17.180]  we are today. Sure thing. I'm Sean Metcalf, Pyrotek3 on Twitter. Hello everyone. I've spoken at a few
[01:17.180 --> 01:24.560]  DEF CONs in the past. I really enjoy the security research element of technology and IT. I've been
[01:24.560 --> 01:29.620]  working with Active Directory since pretty much when it came out in the year 2000. First as
[01:29.620 --> 01:36.740]  operations admin, engineer, designer, architect, what have you. And then pivoted pretty hard into
[01:36.740 --> 01:43.680]  the security aspect in say 2003, 2004. But I'd say probably the interesting thing to me was looking
[01:43.680 --> 01:49.100]  at the security aspects of these systems along the way. A lot of times you have people that are
[01:49.100 --> 01:52.740]  administrators and engineers and they understand the security elements of it. They understand the
[01:52.740 --> 01:58.880]  challenges, but they just don't necessarily have the backing to push in that direction. So certainly
[01:58.880 --> 02:04.560]  for me, since I was coming up through the Microsoft area, I didn't feel like the security space or
[02:04.560 --> 02:11.020]  InfoSec was really a space for me because I had worked with Microsoft Windows and most of the
[02:11.020 --> 02:17.000]  security people in 2000 to 2010 and certainly beyond are like, oh, Microsoft Windows, that's a
[02:17.000 --> 02:23.000]  toy OS. What do you know about security in that area? So after I had been working with
[02:23.000 --> 02:29.940]  Active Directory for a long time and I started seeing these attacks go from hypothetical to
[02:29.940 --> 02:33.500]  reality, I said, hey, there's really something here. And I started putting together some talks
[02:33.500 --> 02:38.980]  to help people better understand Active Directory security. And then in 2017, I did a talk with
[02:39.500 --> 02:45.380]  Taya about hacking the cloud and what that actually means. And at the time,
[02:45.380 --> 02:50.320]  Taya was working on the Azure Red team. And so I learned a lot from Taya about
[02:51.040 --> 02:57.520]  how these things interconnect. Certainly looked a lot at Azure AD and Office 365 at that time.
[02:57.520 --> 03:04.420]  As I was continuing that journey, in the past year, I identified some issues or concerns that
[03:04.420 --> 03:10.260]  I had with hybrid cloud. So these connection points between your on-prem Active Directory and
[03:10.260 --> 03:18.620]  Azure AD or Office 365 or Azure and beyond. And certainly Dirk-Jan Milema, he did a great talk
[03:18.620 --> 03:23.360]  last year at DEF CON and has been publishing some great information about doing just that
[03:23.880 --> 03:29.140]  from a comprehensive attack perspective. So certainly the research of others have been
[03:29.140 --> 03:33.000]  inspiring my research recently and things that I've been looking at.
[03:34.700 --> 03:41.240]  Excellent. Sean, so I guess also just for starters, can you kind of like
[03:42.240 --> 03:47.600]  explain in a nutshell what like the hybrid cloud... I think people kind of understand
[03:47.600 --> 03:51.380]  the cloud and people understand on-prem. Can you kind of talk a little bit about
[03:51.380 --> 03:56.440]  what you mean with the hybrid cloud? Sure thing. So it's good to have a good
[03:56.440 --> 04:00.180]  definition or it's good to have a solid definition of what it actually is because,
[04:00.800 --> 04:05.940]  like you said, it can be confusing. So for me, at least the definition I put together for this talk
[04:05.940 --> 04:11.340]  is hybrid cloud is when you have on-premises infrastructure. So you have something like
[04:11.340 --> 04:16.840]  Active Directory and then you have something in the cloud. It could be you've extended your
[04:16.840 --> 04:23.680]  on-prem environment into cloud IaaS infrastructure as a service. So you're using the cloud sort of as
[04:23.680 --> 04:28.120]  an extension of your data center. A lot of organizations are moving into the cloud and
[04:28.120 --> 04:35.320]  using the Azure or AWS or even GCP as their data center now. So that's one part of it. Another part
[04:35.320 --> 04:39.300]  of it is when you have all your on-prem infrastructure that's handling your typical
[04:39.300 --> 04:43.920]  things like Active Directory logons, things like that. But then you have services that are up in
[04:43.920 --> 04:49.260]  the cloud. So your SaaS side, so software as a service. You have things like Salesforce or you
[04:49.260 --> 04:54.560]  have Workday or you have Office 365 or things along those lines where you have some connection
[04:54.560 --> 05:01.780]  points. And so certainly from the Office 365 on-prem AD side, there's a connection point called
[05:02.320 --> 05:06.960]  Azure Active Directory Connect. And there's some interesting things that have occurred with
[05:06.960 --> 05:11.960]  that connection point between your on-prem and that cloud environment. I pointed out some back
[05:11.960 --> 05:17.140]  in 2017, Dirk Jans published a whole bunch of information about that. Others like Adam
[05:17.140 --> 05:21.880]  Chesters has identified some things where the additional connection points of what Microsoft's
[05:21.880 --> 05:29.460]  been doing to simplify this authentication flow between on-prem and the cloud. And I think that's
[05:29.460 --> 05:35.600]  really one of the things that I wanted to dive into as part of my talk was discussing the roles
[05:35.600 --> 05:41.060]  and how they're typically over permission and also looking at this authentication flow that
[05:41.060 --> 05:45.880]  gets very complicated. And that's why I closed out the talk with a bunch of different slides
[05:45.880 --> 05:49.820]  where you have three different cloud environments and you have your on-prem environment and you're
[05:49.820 --> 05:55.940]  working through the federation of it and how they all get interconnected in very interesting ways.
[05:56.040 --> 06:00.740]  The IAM story there, the Identity Access Management story is very complicated when
[06:00.740 --> 06:05.360]  you have multiple cloud environments. And it gets difficult to track what all these roles are.
[06:05.360 --> 06:10.940]  And typically they get over permission just like they do on-prem. So the other thing I wanted to
[06:10.940 --> 06:16.320]  establish as a narrative of my talk was that we have virtualization on-prem. We're using VMware
[06:16.320 --> 06:22.380]  primarily, predominantly. And then there's also Hyper-V to some extent. And then in the cloud,
[06:22.380 --> 06:29.220]  we have effectively virtualization writ large. Be it Amazon AWS, which started with Zen,
[06:29.220 --> 06:35.420]  uses more of Amazon's Nitro now, to Azure leveraging a custom version Hyper-V core, to
[06:35.960 --> 06:42.400]  GCP using Zen to straight up in their environment. So this concept of virtualization and the way that
[06:42.400 --> 06:47.680]  you attack or could attack virtualization on-prem is very similar to how you can do so in the cloud.
[06:47.680 --> 06:51.560]  And I think that was an important part of what I was talking about. And I even mentioned how you
[06:52.540 --> 06:57.780]  could attack on-prem AD domain controllers, as well as those on-prem AD domain controllers
[06:57.780 --> 07:02.700]  hosted in the cloud. So regardless of where they are, they're vulnerable. And then the attacks
[07:02.700 --> 07:06.680]  across those different platforms can have some similarities, but also some pretty
[07:06.680 --> 07:16.980]  significant differences. Excellent. Also, is there really any kind of difference or what
[07:16.980 --> 07:21.860]  should people think about if they have their AD environment in Azure or if they have it as an
[07:21.860 --> 07:29.000]  on-prem AD environment? Are there differences they should think about? Sure. So my friend and
[07:29.000 --> 07:34.540]  colleague Demetrius, his first question is, do you trust the cloud? Because everything starts
[07:34.540 --> 07:40.520]  with that trust. So we usually presume or assume that our customers trust the cloud because they
[07:40.520 --> 07:45.880]  already have things in it. But we still ask the question that to what degree or to what level do
[07:45.880 --> 07:51.340]  you trust the cloud? Because you have to have that trust. I have concerns certainly about placing
[07:51.340 --> 07:55.240]  on-prem Active Directory domain controllers into cloud environments, IaaS environments,
[07:55.240 --> 07:58.840]  regardless of what they are, because ultimately there's a significant amount of trust.
[07:59.560 --> 08:04.100]  With the cloud provider. The other part of that is oftentimes you'll set up your IaaS environment,
[08:04.100 --> 08:09.900]  AWS or Azure, where your server admins are the ones that manage that entire environment.
[08:09.980 --> 08:14.600]  Well, your server admins who manage that environment can run commands potentially on
[08:14.600 --> 08:20.060]  the domain controllers in those environments. So if an attacker can compromise one of those
[08:20.060 --> 08:26.560]  server admin accounts, then they can compromise your on-prem AD. I walked through for the scene
[08:26.560 --> 08:34.640]  of the talk with Amazon over Federation, a way that you can link your IAM role in AWS with your
[08:34.640 --> 08:39.300]  on-prem AD group. And then you can have an on-prem regular user that's a member of that group
[08:39.300 --> 08:44.460]  that gets compromised because he's a regular user. And then leverage that account in order to
[08:44.460 --> 08:50.300]  compromise the domain controllers hosted in AWS, just because that one account was compromised.
[08:50.300 --> 08:56.240]  It has that extended role access and privileges. And then because it's in the cloud, that can
[08:56.240 --> 09:00.200]  roll right back again and compromise the full on-prem Active Directory environment.
[09:00.620 --> 09:05.240]  So there's some very interesting things that happen with that. So I also talk about one
[09:05.240 --> 09:10.820]  interesting one from Azure AD to Azure, because of this sort of backdoor that Microsoft put into it
[09:10.820 --> 09:15.860]  and has talked about, but it wasn't clear that if you were a global admin in Azure Active Directory,
[09:15.860 --> 09:19.700]  that you could then go jump over to Azure and have full control of that environment.
[09:19.760 --> 09:24.360]  So I walked through that as well, because these sort of connection points are interesting, but
[09:24.660 --> 09:28.060]  a lot of times operations is like, let's go, let's get it done.
[09:28.320 --> 09:33.240]  And they're being told by the executives, we have to get into the cloud. Our number one goal right
[09:33.240 --> 09:38.800]  now is to get in the cloud. I mean, we've had a surge of interest and companies that have moved
[09:38.800 --> 09:42.760]  to the cloud. We've been very busy talking and consulting with customers that are moving to
[09:42.760 --> 09:46.740]  the cloud, because they're like, are we doing this right? Because operations gets pulled along
[09:46.740 --> 09:51.460]  and thrown in and say, you got to migrate all these systems in the cloud. And then you have
[09:51.460 --> 09:56.140]  security team going, I just don't know what I'm supposed to do with this. Like,
[09:56.140 --> 10:01.820]  what are we supposed to know? Because the thing is on-premise is well understood, right? We at
[10:01.820 --> 10:06.740]  least know what our egress ingress points are. At least we hope that they do. Pen testers and
[10:06.740 --> 10:11.760]  red keepers are good at helping to point out what those actually are. We have a decent idea of
[10:11.760 --> 10:15.820]  auditing and logging. And while things aren't great, at least there's some knowledge of where
[10:15.820 --> 10:21.160]  some of those weaker points are. In the cloud, we have to leverage whatever the cloud provider
[10:21.720 --> 10:27.280]  gives to us. So Azure, AWS, GCP, they have different capabilities. They have different
[10:27.280 --> 10:32.580]  controls. And then the nomenclature, the names for all these things are different across all of them.
[10:32.580 --> 10:38.080]  So one thing that may be called something in Azure, it may be called something different in
[10:38.080 --> 10:44.580]  AWS and something else in GCP. So what I find myself doing is saying, okay, a subnet, whatever
[10:44.580 --> 10:48.920]  that may be called in this cloud environment, that's what you need to do. Or let's have a zone
[10:48.920 --> 10:55.380]  where we segment off this one type of system from the others. And then we make sure that we can
[10:55.380 --> 11:00.820]  track and control what systems that can connect with it. I will say that one of the things that
[11:00.820 --> 11:05.420]  we have the opportunity with in the cloud now is the ability to actually implement network
[11:05.420 --> 11:10.620]  segmentation, which we've failed for years on prem, right? Because now we're setting everything
[11:10.620 --> 11:15.780]  up. We should be building these zones. A zone for domain controllers, a zone for servers,
[11:15.860 --> 11:20.340]  a zone for clients, a zone for other things, and then control the communication between them.
[11:21.120 --> 11:25.880]  There's some ways that that could be done on prem, but the cloud gives the capability and
[11:25.880 --> 11:34.300]  ability now to move forward in that direction. Cool. We've got some coming in from chat here.
[11:34.720 --> 11:43.080]  So Mugs asks, Azure services evolve quickly. Do you see AAD evolving rapidly, or is it pretty
[11:43.080 --> 11:48.860]  well baked at this point as a fundamental underpinning of PaaS and software as a service
[11:49.540 --> 11:55.620]  services, generally speaking? Right. So Azure Active Directory and the Office 365 cloud,
[11:55.620 --> 12:00.920]  that's kind of an extension of that, is evolving very rapidly. Microsoft keeps hiring developers
[12:00.920 --> 12:07.060]  and adding new features. And it's funny because Mark Morrow, who I did a talk with
[12:07.060 --> 12:11.620]  about the cloud last year at Black Hat, I was at Redmond with him earlier this year
[12:11.620 --> 12:17.440]  for an Azure AD identity event. And as Microsoft was talking about some of the new features,
[12:17.440 --> 12:21.120]  I looked over at him, I was like, yeah, so like Active Directory, right? He's not in his head.
[12:21.120 --> 12:26.680]  So I think there's going to be some more and more parity between the Azure AD side and the AD side,
[12:26.680 --> 12:32.320]  even though Azure AD is not Active Directory, at least not the same, because the authentication
[12:32.320 --> 12:36.580]  is very different, the management is very different. But when you look at the way that
[12:36.580 --> 12:43.000]  the features are being deployed and configured, MFA is getting baked into it. Conditional access
[12:43.000 --> 12:47.800]  I consider is kind of an identity-based firewall. You can control who can access from where
[12:47.800 --> 12:54.740]  with what sort of credentials, be it MFA or passwordless. So you have some of that control
[12:54.740 --> 12:59.820]  capability baked into it. So I see it just growing. And the challenge is that the cloud
[12:59.820 --> 13:06.000]  changes so frequently. I mean, myself trying to keep up with it, it's a lot. I mean,
[13:06.000 --> 13:10.920]  Microsoft sends out emails to Office 365 customers, I think every week, saying these
[13:10.920 --> 13:15.400]  are the new features. Azure Active Directory is growing and developing, maturing, and will
[13:15.400 --> 13:22.040]  continue to. I think on the IaaS side, so Azure, AWS, GCP, I think pretty much the platform is
[13:22.040 --> 13:26.880]  relatively stable from the perspective of hosting virtual machines, instances, whatever you want
[13:26.880 --> 13:32.960]  to call them. And the management of those will grow and develop. And the orchestration around
[13:32.960 --> 13:38.040]  that will grow and develop. The IAM, the ability to manage them will grow and develop. But I think
[13:38.040 --> 13:43.900]  the core hosting components are pretty static. I think that the security elements and controls
[13:43.900 --> 13:51.580]  will grow and develop and improve in that area as well. Excellent. So with regard to security
[13:51.580 --> 13:59.900]  or hardening, R0 wants to know, what's the best AD sync scenario direction for hybrid environments?
[13:59.900 --> 14:06.800]  Is it Azure to on-prem or on-prem to Azure? Or does it not matter? So typically, you're going
[14:06.800 --> 14:13.540]  to have your on-prem environment sync to a cloud environment. And last year, I identified that there
[14:13.540 --> 14:19.920]  were a lot of these sync tools. There's a different sync engine for just about every platform.
[14:19.920 --> 14:27.000]  I mentioned Azure AD Connect for the Microsoft Azure AD Office 365 component. But oftentimes,
[14:27.000 --> 14:30.640]  it's going to go that way because your core identity is going to be rooted in Active Directory
[14:30.640 --> 14:35.960]  on-prem, at least for most organizations. As organizations would go more cloud first,
[14:35.960 --> 14:42.860]  the challenge is that I've heard customers say, well, we're going to migrate from AD to Azure AD.
[14:42.860 --> 14:48.400]  And I'm like, it just doesn't work that way. So you don't have LDAP. You don't have Kerberos. You
[14:48.400 --> 14:54.260]  don't have NTLM for authentication. You don't have group policy. So everything's very different. So
[14:54.260 --> 14:58.560]  it's not going to work the same way. And there's different controls and capabilities there. So
[14:58.560 --> 15:03.400]  the identity is basically still going to be rooted in your on-prem AD unless you go with a
[15:03.400 --> 15:10.360]  large federation provider that then becomes your identity provider, your IDP for that
[15:10.360 --> 15:15.000]  identity for your users. At that point, then there's some other things you could do. But I
[15:15.000 --> 15:18.600]  think for the most part, we're going to see on-prem AD, at least for the next few years,
[15:18.600 --> 15:26.040]  syncing up to the cloud or some sort of weird amalgamation of combined identities. For years,
[15:26.040 --> 15:30.500]  there was this concept of like a metaverse sync engine where you have different identities in
[15:30.500 --> 15:36.800]  different places. You may have employees in your on-prem HR system, and you may have
[15:37.320 --> 15:41.960]  contractors in some other system. And then you have this kind of collected understanding of
[15:41.960 --> 15:47.040]  identity across those. I think that with federation, that gets simpler. And yet with the cloud,
[15:47.040 --> 15:52.500]  it gets more complex because the identities need to be managed even more so now. And it's already
[15:52.500 --> 15:58.000]  been talked about several times about how identity is the new vulnerability or the new attack surface
[15:58.000 --> 16:04.500]  for organizations. Because we've seen that when an admin identity gets compromised, then the
[16:04.500 --> 16:08.520]  whole environment can get compromised. And in the cloud, that gets even more complicated because
[16:09.040 --> 16:14.020]  you don't necessarily know what users on-prem could be mapped to other things in a cloud
[16:14.020 --> 16:18.100]  environment as far as what rights they have there. You can check them out in AD, and they're a member
[16:18.100 --> 16:21.840]  of the right groups, and they can do all these other things, but they may be configured as an
[16:21.840 --> 16:26.580]  admin in Workday or an admin in Salesforce. And that's not going to be clear. Of course, the same
[16:26.580 --> 16:31.900]  thing can be true for, we're said, for VMware on-prem or another application. 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:46.660]  I'm curious, what do you think, for an organization that is
[16:46.660 --> 16:53.200]  kind of maybe thinking about moving towards more of a cloud strategy, do you think that,
[16:53.200 --> 16:56.500]  because like you said, you've got upper management kind of saying, hey, this is what
[16:56.500 --> 17:00.040]  we've got to do. We've got to move to the cloud, wave our hands around, say move to the cloud.
[17:01.100 --> 17:06.040]  Is that kind of move towards the cloud in any of these kind of different scenarios, do you
[17:06.040 --> 17:10.900]  that kind of move from a strictly security perspective? Is that more risky to do that
[17:10.900 --> 17:15.840]  than sticking with on-prem? And how much more risky do you think people are taking on by doing that?
[17:16.340 --> 17:22.140]  I think it's a balancing act, honestly, and it's a tough one. So the issue is that when
[17:22.840 --> 17:27.640]  this train, this cloud train is moving and operations and security in an organization
[17:27.640 --> 17:33.600]  just kind of has to get in line and just get on board with the cloud train,
[17:33.600 --> 17:38.760]  the challenge is that there's a knowledge gap. And with the cloud, there's a huge learning curve.
[17:38.760 --> 17:42.440]  I've certainly seen it. I'm sure others have. First of all, you can't just download some
[17:42.440 --> 17:50.980]  software or trial and run it on a VM on your existing system. You can get a trial for 30 days,
[17:50.980 --> 17:54.420]  but very often you're not going to learn what you need to. You're not going to learn what you
[17:54.420 --> 17:59.000]  need to in 30 days on a trial. So it's going to cost some money. And then you have to find the
[17:59.000 --> 18:03.700]  time to work with this new paradigm of an environment, whatever they may be. So there
[18:03.700 --> 18:11.040]  are some pretty big barriers for entry as far as I'm concerned with it. And so the challenges with
[18:11.040 --> 18:15.080]  the security of the cloud is you have to kind of understand the security capabilities of that cloud
[18:15.080 --> 18:20.380]  environment. The other thing I mentioned in the talk is that we've talked to a customer where
[18:20.380 --> 18:25.220]  their executive didn't want to have all their eggs in one basket. So they signed up with
[18:25.900 --> 18:31.220]  all of the big three cloud providers, Amazon, AWS, Microsoft Azure, and Google Cloud Platform.
[18:31.240 --> 18:36.120]  Now their eggs are in all the baskets. And it's even more challenging from that perspective,
[18:36.120 --> 18:40.240]  because operations and security, they've got to figure out what that looks like and how to
[18:40.240 --> 18:47.740]  normalize across all three. And of course there's programs or applications or systems that will help
[18:47.740 --> 18:52.240]  you kind of merge all that together in a way that makes sense. But then you have one system that
[18:52.240 --> 18:57.800]  overarches and controls or has control over all of these. So I think it's a complicated issue.
[18:57.800 --> 19:02.420]  I think that certainly there are a lot of security benefits that can be gained from the cloud,
[19:02.420 --> 19:05.760]  but you have to know what you're doing and know how to do it right. I mean, if you're going into
[19:05.760 --> 19:11.000]  Office 365 and Azure AD, you could absolutely, as a relatively new company or relatively small
[19:11.000 --> 19:15.840]  company, go cloud only and not have the on-prem AD, assuming that you don't have all the applications
[19:15.840 --> 19:20.880]  that are tied into it. I did an Active Directory security assessment in the last year where they
[19:20.880 --> 19:25.920]  had one Active Directory forest that had to stay around because the application they needed for
[19:25.920 --> 19:31.940]  whatever they were doing that was in that forest, it was hard-coded to the name of the Active
[19:31.940 --> 19:36.100]  Directory forest. And that application, the company that made it isn't around anymore. This is
[19:36.100 --> 19:40.880]  10, 15 years old. So there's no way that they can move off that environment until they can figure
[19:40.880 --> 19:45.980]  out how to have someone else come in and recode that application potentially. But there's
[19:45.980 --> 19:50.260]  some weird scenarios like this that are challenges, but ultimately the migration from on-prem to the
[19:50.260 --> 19:55.060]  cloud, I think the challenges that are going to be applications and authentication flow.
[19:55.060 --> 20:01.160]  Some of the applications aren't going to support federation. I've told customers, look,
[20:01.160 --> 20:05.380]  telecontracting now, any new applications have to support federation because this is the time to
[20:05.380 --> 20:09.640]  actually get those onboarded. So that way you're not in a situation 10 years from now where you
[20:09.640 --> 20:17.440]  can't move things. Now, as I said, the managed AD for the major cloud providers, Azure, AWS, GCP,
[20:17.440 --> 20:23.400]  those are there to support those applications. But as I discussed in the talk, there's some
[20:23.400 --> 20:27.580]  interesting things there because now you're providing an AD environment managed by the
[20:27.580 --> 20:33.160]  cloud provider, but you're giving the application owner effectively the admin rights to that
[20:33.160 --> 20:38.000]  environment. And they're not going to be as cognizant of how well to protect those credentials
[20:38.000 --> 20:42.600]  potentially as someone else may be. So there's some interesting things with the managed AD
[20:42.600 --> 20:47.860]  environments as well from a security perspective. So I say the, my answer is it's complicated,
[20:48.200 --> 20:53.860]  but I think eventually it hopefully will get less complicated and be easier to actually
[20:53.860 --> 20:59.200]  onboard these security tools like Microsoft security defaults for Office 365, which are
[20:59.200 --> 21:03.940]  enabled or turned on by default now, once you have a new tenant.
[21:04.960 --> 21:10.140]  What do you, having given that you've now kind of taken a big picture look at all of the different
[21:10.140 --> 21:17.120]  platform options there, do you, is there one that kind of sticks out to you as one platform is doing
[21:17.120 --> 21:23.720]  it better than the others? I'd say from a managed AD environment, and I looked at Azure AD domain
[21:23.720 --> 21:31.760]  services, Microsoft managed AD in 2017. I looked at Amazon AWS as well in 2017. I like the fact
[21:31.760 --> 21:37.660]  that Amazon AWS had all the different delegation groups that they have had. The initial goals of
[21:37.660 --> 21:41.420]  those two environments were quite different. So that explained why they were, they were
[21:41.420 --> 21:46.800]  configured that way. There's some interesting aspects around Amazon or Azure Active Directory
[21:46.800 --> 21:51.740]  domain services, Microsoft's managed AD and how they sync, which could be some interesting things
[21:51.740 --> 21:56.860]  for pen testers or red teamers. I would say that there's, there's certainly elements of each that
[21:56.860 --> 22:02.780]  I like. I like how Amazon has delegated a lot of different things. I like GCP's approach to some
[22:02.780 --> 22:06.960]  of the delegation that they're doing as far as just saying, okay, we're just going to give you
[22:06.960 --> 22:15.880]  access to this component. For example, Azure ADDS and Amazon AWS both pre-create a fine-grained
[22:15.880 --> 22:20.160]  password policy and say, here, you have rights to modify this. GCP is just like, go ahead and
[22:20.160 --> 22:24.140]  create as many as you want, you know, kind of do your own thing. So there's definitely things I
[22:24.140 --> 22:30.380]  like about them, the different ones. But I'd say probably Amazon AWS is probably a little more
[22:30.380 --> 22:35.420]  mature from, from the delegation perspective and, and the, you can set this up and, and create a
[22:35.740 --> 22:40.240]  from your on-prem to, to this managed AD environment and leverage this as an extension
[22:40.240 --> 22:48.900]  of your on-prem AD. I was going to combine two of the questions that we got here, Gers,
[22:48.900 --> 22:56.820]  from both Mugs and CrunchBank. How much better off are we if we don't sync credentials from the
[22:56.820 --> 23:02.700]  on-prem to the cloud platform and rely on SSO? And if you're unwilling to do that,
[23:02.700 --> 23:06.620]  what would you be missing out on using something like the ADPTA?
[23:07.680 --> 23:13.740]  Good question. So the question really comes down to authentication and the risk profile of the
[23:13.740 --> 23:19.500]  customer themselves. So for your single sign on from your on-prem to your cloud, it's typically
[23:19.500 --> 23:23.800]  going to be federation, but that means you're going to have to manage and maintain your own
[23:23.800 --> 23:28.080]  ADFS servers, your Microsoft Active Directory Federation servers, which are a pain. They are
[23:28.080 --> 23:32.140]  not that easy to set up. It's, it's difficult to get right, get right. There's a lot of different
[23:32.140 --> 23:36.780]  things you need to get correct. So then you're looking at Ping or Okta or one of those companies
[23:36.780 --> 23:41.480]  that simplify that process for you, which is going to cost money. If you're a smaller company,
[23:41.480 --> 23:44.340]  you're probably going to do something like password hash sync, at least to the Microsoft
[23:44.340 --> 23:49.340]  platform where you're going to, it's Azure AD Connect is going to have the permissions and AD
[23:49.340 --> 23:54.320]  to pull the hashes for all the different users that are synced. Go ahead and hash those and
[23:54.320 --> 24:00.120]  send them up to Azure AD. And then when the user logs into Azure AD, it compares the password that
[24:00.120 --> 24:06.540]  the user has typed to the hash function that it runs through the on-prem AD hash function, plus
[24:06.540 --> 24:11.680]  the Azure AD hash function to see what that password actually is. The benefit of this password
[24:11.680 --> 24:18.180]  hash sync is that Microsoft gets a ton of password data from security researchers privately, law
[24:18.180 --> 24:23.380]  enforcement, dark web, stuff like that. So at least if you're doing password hash sync, you have a
[24:23.380 --> 24:29.000]  pretty good chance of knowing if that credential has been compromised. So that, that is a nice
[24:29.000 --> 24:33.220]  benefit. And if there's any sort of problem where like ransomware just crushes your on-prem AD
[24:33.220 --> 24:37.920]  and your users can't authenticate, you can flip a bit and the users can authenticate directly to
[24:37.920 --> 24:42.200]  Azure AD. So that way, at least they still have access to their collaboration environment.
[24:42.580 --> 24:47.340]  So a couple of nice benefits there. PTA is interesting from the perspective of providing
[24:47.340 --> 24:53.340]  access without having to do password hash sync or federation. I think that ultimately
[24:53.340 --> 24:56.940]  password hash sync is probably the direction that everything's going to be going in.
[24:58.080 --> 25:03.580]  There's certainly concerns, as I've highlighted, that other people have identified with the
[25:03.580 --> 25:08.160]  different options. Like I said, federation's hard and a federation server has to be available to the
[25:08.160 --> 25:13.920]  internet. So you have a federation server that's basically a web server that's listening to requests
[25:13.920 --> 25:18.360]  from the internet. We have customers that have been had denial of service attacks, basically,
[25:18.360 --> 25:22.980]  because accounts have been locked out with older versions of AD FS. So there's some challenges
[25:22.980 --> 25:29.560]  there. You got to get up to AD FS on server 2019 to enable smart lockout and really have that
[25:30.100 --> 25:35.480]  protect against this denial of service accounts are locked out. So I think it's definitely a
[25:35.480 --> 25:40.700]  complicated story and it's going to be per organization. I'd say the larger organizations
[25:40.700 --> 25:46.480]  pretty much already have federation because they have SaaS apps that they're using. And they pretty
[25:46.480 --> 25:50.960]  well understand that the smaller organizations are going to use password hash sync or PTA.
[25:51.400 --> 25:57.500]  Cool, I'm going to kind of combine maybe a little bit of a look forward along with with a fairly
[25:57.500 --> 26:05.140]  good question that we got from chat. You mentioned in your talk that, you know, cloud is in cloud
[26:05.140 --> 26:11.100]  security is a large area, it's growing area, and it's an opportunity for people that that are in
[26:11.100 --> 26:16.880]  security or looking to further specialize to see some success over the next few years. I think that
[26:16.880 --> 26:20.440]  the challenge for that is how do you how do you get in there? And how do you mess around with this
[26:20.440 --> 26:26.480]  stuff? How do you learn this kind of thing? Specifically, you've been asked if you're going
[26:26.480 --> 26:32.720]  to set up a hybrid training lab for red teamers of some kind. But you know, beyond maybe that,
[26:32.720 --> 26:38.020]  you know, if someone wanted to learn this in their spare time on the side, what's the best way for
[26:38.020 --> 26:44.420]  them to get into this kind of stuff? I would say that the best way to get into it would be
[26:44.980 --> 26:50.700]  to use a trial. I mean, that'll get you 30 days of experience, I would say read the documentation.
[26:51.900 --> 26:55.700]  There's videos out there as well, we're kind of walking through new features, that's a good way
[26:55.700 --> 27:00.500]  to learn and understand what's there. For me, there's nothing better than actually doing and
[27:00.500 --> 27:05.080]  playing around with it. I mean, for speaking specifically to Azure Active Directory and
[27:05.080 --> 27:13.080]  Office 365, you can get an account for about $20 a month, I think, that gives you Office 365,
[27:13.080 --> 27:19.200]  but they have cheaper ones than that, I think that you can use. But again, that is a barrier
[27:19.200 --> 27:24.000]  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:28.820]  So you can, there's different trials that you can sign up for. So you could have one account
[27:28.820 --> 27:34.620]  that might be $8 or $10 a month, and then kind of have trials for the others. And from what I've
[27:34.620 --> 27:38.900]  seen with some of my testing, you can create a bunch of different accounts, and then have those
[27:38.900 --> 27:44.880]  kind of last for a period of time, a short period of time, before they kind of just get pulled out
[27:44.880 --> 27:52.640]  because they're not subscribed. So it is a challenge. I would say that every organization
[27:52.640 --> 27:58.380]  should have a test account. And if your job is dealing with the cloud in any way, shape, or form,
[27:58.380 --> 28:01.960]  ask your company to make sure there's a test account so you can better understand this,
[28:01.960 --> 28:05.440]  because if you're going in this direction, company's going in this direction, the most
[28:05.440 --> 28:09.540]  important thing they can do is to make sure that the operation security people understand the
[28:09.540 --> 28:14.640]  elements and ramifications of this. The cloud to me is the wild west. We just have not explored
[28:14.640 --> 28:20.040]  enough of it and gotten to the point where we truly understand it. We're not testing it as well
[28:20.040 --> 28:24.120]  from a security perspective, from a red team pen test perspective. And I think from the security
[28:24.120 --> 28:28.300]  perspective, I don't think the controls have been configured the way that they should be
[28:28.300 --> 28:32.500]  for most organizations, just because there's a lack of understanding. New things come out,
[28:32.500 --> 28:35.000]  new features are there, and they just don't get implemented.
[28:36.000 --> 28:41.180]  So given that, if you can't mitigate the risk technically and practically,
[28:41.940 --> 28:45.720]  here comes the lawyer to solve problems with lawyers and contracts.
[28:46.580 --> 28:53.500]  What kinds of things do you think that somebody could build into an SLA to protect the client
[28:53.500 --> 28:58.740]  in case you've got a compromise at the cloud service provider level?
[29:00.860 --> 29:06.340]  That's a great question. I'm not sure. That's probably above my head as far as what that would
[29:06.340 --> 29:12.980]  look like. And there's mitigations for that sort of thing. I mean, certainly from the IaaS side,
[29:12.980 --> 29:17.640]  Amazon AWS has some components around how you can configure your own encryption key. That would
[29:17.640 --> 29:23.280]  mitigate that pretty strongly, I would think. I believe GCP has the same capability. Azure
[29:23.280 --> 29:28.100]  probably has the same capability as well. So there are some options there. Encryption is easy.
[29:28.100 --> 29:31.640]  Key management is hard. So if you're managing your own keys, that makes things a little more
[29:31.640 --> 29:36.640]  difficult. But I think that those are some mitigations that could be done. There are
[29:36.640 --> 29:41.580]  certainly regulatory requirements based on things. But the thing is that these cloud providers have
[29:41.580 --> 29:48.960]  all said, we meet all these criteria. So it does make it challenging. I don't have a good answer
[29:48.960 --> 29:55.360]  for that. The cloud providers compromise at a pretty major level, which probably will happen
[29:55.360 --> 29:59.400]  at some point. I don't know that it'll be the big three, because they spend a tremendous amount of
[29:59.400 --> 30:03.700]  money on security. But a cloud provider compromise, I think, is going to happen at some point. It's
[30:03.700 --> 30:08.220]  just the nature of what we do, like the Intel processors were compromised, which I think is
[30:08.220 --> 30:13.220]  interesting in the past few years. So when you have hypervisors that are kind of the core to
[30:13.220 --> 30:17.240]  what you're doing, and then people are going to look at the hypervisors, which they have.
[30:17.800 --> 30:23.700]  And I think that's why Microsoft has something like $100,000 or $200,000 bug bounty for Azure
[30:24.250 --> 30:26.100]  core hypervisor bugs.
[30:28.160 --> 30:32.780]  Cool. I think there's kind of one last question. This kind of relates to how some of this stuff
[30:32.780 --> 30:40.520]  operates out of the box, right? Do any of these cloud services that you have taken a look at
[30:40.520 --> 30:46.000]  meet any of the kind of HIPAA requirements out of the box when it comes to using Active Directory
[30:46.000 --> 30:52.000]  creds to try to link those together with any electronic medical records programs that you know?
[30:52.860 --> 30:59.380]  So I don't look at the regulations per se. So I can't speak to that or really how they work
[30:59.380 --> 31:06.500]  across the different cloud providers. I can tell you that the regulations, there's always the
[31:06.500 --> 31:10.520]  regulation of how something's supposed to be because it's generally understood, that's the
[31:10.520 --> 31:15.460]  best way to do it. Based on Active Directory security systems that I've done on-prem and what
[31:15.460 --> 31:23.180]  I've seen customers do, which have been HIPAA compliant or PCI compliant, when you have a
[31:23.180 --> 31:27.900]  domain in an Active Directory force, which is a PCI domain, and then you firewall that off, but
[31:27.900 --> 31:31.640]  I can compromise a domain controller in one domain to jump over to a domain controller in
[31:31.640 --> 31:37.300]  that other domain, then that breaks the whole concept of PCI for that. So these things have
[31:37.300 --> 31:42.860]  to be separated. The security controls have to be better understood from the reality of it. And
[31:42.860 --> 31:46.720]  that's why pentesting and red teaming, I think, is important. And certainly security assessments
[31:46.720 --> 31:51.440]  like what we do, but the pentesting and red teaming, showing what these issues are and
[31:51.440 --> 31:58.940]  walking through how they could be compromised despite controls that people academically think
[31:58.940 --> 32:05.120]  are good, I think that's a big part of it. And I think that any aspiring or junior pentester or
[32:05.120 --> 32:08.900]  red teamer watching this right now should absolutely start learning the cloud as best they
[32:08.900 --> 32:14.000]  can. I mean, again, with the constraints of what it costs, but there's a lot of documentation out
[32:14.000 --> 32:18.720]  there, especially from Microsoft. And there's videos about walking through what these features
[32:18.720 --> 32:24.300]  are and what they do, and then start figuring out some ideas and some hypothesis of what this
[32:24.300 --> 32:30.460]  might mean, and then spin up an environment and see what it looks like in a trial and play around
[32:30.460 --> 32:34.040]  with it. And then your trial is going to expire and then give it a couple more months, set up
[32:34.040 --> 32:38.360]  another trial to play around with it. And hopefully the cloud providers will provide some sort of
[32:38.360 --> 32:43.960]  student or beginner access where they can actually just start playing around with these
[32:43.960 --> 32:47.560]  things and get a better understanding of it. I'm sure that there's some learning programs that I'm
[32:47.560 --> 32:53.780]  not aware of that someone will say afterwards, but that would be very helpful. Cool. Well, hey,
[32:53.780 --> 32:59.120]  we are just about out of time, but I want to thank you for putting together your talk and
[32:59.120 --> 33:04.180]  doing it pre-recorded, which I know is definitely a different experience than most of us are
[33:04.180 --> 33:08.520]  used to kind of getting up there and doing it live, but then also kind of playing around with
[33:08.520 --> 33:13.580]  this, with our kind of experiment of doing the live Q&A. I know I had a good time watching your
[33:13.580 --> 33:20.580]  talk. I thought it was great. And I hope everybody in the chat thought the same thing. If anybody
[33:20.580 --> 33:25.640]  needs to get ahold of you or, you know, kind of follow you for more of your developments,
[33:25.640 --> 33:33.280]  where can folks find you on the internet? Twitter's the best, at Pyrotek3, that's P-Y-R-O-T-E-K,
[33:33.280 --> 33:41.720]  number three. Good stuff. Well, thank you very much again, and everybody, everybody hanging out
[33:41.720 --> 33:45.960]  in chat, you know, we're going to take a 30-minute break so you can watch the next talk if you
[33:45.960 --> 33:52.180]  haven't watched it yet, and we'll have a new crew of goons and the next speaker up here in just a
[33:52.180 --> 33:55.760]  little bit. Thanks a bunch. We'll talk to everybody soon. Thank you.