start	end	text
1700	2940	Hello, DEF CON.
2940	5720	I speak to you today from my own version of the Batcave,
5720	7880	the ultimate in social distancing.
8160	11160	This is Hacking the Hybrid Cloud, and I am Shah Metcalf.
11540	13960	I'm the founder of Trimark, a professional services company
13960	15500	that helps organizations better secure
15500	16760	their Microsoft platform,
16760	19180	including the Microsoft Cloud and VMware infrastructure.
19360	21360	I'm a Microsoft certified master in Active Directory
21360	22980	and a Microsoft MVP.
23080	24540	I've spoken at a number of conferences
24540	26780	and I'm excited to be back speaking at DEF CON,
26780	29360	even if I'm not physically at DEF CON.
29360	31500	Last year, I keynoted the DEF CON Cloud Village
31500	32780	and three years ago gave a talk
32780	34840	on Hacking the Cloud at DEF CON.
35280	38120	This talk will take a journey through the hybrid cloud,
38120	40520	starting with the comparison between cloud and virtualization
40520	42780	discussing how on-prem Active Directory
42780	44700	domain controllers can be compromised.
45020	46880	I will also walk through the cloud hosted
47640	49760	managed Active Directory deployments
49760	53320	from AWS, Azure, and GCP.
53640	55180	Since this is hybrid talk,
55180	57520	I will walk through some hybrid components
57520	59660	and see how they can be attacked.
59760	61340	I'll touch on cloud administration
61340	64640	and identity access management, or IAM concepts,
64640	66620	and finally walk through escalation scenarios
66620	69800	for compromising cloud-hosted on-prem domain controllers,
69800	71400	AWS, and Azure.
72220	74880	First, we need to talk about what hybrid cloud is,
74880	76700	at least in the context of this talk.
76700	79460	There are likely lots of definitions of hybrid cloud.
79580	81040	Due to this, I'm defining hybrid cloud
81040	83440	as something on-prem and something in the cloud.
83440	86380	This typically means infrastructure on-prem and in the cloud,
86380	88480	more IaaS than strict SaaS.
88960	90500	Now that we've defined hybrid cloud,
90500	92400	let's look at three common scenarios.
92480	94580	The first is the on-prem Active Directory environment
94580	97480	with Office 365 SaaS services.
97540	99700	SaaS stands for software as a service.
99740	101360	Many organizations are leveraging the cloud
101360	103800	for infrastructure as a service, or IaaS,
103800	105560	as their cloud data center.
105560	107820	The third scenario here is an on-prem Active Directory
107820	111880	with a cloud-managed AD as an additional or resource forest.
111940	113660	Since cloud can be used in many ways,
113660	115000	it's likely that most organizations
115000	117440	use a combination of these, among others.
118380	122120	This section covers virtualization concepts and controls
122120	124020	as foundational information to better set up
124020	126060	and describe potential attacks.
127020	129260	Conceptually, the cloud is virtualization,
129260	131240	certainly from an IaaS perspective.
131240	133960	Amazon has used Xen and a switch to Nitro.
134300	136740	Azure uses a custom version of Hyper-V Core,
137040	140000	and Google Cloud Platform uses KVM.
141520	143160	Now, there is a cloud fabric
143160	144720	that ties the virtualization elements
144720	146340	together with orchestration,
146340	148780	which is what makes the cloud the cloud.
149300	151760	So, this diagram shows Azure IaaS
151760	153440	with a VM and related components.
153440	155740	This is similar to on-prem virtualization.
157500	159300	And Amazon's Nitro is pretty cool.
159300	160900	The Nitro hypervisor can take advantage
160900	162860	of Nitro-optimized hardware,
162860	164800	including a Nitro security chip.
164800	167660	Any instance created prior to Nitro is still running Xen.
170400	173680	AWS also has this concept of connectivity
173680	176240	between the AWS-managed Active Directory
176240	177820	that they host themselves,
177820	181820	and EC2, which is their IaaS environment
181820	183700	within the AWS cloud.
183700	186480	And then, of course, since you can host Windows servers
186480	188320	and Windows systems and other types of systems,
188320	189620	you can also integrate and connect
189620	191380	to other cloud environments.
191380	194820	This demonstrates how cloud can get complex pretty fast.
195840	197640	And you can run VMware on-prem
198020	201800	and in AWS and Azure and GCP.
203480	205700	Domain controllers control the keys to the kingdom
205700	207540	and require special security protections
207540	210300	that are often ignored on virtual platforms.
210780	212840	Compromising physical domain controllers
212840	214960	boils down to either gaining physical access
214960	218480	or compromising an out-of-band management system like iLO.
218540	221300	iLO hosts a web server on port 2381,
221300	223640	and we can scan for this using PowerShell.
223840	227340	So, if iLO is hosted on the same network
227340	232240	as production systems and clients, such as workstations,
232240	234300	we can scan and identify iLO.
234420	236300	iLO has had a number of security issues
236300	237780	with firmware patches available,
237780	239400	but the issue is that pretty much
239400	241920	no one updates firmware on physical servers.
243080	244320	Airbus Security has identified
244320	246580	many of these security issues with iLO,
246580	248260	from accessing memory to an RCE
248260	250040	to get read-write memory access
250040	253140	to the ability to execute arbitrary commands via DMA
253140	255560	to gain host access through iLO
255560	257360	even when iLO is disabled.
257440	258440	And I have a link at the bottom
258440	262460	that includes a list even beyond what I have up here
262460	264280	and a Go scanner to discover
264280	266180	vulnerable servers running iLO.
267280	269980	When VMware is hosting virtual DCs,
269980	272680	which is probably around 95% of the organizations are better,
272680	274460	certainly the larger ones,
274460	277640	there's different ways that you could compromise VMware
277640	280340	to get access to a virtual domain controller.
280460	282440	This could involve compromising an account
282440	284280	with rights to VMware.
284280	285720	Often this is a regular user account
285720	289620	that is a member of an 80 group called VMware Admins,
289620	291560	or we just need to compromise an account
291560	293880	that has VMware access to,
293880	298720	or at least one virtual domain controller,
298720	299840	potentially more.
299860	302600	If we can compromise a system which runs vCenter,
302600	304860	we can ultimately compromise VMware.
305220	308700	Also, every ESXi server has a root account.
308700	311040	And most of the time, every ESXi server
311040	312560	has the same root password,
312560	314840	which may be the organization default password,
314840	317640	which could be guest or found in a password file.
318260	321900	We can compromise the vCenter system,
321900	324580	we can compromise the vSphere environment.
325740	328800	And the VMware VIX API has functionality
328800	331900	that allows for direct access to guest OSs,
331900	333080	which is used by solutions
333080	335440	such as VMware Site Recovery Manager.
335440	337600	This requires VMware tools to be installed
337600	339500	on the guest OS or VM.
339500	342540	The VIX API allows guest operations
342540	344480	such as starting, stopping the application,
344480	346020	file directory manipulation,
346020	347440	uploading, downloading files,
347440	348800	all within the guest OS
348800	350540	without requiring any network connectivity
350540	352120	to the virtual machine.
352120	353840	This functionality may also be used
353840	356520	by vSphere accounts with limited privileges
356880	359840	to access a guest OS without the need to authenticate.
360120	361540	There is a scenario where an account
361540	364080	with vCenter privileges can use the vSphere API
364080	365980	to interact with the local OS installation
365980	368900	of VMware tools to allow a pass-through session
368900	370160	for an unprivileged account
370160	371860	to connect to that virtual machine
371860	374140	and execute local commands.
374140	377660	Since this applies to virtual domain controllers,
377660	379420	Active Directory could be compromised in this manner
379420	381600	by allowing execution of commands locally
381600	383760	on the virtual DC with accounts
383760	387500	not normally allowed local logon access to the DCs.
389260	391900	For Hyper-V, the attacks are similar to VMware.
391900	393340	We compromise an account with rights
393340	395520	or find a way to compromise a server,
395520	397460	either through a server admin account,
397460	399440	discover the local admin password,
399440	402600	or a modified group policy to gain access to the server.
404520	406000	So I decided I would take a look
406000	408540	at the so-called big three cloud hosting providers,
408540	410120	Managed Active Directory Environments,
410120	411640	and then focus on what this means
411640	413660	to Pentesters and Red Teamers.
414120	415660	The Managed Active Directory Environment
415660	418760	does not provide AD admin rights to the AD environment,
418760	421200	so the customer will never have domain admin rights
421200	423140	or even domain controller access.
423340	426180	The cloud provider controls AD infrastructure management
426180	430540	and delegates rights to OUs and AD components to the customer.
431400	433940	Let's start with Amazon AWS Directory Services
433940	435880	from Microsoft Active Directory.
435880	437560	That's quite the mouthful.
438680	442340	The AWS Managed AD has an AWS Delegated Groups
442340	444200	OU that contains the delegation groups
444200	447740	which the customer is provided membership in and access to.
447740	450560	The AWS Reserved OU is controlled exclusively
450560	452600	by the AWS system.
452600	455340	There is a customer OU created in the Managed AD domain
455340	457480	that is typically named after the AD subdomain
457480	460660	or the first part of the fully qualified domain name
460660	464060	or the domain's NetBIOS name.
464060	467900	This customer OU contains OUs for computers and users.
468860	471400	AWS Managed AD spins up two domain controllers
471400	473140	which are in different network segments
473140	475480	but in the same Active Directory site.
475480	477180	The default domain admin account
477180	479340	retains the default name administrator,
479340	481920	though this is moved to the AWS Reserved OU.
482280	485240	When a customer creates an AWS Managed AD,
485240	487600	their first account in the AD environment is called admin
487940	490340	and is granted full delegated rights to the AD environment
490740	493420	for that customer, not to the domain controllers
493420	497980	or AD admin rights to the full AD.
498840	501400	The domain password is default, still seven characters,
501400	504440	but there are five AWS-created fine-grained password policies
504440	506840	which are delegated to the customer to modify.
507140	509540	Based on the group policy linked to the domain controller's OU,
509540	512100	I was able to identify a pretty decent audit policy,
512100	513860	though it was missing Kerberos auditing,
513860	516340	which means Kerberos activity would be missed.
517760	520760	The first customer account, admin, is created with the description
520760	523420	that notes the customer OU distinguished name,
523420	525240	so it's very nice that they provide this description
525600	529080	so that way you can quickly and easily identify where this OU is.
530020	533800	There are several delegation groups in the AWS Managed AD environment.
533800	536260	All these are named with the prefix AWS-delegated
536260	539600	and are contained in the AWS Delegated Groups OU.
539860	542000	The AWS Delegated Administrators Group
542000	544140	is the primary customer admin group.
544200	547000	There are also delegation groups for managed service accounts,
547000	549360	adding workstations to the main Kerberos delegation,
549360	551300	DNS, and server administration.
552720	556080	Let's take a look at Azure Active Directory Domain Services.
556180	559080	While Azure Active Directory is not exactly Active Directory,
559080	561160	since it's a cloud directory with no Kerberos
561160	564120	or NTLM authentication, group policy, or LDAP,
564120	566600	Azure AD Domain Services is Active Directory,
566600	568660	just like you would have on a corporate network,
568660	570840	and is Microsoft's managed Active Directory.
572440	575700	So this environment, Azure AD DS,
575700	578000	has several top-level OUs that are created.
578000	580280	These are prefixed with AADD,
580280	585820	and the AADDC computers and AADDC users OUs
585820	587740	are the primary customer OUs.
588720	592520	The Azure AD DS domain controllers are in the same network,
592520	595140	and at least in this instance that I created,
595140	597860	had sequential IPs, .4 and .5.
597860	602840	The default domain admin account is called DCAASAdmin,
602840	605120	and remains in the default user's OU.
605180	608020	There is one fine-grained password policy that's pre-created.
608020	609880	I'm not going to try to read the name.
609980	613500	As it is, it's a bit tough with all the AA and DDs,
613500	615720	but the customer has delegated modifier rights
615720	617840	to this fine-grained password policy object.
618060	620600	I can't see any auditing configuration set in GPO,
620600	622840	so I have to assume that they are set via local policy,
622840	625220	which I can't see without domain controller access.
627860	630940	Azure AD DS has a few delegation groups
630940	637860	which are prefixed with AADDC, and are in the AADDC users OU.
637860	642600	The primary customer group is AADDC administrators,
642600	645980	which is delegated full control to many OUs and AD components.
646140	648160	I'm pretty sure when Microsoft came up with the names
648160	649540	for these groups,
649540	652920	they were not thinking about having to say this out loud in a row.
653040	655260	So thank you, Microsoft, for that.
655900	658480	Moving on to the third and final managed AD environment
658480	660260	that I reviewed recently,
660260	663340	this is the Google Cloud Platform Managed Active Directory.
667090	669150	It's interesting to note that the GCP-managed AD
669150	671690	seems to cost about twice what the Amazon AWS
671690	674930	and Microsoft Azure-managed AD environments cost,
674930	676990	because they're about $100 each.
678430	681590	The GCP-managed AD environment has a single root OU
681590	683250	for the customer called Cloud,
683250	685650	with a single child OU called Computers.
685650	689170	The Cloud Service Objects OU contains delegation groups.
690350	693850	GCP-managed AD is different from the others
693850	695970	that I just talked about in that domain controllers
695970	698190	are running Windows Server 2019,
698190	700630	though the Active Directory forest functional level
700630	702630	is still set to 2012 R2.
703210	705110	Also, the Active Directory Recycle Bin,
705110	706750	which enables rapid undelete capability,
706750	708650	is not enabled, which is interesting.
708770	710730	The default domain administrator account
710730	712610	keeps the default name Administrator,
712610	714250	and it's disabled.
714250	717730	So, GCP spins up a second domain admin account
717730	722150	called CloudSVCAdmin, and this account is enabled.
722610	724750	The domain password policy is default,
724750	727450	and the customer can create fine-grained password policies.
727730	730010	And with this, the DC event auditing
730010	731470	is not configured through group policy,
731470	734090	so again, I couldn't identify how it may be configured.
735130	738030	GCP-managed AD has several delegation groups.
738030	739770	They start with Cloud Service,
739770	742650	and these are stored in the Cloud Service Objects OU.
742650	744470	The Cloud Service All Administrators
744470	745890	and the Cloud Service Administrators
745890	748090	are the primary customer admin groups.
748270	750850	GCP delegation groups include computer admins,
750850	753330	managed service account admins, and others.
753850	755750	This slide captures some of the common themes
755750	758850	of the three managed AD environments I reviewed.
758850	760970	I used a version of the Trimark Active Directory
760970	762950	assessment tool that I wrote to perform the review
762950	764670	of the different AD environments,
764670	766550	which enabled me to capture data for all three
766550	768650	and identify the key security features
768650	771810	and delegation in about a day to put this talk together,
771810	773030	or at least this part of it.
773030	774410	The bottom of the slide will provide a link
774410	777170	to an Active Directory security review PowerShell script
777170	779470	that I wrote and published in June.
779650	780950	The link points to the article
780950	783410	where I highlight key AD security items
783410	784890	to check and what to check for,
784890	786570	and the PowerShell script simplifies
786570	790450	the data collection part, so analysis is much simpler.
790570	792550	So it's good to check that out. It would be helpful
792950	795470	if you're looking at an environment such as these.
796850	800090	So since the customer does not actually have AD admin rights
800090	801370	to a managed AD environment,
801370	804210	there's not much point in attempting to escalate to DA.
804630	807450	Better to identify which managed AD environment it is
807450	809450	and enumerate the managed AD privilege groups
809450	812230	to determine which accounts are highly privileged.
812550	816150	Interesting note about Azure Active Directory domain services,
816150	818770	Microsoft's managed AD.
818770	821330	It can be managed by Azure AD accounts,
821330	823730	and these are synchronized into Azure AD DS
823730	826250	or even by on-prem AD accounts
826250	829810	that are synced in from the on-prem AD environment.
829810	832010	And these are synced using the on-prem Azure AD
832010	837330	Connect system through Azure AD to Azure AD domain services.
837330	840210	And if password hash sync is enabled, which it usually is,
840210	843720	then the on-prem AD account password hash is included.
843990	847130	Normally, password hash sync does a hash of a hash,
847130	851350	but when syncing through to Azure AD domain services,
851350	856050	that original AD password hash is retained and synchronized,
856050	858770	so that way the password can actually be used
858770	861470	in Azure Active Directory domain services.
863690	865470	So, there are several cloud components
865470	867310	that connect on-prem to cloud.
867310	870150	This connectivity has some very interesting implications.
871250	873070	Amazon's AD Connector is effectively
873070	875850	an on-prem AD authentication proxy.
876210	878250	AD Connector is designed to provide an easy way
878250	879970	to establish a trusted relationship
879970	882290	between your Active Directory and AWS.
882310	884310	So, when AD Connector is configured,
884310	887270	it enables the ability to sign into AWS applications
887270	889350	with on-prem AD credentials,
889350	894050	join AWS Windows instances to the on-prem AD domain,
894050	897230	and provides federated sign-in to the AWS Management Console
897590	903170	by mapping these on-prem identities to AWS IAM roles.
904810	907390	And AD Connector can't be used with custom applications
907390	909310	since it's just for AWS.
909750	912690	Basically, a user opens the secure custom sign-in page,
912690	914890	supplies their Active Directory username and password.
914890	917930	This authentication request is sent over SSL to the AD Connector,
917930	920570	and then the AD Connector performs LDAP authentication
920570	922170	to Active Directory.
922170	925660	The interesting part happens at this point.
925910	927830	Once the user has been authenticated,
927830	930610	the AD Connector calls the STS assume role method
930610	933580	to get temporary security credentials for that user.
933850	935710	Using those temporary security credentials,
935710	937350	AD Connector constructs a sign-in URL
937780	940560	that users use to access the console.
940870	942590	And if a user is mapped to multiple roles,
942590	945190	the user will be presented with a choice at the sign-in time
945190	947110	as to which role they want to assume.
947110	949050	User session is valid for an hour,
949050	951130	which is pretty standard for cloud apps.
951730	955050	Since the AD Connector environment is hosted in AWS,
955050	958110	this would need to be targeted in order to potentially impersonate the users
958110	963410	and be able to leverage that STS assume role method.
965770	967770	Microsoft's pass-through authentication is similar
968350	971670	because with Microsoft pass-through authentication, or PTA,
971670	975630	it provides users the ability to authenticate to Azure Active Directory,
975630	977690	which is passed through to the on-prem AD
977690	983190	and validated in Azure AD by getting the status back
983190	986230	from the PTA agent in the on-prem environment.
987030	990010	PTA is enabled via Azure AD Connect.
990010	991890	The users use the same passwords
991890	995130	to sign into both on-prem and cloud-based applications.
995310	997470	The communication between an agent and Azure AD
997470	1000130	is secured using certificate-based authentication,
1000130	1001910	and these certificates are automatically renewed
1001910	1004050	every few months by Azure AD.
1004230	1007350	I couldn't figure out what happens if you get one of these certificates,
1007350	1009050	but that could be pretty interesting.
1010370	1013130	But ultimately, this supports user sign-in
1013130	1015530	into all web browser-based applications
1015530	1017710	and into Microsoft Office client applications
1017710	1019370	that use modern authentication.
1022860	1025960	Adam Chester, aka XPN, has done a great blog post
1025960	1029180	on how to leverage a compromised Azure AD Connect server
1029180	1032320	with PTA enabled in order to gather usernames
1032320	1036800	and cleartext passwords that were used to authenticate via PTA.
1036800	1040100	So since password authentication is managed by Azure AD Connect,
1040100	1041940	you can compromise that server.
1041940	1045420	And then during this authentication process,
1045420	1047520	Azure AD sends the cleartext password,
1047520	1049500	not hashed, to authenticate the user.
1049500	1051380	So it's sent to Azure AD Connect.
1051380	1055140	Azure AD Connect PTA component is going to check
1055140	1058460	and validate the username and password with Active Directory,
1058460	1062180	then send back the status to Azure AD for that.
1062340	1065560	So Adam identified that you could inject a DLL
1065560	1067760	to compromise the credentials that were used for PTA
1068160	1072680	and then have those credentials for anyone that was using PTA.
1073780	1076260	Azure Active Directory Seamless Single Sign-On,
1076260	1079760	or Azure AD Seamless SSO, automatically signs users
1079760	1081440	in when they are on their corporate devices
1081440	1083320	connected to the corporate network.
1084040	1086220	This graphic is interesting and nice,
1086220	1088200	but I prefer this one because it has a lot more
1088200	1089300	of the flow.
1089380	1090700	But basically what ends up happening
1090700	1093240	is that users don't need to type in their passwords
1093240	1097100	to sign into Azure AD or even really type in their usernames.
1097100	1099280	It provides the users easy access
1099280	1100800	to their cloud-based applications
1100800	1104320	without any additional on-prem components like federation.
1104320	1106320	This is done by converting the on-prem authentication
1106320	1109040	to cloud authentication through a computer account
1109040	1110360	in the Active Directory.
1110800	1113500	So Michael Grafner from DS Internals
1114090	1116660	posted this article a few years ago,
1116660	1118940	or a couple of years ago, where he was talking about
1118940	1123300	how the Azure AD has a publicly available endpoint
1123300	1124880	that accepts these Kerberos tickets
1124880	1127320	and translates them into SAML and JWT tokens
1127320	1129860	that can be leveraged for cloud apps.
1131320	1133640	Effectively, if you can compromise the Azure AD
1133640	1135780	Seamless Single Sign-On computer account,
1135780	1137480	the password has to be associated with it.
1137480	1140920	The computer account is called Azure AD SSO ACC
1141740	1144860	and can be identified as in the computer's container.
1144860	1147320	If you're able to compromise this and get this password hash,
1147320	1149880	you can generate a silver ticket for any user
1149880	1151460	you want to impersonate,
1151460	1153960	and the service that you use in the silver ticket
1153960	1158140	is going to be aadg.windows.net.nsatc.net.
1158140	1161560	You inject this ticket into the local Kerberos cache,
1161560	1164340	and Azure AD Seamless Single Sign-On,
1164340	1167440	the computer account password doesn't actually change.
1167440	1169280	Microsoft does recommend that it gets rolled
1169280	1171700	and changed at least every 30 days.
1171700	1174700	What's interesting is because it's a computer account,
1175210	1178760	there is no actual computer that is behind the scenes
1178760	1180840	that is using that computer account
1180840	1183070	other than the Azure AD Connect client.
1183480	1186620	So normally a computer in Active Directory
1186620	1188640	would update the computer account password
1188640	1190400	that's associated with that computer.
1190400	1192400	Since there isn't really a computer here,
1192400	1194160	that password isn't getting changed.
1194160	1197020	So maybe in the future Microsoft will code into Azure AD Connect
1197020	1200460	to automatically update the computer account password for this.
1202000	1204660	Three years ago at DEF CON 25 in Las Vegas,
1204660	1206920	I co-presented a talk called Hacking the Cloud.
1206920	1209420	I talked about how Azure AD Connect's password
1209420	1212980	hash sync permissions provided Mimikatz DC-sync rights,
1212980	1216860	and that the author of Mimikatz DC-sync, Vincent Leteau,
1216860	1219460	was inspired by password hash sync to create DC-sync
1219460	1221820	because PHS requests password hashes
1221820	1224620	for sync users on a regular basis.
1225520	1227640	We can scan Active Directory domain permissions
1227640	1231020	looking for potential Azure AD Connect service counts.
1231720	1234900	Or if the Azure AD Connect install
1234900	1237380	would use the express install option,
1237380	1238960	then there's a helpful description on the account
1238960	1242080	noting on which server Azure AD Connect is installed.
1242180	1243780	We can then check in Active Directory
1243780	1246620	to figure out where that computer is stored.
1246620	1250040	Very often this is in the server's OU or somewhere similar.
1250260	1254100	Once we know the server name, we can check for,
1254100	1255320	and its location,
1255320	1258160	the actual distinguished name of the OU that it's in.
1258160	1259840	We can check AD for any group policies
1259840	1262960	that add AD groups to the local administrators group.
1263080	1264200	Compromising any account
1264200	1265980	that is a member of the local administrators group
1265980	1267560	on the Azure AD Connect server
1267560	1270800	would result in compromise of the Azure AD Connect server
1270800	1272540	and ultimately Active Directory,
1272540	1276460	assuming that it has password hash synchronization
1276460	1279320	rights configured in the environment.
1280100	1281820	Also, if we can modify a group policy
1281820	1284360	that links to the Azure AD Connect server OU,
1284360	1286860	then we can compromise the server that way as well.
1288240	1290540	When talking about cloud environments,
1290540	1293440	it's important to mention how administration is performed.
1293440	1296040	This is commonly referred to as Identity Access Management,
1296040	1296920	or IAM.
1297480	1300220	So we've gone from groups in our on-prem environment
1300220	1302020	with Active Directory to roles,
1302020	1303660	which is effectively these rights
1303660	1305380	that are packaged together.
1305740	1308580	Azure and AWS and GCP have their own methods,
1308580	1311220	but a lot of the concepts are effectively the same.
1311860	1314020	Azure IAM uses the concept of an owner,
1314120	1315380	a contributor, and a reader.
1316860	1319700	The owner has full access, the contributor has the ability
1319700	1321740	to create and manage the resources
1321740	1323400	but can't grant access to others,
1323400	1325800	and then a reader can just view things.
1326900	1330280	And so Azure has the tenant,
1330280	1333920	which is the top-level container of the Azure environment,
1333920	1335940	and this contains subscriptions.
1337660	1341140	The tenant admins are effectively the owner role on the tenant,
1341140	1343620	and subscription admin would be effectively the owner role
1343620	1345160	on the subscription.
1348050	1350550	What's interesting is that Microsoft notes
1350550	1352630	that Azure roles and Azure AD roles
1352630	1355990	are separate and different, mostly,
1355990	1358130	and I'll cover that in a little bit.
1361620	1364040	AWS has a root account, often called
1364040	1365680	or referred to as a payer account,
1365680	1367360	which is the primary account,
1367360	1369720	though it really shouldn't be used regularly.
1369720	1371560	Then there are account admins.
1371560	1375160	So in AWS, the account is similar to the Azure tenant.
1375160	1377720	It's the top-level container for the environment
1377720	1378980	for that customer.
1378980	1381940	The account admins have full control over the account.
1381960	1384780	If an account is a root account and an admin account,
1384780	1387720	then that account has full organizational control.
1387940	1390300	It's important to note here that any overscoped roles
1390300	1392440	provide escalation capability.
1392920	1395020	And Rhino Security Labs has an extensive article
1395020	1398880	covering 21 AWS IAM privilege escalation methods,
1398880	1400620	which allow an attacker to escalate
1400620	1402820	from a compromised low-privilege account
1402820	1404640	to full admin privileges.
1404640	1406020	So I've listed a bunch of them here,
1406020	1407800	I apologize for the small text,
1407800	1409980	but really what you want to do is you want to read
1410440	1412940	the blog article that they wrote,
1412940	1415100	which is linked at the bottom and in the slides.
1415160	1416500	They also released a scanning tool,
1416500	1418460	which is on GitHub, to identify these vulnerabilities
1419180	1422800	in an AWS user account.
1422860	1425280	And if you have an account with IAM read access for all users,
1425280	1427280	the script can be run against every user in the account
1427280	1429820	to detect these vulnerabilities account-wide.
1429820	1432180	So if you're asked to pen test AWS,
1432180	1436500	or you're providing security consulting services around AWS,
1436500	1438080	or even you work in an organization
1438080	1439060	and you're moving to AWS
1439060	1441160	and you have some of the IAM roles configured,
1441160	1442520	you definitely want to scan them
1442520	1444820	for potential escalation methods.
1446020	1449240	API keys, I'm just going to cover this really quickly.
1449240	1451580	They provide permanent access to an environment,
1451580	1453400	often with extensive privileges.
1453500	1455920	These keys can often bypass the typical username
1455920	1457840	and password used to authenticate as an account
1457840	1460280	if it's configured as such.
1461680	1463540	Well, I've covered a number of scenarios
1463540	1466780	on how to attack on-prem and hybrid cloud components.
1466780	1469920	Let's focus on on-prem Active Directory domain controllers
1469920	1474120	hosted in cloud infrastructure as a service.
1474120	1477420	So first up is Amazon AWS EC2.
1478160	1481920	Many organizations leverage Amazon AWS EC2
1481920	1484460	or IaaS as a cloud data center.
1484460	1489220	Some of these host on-prem AD domain controllers in AWS.
1489820	1492180	So we start with Acme Corporation,
1492180	1494900	which has the on-prem AD environment.
1494900	1497680	They have stood up an Amazon AWS account
1497680	1501100	to use EC2 as a cloud data center.
1501620	1504940	Then Acme configures an IAM role for the server admins
1504940	1508000	and they stand up a couple of on-prem Active Directory
1508000	1509960	domain controllers in AWS.
1511160	1512780	Acme then configures Federation
1512780	1514400	so that users in the on-prem AD
1514400	1518100	can authenticate to AWS using their AD credentials.
1518540	1520640	To simplify access for server admins,
1520640	1523700	the on-prem AD group AWS EC2 admins is created
1523700	1527180	and then that's associated with AWS IAM role.
1527280	1529100	The server team accounts are then added
1529100	1533440	to the on-prem AD group called AWS EC2 admins
1533440	1537480	to enable the team to easily administer the AWS environment.
1539200	1541280	But if an attacker is able to compromise
1541280	1542460	one of the user accounts
1542460	1545800	that's a member of the AD group AWS admins,
1547460	1550700	then they are able to connect to the AWS console
1550700	1552720	as an AWS admin.
1553260	1555320	And then now the attacker can configure
1555320	1557760	the virtual domain controller instance in AWS
1557760	1559620	and run commands on it.
1559640	1563680	Once the command runs to modify the domain controller's copy of AD,
1563680	1566240	the changes replicate back to the on-prem domain controllers
1566240	1569040	and then we end up with the on-prem Active Directory
1569040	1570300	being compromised.
1570520	1572260	So effectively in this scenario,
1573280	1575400	the attacker can compromise an account
1575580	1576440	a regular user account
1577280	1579780	that doesn't have any Active Directory rights.
1579780	1582400	It's just a member of a group in Active Directory.
1582400	1586300	This group is associated with the AWS IAM role
1586300	1588080	through federation.
1588120	1590540	And so once the attacker compromises this account,
1590540	1595260	which has these rights granted in the group in Active Directory,
1595260	1599440	but then are relayed and related to this AWS IAM role,
1599440	1601540	then they can leverage that in order to compromise
1602060	1603600	any of the systems that are in there
1603600	1605060	that they have rights to.
1605720	1610560	So I've got a summary slide here that covers this very briefly.
1610860	1612820	But keep in mind that Amazon SSM,
1612820	1614860	which is effectively the Amazon agent,
1614860	1617440	is installed by default on most Amazon-provided instances
1617440	1620240	or templates. You do need the role to execute,
1620240	1622640	but once you have the rights over that environment
1622640	1625880	as a server admin would, you can normally go ahead and get that.
1626020	1628440	Hopefully you're logging this and looking at the logs.
1628440	1630960	Amazon CloudTrail can pull these logs.
1630960	1634400	And the logs need to be configured to not be deleted.
1634640	1637580	So very often an attacker is just going to delete the logs
1637580	1639420	so you can't see what they did.
1640540	1643240	For most of 2019, I was digging in Office 365
1643240	1645700	and Azure Active Directory looking at features.
1645700	1647420	As I went through each of them, I found one
1647420	1649020	that was very interesting.
1650160	1652180	Remember earlier how I noted that Azure roles
1652180	1653920	and Azure AD roles are separate?
1653920	1657020	Well, not exactly. Here it describes a way
1657020	1659720	that global administrators could actually elevate their access
1659720	1662320	and have some control over Azure.
1662960	1665040	Surely the global administrator role description
1665040	1666500	notes this, right?
1667020	1670680	Well, no, it didn't, at least not as of May.
1671120	1673580	The global administrator role provides full admin rights
1673580	1677520	to Azure AD and ultimately all the Office 365 services.
1677520	1680680	The Microsoft Online document provides key information
1680680	1684300	about this, and there's nothing here showing Azure capability.
1684300	1686020	I took this screenshot in May.
1686560	1688680	After contacting Microsoft and providing information
1688680	1690780	about this escalation path, the document's been updated
1690780	1693800	in the past month or so, stating that, yes,
1693800	1695560	there is a way for a global administrator
1695560	1697760	to have Azure rights,
1697760	1700400	which is a bit different than what it said before.
1701740	1703900	Once we have access to the Azure AD portal,
1703900	1706380	which is typically all Azure AD users by default,
1706380	1709020	we can view several different configuration settings
1709020	1710380	for Azure Active Directory,
1710380	1712940	which controls many aspects of Office 365.
1713080	1714960	This page shows the directory properties,
1714960	1717640	which now includes the new managed security defaults.
1717640	1719240	Towards the bottom is access management
1719240	1721800	for Azure resources toggle.
1721800	1723620	So we can see what that is.
1723980	1725600	According to Microsoft documentation,
1725600	1727240	toggling this option from no to yes
1727240	1729660	adds the global administrator account
1729660	1731640	to the user access administrator role
1731640	1734480	in Azure RBAC at the root scope.
1734760	1737420	This has control over all subscriptions in the tenant.
1737420	1739100	And this option is only available to accounts
1739100	1741600	that are members of the global administrator role.
1741600	1743020	While this option is configured
1743020	1744480	in the directory properties section,
1744480	1746880	this is actually a per account configuration option.
1746880	1750500	So this magic button provides ability to manage Azure roles,
1750500	1753960	but no direct Azure rights as into VMs.
1753960	1756360	Further in the documents documentation,
1756360	1759340	there's additional context on what elevate access is
1759340	1760420	and how it works.
1760420	1762620	When developing Azure Active Directory in Azure,
1762620	1764620	Microsoft had to decide if the global admin
1764620	1766800	should have Azure rights initially,
1766800	1768860	and opted for no, they shouldn't.
1768860	1772120	But they provided this capability to gain Azure access.
1772120	1774500	This is that backdoor of sorts,
1774500	1776060	which has been somewhat highlighted now
1776060	1777700	that the managed security default option
1777700	1779140	is right below it.
1780320	1782400	This graphic shows what happens in the connection point
1782400	1784000	between Azure AD and Azure.
1784000	1786440	My biggest concern here is that for many organizations,
1786440	1788180	the group that manages Azure Active Directory
1788180	1790320	and Office 365 are often a different group
1790320	1792240	from those that manage Azure.
1792240	1794300	This means that someone could elevate access,
1794300	1797720	think a rogue admin, and no one probably would notice.
1797720	1799120	This is potentially a serious threat
1799120	1800980	from an insider threat perspective,
1800980	1802800	especially around the detection part of this issue,
1802800	1804180	which I'll cover in a bit.
1805040	1806660	This note in the Microsoft document
1806660	1809000	highlights an interesting phenomena with this option.
1809000	1810200	Only while the account is a member
1810200	1811400	of the global administrator role
1811400	1814860	can the account toggle this option to yes or no.
1814860	1816720	This means that if an account is no longer
1817220	1819260	in the global administrator role,
1819260	1821020	and the option has been set to yes,
1821020	1822640	they cannot change it back to no,
1822640	1824420	and no one else can change it either.
1825180	1827460	I also found an API that seems related,
1827460	1829520	which means that an attacker would not need to visit
1829520	1831760	the Azure AD portal to perform this action.
1831760	1835100	They just have to run this API call.
1835900	1839820	And Ryan added this REST API elevation method to PowerAzure,
1839820	1841000	which you should check out.
1841000	1843140	I have a link at the bottom of the slide.
1844960	1847860	Now, what I'm going to do is walk through a scenario
1847860	1853100	where we have Acme, and Acme has stood up.
1853260	1856080	They have a new Office 365 environment.
1856080	1858100	They've had Azure for a very long time.
1858100	1860620	They're using Azure as their cloud data center.
1860620	1861740	They've got domain controllers there.
1861740	1863880	They've got a bunch of different servers in Azure.
1864100	1866480	But they're just now spinning up Office 365.
1866480	1867560	They're going to use it for email.
1867560	1869260	They're going to use it for a number of different things.
1869260	1872980	So they have members of the Active Directory team,
1872980	1876000	Exchange, SharePoint, a bunch of different people,
1876000	1877880	probably 30 to 50 people
1877880	1880280	are members of the global administrator role.
1880280	1883400	Not everyone has had their account configured for MFA,
1883400	1886400	which is realistic since many admins,
1886400	1888080	this is from last year's Black Hat talk
1888080	1889840	that I gave with Mark Morrow,
1889840	1891300	and it was only about 8%.
1891860	1893400	Hopefully, it's much higher than that,
1893400	1896660	but it's still probably less than 15% if I had to guess.
1896820	1899080	And so this means that most global admin accounts
1899080	1900640	don't have MFA configured.
1900640	1902620	And so if an attacker is able to password spray
1902620	1904940	and guess the account password,
1904940	1906800	then they're able to take over this account.
1908320	1910440	So by default, this option is set to no.
1910440	1913080	So if an attacker compromises a global admin account,
1913080	1915840	they can go in and actually toggle this from no to yes,
1915840	1919820	which gives them Azure User Access Administrator role
1920320	1922220	rights at the root of Azure,
1922220	1928020	that Azure tenant that's configured on the Azure side.
1928160	1930240	So once that toggle option is set to yes,
1930240	1932740	we can see a new account appears in the User Access
1932740	1935460	Administrator Azure RBAC role.
1935460	1937240	I call this attack account hacker,
1937240	1938820	so I don't forget which one I'm using.
1938820	1941220	But you'll notice that I also added a couple others
1941220	1943020	that look like they belong.
1943080	1944940	There's really nothing that's supposed to be in this role.
1952100	1953520	Monitoring for this can be a challenge
1953520	1955380	since the primary method is running an Azure
1955380	1957300	CLI command at the root scope.
1957540	1961640	I can't find root level Azure RBAC roles listed in the portal,
1961640	1964500	so I can't go there to see what the membership is.
1964620	1966680	So something that could be monitored through an API
1966680	1970040	or if you're pulling logs into your sim,
1970040	1974560	you could alert on RBAC role or role membership modification.
1974920	1978520	But when I run that command, I get this output,
1978520	1980360	which means I would have to parse it.
1980900	1982720	And so this is the message that appears
1982720	1984360	when attempting to remove root level role
1984360	1985920	assignments from a subscription.
1985920	1988520	Removing an account from a root level Azure RBAC role
1988520	1991220	requires running an Azure PowerShell command.
1991220	1993860	When an account toggles elevate access from yes to no,
1993860	1997080	it is automatically removed from the User Access Administrator.
1997760	2000120	Once the attacker has User Access Administrator
2000120	2001300	rights at the root level,
2001300	2004860	this account can modify roles for any subscription in Azure.
2004900	2007300	Owner's obvious and probably monitored, maybe.
2007300	2009180	What about something more innocuous?
2009660	2011760	So I found Virtual Machine Contributor,
2011760	2014160	and this is pretty interesting because the documentation states
2014160	2016300	it lets you manage virtual machines,
2016300	2018720	but not access to them and not the virtual network
2018720	2021540	or storage account that they're connected to.
2021820	2024260	And it includes this ability,
2024260	2027080	which is Microsoft.compute slash virtual machine
2027080	2028480	slash run command.
2028480	2030840	This provides the ability to run commands on the VM
2030840	2033460	as system such as PowerShell.
2034200	2036640	And so we can click on run PowerShell script
2036640	2037860	and we can do that.
2037860	2039080	The other thing that's interesting here
2039080	2040660	is that it provides the ability
2040660	2042680	to re-enable the administrator account,
2042680	2044420	which on a domain controller in Azure
2044420	2046780	would be the RID 500 account for the domain.
2046800	2048360	So we have seen some environments
2048360	2050220	when we look at them from an Active Directory
2050220	2051760	assessment perspective,
2051760	2054780	they have had the default domain administrator account
2054780	2057880	disabled, but very often it has an old password,
2057880	2059980	say 10 years old or more.
2059980	2062720	And it may actually have a Kerberos service
2062720	2064480	principal name or spin associated with it,
2064480	2066200	which means that we can Kerberos it.
2066200	2069200	So if an attacker could just go ahead and Kerberos it,
2069680	2071140	then re-enable it through here,
2071140	2074160	they could potentially leverage that default admin account,
2074160	2075860	which was originally disabled.
2077560	2080320	So we're going to add the attacker controlled account
2080320	2082160	to the virtual machine contributor.
2083800	2086380	And now that our attacker has the ability to run commands,
2086380	2088320	we can update the administrators group.
2088320	2090380	This will happen on the Azure based domain controller
2090380	2092980	then replicate to the domain controllers that are on-prem.
2093060	2095400	Note that being able to run commands on an Azure VM
2095400	2097540	is not specific to customer on-prem
2097540	2099040	DCs hosted on Azure,
2099040	2102080	but also other systems hosted there as well.
2102620	2104500	So we take a look to see what would happen.
2104500	2106240	We can go switch to a computer on-prem
2106240	2110100	or run another command on the DC to see what the result is.
2110100	2112660	And we've now compromised the on-prem active directory
2112660	2114200	from Azure.
2114980	2117100	If PowerShell logging is configured appropriately
2117100	2118800	and sent to a sim and monitored,
2118800	2121020	this event should identify unusual activity
2121620	2123560	showing up in the PowerShell log.
2124460	2126700	Another option an attacker has with these rights
2126700	2128820	is running invoke mimikatz from the internet
2128820	2131160	or even a compromise system on the corporate network
2131160	2133100	or within the Azure tenant.
2133420	2134860	So here I'm running mimikatz
2134860	2136920	just to get the curb CD password hash
2136920	2139240	because with that I can create golden tickets,
2139240	2140660	which means I can persist forever
2140660	2142660	in the on-prem active directory
2143140	2144600	even though I've never touched that
2144600	2147220	or had access to the corporate network.
2147220	2148700	So that means once I get a foothold,
2148700	2151600	I can have domain admin possibly forever.
2152200	2154200	But what if instead of running invoke mimikatz
2154200	2157720	directly from GitHub, we loaded it into Azure Blob Storage?
2157720	2160040	So effectively, we're going to use a PowerShell script.
2160040	2161060	We're going to upload.
2161060	2162840	I'm not going to call it invoke mimikatz.
2162840	2165680	I'll call it invmmk.txt.
2165760	2167740	And Azure Blob Storage is very nice
2167740	2171280	because it gives me a URL in which I can interact
2171280	2173800	and connect to this file.
2174420	2176080	So that would work as well.
2176700	2178440	Let's take a moment to recap.
2178440	2181620	From global admin to Azure user access administrator
2181620	2185460	to Azure admin or virtual machine contributor.
2185500	2186760	So if an attacker compromises
2186760	2188740	an organization's global administrator account,
2188740	2190760	either because they're just starting with Office 365
2190760	2194320	or didn't realize the risks around protecting global admins,
2194320	2195860	either way, the global admin accounts
2195860	2198700	weren't locked down with PIM, conditional access, or MFA.
2198700	2201360	Or a global admin session token was stolen
2201360	2205080	because this admin was using their regular web browser
2205080	2207760	on the regular user workstation, which was compromised.
2207760	2209680	This would mean that the attacker was about an hour
2209680	2212140	to perform these actions, compromise the account,
2212140	2214760	elevate access to Azure, get access to get Azure rights
2214760	2218640	through Azure role membership, remove elevate access rights,
2218640	2221800	perform malicious actions on any or all Azure VMs
2221800	2222880	and all subscriptions,
2222880	2225620	then remove role membership in Azure or not.
2225620	2227620	The total time required only a few minutes,
2227620	2229900	perhaps as much as 15 minutes total.
2230900	2232880	In many organizations, there are two different groups
2232880	2235840	that manage Azure AD, Office 365, and Azure.
2235840	2238160	As I mentioned earlier, they have no expectations
2238160	2240360	that the other team has the ability
2240360	2242640	to affect their environment.
2243820	2246340	So why is this issue important?
2246340	2248040	Well, customers don't usually expect
2248040	2249360	that the global administrator role
2249360	2251760	that says it has Office 365 admin rights
2251760	2254020	can also control Azure subscriptions.
2255380	2257200	We need to be very careful what accounts
2257200	2259300	are members of roles in Azure at the root level,
2259300	2261500	as well as on the subscriptions,
2261500	2264020	since this impacts the security posture.
2264020	2266120	It's not obvious that removing the account
2266120	2267220	from global administrator role
2267220	2268280	does not remove the account
2268280	2271620	from the Azure RBAC role, user access administrator,
2271620	2272560	when the access management
2272560	2276240	for Azure resources toggle option is still set to yes.
2279100	2280580	And the key points around detection
2280580	2282820	is there's no way to detect this configuration
2282820	2284300	in Azure Active Directory at all.
2284300	2286380	There's no property to query on accounts.
2286380	2288040	You have to run an Azure CLI command
2288040	2289320	to check the role group membership,
2289320	2291200	but that's on the Azure side.
2291320	2292700	When I walked through the Azure AD
2292700	2294600	to Azure access elevation,
2294600	2296400	I attempted to identify a clear event
2296400	2298500	that I could alert on and was unable to.
2298660	2301020	The core directory, directory management set company
2301020	2303140	information log notes that something has changed,
2303140	2304180	but not what.
2304180	2306400	The capability for an Azure AD global admin
2306400	2308440	is quote unquote by design.
2308440	2311120	However, not expected, not well documented by Microsoft
2311120	2314560	when reading about what Azure AD global admins can do.
2314560	2316420	Certainly now the documentation has been updated
2316970	2319360	to mention this, but I feel like there should be better
2320260	2323420	logging and alerting around this sort of configuration.
2324620	2327400	I'm concerned that this is a scenario
2327400	2329920	where the Microsoft cloud customer can't detect,
2329920	2331900	can't remediate and ultimately can't prevent
2331900	2333800	since there's no real gate to lock
2333800	2336400	if an Azure AD global admin account is exposed.
2336420	2338560	And then they can jump over on the Azure side.
2338600	2341220	So the only real good answer I can find for this
2341220	2344700	is to ensure that global administrator groups
2344700	2348380	are managed or their roles are managed with Azure AD PIM.
2348420	2350340	But even this doesn't stop a rogue admin
2350340	2352280	from doing whatever they want.
2352680	2354540	The best mitigation is to prevent compromise
2354540	2355960	of global admin accounts.
2355960	2358200	Using PIM reduces this risk tremendously.
2358220	2360460	Outside of that, monitor global admin role membership
2360460	2362820	in Azure AD and the user access administrator group
2362820	2364500	at the Azure root level.
2364620	2365960	Regarding sensitive systems,
2365960	2367740	severely restrict who has access to them.
2367740	2369060	Placing them in a separate subscription
2369480	2371800	will protect against common over-permissioning,
2371800	2373580	but not against a sort of attack.
2373660	2376020	So leveraging a separate Azure tenant is the best method
2376020	2378380	for isolating and securing sensitive systems,
2378380	2379880	including domain controllers.
2381040	2383560	I reported this issue to Microsoft security
2383560	2385640	in September of 2019,
2385640	2386900	continued corresponding with them,
2386900	2389560	providing additional details through the rest of the year.
2389560	2390900	Again, my biggest concern with this
2390900	2392740	is that on the Azure AD side,
2392740	2394660	there is no way to detect, remediate,
2394660	2396720	or prevent a global admin from flipping the switch
2396720	2398800	and gaining full Azure rights.
2400080	2401940	Instead of an external attacker,
2401940	2403360	what if there was a malicious insider,
2403360	2404460	someone who did not benefit
2404460	2407440	from the company's spared no expense mantra?
2408200	2410420	And we know what happened in that scenario.
2411280	2414140	But how bad could it really get?
2414200	2415760	Let's play what if.
2415760	2419640	What if an attacker takes control of Azure resources?
2419980	2421760	What if the attacker then removes
2421760	2423900	all the accounts from all the roles?
2424160	2427040	And what if they decide to ransom the Azure environment?
2427040	2429420	Azure ransomware? Azureware?
2430020	2431720	Yeah, that could be pretty bad.
2432680	2434900	So let's take the cloud architecture concepts
2434900	2435760	to the next level,
2435760	2437920	which is pretty much where organizations are headed.
2438200	2438880	Let's say you start
2438880	2440780	with the typical Microsoft server architecture
2440780	2442620	with on-prem Active Directory,
2442620	2445220	and then we're going to add Azure to it.
2445680	2448640	And then we're going to add AWS to the mix.
2448860	2451460	And then we're going to add Google Cloud Platform.
2451820	2454760	And so I'm just going to provide a simplified view of this
2454760	2457540	because really the architecture diagrams get pretty messy.
2458400	2460400	We have AWS, we have Azure,
2460400	2462100	and we have Google Cloud Platform.
2462460	2464240	And I simplify this, like I said,
2464240	2466060	showing the on-prem data center
2466060	2468840	and federation to the three different cloud environments.
2468840	2471100	But ultimately this federation just means
2471100	2472640	that we have this sort of configuration
2472640	2474560	where everything can talk to everything else
2475130	2476880	and that they're interconnected.
2477580	2479300	And this means a compromise in one
2479910	2482220	will likely lead to a compromise in all cloud environments.
2482220	2483820	Since the IAM story is quite different in each
2483820	2486540	and difficult to track roles and privileges across them,
2486540	2488060	it's likely the accounts are over-permissioned
2488060	2489180	in this scenario.
2489340	2492080	And the use of federation provides the ability
2492080	2496120	to jump across between these different environments.
2497000	2498620	So a compromise of all three cloud environments
2498620	2500320	will likely result in on-prem compromise
2500320	2502600	since there's likely on-prem AD domain controllers
2502600	2504460	in one or more of the cloud environments.
2504460	2507040	Federation or any type of authentication flow,
2507040	2508620	really, between these environments
2508620	2511020	enables a new type of lateral movement.
2511320	2513580	The attacker could leverage over-privileged Azure
2513580	2515780	and AWS roles and the rights provided with them
2515780	2519340	and showing which ones can provide system access to VMs,
2519340	2520660	despite how they're described,
2520660	2523120	is one way that we can identify
2523570	2527080	and lock down those controls or those roles.
2528020	2530760	But the attacker could jump across the federation
2530760	2532800	to gain privileged access to cloud-hosted services
2532800	2535080	and systems once they compromise a single system
2535080	2536840	or even an account.
2537280	2538980	Because ultimately, gaining privileged access
2538980	2543360	to the IaaS service provider, so Azure, Amazon, AWS, GCP,
2543360	2544960	means that the attacker could do anything
2544960	2546600	with the VMs hosted in the environment,
2546600	2549200	including accessing and modifying data on the systems.
2549200	2551520	So it's very important that administrative roles
2551520	2553480	need to be limited and gated.
2554800	2556660	I recently heard a customer tell me
2556660	2557940	that an executive was concerned
2557940	2560520	about putting all their eggs in one basket.
2560940	2564660	So they signed up for Azure and AWS and Google Cloud Platform,
2564660	2568040	so now their eggs are in all the baskets.
2568360	2569540	And the security capabilities
2569540	2572380	and controls across these environments is quite different.
2572560	2574420	And it's up to the operation and security teams
2574420	2575940	to figure that part out.
2578060	2580720	So the cloud provides many benefits and power,
2580720	2583080	though cloud integration often complicates security.
2583120	2585200	Organizations will have to do better to map security
2585200	2587600	between on-prem and cloud systems and authentication.
2587880	2589940	It's important as a security professional
2589940	2593060	or security hobbyist to learn about these things.
2593060	2595620	The cloud is the Wild West at this point.
2595620	2597560	It is the whole brave new world.
2597720	2599440	If you want to go far in your career,
2599440	2602380	focus on cloud and cloud security because it is wide open.
2602380	2605120	There's a lot of areas that haven't been explored,
2605120	2610140	and especially in those areas across on-prem
2610140	2612000	and the hybrid environment.
2612080	2614500	So there's a lot of work that needs to be done there,
2614500	2617180	and there's a lot that we need to do moving forward
2617180	2619840	to improve the security in this environment.
2620200	2621400	That's been my time.
2621400	2622780	Thank you very much for yours.