Creating immutable users through a bug in Entra ID restricted administrative units

Key points

We identified a bug in restricted management administrative units (AUs) that could enable an attacker to prevent selected users from being modified, deleted, or disabled — even by a Global Administrator.
A privileged attacker could have used this bug to protect an account under their control, preventing containment by any Entra ID administrator.
This bug could be cleaned up by a Global Administrator or Privileged Role Administrator, but required specific knowledge to fix.
We reported this bug to the Microsoft Security Research Center (MSRC) along with proof of concept (POC) code to replicate the issue. MSRC responded that the bug was of "moderate severity," and fixed the issue on February 22, 2025.
If you aren't familiar with restricted management AUs, we recommend that you read our article Hidden in Plain Sight: Abusing Entra ID Administrative Units for Sticky Persistence first, then return here.

In this article, we report our findings on a timing-based bug in the way AU restricted management was handled by the Microsoft Graph API. This bug could have enabled an attacker to protect an account under their control, preventing it from containment.

This is similar to our previously documented attack technique on sticky backdoor accounts through restricted management AUs. However, this scenario is different in that an affected user will stay in a restricted management state indefinitely, even after its removal from a restricted management AU. This made the user immutable without an associated AU.

Imagine how this might impact an incident: An incident response team contacts an administrator to disable a user that is performing malicious actions in the team's Azure environment. However, the administrator can't disable it! The user's details warn that it is in a restricted management AU, but no such AU exists. It isn't clear how to disable the malicious user or remove its restricted management status.

This bug was determined to be a moderate severity security feature bypass during review with the MSRC, and was fixed following Datadog's report. Microsoft's full response can be found in Microsoft's response below.

Note: To execute the persistence scenario described in this article, an attacker would have needed the Global Administrator or Privileged Role Administrator role, which is required for AU management.

Discovering an unexpected behavior

While implementing the entra-id.persistence.restricted-au technique in Stratus Red Team to emulate restricted management AU persistence, we noticed a curious behavior. Each time we removed a user from a restricted management AU, the user's restricted management status was removed only after a delay of five to ten minutes.

The following diagram depicts this behavior:

Standard workflow to remove a user from a restricted management AU (click to enlarge).

This wasn't convenient for the cleanup function in Stratus, which should be able to both revert the conditions of an emulated attack and remove its associated Terraform resources simultaneously.

While investigating if there were any workflows that could reduce this delay, we discovered an order of events that accidentally caused the user's restricted management state to never clear.

We replicated the behavior by following these steps:

Create a restricted management AU.
Add a test user account to AU membership.
Remove the test user from AU membership.
Delete the AU.

The following diagram depicts this workflow:

Bugged workflow resulting in a user remaining restricted with no associated AU (click to enlarge).

This resulted in the user remaining in a restricted management state indefinitely, despite no longer having membership in a restricted management AU.

The user displayed a warning commonly shown for all restricted management AU members:

A user stuck in restricted management state (click to enlarge).

However, the user had no associated restricted management AU memberships to explain this status:

The user stuck in a restricted management state has no associated AU (click to enlarge).

Any scoped role assignments over the original restricted management AU no longer applied to the user, as the user was no longer a member of any AU. This meant that any user who would have had control over the user in its restricted management AU would no longer have permissions over that user.

During testing, we observed a user remaining in this state for over a month after it was placed in a restricted management state with no AU using this bug. The restricted management status was never cleared once the user had been placed in this state.

Impact

The impact of a user staying in a restricted membership state without belonging to an associated AU meant that an Entra ID administrator could not modify their account. This included the following common account containment tasks:

Reset password
Revoke user sessions
Delete user
Clear user MFA methods

Scoped role assignments also could not be granted over this user, as an associated AU did not exist to define an assignment scope.

A privileged attacker could have used this bug to prevent any Entra ID administrators from disabling an account, which would have caused a significant delay in remediating an account that was under an attacker's control.

Cleanup

