If you’ve ever seen a zombie movie, you know how it starts—something goes wrong, Patient Zero gets infected, and at first, they feel fine. Then they get sick, die, and before anyone realizes, the infection spreads like wildfire. But that won’t happen in real life… or will it? What if someone told you the same concept can apply to IT security?
With organizations increasingly relying on third-party solutions, a single misconfiguration or miss click can compromise an entire IT system. Entra ID (formerly Azure AD) is one such critical solution. When an attacker sneaks in a malicious application, the result can be just as catastrophic as a zombie outbreak.
For this attack scenario, we can assume that the attacker has access to an account. However, even without initial access, a well-crafted phishing attack could achieve the same outcome.
Step 1: Plating the malicious application
To begin with, an attacker needs one of the following:
- An account that already owns an app.
- An account that has permission to create apps.
Note: It may also be possible to exploit an app simply by obtaining its client ID and secret, though initial research suggests that control over the redirect URL is necessary.
Once a user installs the malicious app, a service principal (essentially an account for the app) is created in the tenant. This is why an attacker needs either ownership of an app or the ability to create one. The owner of an app can always access the service principal for their app.
This persistence mechanism is a dream for attackers: as long as someone in the domain installs their app, they gain access via the service principal, maintaining a foothold in the environment.
Step 2: Gaining Permissions
Understanding OAuth in Entra ID
Entra ID leverages OAuth for authorization and OpenID Connect for authentication. If you’re unfamiliar with these concepts, this video from OktaDev is a great primer.
In Entra ID, there are two primary types of permissions:
1. Application Permissions
These are granted to the service principal (the app’s account), not a specific user. For example, an app with Files.Read.All permission can access all users’ files within the organization.
2. Delegated Permissions (The Real Danger)
This is where things get interesting for an attacker. Delegated permissions allow an app to act on behalf of a user.
For example, if an app like “LunchBuddy” wants to scan emails for lunch plans, it might request the “Mail.Read” permission. When the user consents, an access token is issued to the app’s service principal, an access token is a JWT, that handles authentication and authorization, imitating the user it was created for. The service principal presents its access token to the mail API and is granted access to read emails as the user.
Now a question for you: what if it wasn’t just reading a user’s email, but also sending them with mail.send? The service principal could read and send emails, impersonating the user. This enables easy phishing attacks, turning more and higher-privileged accounts into zombies.
Because of the way Oauth works in EntraID, attackers can create consent links that request permissions beyond what a user can approve without erroring, this does not mean that the attackers automatically gain a higher access level, as they are only copying the permissions the infected user has. However, it does make it possible to create a link that requests a lot of permissions at once and send it out to as many people as possible, and if an administrator is affected, the attackers can gain access to permissions such as “RoleManagement.ReadWrite.Directory” and start changing user roles.
The Stealthy Nature of Delegated Permissions
Since delegated permissions allow an app to act as the user, logs will show legitimate user activity.
- At 08:05, User1 “checked their email.”
- But in reality, the service principal did it.
Much like a virus, the infection spreads, and the host is taken over. But unlike normal zombies these don’t appear any different, they work, talk and do everything a normal account would. All while unaware that they are spreading the attack.
Step 3: Exploiting OAuth to spread the infection
To demonstrate how this attack unfolds, a Windows VM running Ngrok, has been set up to simulate the entire flow.
Attack Flow:
Attacker sends a malicious link to the target (fake tenant & client ID):
Breaking down the attack URL:
Clicking the link.
When the target clicks the link, they be asked to grant permission listen in the scope of the URL. If they click accept, they are then sent to the ‘redirect_uri’ in the link.
The Redirect URI
The callback link in this case was the Ngrok server which has a listener waiting to capture the authorization code.
The attacker exchanges the auth code for access & refresh tokens
A script has been created for automating the process by doing the following:
- Extracts the auth code from the URL.
- Generates both tokens.
- Redirects the user back to Microsoft.
The script can be seen underneath:
By executing the code, it has succeeded in returning the infected user.
Conclusion: Defending Against the Undead
This attack highlights a serious security gap in Entra ID—one that organizations must proactively defend against. The key takeaways:
- Beware of OAuth Consent Prompts: Users should never blindly accept permission requests, especially those asking for admin-level access.
- Monitor App Registrations & Service Principals: Regularly audit new applications and track permissions granted within the tenant.
- Limit Who Can Create Applications: Restrict app registration privileges to a small, trusted group.
- Enable Conditional Access Policies: Require MFA and restrict access based on device compliance.
- Review Delegated Permission Usage: Track what apps are doing on behalf of users and investigate suspicious activity.
While this attack requires either stolen credentials or social engineering, the potential for damage is immense. Just like in a zombie outbreak, one bad decision can spread chaos, making prevention the best cure.
Recent Comments