Every few months, a batch of research lands that confirms something a lot of identity security teams have suspected for a while: attackers stopped trying to look suspicious. They log in with valid sessions, run queries that violate no policy, and move through infrastructure using accounts nobody would flag on their own. Three reports published in the past few weeks — one from Microsoft, two from Google's Threat Intelligence Group (GTIG) and Mandiant — each document a different version of the same pattern. Read together, they make a stronger case than any one of them makes alone.
Legitimate identity, illegitimate behavior
GTIG's August update on the extortion cluster it tracks as UNC6671 is a good place to start, because it shows how little an attacker needs to compromise an identity convincingly. The group's method doesn't involve exploiting software — it involves phone calls. Operators impersonate internal IT helpdesk staff, often reaching employees on personal mobile numbers, and direct them to convincing fake login portals built to intercept credentials and MFA tokens in real time through adversary-in-the-middle (AiTM) infrastructure. According to GTIG's August 6 report, the group has continued operating under several successor brand names since its original identity was retired, while its core tactics — vishing, AiTM interception, then automated data exfiltration from Microsoft 365 and Okta — have stayed consistent throughout.
The result is an authenticated session that, from the identity provider's perspective, looks completely normal. No password was cracked. No MFA was bypassed through a flaw — it was handed over willingly, under a false premise. The account behaves exactly as a valid account should, right up until it doesn't.
Evasion hides inside the normal, not outside it
The more technically interesting detail in GTIG's research is how the group avoids detection once it's inside. Rather than downloading files in bulk — the kind of activity most SOC rules are built to catch — the actors used Microsoft Graph, PowerShell, and direct HTTP requests to retrieve SharePoint and OneDrive content in a way that generated FileAccessed events rather than FileDownloaded events. That single distinction is enough to slip past detection logic tuned around the more obvious signal. A second useful clue GTIG flagged: inconsistent user-agent strings, where a legitimate Microsoft application identifier appeared alongside traffic patterns more typical of python-requests or scripted PowerShell activity.
Neither of those things is inherently suspicious. A file being accessed instead of downloaded isn't an alert-worthy event on its own, and mixed client tooling happens in legitimate environments too. What makes it a signal is the combination — frequency, sequencing, and client context that doesn't match how that particular identity has behaved before. That's a directory-and-access-pattern problem, not a malware-signature problem, and it's the same principle behind how we think about LDAP telemetry: the operations worth modeling aren't the rare dangerous ones, they're the ordinary ones happening at an ordinary-looking pace that's quietly no longer ordinary for that specific account.
Drift isn't only a user problem — it can be an infrastructure problem
The most technically significant finding of the three came from Mandiant, and it broadens what "identity drift" should mean. In a recent red-team engagement, Mandiant found that manually rotating an ADFS token-signing certificate — rather than letting automatic rollover handle it — can leave the previous signing key recoverable through Machine DPAPI, even after it's no longer the certificate ADFS is actively using. Mandiant calls the leftover record a "ghost" entry: it still decrypts successfully, but no longer reflects what the service is actually signing tokens with. A sufficiently privileged process on the host can recover that live key without touching LSASS memory at all.
The practical consequence is serious: a recovered signing key enables a Golden SAML attack, letting an attacker forge valid assertions for any user — including Global Administrator access — while bypassing MFA and conditional access entirely, because the forgery happens at the level that determines whether authentication is valid in the first place. Mandiant identifies ADFS Event ID 385, normally just a certificate-validity warning, as the clearest observable sign that this kind of drift condition exists in an environment.
What we take from this isn't a new detection rule — it's a reason to hold "drift" to a wider definition than user behavior alone. A manually-managed certificate rotation, drifting quietly out of sync with what the service is actually doing, is the same underlying pattern as a service account's access scope drifting past what it was provisioned for. Both are changes nobody explicitly authorized, accumulating in infrastructure that looked fine at every individual checkpoint.
Not every anomaly deserves the same weight
Microsoft's contribution is less about a single attack and more about how identity risk should be scored at all. The company's Defender for Identity risk score, now generally available, rates identities from 0 to 100 based on both the likelihood of compromise and the potential impact — factoring in criticality and privileged role assignments, not just observed activity in isolation. The underlying idea is straightforward but easy to skip in practice: ten unusual directory queries from an ordinary user account and ten unusual queries from a synchronization account or AD admin are not the same event, even if the raw anomaly score is identical.
That's consistent with how we think about detection quality generally. A platform that treats every account the same regardless of what it's privileged to do will either drown analysts in low-value alerts or bury the handful that actually matter. Identity criticality has to be a standing dimension of the model, not an afterthought applied after the fact.
Where this leaves directory-level defense
None of this changes what we're building right now. Identera's current focus is deliberately narrow: longitudinal behavioral modeling of Active Directory and LDAP telemetry, the layer closest to where identity actually gets provisioned, delegated, and used. What this research does is confirm the reasoning behind that focus, and behind where it's headed next. The identity attack chain increasingly spans directory activity, authentication behavior, SaaS access, and — as the ADFS research shows — the configuration of the infrastructure that issues trust in the first place. A detection approach that only watches one layer of that chain will keep missing the parts of the story that live in the others.
That's the case for the direction on our own product roadmap: stay focused on directory-native detection today, and extend the same behavioral baseline model to correlate across SaaS, SIEM, and Entra ID telemetry next — without changing the deployment model or the attack-surface commitment that focus is built on.
- Google Threat Intelligence Group, "UNC6671 Rebrands: Multi-Brand Vishing Extortion Targets Financial Services and Enterprise Cloud Environments," Google Cloud Blog, August 6, 2026.
- Mandiant, "Recovering Active ADFS Signing Keys via Machine DPAPI," Google Cloud Blog, July 2026.
- Microsoft, "What's New — Microsoft Defender for Identity," Microsoft Learn, 2026.
See how this maps to our roadmap
Directory-native today, cross-signal correlation next — and why we're deliberately holding one technology back.