Azure Sign-In Log Bypasses: When 'Check the Logs' Isn't Enough

This post covers a series of now-patched vulnerabilities in Azure Entra ID sign-in logging disclosed by TrustedSec researcher Nyxgeek. All four bypasses are fixed. The disclosure matters for understanding historical log gaps and future detection posture.

What’s New This Week

TrustedSec published the third and fourth Azure Entra ID sign-in log bypasses this week – named GraphGoblin and Graph****** by researcher Nyxgeek. Unlike the two previous bypasses (GraphNinja, GraphGhost), these returned fully functioning bearer tokens without any log entry. Microsoft has fixed both but declined to classify them as ‘Important’ severity, and issued no public acknowledgement.

Changelog

This week TrustedSec’s Nyxgeek published the third and fourth Azure Entra ID sign-in log bypasses they’ve discovered since 2023. The previous two – GraphNinja and GraphGhost – let an attacker confirm whether a password was valid without a successful login event appearing in the audit logs. Useful for credential stuffing. Damaging, but limited.

The new ones are a different category of problem. GraphGoblin and Graph****** didn’t just validate passwords silently. They returned fully functioning bearer tokens. An attacker using these techniques could authenticate to your Azure tenant, access the Graph API, and operate as a legitimate session – without a single entry appearing in the sign-in logs that your SIEM is watching.

All four are patched. But the window between discovery and fix ranged from weeks to seven months. And the logs from that period are gone.

The Four Bypasses

Here’s the complete timeline:

GraphNinja (reported August 2023, fixed May 2024): Authentication via the ROPC flow against a foreign tenant ID – a tenant the user doesn’t belong to. The response still indicated whether the password was valid, but no log was generated in the user’s home tenant (no valid user there to log) or the foreign tenant (no valid user there either). No token was returned, but the password oracle worked cleanly.

GraphGhost (reported December 2024, fixed April 2025): Supplying an invalid Client ID value caused the authentication flow to fail after credential validation had already occurred. The sign-in logs recorded a failed login with no indication that the password itself had been successfully verified. Again, no token – but the credential check was invisible.

GraphGoblin (discovered September 2025, fixed November 2025): Repeating a valid scope value tens of thousands of times in the OAuth2 token request – openid openid openid... – caused the request to succeed but the log to be dropped. Nyxgeek’s hypothesis: the repeated scope string overflowed a SQL column length limit, causing the INSERT to fail silently. The token was issued. The log was not.

Graph****** (discovered September 2025, fixed October 2025 – before it was even reported): Setting the user-agent string to 50,000 characters had the same effect. Microsoft fixed this one independently before Nyxgeek could submit a report, apparently without noticing the related GraphGoblin issue that was still open.

A single bypass is a bug. Four different bypass mechanisms across four different request parameters – scope, client ID, tenant routing, user-agent – over three years, all in the same critical log path, is something else. It’s a signal that the logging pipeline has not been treated with the same rigour as the authentication pipeline it’s supposed to observe.

Why the ROPC Flow Matters

Every one of these bypasses uses the OAuth2 Resource Owner Password Credentials (ROPC) flow – the authentication pattern where a client application sends username and password directly to the token endpoint rather than redirecting through a browser-based login page. Microsoft deprecated ROPC in 2019 and recommends against it for new integrations. It remains supported for legacy compatibility.

If your organisation has disabled legacy authentication flows and doesn’t rely on ROPC, your exposure from these specific bypasses is materially lower. The attack requires a valid username and password delivered via a specific API flow. If that flow is blocked at the tenant level, the bypass can’t run.

Conditional access policies that block legacy authentication are worth auditing now if you haven’t already. This isn’t a new recommendation – Microsoft has been pushing it for years – but four sign-in log bypasses all routed through ROPC is as concrete an argument as you’ll find.

From Password Validation to Full Token Exfiltration

The distinction between the first two bypasses and the last two matters operationally.

GraphNinja and GraphGhost confirmed passwords without logging the attempt. An attacker running credential stuffing against a list of usernames and a leaked password database could silently validate which passwords were current. Damaging for exposure assessment; but the attacker still doesn’t have an authenticated session.

GraphGoblin and Graph****** changed that. The token endpoint returned a bearer token – a functioning OAuth2 credential that could be used to call the Graph API, access SharePoint, query directory information, or pivot to other services. An attacker using these bypasses didn’t just know whether the password was right. They had an active, authenticated session with no log entry attached.

That’s the threat model that matters for credential chain attacks: an authenticated session obtained silently, operating under a legitimate user identity, with no audit trail connecting the initial token issuance to subsequent activity.

What the Detection Gap Means for Historical Logs

All four bypasses are now fixed. But ‘fixed now’ doesn’t mean ‘clean retrospectively.’ The relevant question for most security teams isn’t whether the bypasses can be exploited today – they can’t – it’s whether they were exploited between initial availability and the patch.

