From Azure AD To Active Directory (Via Azure) - An Unanticipated Attack Path - Active Directory Security

From Azure AD to Active Directory (via Azure) – An U... https://adsecurity.org/?
p=4277
•  (https://adsecurity.org/?feed=rss2)
 What is Azure Active Directory? (https://adsecurity.org/?p=4211)
Attacking Active Directory Group Managed Service Accounts (GMSAs) (https://adsecurity.org

/?p=4367) 
May 27 2020
From Azure AD to Active Directory (via Azure) – An Unanticipated Attack Path

• By Sean Metcalf (https://adsecurity.org/?author=2) in Cloud Security (https://adsecurity.org
/?cat=431), Microsoft Security (https://adsecurity.org/?cat=11), TheCloud (https://adsecurity.org
/?cat=156)
For most of 2019, I was digging into Office 365 and Azure AD and looking at features as part of the
development of the new Trimarc Microsoft Cloud Security Assessment (http://trimarc.co/mcsa) which
focuses on improving customer Microsoft Office 365 and Azure AD security posture. As I went through each
of them, I found one that was very interesting.
In May 2020, I presented some Microsoft Office 365 & Azure Active Directory security topics in a Trimarc
Webcast called “Securing Office 365 and Azure AD: Protect Your Tenant”
(https://www.hub.trimarcsecurity.com/post/webcast-securing-office-365-and-azure-ad-defend-your-tenant)
and included the attack path described in this article that takes advantage of a little known feature.
While Azure leverages Azure Active Directory for some things, Azure AD roles don’t directly affect Azure (or
Azure RBAC) typically. This article details a known configuration (at least to those who have dug into Azure
AD configuration options) where it’s possible for a Global Administrator (aka Company Administrator) in
Azure Active Directory to gain control of Azure through a tenant option. This is “by design” as a “break-
glass” (emergency) option that can be used to (re)gain Azure admin rights if such access is lost.
In this post I explore the danger associated with this option how it is currently configured (as of May 2020).
The key takeaway here is that if you don’t carefully protect and control Global Administrator role
membership and associated accounts, you could lose positive control of systems hosted in all Azure
subscriptions as well as Office 365 service data.
Note:
Most of the research around this issue was performed during August 2019 through December 2019 and
Microsoft may have incorporated changes since then in functionality and/or capability.
1 of 24 10/15/23, 16:38
From Azure AD to Active Directory (via Azure) – An U... https://adsecurity.org/?p=4277
Attack Scenario:
In this scenario, Acme has an on-premises Active Directory environment. Acme embraced Azure
Infrastructure as a Service (IAAS) as an additional datacenter and deployed Domain Controllers to Azure for
their on-prem AD (as their “cloud datacenter”). Acme IT locked down the DCs following hardening advice
and limited Azure administration to the VMs hosting the DCs. Acme has other sensitive applications hosted
on servers in Azure.
Acme signed up for Office 365 and started a pilot. All of the Active Directory and Exchange admins (and
many other IT admins) are granted temporary Global Administrator (https://docs.microsoft.com/en-us/azure
/active-directory/users-groups-roles/directory-assign-admin-roles) (aka Global Admin or GA) rights to
facilitate the pilot. So, more than should be there and not well protected.
The Global Administrator role provides full admin rights to Azure AD and ultimately all Office 365 services.
The Microsoft online document provides key information (5/26/2020): https://docs.microsoft.com/en-
us/azure/active-directory/users-groups-roles/directory-assign-admin-roles (https://docs.microsoft.com/en-
us/azure/active-directory/users-groups-roles/directory-assign-admin-roles)
Note that there is nothing stated here about Azure capability.
2 of 24 10/15/23, 16:38
Once we have access to the Azure AD portal (which is typically all Azure AD users by default).
We can view several different configuration settings for Azure Active Directory which controls many aspects
of Office 365.
This page shows the Directory Properties and now includes the new Manage Security Defaults
Towards the bottom is “Access management for Azure resources” toggle. That’s interesting….
The Attack:
The attacker password sprays the Acme Office 365 environment and identifies a Global Admin account that
doesn’t have MFA (multi-factor authentication). Since less than 10% of Global Admins have MFA
configured, this is a real threat.
3 of 24 10/15/23, 16:38
(https://adsecurity.org/?p=4019)
The attacker creates a new Global Admin account (or leverages an existing account). In this example, the
Office 365 Global Admin account “AzureAdmin” is compromised.
Attacker Moves from Office 365 Global Admin to Shadow Azure Subscription Admin
According to Microsoft documentation, toggling this option from No to Yes, adds the account to the User
4 of 24 10/15/23, 16:38
Access Administrator role in Azure RBAC at the root scope (which has control over all subscriptions in the
tenant). This option is only available to accounts that are members of the Global Administrator role.
While this option is configured in the Directory Properties section, this is actually a per account configuration
option.
This “magic button” provides the ability to manage Azure roles, but no direct Azure rights (to VMs).
5 of 24 10/15/23, 16:38
The graphic below shows what happens with Elevate Access and the connection point between Azure AD
and Azure.
My biggest concern here is that for many organizations, the group that manages Azure AD & Office 365 are
often a different group from those that manage Azure. This means that someone could elevate access
(think rogue admin) and no one would notice. This is potentially a serious threat from an insider threat
perspective. Especially around the detection part of this issue which is explored at the end of this post.
6 of 24 10/15/23, 16:38
I also found an API that seems related which means an attacker would not need to visit the Azure AD Portal
to perform this action.
7 of 24 10/15/23, 16:38
What’s interesting is that if this option is toggled to “Yes” that the account is removed from the Global
Administrator role, the Azure RBAC role remains and is not removed. In fact, the account can’t toggle this
option back to “No” until it has Global Admin rights again.
8 of 24 10/15/23, 16:38
The attacker determines that Acme has a few on-prem AD Domain Controllers in Azure. In order to exploit
this configuration the attacker decides to create a new account and use that one to access Azure.
With Azure access management enabled for the attacker-controlled account (called “hacker” so I wouldn’t
forget which account I was using), this account can logon to the Azure subscription management and
modify roles.
You will notice I also added a couple of others that “look” like they belong.
Monitoring for changes to the root Azure RBAC group “User Access Administrator” is a bit complicated
since there doesn’t seem to be any way to view this in the Azure portal. The primary method to review is
through Azure CLI.
9 of 24 10/15/23, 16:38
Once there is an account identified that needs to be removed, it must be removed using the Azure CLI
(since this is a root level role).
If one attempts to remove an account from the subscription role, the following message appears since it
must be removed at the root level.
When an account toggles Elevate Access from Yes to No, it is automatically removed from User Access
Administrator.
10 of 24 10/15/23, 16:38
Issue Recap
Let’s pause here for a moment and recap the configuration so far.
1. The attacker compromises a Global Admin account by password spraying Acme’s Office 365 tenant and
finds one with a bad password (& no MFA). OR a GA session token was stolen because the GA is using
their web browser on their regular user workstation (which was compromised).
2. The attacker authenticates with this account and leverages the account rights to either create another
account used for the attack or use the compromised account.
3. The attacker toggles the “Access management for Azure resources” option to “yes” which adds the Azure
AD account to the Azure RBAC role “User Access Administrator (https://docs.microsoft.com/en-us/azure
/role-based-access-control/built-in-roles#user-access-administrator)” at the root level which applies to all
subscriptions.
4. User Access Administrator provides the ability to modify any group membership in Azure.
5. The attacker can now set any Azure AD account to have privileged rights to Azure subscriptions and/or
Azure VMs.
From Global Admin to (Azure) User Access Administrator to Azure Admin (or Virtual Machine Contributor).
An attacker compromises an organization’s Global Administrator account either because they are just
starting with Office 365 or didn’t realize the risks around protecting GAs. Either way, the GA accounts
weren’t locked down with PIM, Conditional Access, or MFA. OR a GA session token was stolen because
the GA is using their web browser on their regular user workstation (which was compromised).
The attacker has about an hour to perform these actions.

Compromise the account, Elevate Access to Azure, Get Azure rights through Azure role membership,
Remove Elevate Access rights, perform malicious actions on any or ALL Azure VMs in all subscriptions,
11 of 24 10/15/23, 16:38
then remove role membership in Azure (or not).

Total time required: only a few minutes, perhaps as much as 15 minutes total.
Attacker updates Azure role membership to run commands on Azure VM(s):

Setting “Owner” rights to this account is obvious (and is possible as is adding an account to Virtual Machine
Administrator). This would result in an attacker controlled account having full access to Azure VMs.
While exploring the various Azure RBAC roles, I realized a more stealthy method is “Virtual Machine
12 of 24 10/15/23, 16:38
Contributor” which sounds pretty innocuous.
Virtual Machine Contributor, according to the Azure roles description: (https://docs.microsoft.com/en-

us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor (https://docs.microsoft.com/en-
us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor)) “lets you manage virtual
machines, but not access to them, and not the virtual network or storage account they’re connected to.”
[quote excerpted in September 2019]
This sounds like very limited access to the Azure VM until you consider the ability to run PowerShell (as
System) on the VM. This right is Microsoft.Compute/virtualMachines/runCommand/ action which is included
in Virtual Machine Contributor.
This includes the ability to re-enable the Administrator account. Which on a Domain Controller in Azure, this
would be the RID 500 account for the domain.
13 of 24 10/15/23, 16:38
Once the attacker can run PowerShell on the Azure VM, they can execute commands as System.
I added the obvious “hacker” account and a secondary one that looks “normal” (maybe?) called “Azure AD
Service Account.
Both of these can run PowerShell commands.
14 of 24 10/15/23, 16:38
In this example, I run a PowerShell command to run “net localgroup” which updates the local Administrators
group. When this is executed on a Domain Controller, this applies to the domain Administrators group. This
will happen on the Azure based DC, then replicate to the DCs on-prem.
Note: Being able to run commands on an Azure VM is not specific to customer on-prem Active Directory
DCs hosted on Azure, but also other systems hosted there as well.
15 of 24 10/15/23, 16:38
Back on-prem, I then run the Active Directory module PowerShell command to get the membership of the
domain Administrators group and we can see that the account was added.
16 of 24 10/15/23, 16:38
Assuming PowerShell logging is enabled (and sent to the SIEM), it’s possible to see this command
execution. Based on my experience, this isn’t common.
17 of 24 10/15/23, 16:38
Once the attacker can run PowerShell as System on the Azure VM, they can extract anything from the
cloud hosted Domain Controller, including the krbtgt password hash which means total compromise of the
on-premises Active Directory environment.
In this example, the attacker runs a one-liner Invoke-Mimikatz PowerShell command that dumps the
password hash of the AD krbtgt password hash.
Note that the way I run it here, this would require internet access. However, it would be possible to
obfuscate and host Invoke-Mimikatz on a compromised system on the corporate network (or within the
Azure tenant) and leverage that instead.
Conclusion:
The customer is hosting on-premises Active Directory Domain Controllers in the Azure cloud.The customer
also has Office 365 with admin accounts that are not appropriately protected.
The attacker password sprays the company’s accounts and identifies the password for an Office 365 Global
Administrator. With this account, the attacker pivots to Azure and runs PowerShell on the Azure VM which
hosts the company’s on-prem Active Directory Domain Controllers. The PowerShell command can update
18 of 24 10/15/23, 16:38
the domain Administrators group in Active Directory or event dump the krbtgt password hash which enables
the attacker to create Kerberos Golden Tickets offline and then use forged Kerberos TGT authentication
tickets against the on-prem AD environment to access any resource.
Why is this issue important?
• Customers usually have no expectation that an Office 365 Global Administrator has the ability to
control Azure role membership by flipping an option on the account (under Directory Properties of all
places).
• Microsoft documented Global Administrator as an “Office 365 Admin”, not as an Office 365 and Azure
administrator (or at least having that capability.
• Office 365 (Azure AD) Global Administrators can gain Azure subscription role administration access
by toggling a single switch.
• Azure doesn’t have great granular control over who can run commands on Azure VMs that are
sensitive like Azure hosted Domain Controllers (or other applications hosted on customer Azure
VMs).
• An attacker can compromise an Office 365 Global Administrator, toggle this option to become the
Azure IAM “User Access Administrator”, then add any account to another Azure IAM role in a
subscription, and then toggle the option back to “No” and the attacker account from the User Access
Administrator IAM role with minimal logging and nothing clearly identifying in Azure AD that “Access
management for Azure resources” was modified for an account and no default Azure logging alerts to
this.
• Once the “Access management for Azure resources” bit is set, it stays set until the account that
toggled the setting to “Yes” later changes it to “No”.
• Removing the account from Global Administrators does not remove this access either.
Logging & Detection

As of early 2020, it’s not possible to check for Azure AD accounts with this “Access management for Azure
resources” bit set (either via the Azure AD portal or programmatically). Furthermore, it’s not possible to
remove this setting as an Azure AD Global Administrator even if it could be detected on another account.
Only the account that sets it can remove it.
There appears to be no clear logging of any of this activity (in Office 365, Azure AD, or Azure logs) as I
walked through my attack chain on this. There is no way to detect this configuration in Azure AD – no
property to query on accounts.
The only clear detection I could identify is by monitoring the Azure RBAC group “User Access Administrator”
membership for unexpected accounts. You have to run an Azure CLI command to check the role group
membership in Azure.
When I walked through the Azure AD to Azure access elevation, I attempted to identify a clear event that I
could alert on and was unable to.
The Core Directory, DirectoryManagement “Set Company Information” log notes that something changed,
but not what.
The capability for an Azure AD Global Admin is “by design”; however not expected and not well
documented by Microsoft when reading about what Azure AD Global Admins can do.
Additionally, I am concerned that this is a scenario where the Microsoft cloud customer: can’t detect, can’t
remediate, and ultimately can’t prevent since there is no real gate to lock if an Azure AD Global Admin
account is exposed.
The only good answer to this is managing Global Administrators group with Azure AD PIM. Though even
19 of 24 10/15/23, 16:38
this doesn’t stop a rogue admin.
Detection Key Points:
• Can’t detect this setting on Azure AD user accounts using PowerShell, portal, or other method.
• No Office 365/Azure AD logging I can find that states that an Azure AD account has set this bit
(“Access management for Azure resources”).
• No Audit Logs logging that clearly identifies this change.
• Core Directory, DirectoryManagement “Set Company Information” Log shows success for the
tenant name and the account that performed it. However, this only identifies that something changed
relating to “Company Information” – no detail logged other than “Set Company Information” and in the
event the Modified Properties section is empty stating “No modified properties”.
• No default Azure logging after adding this account to the VM Contributor role in Azure.
Azure AD to Azure Mitigation:
• Monitor the Azure AD role “Global Administrator (https://docs.microsoft.com/en-us/azure/active-

directory/users-groups-roles/directory-assign-admin-roles#company-administrator-permissions)” for
membership changes.
• Enforce MFA on all accounts in the Global Administrator role.
• Control the Global Administrator role with Azure AD Privileged Identity Manager (PIM)
(https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/). While PIM
requires Azure AD Premium 2 (AAD P2), these licenses are only required for the accounts that use
PIM, so only your admin accounts; not all Azure AD accounts. If you have 10 admin accounts that will
be members of Azure AD role groups, then you only need 10 Azure AD P2 licenses.
This is the best way to protect Global Admins.
• Ensure that Global Admins only use admin workstations or at a minimum, secure web browser
configuration.
• Monitor the Azure RBAC role “User Access Administrator (https://docs.microsoft.com/en-us/azure
/role-based-access-control/built-in-roles#user-access-administrator)” for membership changes.
• Ensure sensitive systems like Domain Controllers in Azure are isolated and protected as much as
possible. Ideally, use a separate tenant for sensitive systems.
MSRC Reporting Timeline:
• Reported to Microsoft in September 2019.

• MSRC responds in early October 2019:
“Based on [internal] conversations this appears to be By Design and the documentation is being
updated. “
• Sent MSRC additional information in mid October 2019 after a day of testing detection and potential
logging.
• MSRC responds that “most of what you have is accurate”
• Sent MSRC update in late January 2020 letting them know that I would be submitting this as part of a
larger presentation to Black Hat USA & DEF CON.(2020).
• MSRC acknowledges.
• Sent MSRC notification that I would be sharing this information in this blog.
• MSRC Security incident still open as of May 2020.
I was informed by Microsoft during my interactions with MSRC that they are looking into re-working
this functionality to resolve some of the shortcomings I identified.
(Visited 33,014 times, 5 visits today)
20 of 24 10/15/23, 16:38
•  Access management for Azure resources (https://adsecurity.org/?tag=access-management-

for-azure-resources), ActiveDirectory (https://adsecurity.org/?tag=activedirectory), Azure AD PIM
(https://adsecurity.org/?tag=azure-ad-pim), Azure Owner (https://adsecurity.org/?tag=azure-
owner), Azure RBAC (https://adsecurity.org/?tag=azure-rbac), Azure root (https://adsecurity.org
/?tag=azure-root), AzureAD (https://adsecurity.org/?tag=azuread), Company Administrator
(https://adsecurity.org/?tag=company-administrator), Compromise Azure Domain Controller
(https://adsecurity.org/?tag=compromise-azure-domain-controller), Compromise Azure VM
(https://adsecurity.org/?tag=compromise-azure-vm), Elevate Access (https://adsecurity.org
/?tag=elevate-access), EnableAdminAccount (https://adsecurity.org/?tag=enableadminaccount),
From Azure AD to Azure (https://adsecurity.org/?tag=from-azure-ad-to-azure), Global Admin to
Azure (https://adsecurity.org/?tag=global-admin-to-azure), Global Administrator
(https://adsecurity.org/?tag=global-administrator), Global Administrator Elevate Access
(https://adsecurity.org/?tag=global-administrator-elevate-access), MFA (https://adsecurity.org
/?tag=mfa), Microsoft.Compute/virtualMachines/runCommand/ (https://adsecurity.org
/?tag=microsoft-compute-virtualmachines-runcommand), net localgroup (https://adsecurity.org
/?tag=net-localgroup), Office 365 Security (https://adsecurity.org/?tag=office-365-security), PIM
(https://adsecurity.org/?tag=pim), Privileged Identity Manager (https://adsecurity.org
/?tag=privileged-identity-manager), Run PowerShell on Azure VM (https://adsecurity.org
/?tag=run-powershell-on-azure-vm), runCommand (https://adsecurity.org/?tag=runcommand),
RunPowerShellScript (https://adsecurity.org/?tag=runpowershellscript), User Access
Administrator (https://adsecurity.org/?tag=user-access-administrator), Virtual Machine
Contributor (https://adsecurity.org/?tag=virtual-machine-contributor)
•
(https://adsecurity.org/?author=2)
Sean Metcalf
I improve security for enterprises around the world working for TrimarcSecurity.com
Read the About page (top left) for information about me. :)
https://adsecurity.org/?page_id=8
•  (mailto:sean@adsecurity.org)
 5 comments
Skip to comment form 
1.
◦ Max Armah on May 27, 2020
◦ ◦ # (https://adsecurity.org/?p=4277#comment-15829)
Great article, thank you!
21 of 24 10/15/23, 16:38
2.
◦ Anonymous on May 28, 2020
Azure backdoor service (WindowsAzureNetAgentSvc) can be disabled inside
the VMs
3.
◦ JeffJ on May 29, 2020
This is definitely by design. It’s important to remember that the AzureAD tenant
is the management plane. All subscriptions need to exist within a tenant. Administrators need to
be able to rip out old users from subscriptions with no other access.
The different names for the same things is a problem. A global admin is a global admin.
The contributor role isn’t that misleading when you understand Azure’s context for it. You
basically get full rights to the thing but not the right to assign others to it.
4.
◦ Joe on May 29, 2020
Microsoft would highly recommend enabling mfa with conditional access found
in azure active directory premium 1 licensing to help mitigate an attack like this. There is also a
product called azure advanced threat protection that helps detect lateral movement in a
companies on prem environment to help detect elevation of privileges at the identity level.
5.
◦ Jabberwocq on June 1, 2020
As always, great info. Working on remediation and advising MSFT to make
changes.
 Comments have been disabled.
Recent Posts
• Attacking Active Directory Group Managed Service Accounts (GMSAs) (https://adsecurity.org
/?p=4367)
• From Azure AD to Active Directory (via Azure) – An Unanticipated Attack Path (https://adsecurity.org
/?p=4277)
• What is Azure Active Directory? (https://adsecurity.org/?p=4211)
• Slides Posted for Black Hat USA 2019 Talk: Attacking & Defending the Microsoft Cloud
(https://adsecurity.org/?p=4179)
• AD Reading: Windows Server 2019 Active Directory Features (https://adsecurity.org/?p=4187)
Trimarc Active Directory Security Services

Have concerns about your Active Directory environment? Trimarc helps enterprises improve their security
posture.
Find out how... (http://trimarcsecurity.com/security-services) TrimarcSecurity.com
22 of 24 10/15/23, 16:38
Popular Posts
• Attack Methods for Gaining Domain Admin Rights in… (https://adsecurity.org/?p=2362)
• PowerShell Encoding & Decoding (Base64) (https://adsecurity.org/?p=478)
• Kerberos & KRBTGT: Active Directory’s… (https://adsecurity.org/?p=483)
• Finding Passwords in SYSVOL & Exploiting Group… (https://adsecurity.org/?p=2288)
• Securing Domain Controllers to Improve Active… (https://adsecurity.org/?p=3377)
• Securing Windows Workstations: Developing a Secure Baseline (https://adsecurity.org/?p=3299)
• Mimikatz DCSync Usage, Exploitation, and Detection (https://adsecurity.org/?p=1729)
• Detecting Kerberoasting Activity (https://adsecurity.org/?p=3458)
• Scanning for Active Directory Privileges &… (https://adsecurity.org/?p=3658)
• The Most Common Active Directory Security Issues and… (https://adsecurity.org/?p=1684)
Categories
• ActiveDirectorySecurity (https://adsecurity.org/?cat=565)
• Apple Security (https://adsecurity.org/?cat=55)
• Cloud Security (https://adsecurity.org/?cat=431)
• Continuing Education (https://adsecurity.org/?cat=17)
• Entertainment (https://adsecurity.org/?cat=396)
• Exploit (https://adsecurity.org/?cat=347)
• Hacking (https://adsecurity.org/?cat=1039)
• Hardware Security (https://adsecurity.org/?cat=168)
• Hypervisor Security (https://adsecurity.org/?cat=172)
• Linux/Unix Security (https://adsecurity.org/?cat=126)
• Malware (https://adsecurity.org/?cat=343)
• Microsoft Security (https://adsecurity.org/?cat=11)
• Mitigation (https://adsecurity.org/?cat=819)
• Network/System Security (https://adsecurity.org/?cat=48)
• PowerShell (https://adsecurity.org/?cat=7)
• RealWorld (https://adsecurity.org/?cat=698)
• Security (https://adsecurity.org/?cat=21)
• Security Conference Presentation/Video (https://adsecurity.org/?cat=234)
• Security Recommendation (https://adsecurity.org/?cat=1045)
• Technical Article (https://adsecurity.org/?cat=24)
• Technical Reading (https://adsecurity.org/?cat=4)
• Technical Reference (https://adsecurity.org/?cat=2)
• TheCloud (https://adsecurity.org/?cat=156)
• Vulnerability (https://adsecurity.org/?cat=930)
Tags
ActiveDirectory (https://adsecurity.org
/?tag=activedirectory) Active Directory (https://adsecurity.org/?tag=active-directory)
ActiveDirectorySecurity
ActiveDirectoryAttack (https://adsecurity.org/?tag=activedirectoryattack)
(https://adsecurity.org/?tag=activedirectorysecurity) Active Directory Security

(https://adsecurity.org/?tag=active-directory-security) ADReading (https://adsecurity.org
/?tag=adreading) ADSecurity (https://adsecurity.org/?tag=adsecurity) AD Security (https://adsecurity.org
23 of 24 10/15/23, 16:38
/?tag=ad-security) DCSync (https://adsecurity.org/?tag=dcsync) DEFCON (https://adsecurity.org/?tag=defcon)

DomainController (https://adsecurity.org/?tag=domaincontroller) EMET5
(https://adsecurity.org/?tag=emet5) GoldenTicket (https://adsecurity.org/?tag=goldenticket) HyperV
(https://adsecurity.org/?tag=hyperv) Invoke-Mimikatz (https://adsecurity.org/?tag=invoke-mimikatz) KB3011780
(https://adsecurity.org/?tag=kb3011780) KDC (https://adsecurity.org/?tag=kdc) Kerberos
(https://adsecurity.org/?tag=kerberos) KerberosHacking (https://adsecurity.org

/?tag=kerberoshacking) KRBTGT (https://adsecurity.org/?tag=krbtgt) LAPS (https://adsecurity.org/?tag=laps)
LSASS (https://adsecurity.org/?tag=lsass) MCM (https://adsecurity.org/?tag=mcm)
MicrosoftEMET (https://adsecurity.org/?tag=microsoftemet) MicrosoftWindows (https://adsecurity.org
/?tag=microsoftwindows) mimikatz (https://adsecurity.org/?tag=mimikatz)

MS14068 (https://adsecurity.org/?tag=ms14068) PassTheHash (https://adsecurity.org/?tag=passthehash)
PowerShell (https://adsecurity.org/?tag=powershell)
PowerShellCode (https://adsecurity.org/?tag=powershellcode) PowerShellHacking
PowerSploit
(https://adsecurity.org/?tag=powershellhacking) PowerShellv5 (https://adsecurity.org/?tag=powershellv5)
(https://adsecurity.org/?tag=powersploit) Presentation (https://adsecurity.org/?tag=presentation) Security
(https://adsecurity.org/?tag=security) SIDHistory (https://adsecurity.org/?tag=sidhistory) SilverTicket (https://adsecurity.org
/?tag=silverticket) SneakyADPersistence (https://adsecurity.org/?tag=sneakyadpersistence) SPN (https://adsecurity.org
/?tag=spn) TGS (https://adsecurity.org/?tag=tgs) TGT (https://adsecurity.org/?tag=tgt) Windows10
(https://adsecurity.org/?tag=windows10) WindowsServer2008R2 (https://adsecurity.org/?tag=windowsserver2008r2)
WindowsServer2012 (https://adsecurity.org/?tag=windowsserver2012) WindowsServer2012R2
(https://adsecurity.org/?tag=windowsserver2012r2)
Copyright
Content Disclaimer: This blog and its contents are provided "AS IS" with no warranties, and they confer no
rights. Script samples are provided for informational purposes only and no guarantee is provided as to
functionality or suitability. The views shared on this blog reflect those of the authors and do not represent
the views of any companies mentioned. Content Ownership: All content posted here is intellectual work and
under the current law, the poster owns the copyright of the article. Terms of Use Copyright © 2011 - 2020.
Content Disclaimer: This blog and its contents are provided "AS IS" with no warranties, and they confer no
rights. Script samples are provided for informational purposes only and no guarantee is provided as to
functionality or suitability. The views shared on this blog reflect those of the authors and do not represent the
views of any companies mentioned.
Made with  by Graphene Themes (https://www.graphene-theme.com/).
24 of 24 10/15/23, 16:38

From Azure AD To Active Directory (Via Azure) - An Unanticipated Attack Path - Active Directory Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

From Azure AD To Active Directory (Via Azure) - An Unanticipated Attack Path - Active Directory Security

Uploaded by

Copyright:

Available Formats

From Azure AD to Active Directory (via Azure) – An U... https://adsecurity.org/?

 What is Azure Active Directory? (https://adsecurity.org/?p=4211)

Attacking Active Directory Group Managed Service Accounts (GMSAs) (https://adsecurity.org

From Azure AD to Active Directory (via Azure) – An Unanticipated Attack Path

Note that there is nothing stated here about Azure capability.

The attacker has about an hour to perform these actions.

then remove role membership in Azure (or not).

Attacker updates Azure role membership to run commands on Azure VM(s):

Contributor” which sounds pretty innocuous.

Virtual Machine Contributor, according to the Azure roles description: (https://docs.microsoft.com/en-

Why is this issue important?

Logging & Detection

this doesn’t stop a rogue admin.

Detection Key Points:

Azure AD to Azure Mitigation:

• Monitor the Azure AD role “Global Administrator (https://docs.microsoft.com/en-us/azure/active-

MSRC Reporting Timeline:

• Reported to Microsoft in September 2019.

(Visited 33,014 times, 5 visits today)

•  Access management for Azure resources (https://adsecurity.org/?tag=access-management-

Skip to comment form 

 Comments have been disabled.

Trimarc Active Directory Security Services

(https://adsecurity.org/?tag=activedirectorysecurity) Active Directory Security

/?tag=ad-security) DCSync (https://adsecurity.org/?tag=dcsync) DEFCON (https://adsecurity.org/?tag=defcon)

(https://adsecurity.org/?tag=kerberos) KerberosHacking (https://adsecurity.org

/?tag=microsoftwindows) mimikatz (https://adsecurity.org/?tag=mimikatz)

Made with  by Graphene Themes (https://www.graphene-theme.com/).

You might also like