I’m a contributor to the Centre for Internet Security Benchmark for Windows 365 Fundamentals, where a global team of security pros and I are hashing out the best hardening advice for the next version of the benchmark. During this process, a community ticket came across our desk that I had to write about. It highlighted a seemingly benign default setting in Entra ID—specifically, the one that allows “Users can create security groups in Azure portals, API or PowerShell”—that is, in reality, an open invitation for a tenant takeover.
This isn’t a new idea. The CIS Azure Foundations Benchmark (see control 6.19) has recommended this for years. But the question made me realise that this default setting is one of the most overlooked and misunderstood risks in Entra ID. It’s an incredibly easy fix that closes the door on a surprisingly effective attack path.
Let’s walk through how a feature that sounds like harmless self-service can be weaponised.
The Anatomy of an Attack
The risk here isn’t that a user can create a group and magically grant themselves Global Admin. The attack is more subtle. It’s a social engineering exploit that exploits the logical separation between the individuals who manage identity (group owners) and those who manage security policy (administrators).
Here’s the playbook:
The Setup: A Well-Meaning Admin & a Powerful Policy. A security admin creates a critical Conditional Access (CA) policy. Let’s say it’s a policy to Block Legacy Authentication for
All Users. This is a fantastic security move. But, to accommodate a legacy application, the admin adds an exclusion for a security group namedCorp-Legacy-Auth-Exceptions. Any member of this group bypasses the policy.The Attacker’s Move: The Trojan Horse Group. An attacker—either a malicious insider or someone who has compromised a standard user account—creates a new security group. Because the default setting allows it, this action requires no approval and raises no alarms. They give it a plausible name, like
Project-Phoenix-API-Testers. As the creator, they are the sole Owner and have complete control over its membership.The Deception: A Plausible Request. The attacker now contacts the IT help desk. They submit a ticket that reads something like this:
“Hi, our new ‘Project Phoenix’ needs to test an integration with an older API. Can you please add our security group,
Project-Phoenix-API-Testers, to the legacy auth exclusion policy for a few weeks? Thanks.”
The Mistake: Trust Without Verification. A busy administrator sees the request. The project name sounds legitimate, the request seems temporary, and the group appears to exist. Without checking who owns the group or how it’s governed, the admin adds the attacker’s group to the CA policy’s exclusion list.
The Payoff: The Back Door is Open. The game is over. The attacker now has a persistent backdoor into your tenant. They control a group that is exempt from a critical security control. They can add their own account or any other account they compromise in the future to this group at will. They can now use legacy protocols to bypass MFA, move laterally, and access sensitive data, all while appearing to be a legitimate exception.
An Easy Fix for a Big Problem
What’s so powerful about this attack is that every individual step is a legitimate action. No malware, no zero-days. It’s a process failure, enabled by a default setting that is far too permissive.
Turning off this setting directly breaks the attack chain. The attacker can no longer perform step two. They can’t create the Trojan horse group in the first place. Any request for a new group has to go through an official channel, where it will (hopefully) be created by an administrator who understands its purpose and assigns a trusted owner.
Here’s how you fix it:
Navigate to the Microsoft Entra admin centre.
Go to Groups → Settings.
Under the Security Groups section, find the toggle for “Users can create security groups in Azure portals, API or PowerShell”.
Set it to No.
Click Save.
That’s it. You’ve just closed a significant and unnecessary risk in your tenant.
Yes, this removes some self-service convenience. You will need a process for users to request groups. But that’s a small price to pay for eliminating a direct path to policy bypass. In security, the best fixes are often the simplest ones. This is one of them. Check your settings today.
Disclaimer: The recommendation in this post is my own opinion and does not represent the official position of the Centre for Internet Security (CIS). While this control is being discussed, the CIS team has not yet decided to include it in the Windows 365 Fundamentals benchmark. If and when it is added, I will update this post with the official control number.