Wiz CTF #3: Breaking The Barriers

No flags are included in this writeup.

Overview

Breaking The Barriers moved the championship into Azure and OAuth. The scenario started with credentials for an application that already had access inside a victim tenant. The solve was not about stealing a user password. It was about understanding what the app had already been allowed to do.

Reading The App’s Power

The first step was authenticating as the service principal and inspecting its token claims. The important permissions were directory-level capabilities rather than subscription-level cloud resource access.

The useful combination was:

• read enough directory/group information to understand access rules
• invite users into the tenant
• use dynamic membership behavior to make a newly invited identity qualify for access

This is exactly where OAuth apps become dangerous. A consented app can look harmless if nobody thinks through how its permissions compose.

Directory Enumeration

With the app identity authenticated, I focused on the tenant structure:

• groups
• app role assignments
• dynamic membership rules
• guest invitation behavior
• resources exposed through user-facing app portals

The key was not just “find the flag app.” The key was identifying the access condition that would allow a user to reach it.

Dynamic groups are powerful, but they can also become an attack surface. If membership rules rely on attributes that an attacker can influence through invitation or profile creation, the rule becomes a privilege escalation path.

Guest User Pivot

The main move was to use the application’s invitation capability to create a guest user that satisfied the dynamic group conditions. After redemption/authentication as that guest, the access model changed. The user was no longer just an outside account; it became a tenant identity with membership-derived reach.

From there, the remaining work was normal cloud enumeration:

1. authenticate as the guest user
2. inspect available applications/resources
3. identify the storage-backed target
4. access the object through the allowed identity path

Root Cause

The issue was not a single Azure bug. It was authorization design:

• OAuth app permissions were too broad for the trust placed in the app
• guest invitation capability created new identities inside the tenant
• dynamic group membership rules trusted attributes that could be shaped by the attacker
• downstream storage access trusted group membership

This is a very cloud-realistic pattern: identity is the perimeter, and small permission combinations can become an attack path.

Takeaways

For Azure/Entra ID environments, this challenge reinforced a few checks I want to keep in my own methodology:

• audit consented applications, not just human users
• review User.Invite.All and similar permissions carefully
• threat model dynamic group rules as executable authorization logic
• monitor guest user creation and group membership changes
• treat app role assignments and MyApps visibility as useful recon data

Breaking The Barriers was not the highest point challenge, but it was one of the clearest identity-security lessons in the early set.