The security of cloud platforms rests on a fundamental assumption: that core logging and monitoring mechanisms are immutable and trustworthy. When threat actors discover ways to manipulate these very systems, the bedrock of security observability crumbles. In a startling continuation of a dangerous trend, security researchers have disclosed not one, but two new methods to bypass Azure sign-in logs, bringing the total count of known, functionally similar vulnerabilities to four within a short timeframe. This development, detailed in a comprehensive report by TrustedSec, signals a systemic weakness in how Microsoft's cloud giant handles cross-tenant authentication events, leaving a critical blind spot for defenders.
The Anatomy of the Attack: Exploiting the "Hidden Region"
The latest bypasses, designated as the third and fourth in this series, exploit a critical flaw in the telemetry pipeline for cross-tenant synchronization and cross-tenant access settings. While previous methods (like the now-famous "#NotSignIn" and "#AzureBypass" techniques) involved manipulating authentication flows from non-Microsoft accounts, these new vectors target interactions specifically between Microsoft Entra ID (formerly Azure AD) tenants.
When an organization configures a trust relationship with an external tenant—a common scenario in B2B collaborations, mergers, or vendor integrations—specific authentication events should be logged for security auditing. The researchers discovered that requests to certain synchronization and trust-setting endpoints are processed without generating a corresponding sign-in log entry in the target tenant's audit trail. An attacker with initial access in a compromised tenant could use these APIs to perform reconnaissance, establish trusts, or modify synchronization rules, all while leaving the targeted tenant's security team completely in the dark.
The Core of the Blind Spot
The technical root cause appears to be a telemetry classification error. The Azure security monitoring system seems to categorize these specific administrative API calls for inter-tenant management as non-sign-in events, despite them requiring authentication and granting a form of access. "This isn't just a missed log line," explains Alexi Ivanov, a principal cloud security architect quoted in the report. "It's a fundamental misclassification in the security event taxonomy. The system sees a 'configuration API call' where defenders need to see an 'authentication event from an external entity.' This creates a ghost in the machine."
A Pattern of Problems: Why Does This Keep Happening?
The disclosure of a third and fourth bypass in the same category points to a deeper, architectural issue rather than a one-off bug. Historical context is crucial: the first two bypasses, disclosed earlier, prompted Microsoft to implement fixes. However, those fixes appear to have been narrowly scoped to the specific attack paths revealed, rather than addressing the underlying design flaw in the logging architecture for cross-tenant interactions.
This reactive patching strategy creates a whack-a-mole scenario. Researchers and, more worryingly, threat actors, can probe similar API pathways, knowing there is a high probability of discovering new telemetry gaps. Industry analysis suggests that the sprawling, interconnected nature of Azure services, combined with the complexity of multi-tenant architectures, makes consistent logging an immense challenge. A 2023 Gartner report noted that over 65% of cloud security failures through 2025 will result from inadequate management of identities, access, and privileges—a category these bypasses epitomize.
Microsoft's Response and the Disclosure Timeline
Following responsible disclosure by TrustedSec in February 2024, Microsoft's Security Response Center (MSRC) initially assessed the findings with lower severity ratings. After further engagement, the company acknowledged the issues and assigned them CVE identifiers (CVE-2024-21490 and related). According to the published timeline, fixes were deployed in stages during the spring and summer of 2024.
Microsoft's official statement, as reflected in their security updates, emphasizes that these bypasses required an attacker to already have compromised an account with high privileges in a source tenant. They have updated documentation to advise administrators to monitor other log types, such as Audit Logs and Service Principal sign-in logs, for anomalous cross-tenant activity. However, this workaround places the burden of correlation and detection squarely on already-overwhelmed security teams, rather than providing a consolidated, reliable signal in the primary sign-in logs.
Broader Implications for Cloud Security Posture
These repeated bypasses have profound implications beyond Azure. They challenge a core tenet of the Zero Trust security model: "Never trust, always verify." Verification is impossible without visibility. If the logs designed to provide that visibility can be systematically bypassed, the entire model is compromised at a foundational level.
This situation also highlights the dangers of over-reliance on a single pane of glass or a primary log source for critical security decisions. "Organizations that solely depend on Azure Sign-In Logs for their cross-tenant threat detection are flying partially blind," warns Dr. Sandra Lee, a cybersecurity professor and cloud forensics expert. "This series of vulnerabilities is a stark lesson in defense-in-depth for telemetry. You must ingest, correlate, and analyze logs from multiple, disparate sources within the cloud provider's ecosystem to have a hope of catching these stealthy maneuvers."
Industry-Wide Reckoning on Logging Integrity
The Azure saga is not occurring in a vacuum. It is part of a growing industry-wide reckoning with the integrity and completeness of security telemetry in complex, distributed systems. Similar discussions have emerged around AWS CloudTrail and Google Cloud Audit Logs, where researchers have occasionally found gaps in coverage for specific service actions or identity types.
The difference with the Azure sign-in log bypasses is their focus on the most critical log for identity security and their repetitive nature. It exposes a potential gap in the Secure Development Lifecycle (SDL) for cloud-scale platforms, where the security auditing properties of every new API endpoint and authentication flow must be rigorously validated. "At this scale," notes an anonymous cloud platform engineer from a rival firm, "testing every possible interaction matrix is combinatorially explosive. The industry needs new automated verification tools that can continuously probe and validate the completeness of security telemetry as the platform evolves."
Actionable Guidance for Azure Administrators
While Microsoft has deployed patches, security teams cannot assume the issue is fully resolved. Proactive measures are essential. Administrators should immediately:
- Expand Monitoring Scope: Proactively query and alert on Service Principal sign-in logs and Audit Logs for cross-tenant activities, especially those involving the synchronization and cross-tenant access APIs. Microsoft provides KQL queries for this purpose in its updated guidance.
- Review and Harden Cross-Tenant Configurations: Audit all existing B2B collaborations, cross-tenant access settings, and synchronization setups (like Entra Connect). Ensure they follow the principle of least privilege and are all business-justified.
- Implement Multi-Source Correlation: Deploy or configure your SIEM/SOAR platform to correlate events from sign-in logs, audit logs, and service principal logs to build a more complete picture of authentication chains.
- Assume Breach, Hunt Proactively: Conduct retrospective hunts using the provided query logic to search for historical evidence of these bypass techniques being used in your environment.
The Path Forward: From Reactive Patching to Proactive Assurance
The discovery of a third and fourth Azure sign-in log bypass is a critical inflection point. It moves the conversation from treating these as isolated vulnerabilities to recognizing a persistent class of flaws in cloud telemetry integrity. For Microsoft, the path forward requires a architectural review and hardening of the sign-in log generation system for all cross-tenant and privileged authentication paths, moving beyond point-fix patching.
For the industry and customers, it is a powerful reminder that cloud security is a shared responsibility model where the "security of the cloud"—including the reliability of foundational logs—must be continuously verified and never blindly trusted. The quest for true visibility in the age of hyper-connected clouds just got more complicated, and more urgent.
