{"id":4455,"date":"2025-08-10T15:17:37","date_gmt":"2025-08-10T19:17:37","guid":{"rendered":"https:\/\/adsecurity.org\/?p=4455"},"modified":"2025-08-18T22:28:00","modified_gmt":"2025-08-19T02:28:00","slug":"entra-azure-revisited","status":"publish","type":"post","link":"https:\/\/adsecurity.org\/?p=4455","title":{"rendered":"Entra &amp; Azure Elevated Access Revisited"},"content":{"rendered":"\n<p>In early 2020, I <a href=\"https:\/\/adsecurity.org\/?p=4277\" data-type=\"link\" data-id=\"https:\/\/adsecurity.org\/?p=4533\">published an article<\/a> on how a Global Administrator could gain control of Azure resources, that no one would know about it, and how this access would persist even after removing them from Global Administrator.<\/p>\n\n\n\n<p>From that article:<\/p>\n\n\n\n<p><em>\u201cWhile Azure leverages Azure Active Directory for some things, Azure AD roles don\u2019t 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\u2019s possible for a Global Administrator (aka Company Administrator) in Azure Active Directory to gain control of Azure through a tenant option. This is \u201cby design\u201d as a \u201cbreak-glass\u201d (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\u2019t 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.\u201d<\/em><\/p>\n\n\n\n<p><strong>Elevated Access<\/strong><\/p>\n\n\n\n<p>There is a switch that can be flipped from \u201cNo\u201d to \u201cYes\u201d that allows a Global Administrator to gain \u201cmanage access to all Azure subscriptions and management groups in this directory\u201d. Flipping this switch to Yes adds the current user to the Azure role User Access Administrator at the root level. Once this access is provided, the current user can then add themself to other roles like Subscription Admin.<br>The graphic below shows this flow.<\/p>\n\n\n\n<!--more-->\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"525\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-8-1024x525.png\" alt=\"\" class=\"wp-image-4465\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-8-1024x525.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-8-300x154.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-8-768x394.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-8-823x422.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-8.png 1094w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><br>This leads to some interesting attack scenarios. The one I covered in the article involved jumping to Azure and compromising an Azure hosted Domain Controller. The graphic below shows the conceptual attack scenario laid out in the article.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"540\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-9-1024x540.png\" alt=\"\" class=\"wp-image-4466\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-9-1024x540.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-9-300x158.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-9-768x405.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-9-823x434.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-9.png 1249w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p><strong>Attack Scenario Key Takeaways<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An attacker that can gain admin rights to one environment can often pivot to another.<\/li>\n\n\n\n<li>Hosting Domain Controllers on virtual infrastructure such as cloud requires trust in that platform as well as additional protections around compromised accounts &amp; monitoring.<\/li>\n\n\n\n<li>Jumping from Entra ID to Azure to on-prem Active Directory is possible given how many enterprises are configured and if the Global Admins group isn\u2019t well protected or standard user accounts have the ability to elevate.<\/li>\n\n\n\n<li>The attacker could also use resources in your subscriptions for their purposes such as spinning up new virtual instances for attacker systems or bitcoin mining.<\/li>\n\n\n\n<li>Control of subscription access enables the attacker to launch ransomware against virtual instances.<\/li>\n<\/ul>\n\n\n\n<p><\/p>\n\n\n\n<p><strong>Updates to Elevated Access<\/strong><\/p>\n\n\n\n<p>Since I submitted the information to Microsoft and wrote the article describing the issue, there have been changes to how this works.<br><a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/role-based-access-control\/elevate-access-global-admin\">https:\/\/learn.microsoft.com\/en-us\/azure\/role-based-access-control\/elevate-access-global-admin<\/a><\/p>\n\n\n\n<p>There is now a bar below the Access management for Azure resources area that states how many users have elevated access. This provides clear messaging around how elevate access is used in the environment<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"282\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-15-1024x282.png\" alt=\"\" class=\"wp-image-4472\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-15-1024x282.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-15-300x83.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-15-768x212.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-15-823x227.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-15.png 1248w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p>Clicking on this link takes us to a new page that shows users with elevated access. On this page we have the ability to select and remove the accounts that have this right.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"506\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-10-1024x506.png\" alt=\"\" class=\"wp-image-4467\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-10-1024x506.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-10-300x148.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-10-768x379.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-10-823x407.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-10.png 1249w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p>There are also now logs associated with this right called Elevated Access Audit Logs (preview). The first event I show here is when a user flips the bit and receives elevated access.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"197\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-12-1024x197.png\" alt=\"\" class=\"wp-image-4470\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-12-1024x197.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-12-300x58.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-12-768x148.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-12-823x158.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-12.png 1248w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"853\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-11-1024x853.png\" alt=\"\" class=\"wp-image-4469\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-11-1024x853.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-11-300x250.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-11-768x640.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-11-823x686.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-11.png 1247w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p>When we remove a user from having elevated access, we can now see that in a log as well.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"197\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-13-1024x197.png\" alt=\"\" class=\"wp-image-4468\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-13-1024x197.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-13-300x58.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-13-768x148.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-13-823x158.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-13.png 1249w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"891\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-14-1024x891.png\" alt=\"\" class=\"wp-image-4471\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-14-1024x891.png 1024w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-14-300x261.png 300w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-14-768x668.png 768w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-14-823x716.png 823w, https:\/\/adsecurity.org\/wp-content\/uploads\/2025\/08\/image-14.png 1248w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p><strong>Attack Scenario Key Mitigation<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Severely restrict membership in Global Admins.<\/li>\n\n\n\n<li>Use PIM (eligible) for Global Admins &amp; require MFA.<\/li>\n\n\n\n<li>Once Elevated Access is applied to an account, removing role membership has no impact. Elevated Access must be removed separately.<\/li>\n\n\n\n<li>Monitor the Entra ID Audit Log for Azure RBAC (Elevated Access) activity.<\/li>\n\n\n\n<li>Closely monitor membership of the \u201cUser Access Administrator\u201d Azure role (root level).<\/li>\n\n\n\n<li>Remove any account with Elevated Access that doesn\u2019t require it.<\/li>\n\n\n\n<li>Place Domain Controllers and other sensitive systems in another Azure tenant.<\/li>\n<\/ul>\n\n\n\n<p><\/p>\n\n\n\n<p><strong>Conclusion<\/strong><\/p>\n\n\n\n<p>Elevated Access is one of those nearly hidden options that provides the ability for a Global Admin to gain highly privileged rights in Azure. This level of access should be audited regularly and the logs ingested in the SIEM.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In early 2020, I published an article on how a Global Administrator could gain control of Azure resources, that no one would know about it, and how this access would persist even after removing them from Global Administrator. From that article: \u201cWhile Azure leverages Azure Active Directory for some things, Azure AD roles don\u2019t directly &hellip; <\/p>\n<p><a class=\"more-link btn\" href=\"https:\/\/adsecurity.org\/?p=4455\">Continue reading<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[25,1458,1456,1463,1457,1406],"class_list":["post-4455","post","type-post","status-publish","format-standard","hentry","category-technical-reference","tag-azure","tag-azure-ad","tag-elevatedaccess","tag-elevatedaccesslogging","tag-entra-id","tag-global-administrator","item-wrap"],"_links":{"self":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/4455","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4455"}],"version-history":[{"count":7,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/4455\/revisions"}],"predecessor-version":[{"id":4538,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/4455\/revisions\/4538"}],"wp:attachment":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}