Three of today’s four stories share the same root cause: an identity - human or machine - was trusted without continuous verification, and an attacker exploited that trust to move laterally, exfiltrate secrets, or hijack a release pipeline. Token theft is replacing credential theft as the primary identity attack vector, and MFA alone does not address it.

In the News

M365 AitM Campaign Replays Stolen Tokens to Breach 97 Accounts Across 79 Orgs

Huntress published details of a July–September 2026 campaign using adversary-in-the-middle (AitM) relay infrastructure to intercept Microsoft 365 session tokens. The mechanism is straightforward: the attacker positions a transparent proxy between the victim and Microsoft’s login page. The user authenticates normally - entering their password and completing MFA - and Microsoft issues a session token. The proxy captures that token in transit and replays it from attacker-controlled infrastructure.

The campaign achieved nearly 500 successful sign-ins across 97 accounts in 79 organizations. MFA was present and functioning correctly in every case. The control it provided - verifying the user’s identity at authentication time - was irrelevant because the attacker never needed to re-authenticate. They had the session token.

This is the attack pattern that separates phishing-resistant authentication (FIDO2, passkeys) from traditional MFA. FIDO2 binds the authentication ceremony to the legitimate origin - the AitM proxy cannot relay the challenge because the cryptographic assertion is domain-bound. Push notifications, SMS codes, and TOTP tokens have no such binding. The preventive control is phishing-resistant passwordless authentication. The detection control is identity threat detection and response (ITDR) - monitoring for session anomalies like impossible travel, device fingerprint mismatches, and token reuse from new IP addresses.

What defenders should do: Migrate to phishing-resistant passwordless authentication (FIDO2/passkeys) as the primary MFA method. Deploy ITDR tooling that monitors session-layer signals - token reuse, geographic impossibility, and device fingerprint deviation. Enforce conditional access policies that require compliant, managed devices and block legacy authentication protocols. (Source)

Gheist Campaign Steals GitHub Tokens to Exfiltrate Secrets via Actions Logs

Wiz researchers identified Gheist, an automated campaign that uses stolen GitHub tokens to plant malicious workflows in private repositories. The attack chain: the adversary uses a compromised personal access token or GitHub App credential with write access to a private repo. They commit a workflow file that runs on push and prints environment secrets, repository secrets, and OIDC tokens to the Actions log output. The attacker then downloads the log via the GitHub API and deletes the workflow run to eliminate evidence.

The campaign targets GitHub Enterprise environments - organizations that assume private repos are safe because they are not publicly accessible. The gap is in token governance: the stolen tokens had broad scopes (repo, workflow, admin:org) that were granted at creation and never reviewed, rotated, or scoped down. This is a non-human identity lifecycle failure. The tokens were valid, unexpired, and overprivileged.

What defenders should do: Audit all GitHub personal access tokens and GitHub App installations for scope - revoke and reissue with minimum required permissions. Enable secret scanning in CI/CD pipelines to detect secrets appearing in log output. Monitor GitHub audit logs for workflow_run.created and workflow_run.deleted events from unfamiliar IPs or service accounts. Enforce short-lived, fine-grained tokens over classic personal access tokens. (Source)

AI Coding Agent Hijacked via Malicious AGENTS.md File

Forever Security documented a real-world attack where a malicious AGENTS.md instruction file was placed in a developer’s Downloads folder. When the developer’s AI coding agent scanned the working environment, it parsed the file and followed the embedded instructions - nearly installing a known-malicious npm package before the developer intervened.

The attack exploited ambient authority. The AI agent operated with the developer’s full credentials: file system access, npm registry authentication, Git credentials, and cloud SDK tokens. It had no separate identity, no authorization boundary, and no approval gate for destructive or install operations. From the agent’s perspective, the instruction file was indistinguishable from a legitimate project configuration.

This incident crystallizes the agent identity problem. Federal guidance published this month by NIST, CISA, and NSA (source) now frames runaway agent behavior as a security incident requiring an IR playbook. The core requirement: organizations must be able to answer “whose authority did the agent use?” before the incident occurs. That answer requires agents to have distinct identities with scoped permissions - not inherited human sessions.

What defenders should do: Assign AI agents distinct machine identities with least-privilege scopes - never let agents inherit human credentials. Implement runtime guardrails requiring human approval for install, execute, and publish operations. Restrict agent file system access to project directories only. (Source)

Leaked LiteLLM Master Key Compromised Entire Release Pipeline

A master API key for the LiteLLM agent platform was accidentally committed to a public GitHub repository in May 2026. Microsoft’s security blog confirmed that attackers discovered the key and used it to hijack GitHub tokens associated with the project’s CI/CD pipeline. With pipeline control, they pushed malicious LiteLLM releases containing payloads that stole credentials from developer tools, AI applications, cloud SDKs, and browsers via Python startup hooks.

One non-human identity - a single service key with no rotation policy, no expiration, and administrative scope - gave attackers full control of the software supply chain. The downstream blast radius extended to every developer and organization that installed the compromised releases.

What defenders should do: Enforce automatic rotation and short expiration on all service keys and API tokens. Store secrets in a vault with access logging - never in source code. Implement release signing and provenance attestation in CI/CD pipelines so downstream consumers can verify release integrity. Audit for service accounts with admin-level scope that have never been rotated. (Source)

Defender Action Items

  • Migrate to FIDO2/passkeys for Microsoft 365 and other AitM-targeted SaaS platforms - this is the only authentication method that is both phishing-resistant and token-capture-resistant at the ceremony level.
  • Audit GitHub token scopes - revoke classic personal access tokens with broad scopes, reissue as fine-grained tokens with minimum permissions, and enable GitHub secret scanning in all repositories.
  • Define agent-specific identities for AI coding assistants - distinct machine identities with scoped permissions, runtime approval gates for install/execute operations, and restricted file system access.
  • Rotate all service keys and API tokens for CI/CD pipelines - enforce vault-managed storage, automatic expiration, and access logging. Any key that has never been rotated is an assumption, not a control.
  • Patch Brotli (CVE-2026-111497) in Node.js, Python, Bun, .NET, and especially Envoy sidecar deployments - a compromised auth gateway proxy can intercept tokens and sessions at scale.

Detection Queries

Detect anomalous M365 token replay - sessions where a token is used from a significantly different IP or geographic location within a short window:

1index=o365 sourcetype="o365:management:activity" Operation=UserLoggedIn
2| eval src_ip=ClientIP
3| stats dc(src_ip) as unique_ips, values(src_ip) as ip_list, earliest(_time) as first_login, latest(_time) as last_login by UserId
4| where unique_ips > 2 AND (last_login - first_login) < 3600
5| eval time_window_min=round((last_login - first_login)/60,1)
6| table UserId unique_ips ip_list time_window_min

This query identifies M365 accounts with logins from three or more distinct IPs within a one-hour window - a high-fidelity signal for token replay from AitM infrastructure. False positive rate is low in environments with conditional access enforcing managed devices; higher in BYOD environments where VPN split-tunneling creates legitimate multi-IP sessions. Tune the unique_ips threshold and time window for your environment.

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.