TrustedSec security researcher nyxgeek disclosed two more Azure Entra ID sign-in log bypasses on March 19, bringing the total to four separate vulnerabilities discovered since 2024. Both new bypasses—GraphGoblin and an unnamed fourth technique—let attackers authenticate to Azure and retrieve valid tokens without appearing in sign-in logs. The pattern is the story: four completely different methods to bypass Microsoft’s foundational audit logs suggests systemic design flaws, not isolated bugs.
Enterprises rely on Azure sign-in logs as the authoritative source of truth for “who authenticated when.” These logs drive SIEM alerts, compliance audits, incident response, and forensic investigations. The bypasses break that fundamental assumption by letting attackers operate invisibly.
Four Bypasses, Three Years, One Systemic Flaw
Between 2024 and 2026, security researchers discovered four distinct methods to bypass Azure Entra ID sign-in logging. The latest two both exploited database column overflow vulnerabilities—GraphGoblin repeated the same OAuth parameter (“openid”) 35,000 times in a single request, while the fourth bypass used a 50,000-character user-agent string. Both triggered the same result: the logging system silently dropped the audit entry while authentication succeeded and tokens were issued.
The exploits are ridiculously simple—just standard HTTP requests with oversized parameters. GraphGoblin’s proof-of-concept demonstrates the technique:
# Bypass authentication (NOT logged)
curl -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
--data-urlencode "scope=$(for num in {1..10000}; do echo -n 'openid ';done)"
# Result: Token issued + Log entry SILENTLY DROPPEDThis isn’t one overlooked bug—it’s a pattern revealing architectural flaws in how Azure’s authentication and logging systems interact. If researchers found four different methods, how many more exist? The simplicity of the techniques (parameter repetition, long strings) suggests Microsoft hasn’t implemented basic input validation on critical security infrastructure.
Microsoft Says “Not Important” – Researchers Disagree
Microsoft declined to classify these bypasses as “Important” severity, despite researcher CVSS assessments of 7.5 (v3.1) to 8.7 (v4.0). The researcher cited “complete loss of protection” for critical logging infrastructure affecting integrity. Microsoft silently fixed the fourth bypass before nyxgeek could even write a formal disclosure report—discovered September 28, 2025, patched by October 8.
This echoes the September 2025 CVE-2025-55241 “Actor Token” vulnerability (CVSS 10.0) that bypassed all logging while allowing Global Admin impersonation across tenants. There’s a dangerous disconnect: vendors view logging bypasses as infrastructure bugs, while enterprises rely on these logs as foundational security controls. If your SIEM can’t see authentication attempts, you’re flying blind—that deserves Critical severity, not a shrug.
Enterprises can’t trust vendor severity ratings alone when assessing risk. Microsoft’s classification doesn’t reflect the real-world impact on security teams who depend on these logs to detect intrusions.
The Forensic Nightmare: No Logs = No Investigation
Organizations cannot retroactively detect exploitation between September 2025 and March 2026 because the logs simply don’t exist. Any breach using these techniques may remain undetected indefinitely. Azure sign-in logs only retain 30 days by default—attackers who exploited these vulnerabilities and waited 31 days to escalate privileges left no audit trail for forensic investigation.
Even organizations with E5 licenses and Log Analytics can only attempt forward-looking detection by comparing Graph Activity logs to sign-in logs using anti-join KQL queries. This doesn’t work for historical exploitation—the security incident response playbook assumes you can forensically investigate by reviewing logs. These bypasses break that assumption entirely.
This fundamentally undermines compliance requirements for audit integrity. SOC 2, HIPAA, and PCI-DSS all mandate authentication audit trails. If the logs don’t exist, compliance frameworks built on audit integrity collapse.
Don’t Trust Azure Logs Alone: Layered Defenses
Security teams can’t rely solely on Azure sign-in logs as the authoritative source of truth. Layered defenses are essential: network-level logging independent of Azure, Graph Activity log monitoring, conditional access policies, and Zero Trust architecture that doesn’t assume authentication visibility.
For organizations with E5 licenses, run KQL anti-join queries comparing Graph Activity logs (which logged the successful API calls) against sign-in logs to identify authentication sessions with no corresponding log entry. This won’t prevent exploitation but can help identify gaps going forward.
The shift is from blind trust in Azure logging to defense-in-depth. Add compensating controls: network firewalls that log authentication requests independent of Azure, SIEM correlation across multiple log sources, and MFA enforcement that reduces impact even when initial authentication is invisible. Microsoft’s fixes address specific bypass techniques without solving the root cause—assume more bypasses exist and plan accordingly.
Key Takeaways
- Four distinct Azure sign-in log bypass methods discovered since 2024 reveal systemic flaws in Microsoft’s logging architecture, not isolated bugs.
- Microsoft’s severity ratings don’t reflect enterprise impact—vendors minimize security issues while security teams are left flying blind without audit visibility.
- No way to detect historical exploitation exists because the logs were never created—audit trails for September 2025 to March 2026 may have permanent gaps.
- Don’t rely solely on Azure sign-in logs for security monitoring—add network-level logging, Graph Activity monitoring, and conditional access as layered defenses.
- Assume additional bypasses exist and plan for authentication visibility gaps in your threat model and incident response procedures.
