Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

Table of contents

Invisible password sprays. Invisible logins. Full tokens returned.

Nyxgeek here. It's 2026 and I've got two more Azure Entra ID sign-in log bypasses to share with you. Don't get too excited…these bypasses were recently fixed, but I think it's important that people know.

By sending a specially crafted login attempt to the Azure authentication endpoint, it was possible to retrieve valid tokens without the activity appearing in the Entra ID sign-in logs. This is critical logging…logging that administrators across the world rely on to detect intrusions…logging that could be made optional.

Today I will walk you through the third and fourth Azure sign-in log bypasses that I have found in the last three years. I will also look at how sign-in log bypasses can be detected using KQL queries. By knowing about Microsoft's past mistakes, we can try to prepare for their future failures.

Background

Since 2023, I've uncovered four Azure Entra ID sign-in log bypasses. This means I've found four completely different ways to validate an Azure account's password without it showing up in the Azure Entra ID sign-in logs. While the first two of these merely confirmed whether a password was valid without generating a log, my latest logging bypasses returned fully functioning tokens.

Previously, I had written about ** GraphNinja** and GraphGhost -- two logging bypasses where a user could identify valid passwords without generating any 'successful' events in the sign-in logs. Neither were overly complicated.

| Name | Date | Description | |---|---|---| | GraphNinja | 08/2023 | Validate password without creating a log by specifying a foreign tenant ID as endpoint | | GraphGhost | 12/2024 | Validate password without creating a successful login event by supplying an invalid value for specific logon parameters, causing overall auth flow to fail after performing credential validation |

In each of these, the logging being bypassed is for the Azure Entra ID sign-in logs. Logon method is via an HTTP POST to the Entra ID token endpoint, login.microsoftonline.com, using the OAuth2 ROPC flow, with the Graph API as our intended resource/scope. We submit a username and password, an Application ID, and a target resource/scope, and we'll get a bearer token or refresh token for the Graph API in return.

An example curl command performing a "normal" authentication can be seen below:

curl -X POST "https://login.microsoftonline.com/00000000-1234-1234-1234-000000000000/oauth2/v2.0/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
--data-urlencode "client_info=1" \
--data-urlencode "grant_type=password" \
--data-urlencode "[email protected]" \
--data-urlencode "password=secretpassword123" \
--data-urlencode "scope=https://graph.microsoft.com/.default"

When a valid username and password are supplied, a token is returned that can be used to access the Graph API.

GraphNinja Recap

In the GraphNinja bypass, it was only necessary to target another tenant with the authentication attempt. The authentication response would still indicate if a valid password was found, but the login would fail because it was performed against a foreign tenant where the user didn't exist. No logs were generated on the foreign tenant because only logs for valid users within that tenant are generated.

GraphGhost Recap

With the GraphGhost bypass, providing an invalid Client ID value would cause the overall authentication flow to fail, but not until after credential validation had occurred. This would show to administrators as a failed login, with no indication in logs that the password had been successfully guessed.

Enter GraphGoblin and Graph******

GraphGoblin Bypass

Let's start with what I'm terming GraphGoblin. I stumbled across this bypass while poking at the parameters in the Microsoft authentication POST. Testing the scope parameter, I first tried some simple things like supplying invalid scope values. However, I found that the scope value would be rejected if it wasn't a valid scope name, or didn't match an expected format.

Invalid scopes returned an error: AADSTS70011: The provided request must include a 'scope' input parameter...

But what if the string we submitted WAS valid, but repeating? For instance, instead of specifying a value like openid as the scope, what if we submitted a bunch of the same value, like openid openid openid?

It got through! I checked the Azure Entra ID sign-in logs, and found NO NEW SIGN-INS! It was a solid bypass.

To show how dead-simple this is, a demonstration of this bypass using curl and Bash expansion can be found below:

export TENANT_ID="[tenant-guid-goes-here]"
curl -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
--data-urlencode "client_info=1" \
--data-urlencode "grant_type=password" \
--data-urlencode "[email protected]" \
--data-urlencode "password=secretpassword123" \
--data-urlencode "scope=$(for num in {1..10000}; do echo -n 'openid ';done)"

Why it Worked (Maybe)

There is no way of knowing 100% why this worked without Microsoft publishing information, but I can take a guess. I believe this was a simple matter of overflowing the SQL column length for a field, causing the entire INSERT to fail. It's likely that the parser iterated over the list of scopes included, did not find any invalid ones, but the final logging step failed due to the string length.