Exploit MFA Enablement Gaps for Resource Access

What this lab covers

You determine which identities and access paths in a tenant are not protected by multi-factor authentication, use one of those gaps to gain access, then move from a compromised web application to a managed identity and onward.

The lab reflects a common reality. Organizations report high MFA enrollment and still have accessible paths without it, because enrollment and enforcement are different things and exclusions accumulate.

It is rated intermediate and suits identity administrators particularly. If you own conditional access, this is a direct test of whether your policy set does what you believe.

How MFA enablement gaps arise

Conditional access evaluates policies with conditions covering users, applications, platforms, locations and client apps. Coverage is the union of what those policies match, and anything outside every policy's conditions is unprotected regardless of how many policies exist.

Gaps come from ordinary operational decisions. Break-glass accounts are excluded deliberately. Service accounts are excluded because they cannot complete a challenge. A vendor is excluded temporarily during an integration. Legacy authentication protocols that do not support a second factor may remain enabled for one application. Each exclusion is defensible and their union is the attack surface.

Finding the gaps is systematic rather than clever. An attacker tests which identities and endpoints accept authentication without a challenge, which is why tooling exists to enumerate this and why the exercise is equally available to defenders.

How to detect this in your own environment

Query sign-in logs for successful authentications where multi-factor authentication was not satisfied, and review every result. In a well-configured tenant this list should be short and explainable, and it is usually neither.

Alert on conditional access policy modification, particularly the addition of exclusions. Exclusions added during an incident or by an attacker who has gained administrative access are a persistence mechanism.

Monitor authentication using legacy protocols specifically. These cannot enforce a second factor, so their continued use is both a gap and a strong indicator when it appears from an unexpected identity.

How to prevent it

Validate coverage by querying results rather than reviewing policy. The question is not whether policies exist but whether any successful sign-in bypassed them, and the sign-in log answers that directly.

Block legacy authentication outright. It cannot support modern authentication controls, and where an application still requires it, that application is the exception to manage rather than a reason to leave the protocol open tenant-wide.

Review exclusions on a schedule with an owner and an expiry for each. Temporary exclusions become permanent silently, and a list of exclusions nobody has revisited is where this attack begins.

Real-world context

Attackers routinely target the accounts that fall outside policy rather than attempting to defeat multi-factor authentication, because it is far cheaper. Incident reporting consistently identifies unprotected service accounts and legacy protocol access as initial entry points in cloud intrusions.

The measurement problem is what makes this persist. Organizations track enrollment percentage, which counts identities that have registered a method, while the security property that matters is whether any authentication path succeeds without one.

The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts, T1556 Modify Authentication Process and T1110 Brute Force.

Applying this at work

• Query the last ninety days of sign-ins for successful authentications without multi-factor authentication, and account for every one.
• List every conditional access exclusion, assign an owner and an expiry date to each, and remove those nobody can justify.
• Block legacy authentication protocols tenant-wide, handling the exceptions individually.
• Confirm service accounts and break-glass accounts are protected by compensating controls such as network restrictions and tight monitoring.
• Alert on conditional access policy changes, especially added exclusions.

Frequently asked questions

If most of my users have MFA enrolled, am I protected?

Not necessarily. Enrollment means a method is registered, while protection depends on whether every authentication path enforces it. An attacker needs one identity, application or protocol outside your policy conditions.

Where do MFA gaps usually come from?

Deliberate exclusions for break-glass and service accounts, temporary exclusions for vendors that were never removed, and legacy authentication protocols that cannot support a second factor.

How do I check my actual coverage?

Query sign-in logs for successful authentications where MFA was not satisfied. That measures the effective outcome, whereas reviewing policies only tells you what you intended.

Do I need my own Azure account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.