Three stories today converge on one theme: tokens are the new perimeter, and everything that holds, issues, or accepts them is an attack surface. An AitM campaign replayed stolen Microsoft 365 session tokens across 79 organizations. A zero-permission Android app extracted work-account tokens from the authenticator app that was supposed to protect them. And stolen GitHub API tokens powered automated secret harvesting across enterprise repositories. The thread connecting them is that MFA, as traditionally deployed, does not protect the token after it is issued.

In the News

Microsoft 365 AitM Campaign Replays Stolen Tokens Across 79 Organizations

Huntress confirmed that a sustained adversary-in-the-middle campaign ran through September 22, 2026, achieving 497 successful sign-ins across 97 accounts in 79 organizations over a two-month window. The mechanism is straightforward: attackers deployed phishing infrastructure that proxied legitimate Microsoft 365 login pages. When users authenticated - including completing their MFA challenge - the attacker’s relay captured the post-authentication session token. That token was then replayed from attacker-controlled infrastructure to access mailboxes, SharePoint, and OneDrive.

MFA was present on every compromised account. It did not matter. The attackers never needed to bypass the second factor because they captured the session token that MFA produced. This is the operational distinction between authentication-layer security and session-layer security - and most organizations have invested heavily in the former while ignoring the latter.

The campaign’s scale (79 organizations, not 79 users) indicates infrastructure-grade phishing - likely a phishing-as-a-service platform distributing AitM kits to multiple operators. The two-month dwell time suggests detection of token replay is still not a standard capability in most environments.

What defenders should do: Deploy phishing-resistant passwordless authentication using FIDO2 hardware-bound credentials. These credentials are cryptographically bound to the legitimate domain and cannot be proxied through an AitM relay. For detection, monitor for session tokens being used from geographically inconsistent locations or from infrastructure associated with known AitM phishing platforms. [MITRE ATT&CK: T1557 - Adversary-in-the-Middle, T1550.001 - Use Alternate Authentication Material: Application Access Token]

Source: The Hacker News

Gheist Campaign Uses Stolen GitHub Tokens to Harvest Secrets from Private Repos

The Gheist campaign represents non-human identity abuse at industrial scale. Attackers use stolen GitHub API tokens - service account credentials, personal access tokens, and OAuth app tokens - to programmatically query private repositories and GitHub Actions logs for hardcoded secrets. Wiz’s updated analysis confirms the campaign reached GitHub Enterprise installations, meaning corporate environments with private CI/CD pipelines are in scope.

The operational pattern is distinctly non-human: bulk-querying Actions logs across hundreds of repositories in minutes, searching for environment variables, AWS keys, database credentials, and API secrets that developers inadvertently exposed in build output. No human operator would interact with GitHub this way - but most organizations lack behavioral baselines for their non-human identities, so the activity goes undetected.

This campaign is running concurrently with the GhostAction operation, which pushed 72,000 commits to 23,000 repos using 1,792 stolen tokens between October 13-21. GhostAction now ships payloads that steal developer secrets via malicious font files launched through VS Code and target AWS roles reachable through GitHub OIDC federation. GitGuardian notes tactical overlap between the campaigns.

What defenders should do: Audit all GitHub personal access tokens and OAuth app grants. Revoke tokens with excessive scope or no recent legitimate use. Implement secrets scanning on all repositories and Actions workflows. Deploy behavioral detection for non-human identities - any service account querying logs across dozens of repos in a single session is a high-fidelity anomaly signal.

Source: The Hacker News, GitGuardian Blog

CVE-2026-80097: Microsoft Authenticator Flaw Let Zero-Permission Apps Steal Work Tokens

CVE-2026-80097 is a vulnerability in Microsoft Authenticator for Android (versions prior to 6.2606.4246) that allowed a malicious app - requiring zero device permissions - to impersonate trusted Microsoft applications such as Teams and extract work-account sign-in tokens. The flaw existed in how Authenticator validated inter-app communication: a zero-permission app could present itself as a legitimate Microsoft app and request tokens that Authenticator would provide without additional verification.