It was possible to reverse the bugged user's condition by adding the user to a new restricted management AU and then deleting the AU, without first removing the user from the AU. This process allowed the restricted management state to be correctly removed from the user.

The cleanup process was replicated by following these steps:

Create a new restricted management AU.
Add the user to the new restricted management AU.
Delete the AU.
Wait five to ten minutes for the restricted management status to be removed from the user.

While this was a simple sequence of actions, it required knowledge of the exact issue. Without the cleanup process, a user affected by this bug remained in a restricted management state indefinitely.

Microsoft's response

Initial Response

Datadog reported this bug to Microsoft's MSRC on August 19, 2024. The following response was provided to Datadog by MSRC on September 10, 2024:

"First of all thanks for reporting this to Microsoft responsibly we appreciate your effort in doing so.

We examined your report and found that that this does not pose an immediate threat and is of moderate severity, hence we have shared the report with the team responsible for maintaining the product or service to review how Graph handles deactivating the restricted management state during user removal from a restricted management AU, and ensuring that state is handled the same way whether the AU still exists in the Entra tenant or not. They have reviewed for a potential fix and are taking appropriate action as needed to help keep customers protected."

Following this initial review, MSRC closed the case as Complete, and thanked Datadog for their submission.

Subsequent Response

After Datadog shared a draft of this post with MSRC for review on October 9, 2024, MSRC requested a call to reproduce the issue. Datadog and MSRC met on October 28, 2024 to discuss the issue.

The engineering team confirmed they were able to replicate this bug using proof of concept scripts. This took a few attempts, as the delay between removing a user from an AU and then deleting said AU to create a bugged user varied based on when the request was processed by Microsoft Graph.

Following this call, MSRC updated the case status to Develop, and remediated the issue on February 22, 2025. Datadog retested and was unable to replicate the bug following this fix.

Disclosure timeline

The following represents a timeline of our communications with MSRC about this bug:

August 19, 2024: Datadog reported the issue to MSRC, along with POC code to replicate the issue. MSRC responded that they had received the report.
August 21, 2024: MSRC created a case for the bug and updated the status to Review/Repro.
August 26, 2024: Datadog followed up with MSRC. MSRC responded that they were investigating the report and updated status to Planning.
September 6, 2024: Datadog followed up with MSRC.
September 10, 2024: MSRC responded that this security feature bypass "does not pose an immediate threat and is of moderate severity" and that they had shared the report with the appropriate team at Microsoft. They commented that the case was closed and updated the status to Complete.
October 9, 2024: Datadog shared a draft blog post with MSRC for review.
October 25, 2024: MSRC requested a call to review the bug with the engineering team. Datadog confirmed the call.
October 28, 2024: Datadog and MSRC discussed and replicated the bug with the engineering team.
October 30, 2024: MSRC updated case status to Develop to begin working on a solution, targeting mid-January 2025.
January 9, 2025: Datadog followed up with MSRC requesting a status update.
January 15, 2025: MSRC stated they were asking the engineering team for a new ETA.
January 21, 2025: MSRC communicated a new remediation target date of February 2025.
February 18, 2025: MSRC provided an updated target date in February 2025.
February 20, 2025: Datadog acknowledged the new remediation target date.
February 22, 2025: Microsoft remediated the issue. Datadog retested this issue, and confirmed that it was resolved.

How Datadog can help

For customers using Datadog Cloud SIEM, the following detections will detect suspicious restricted management AU activities:

These detections may indicate an attacker attempting to abuse this bug to protect accounts under their control.

Conclusion

In this post, we reviewed a bug where unexpected use of restricted administrative AUs can lead to placing a user in a restricted management state without an associated AU. This could allow a privileged attacker to prevent security teams from deactivating an account under their control until specific steps are taken to remediate the issue.

We'd like to thank MSRC for working with us on confirming this bug, remediating the issue, and helping to keep customers secure.

We're eager to hear from you! If you have any questions, thoughts, or suggestions, shoot us a message at securitylabs@datadoghq.com or open an issue. You can also subscribe to our newsletter or RSS feed.