GraphNinja’s window: August 2023 to May 2024. Nine months. GraphGhost’s window: December 2024 to April 2025. Four months. GraphGoblin’s window: Unknown start date to November 2025. At minimum, the period between initial discovery (September 2025) and fix. Potentially much longer if the vulnerability was introduced with a code change well before Nyxgeek found it. Graph******: Fixed independently by Microsoft, window unknown.

None of these bypasses were publicly acknowledged. No CVEs. No security advisories. Organisations watching for CVE notifications or Microsoft security announcements would not have known to look. Microsoft’s position – that these are ‘Moderate’ severity and don’t warrant public acknowledgement – means the burden of understanding the gap falls entirely on defenders.

If you’re running incident response or historical forensic review on an Azure tenant, you now have four specific time windows where the sign-in logs cannot be treated as complete.

This connects to a broader problem that isn’t unique to Azure. CISA advisories on Microsoft environments frequently surface detection gaps created by incomplete logging. The assumption that audit logs are comprehensive is an assumption that keeps failing. The documentation gaps in Microsoft’s security architecture compound it: if the logging behaviour isn’t clearly specified, defenders don’t know what they’re not seeing.

The KQL Opportunity

The bypass hides the sign-in event – it doesn’t hide the activity that follows from the token. This is where detection remains possible.

The Graph Activity logs (available with an E5 licence, via a Log Analytics workspace) record API calls made with a Graph token. Each entry includes a SignInActivityId that maps to the UniqueTokenIdentifier in sign-in logs. Under normal conditions, every Graph API call should have a corresponding sign-in event. Any Graph activity without a matching sign-in is either a service principal, a managed identity, a noninteractive login – or it’s something that bypassed the sign-in log.

Fabian Bader has published a KQL approach that accounts for the full range of sign-in sources. Nyxgeek’s disclosure builds on it:

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
    SigninLogs,
    AADNonInteractiveUserSignInLogs,
    AADServicePrincipalSignInLogs,
    AADManagedIdentitySignInLogs,
    MicrosoftServicePrincipalSignInLogs
    | where TimeGenerated > ago(90d)
    | summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
    )
    on $left.SignInActivityId == $right.UniqueTokenIdentifier

This query finds Graph API activity with no corresponding sign-in event. After tuning out expected service accounts and managed identities, what remains is suspicious.

The catch: this requires E5 licensing. Without it, you don’t have access to the Graph Activity logs, and this detection path doesn’t exist. Organisations running on lower licence tiers have fewer options here. The cloud infrastructure threat surface that Azure presents is directly connected to the licence tier you can afford to run security tooling against.

What to Do Right Now

Audit legacy authentication. Check whether ROPC and basic authentication flows are enabled in your tenant. In Azure AD Conditional Access, block legacy authentication protocols if they’re not actively required. This removes the attack surface for all four bypass mechanisms.

Implement the KQL detection. If you have E5 and are running Sentinel or a Log Analytics workspace with Graph Activity logs enabled, implement Bader’s query and create an alert rule. Tune for your environment’s service principal baseline.

Review historical log coverage. For the bypass windows above, consider whether there’s other evidence you can cross-reference: network flow logs, endpoint activity, OAuth token grants visible in other audit tables. Sign-in logs weren’t the only thing recording activity in those periods.

Check your licence tier. If you’re running E3 and relying on sign-in logs as a primary detection mechanism, you’re operating with an incomplete picture. The Graph Activity logs – which enable the detection approach above – require E5. This is a planning input, not a quick fix.

Consider supplementary sources. Any detection that depends entirely on Entra ID sign-in logs has a single point of failure. Network proxy logs, endpoint authentication events, DNS-based identity signals, and OAuth token audit trails from non-Microsoft tooling are all sources that don’t share the same bypass conditions.

The Broader Point

Four bypasses in three years. None of them complicated – Nyxgeek describes them as the result of simple fuzzing. The authentication pipeline is tested extensively. The logging pipeline that observes it, apparently less so.

Microsoft’s response – classifying these as ‘Moderate’, issuing no public advisories, denying bounties on the two most serious bypasses – tells you something about how the organisation prioritises defender awareness versus internal clean-up. The bypasses were fixed quickly once reported. The ecosystem of security teams who relied on those logs during the gap period was given no information.

“Check the logs” assumes the logs are complete. The Azure Entra ID sign-in logs have had four known conditions where they were not. There will likely be more.

The right posture isn’t to distrust the logs – they’re still essential – it’s to stop treating any single log source as ground truth. Overlapping detection, multiple telemetry sources, and the habit of asking “what wouldn’t appear in the logs if this attack succeeded” are the only approaches that hold up when the logs themselves have bypass conditions.

The attacker doesn’t have to be clever. Sometimes, they just need a 50,000-character user-agent string.