Microsoft has patched the vulnerability. The significance is architectural: the authenticator app, which is itself the MFA control, became the exfiltration vector. This undermines the assumption that “MFA is present, therefore credentials are protected.” If the app that issues tokens can be tricked into handing them to unauthorized consumers on the same device, the mobile device’s app isolation model is the actual trust boundary - and in this case, it failed silently.

What defenders should do: Confirm all managed devices are running Microsoft Authenticator version 6.2606.4246 or later. For organizations evaluating mobile-device trust architecture, this vulnerability strengthens the case for phishing-resistant passwordless authentication using FIDO2 hardware keys that remove the mobile app from the token-issuance chain entirely.

Source: The Hacker News

AI Coding Agent Hijacked via Prompt Injection - Confirmed Attack Stopped

Forever Security documented a confirmed, real-world attack where a malicious instruction file placed in a user’s Downloads folder directed an AI coding agent to install a known-bad npm package. This is not a proof-of-concept or conference demo - it is a stopped attack on a customer machine. The AI agent ran with the developer’s identity and permissions: it could install packages, write files, and initiate network connections.

The identity implications are direct. AI agents that inherit user or service-account permissions are non-human identities operating with human-level (or greater) privileges. The attack chain - prompt injection leading to code execution - exploits the gap between what the agent is authorized to do and what it should be doing. Without least-privilege constraints on agent identities, a single malicious instruction file can convert a developer assistant into an adversary tool.

This incident arrives alongside the CyberStrikeAI campaign, where threat actors deployed 44 AI agents to automate hacking operations against Japanese organizations - each agent a distinct non-human identity coordinating reconnaissance, credential theft, and exfiltration.

What defenders should do: Treat AI agent identities as privileged non-human identities. Enforce least-privilege constraints: agents should not be able to install packages, access registries, or make outbound network calls outside a sanctioned allowlist. Monitor agent-initiated actions as a distinct identity class in your ITDR tooling.

Source: The Hacker News

Defender Action Items

  • Update Microsoft Authenticator for Android to version 6.2606.4246 or later across all managed devices - CVE-2026-80097 is patched but requires the update
  • Audit all GitHub personal access tokens and OAuth app grants: revoke tokens with excessive scope, no rotation schedule, or no recent legitimate use
  • Deploy phishing-resistant passwordless authentication (FIDO2 hardware-bound credentials) for Microsoft 365 - session tokens from FIDO2 auth cannot be captured via AitM relay
  • Baseline non-human identity behavior in CI/CD environments: any service account querying Actions logs across 50+ repos in a session is a detection-worthy anomaly
  • Constrain AI agent identities to least-privilege: block package installation, outbound network calls, and registry access outside sanctioned allowlists

Detection Queries

The following KQL query detects potential AitM token replay by identifying Microsoft 365 sign-ins where the same session ID appears from two different IP addresses within a short time window - a high-fidelity indicator of stolen token reuse:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize
    IPCount = dcount(IPAddress),
    IPs = make_set(IPAddress),
    MinTime = min(TimeGenerated),
    MaxTime = max(TimeGenerated)
    by CorrelationId, UserPrincipalName
| where IPCount > 1
| extend TimeDeltaMinutes = datetime_diff('minute', MaxTime, MinTime)
| where TimeDeltaMinutes < 30
| project UserPrincipalName, IPs, IPCount, TimeDeltaMinutes, CorrelationId

This query returns sign-in events where the same correlation ID (session) authenticated from multiple IP addresses within 30 minutes. Tune the TimeDeltaMinutes threshold based on your environment - VPN split-tunneling and mobile carrier NAT can generate false positives, but two distinct geographic IPs for the same session in under 10 minutes is almost always token replay or AitM.

References

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) - Human, machine, and AI identity security — NHI, ITDR, and the IAM market.