One compromised OAuth application identity. One hundred seventy-three customer tenants accessed. The ConnectWise supply-chain breach is a textbook case of what happens when non-human identities are granted broad delegated access and monitored with the same rigor as a shared printer. This morning’s brief covers three stories that all land on the same theme: the identity layer - human and non-human - is the primary attack surface, and the controls most organizations have in place are not keeping pace.

In the News

ConnectWise OAuth Credential Stolen - 173 M365 Tenants Accessed

Attackers compromised an OAuth application identity belonging to ConnectWise’s SkyKick Cloud Backup service and used it to sign into 173 customer Microsoft 365 tenants. ConnectWise responded by disabling seven application identities and suspending the backup service entirely.

The mechanism is straightforward and devastating: a single non-human identity - an OAuth app credential - held delegated access to customer M365 environments. When that credential was compromised, the attacker inherited every permission the application had been granted across every tenant that had consented to it. No phishing of individual users required. No MFA to bypass. The app identity was the access.

This is the operational reality of NHI risk in MSP environments. Customers consent to OAuth apps during onboarding and rarely revisit those grants. The blast radius of a single compromised app credential scales linearly with the number of tenants that consented. ConnectWise’s rapid response - suspending the service and revoking app identities - limited dwell time, but 173 tenants still experienced unauthorized access before that happened.

What defenders should do: Audit all third-party OAuth consent grants in your M365 tenant immediately. Use the Microsoft Entra admin center to review enterprise applications and their permission scopes. Enable M365 unified audit logging and search for Consent to application and Add app role assignment events from the past 30 days. Any organization using ConnectWise Cloud Backup should treat this as a confirmed compromise and investigate accordingly.

Source: BleepingComputer

OpenCode Console Breached - AI Provider API Keys Potentially Exposed

OpenCode’s hosted Console service was breached on October 16. The attacker accessed a legacy system that stored customer-saved API keys for OpenAI, Anthropic, and Google AI services. OpenCode has not disclosed the exact number of affected customers, but the service is widely used by AI development teams to manage provider credentials from a single dashboard.

The breach highlights a growing category of NHI risk: centralized AI-key vaults. Developers store API keys for multiple AI providers in these tools for convenience. When the vault is compromised, every key inside is exposed - and unlike human credentials, API keys often lack MFA protection, have no session expiration, and may carry broad scopes (model access, fine-tuning, billing). The attacker does not need to phish anyone; the keys are the credential.

What defenders should do: If your organization uses OpenCode Console, rotate all AI provider API keys stored there immediately. Implement secrets management with automated rotation and enforce least-privilege scoping on AI provider keys. Monitor AI-provider usage dashboards for anomalous call volumes or unfamiliar source IPs.

Source: The Hacker News

Fake Web3 Accelerator Pushes npm Stealers Targeting AI Developer Credentials

Attackers created a convincing fake Web3 accelerator that offered free Anthropic and Gemini API credits and free security audits to lure AI developers. Victims who engaged were directed to install malicious npm packages that deployed infostealers and backdoors on macOS and Windows systems. The campaign is designed to harvest developer credentials, session tokens, and stored secrets.

This is a social-engineering supply-chain attack specifically tailored to the AI developer community. The lure works because AI developers regularly seek free credits and tooling, and the npm ecosystem makes package installation feel routine. Once the infostealer runs, it can exfiltrate browser-stored credentials, SSH keys, cloud provider tokens, and locally cached API keys - everything needed to compromise both human and non-human identities.

What defenders should do: Enforce software composition analysis on all developer workstations. Require phishing-resistant authentication (FIDO2/passkeys) on developer accounts - stolen session tokens and passwords become useless if the authentication method is origin-bound. Enable commit signing in your Git workflows so compromised developer credentials cannot be used to push unauthorized code.

Source: The Hacker News

UAT-11985 Bypasses Google MFA with AitM Phishing Against Taiwan Researchers

A threat actor tracked as UAT-11985 sent fake event invitations to Taiwan-based research affiliates, directing victims to an adversary-in-the-middle framework that captured Google credentials and real-time MFA codes simultaneously. The credentials and session tokens were replayed to authenticate as the victim before the MFA code expired.

This campaign is a textbook demonstration of why SMS and TOTP-based MFA is not phishing-resistant. The AitM framework sits between the victim and the real Google login, relaying credentials and MFA codes in real time. From Google’s perspective, the authentication looks legitimate. FIDO2 and passkeys are the only authentication methods immune to this technique because the credential is cryptographically bound to the legitimate origin - a relay proxy cannot satisfy the origin check.

What defenders should do: Migrate high-value accounts - researchers, executives, developers - to FIDO2/passkey authentication. Deploy ITDR or identity analytics to detect session anomalies such as impossible-travel events or token reuse from unfamiliar infrastructure following a successful login.

Source: The Hacker News

Defender Action Items

  • Audit M365 OAuth consents now. Review all enterprise application grants in Microsoft Entra. Revoke any ConnectWise/SkyKick app identities and investigate unified audit logs for unauthorized access in affected tenants.
  • Rotate AI provider API keys stored in OpenCode Console. Scope replacement keys to least privilege and implement automated rotation via a secrets manager.
  • Enforce FIDO2/passkey authentication on all developer and researcher accounts. SMS and TOTP MFA are defeatable by commodity AitM frameworks. Phishing-resistant auth is the only reliable control.
  • Run software composition analysis on developer workstations. Flag any recently installed npm packages from unknown publishers, especially those tied to Web3 or AI credit promotions.
  • Deploy ITDR or identity-anomaly detection to catch session-token reuse and impossible-travel events that indicate successful AitM compromise.

Detection Queries

Search M365 unified audit logs for suspicious OAuth consent activity that could indicate unauthorized application access:

index=o365 sourcetype="o365:management:activity"
  (Operation="Consent to application" OR Operation="Add app role assignment to service principal")
| eval app_name=coalesce(Target{}.ID, ModifiedProperties{}.NewValue)
| stats count earliest(_time) as first_seen latest(_time) as last_seen by UserId, app_name, Operation
| where count > 1 OR like(app_name, "%ConnectWise%") OR like(app_name, "%SkyKick%")
| sort - last_seen

This query surfaces OAuth consent grants and app-role assignments in your M365 tenant. Filter for ConnectWise/SkyKick app names immediately, then broaden to review all third-party app consents from the past 30 days. Any consent grant you do not recognize is a finding worth investigating.

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.