Cybersecurity professionals live by a simple axiom: Logs don't lie.
We build entire ecosystems around this truth — our SIEMs, UEBA models, and automated response playbooks, etc., all rely on the binary distinction between a "failed" login and a "successful" one.
So, what happens when an attacker can generate a sign-in that appears legitimate in your Entra ID (Azure AD) environment, creating a successful authentication event that may look like it bypasses MFA and conditional access policies, without gaining access to your data?
Varonis Threat Labs explored a nuance in the Resource Owner Password Credentials (ROPC) protocol that allows the exact scenario above. While the immediate threat isn't necessarily data exfiltration, the implications for your security operations, budget, and data integrity are far more disturbing. Continue reading to learn more.
The mechanism: A log without a login
Authenticating activities without logging relies on a "cross-tenant" architecture. When an attacker has a valid username and password for your organization (Tenant A), they typically can't log in because of enforced MFA or block legacy protocols.
However, if the attacker authenticates these credentials against a different, permissive tenant (Tenant B), a fascinating desync occurs:
- Your tenant (home) verifies the password and logs the event
- The other tenant (resource) checks the Conditional Access policies
Since the other tenant has no policies against this user, the authentication flows through. The result? Your SIEM lights up with a "Sign-in: Success" event. On the surface level, and to many monitoring tools, it appears like a user successfully bypassed your expected authentication controls.
Explore more from Varonis Threat Labs.
The real danger: poisoning the well
Even if the attacker doesn't gain access to your files due to being in a different tenant, security teams should still care because confusion is a powerful weapon in today’s modern cyber landscape.
Let’s dive into how this can transpire in your environment:
1. Poisoning UEBA and ML models
Modern security relies on Machine Learning (ML) to establish a "baseline" of normal behavior. By flooding your logs with "fake" successful logins from random geolocations or IPs, an attacker effectively "poisons the well" With false information, such as:
- A user "successfully logs in" from 50 different countries in an hour, skewing the model’s threshold for "impossible travel"
- The system begins to treat anomalies as noise, potentially masking the real attack happening in the shadows
- Security controls may act based on the false positive alerts generated based on these logs, which may disrupt production systems
2. The financial and operational toll (SOC Tax)
Every false positive has a price tag. Imagine your SOC analyst sees a successful login from a known malicious IP in Russia. They treat it as a critical incident:
- They wake up the CISO
- They disable the user account
- They spend hours investigating a breach that technically never happened
An attacker can script this process, generating thousands of these "ghost logins." This isn't just annoying; it's a Denial-of-Service (DoS) attack on your human analysts. It forces you to burn budget and manpower chasing ghosts.
Compliance and audit nightmares
How would you explain to an auditor that your logs show 500 successful logins without MFA, even though MFA should be enforced everywhere? The "log integrity" is compromised. You are no longer looking at a record of truth, but a record of partial truths.
Disclosure
Varonis reported this behavior to Microsoft through the appropriate disclosure channels. Microsoft assessed the issue as low severity because, while the technique can create misleading successful sign-in events, it does not grant access to cloud resources or tenant data.
From a SOC and audit perspective, the concern remains significant: defenders may still interpret these events as evidence of meaningful access, triggering investigations, alerts, and incident-response workflows based on telemetry that does not necessarily reflect resource compromise.
The takeaway: Context is king
This vulnerability highlights a critical gap in cloud security: Static logs are no longer enough. Many vendors tend to classify ROPC as "low severity" when data wasn't accessed. However, for a CISO managing a SOC, the severity is high.
To properly defend against this, we need to stop looking at "login status" in a vacuum. Organizations need to implement a data-centric security strategy.
Flip the question from, "Did they log in?" to "Did they access data? Did they access a resource inside our tenant?"
If your security tool only looks at the front door, it can be fooled by someone ringing the doorbell. You need visibility into what happens inside the house.
Next time you’re writing a SIEM rule, sprinkle a little salt on those auth logs — they’re not always as honest as they look. Explore more from Varonis Threat Labs.
.png)
