Last updated: July 5, 2026 at 9:01 AM UTC
All 557 Vulnerability 199 Breach 106 Threat 245 Defense 7
Tag: oauth (10 articles)Clear

Umbrij malware steals Google OAuth tokens through a hidden browser to read Gmail

Kaspersky detailed Umbrij, a new tool from the ToddyCat espionage group that steals access to corporate Gmail without ever taking a password. Delivered on Windows through DLL side-loading via trusted signed programs, Umbrij copies the victim's already-signed-in browser profile, launches a hidden Chromium with remote debugging, and drives it through Google's OAuth flow while impersonating legitimate Google Workspace sync apps. Because the copied profile is already authenticated, Google issues an authorization code that is exchanged for an access token, giving the attackers API access to Gmail, Drive, Calendar, and more, and sidestepping both the password and multi-factor authentication. The technique shows how stealing OAuth tokens can quietly bypass account protections.

Check
Audit which third-party apps and OAuth grants have access to your Google Workspace accounts, and watch endpoints for browsers launched with headless and remote-debugging flags outside dedicated test systems.
Affected
Organizations using Google Workspace or Gmail for business; by hijacking an already-signed-in browser profile and the OAuth flow, attackers gain token-based access to email and files without a password or MFA prompt.
Fix
Regularly review and revoke unnecessary OAuth app access to Google accounts, monitor for suspicious DLL side-loading and headless browser debugging, restrict remote-debugging use, and alert on unusual Google API access.

Stolen Klue OAuth tokens let 'Icarus' group raid Salesforce data

A new extortion group called Icarus stole Salesforce CRM data from multiple organizations by abusing Klue, a competitive-intelligence app that integrates with Salesforce. Attackers compromised Klue's backend through a dormant credential, pushed a malicious update that harvested customers' OAuth tokens, and used those tokens to run automated queries against Salesforce's API, exfiltrating contacts, sales communications, and account data over about a day. Salesforce has disabled the Klue Battlecards integration. It is the same OAuth-abuse playbook seen in the Salesloft Drift and Gainsight incidents, exploiting trusted third-party integrations that carry broad, lightly-monitored access. Researchers expect more such attacks through 2026.

Check
Inventory third-party apps connected to your Salesforce and other SaaS, especially Klue, review their OAuth scopes, and hunt API logs for unusual query volume or access from unexpected integrations.
Affected
Organizations using Klue's Salesforce integration, and more broadly any business relying on third-party SaaS integrations whose OAuth tokens grant broad, under-monitored access to CRM and other sensitive data.
Fix
Revoke and rotate OAuth tokens for Klue and other affected integrations, terminate active sessions, restrict integration and API access to known infrastructure, and continuously monitor SaaS integration activity for anomalies.

FBI-flagged Kali365 phishing-as-a-service expands reach - Microsoft 365 OAuth device-code consent abuse grows beyond April campaigns

Dark Reading reports that Kali365 - the phishing-as-a-service platform the FBI flagged for fueling Microsoft 365 attacks in April - is expanding its reach. Rather than stealing passwords, Kali365 captures OAuth access and refresh tokens by tricking victims into completing attacker-initiated Microsoft device-login requests, granting immediate mailbox access. The service generates branded lures impersonating Adobe, DocuSign, and SharePoint in many languages and sells in tiers from $250 for 30 days to $2,000 annually. Its continued growth signals that OAuth device-code consent phishing remains a high-yield technique, and that defenders should prioritize blocking device-code flows for non-mobile platforms and enforcing phishing-resistant MFA across Microsoft 365 tenants.

Check
Search Microsoft 365 logs for unfamiliar device-login completions and OAuth consent grants. Hunt for inbox rules hiding security alerts. Block Adobe/DocuSign/SharePoint-themed device-code lures.
Affected
Microsoft 365 tenants where users can complete attacker-initiated device-login flows. Kali365's branded multi-language lures and tiered pricing keep OAuth device-code phishing scalable and growing.
Fix
Block device-code flow in Conditional Access for non-mobile platforms. Enforce phishing-resistant FIDO2 MFA. Train users to verify device-login codes. Audit OAuth-granted apps regularly.

FBI warns of Kali365 phishing-as-a-service: OAuth device-code consent abuse against Microsoft 365 since April, $250-$2,000/year

The FBI has issued a warning about Kali365, a phishing-as-a-service platform that fueled large Microsoft 365 attacks in April. Instead of stealing passwords, Kali365 customers trigger Microsoft device-login requests and trick victims into completing the authorization, capturing OAuth access and refresh tokens that grant immediate mailbox access. Arctic Wolf, which infiltrated the system, says Kali365 sells in three tiers from $250 for 30 days to $2,000 for the year and generates branded phishing lures impersonating Adobe, DocuSign, and SharePoint in dozens of languages. Threat actors set malicious inbox rules to suppress security notifications and extend dwell time.

Check
Search Microsoft 365 audit logs for unfamiliar device-login completions and OAuth consent grants since April 1. Hunt for inbox rules that auto-delete or hide security-team email addresses.
Affected
Any Microsoft 365 tenant where users can complete device-login flows initiated by an attacker. Adobe, DocuSign, and SharePoint-themed lures are the primary social engineering vector.
Fix
Block device-code flow in Conditional Access for non-mobile platforms. Enforce phishing-resistant FIDO2 MFA. Train users to verify the device-login codes they approve. Audit OAuth-granted apps quarterly.

Tycoon2FA pivots to OAuth device-code phishing - lures Microsoft 365 users to legitimate microsoft.com/devicelogin

The Tycoon 2FA phishing-as-a-service kit, which Microsoft, Europol, Cloudflare and others tried to dismantle in March 2026, is back and has switched tactics. Instead of relaying credentials and MFA codes through a fake login page, operators now send victims to Microsoft's legitimate device-login page at microsoft.com/devicelogin and ask them to enter a code from the lure email. That single consent grants the attacker OAuth tokens for the victim's Exchange Online, OneDrive, and SharePoint through Microsoft's own Authentication Broker app, so it looks normal in Entra logs. eSentire spotted the late-April campaign and published IoCs, including AS45102 (Alibaba Cloud) operator infrastructure.

Check
Search Entra sign-in logs for Microsoft Authentication Broker consents (AppId 29d9ed98-a469-4536-ade2-f981bc1d605e) from unfamiliar IPs, especially AS45102 (Alibaba Cloud) with node/undici user agents.
Affected
Microsoft 365 tenants without Conditional Access policies restricting the OAuth Device Authorization Grant flow. The initial lure abuses legitimate Trustifi click-tracking URLs.
Fix
Block the Device Code Flow in Conditional Access for users who do not need it (most knowledge workers do not). Review eSentire IoCs and revoke matching sessions and refresh tokens.

New 'ConsentFix v3' attack lets criminals take over Microsoft 365 accounts even when MFA and passkeys are turned on

Push Security disclosed ConsentFix v3, a new attack that lets criminals take over Microsoft 365 accounts even if the victim has MFA and phishing-resistant passkeys turned on. The trick: instead of stealing a password, the attacker tricks the user into pasting a Microsoft authorization URL into a phishing page during what looks like a routine login. That URL contains a one-time code that the attacker exchanges for permanent access tokens. v3 automates the whole attack with Cloudflare Pages phishing sites, Pipedream webhook automation, and tenant fingerprinting that customizes the lure to each target organization's branding.

Check
Brief any Microsoft 365 admin or developer that any 'verification step' that asks them to paste a URL containing 'localhost' into a webpage is hostile, no matter how legitimate the page looks.
Affected
Any Microsoft 365 / Entra ID tenant. The attack bypasses MFA, passkeys, and most Conditional Access policies by abusing pre-consented Microsoft first-party apps. Acute risk for organizations whose admins, developers, or DevOps engineers regularly use Azure CLI - those users won't suspect a fake Azure CLI authorization page. Cloudflare Pages and Pipedream both look legitimate in network telemetry.
Fix
Apply token binding to trusted devices and require Conditional Access for first-party Microsoft apps where possible. Hunt Azure sign-in logs for Azure CLI authentications from unfamiliar IPs, especially against accounts that don't normally use it. Train developers to verify out-of-band any 'verification step' that asks them to paste URLs into a webpage. Use app authentication restrictions to limit which first-party apps can issue refresh tokens.

Microsoft patches Entra ID role flaw that let a low-privileged service account impersonate any service principal in your tenant

Microsoft quietly patched a privilege escalation flaw in Entra ID (formerly Azure AD) that let an attacker with a low-privileged service account take over any service principal in the same tenant - including high-value ones with admin consent grants. The bug was in how Entra ID validated role assignments during certain API calls: the validator checked whether the caller had any role on a service principal but didn't check whether that role authorized the specific action. Microsoft fixed the flaw on the back end, so customers don't need a patch - but the takeover scenario means anyone who exploited it before the fix could have created persistent backdoors via OAuth grants.

Check
Audit your Entra ID tenant this week for unfamiliar service principals, unexpected admin consent grants, and OAuth tokens issued to apps you don't recognize.
Affected
Microsoft Entra ID tenants with multiple service principals where any low-privileged account had role assignments on those service principals. The fix is server-side, so you don't need to apply a patch - but you do need to assume any attacker with foothold access before the fix could have abused this to escalate.
Fix
Run a Microsoft Graph audit on your tenant: list all service principals, OAuth grants, and app role assignments created since January 2026. Investigate any unfamiliar app, any grant from a service account, and any service principal whose roles changed unexpectedly. Revoke and re-issue admin consent for high-privilege apps. Enable audit logging for application registrations.

Vercel expands Context.ai breach scope - additional accounts compromised, and some predate the April incident entirely

Vercel updated its security bulletin on April 23 to disclose that ongoing forensics has uncovered additional customer accounts compromised in the Context.ai-linked breach that went public on April 19, and - more worryingly - a separate cluster of customer accounts with evidence of compromise that predates and appears unconnected to the Context.ai incident. CEO Guillermo Rauch confirmed on X that the threat actor has been active beyond Context.ai's compromise. Hudson Rock's forensic report traced patient-zero to a Context.ai employee whose laptop was infected by Lumma Stealer in February 2026 after downloading Roblox auto-farm scripts - a roughly four-week dwell time before the operator pivoted into Context.ai's AWS environment and then through OAuth tokens into Vercel's Google Workspace. The stolen credential set from that single laptop included Google Workspace logins, Supabase keys, Datadog tokens, Authkit credentials, and the support@context.ai account. Vercel has now confirmed non-sensitive environment variables in affected team scopes were readable to the attacker, and says customer notifications are going out individually rather than via a public list.

Check
If you run any service on Vercel, re-check your team's incident email for new direct notifications, and proactively rotate any environment variable not marked as 'sensitive' that was stored in Vercel during February to April 2026.
Affected
Vercel customer teams where a member authorized Context.ai's AI Office Suite OAuth integration against a Vercel enterprise Google Workspace account, and any Vercel team with environment variables not explicitly marked as 'sensitive' stored during the February to April 2026 window. The newly-surfaced predate-April account cluster is separate and Vercel has not publicly scoped it - if you receive a notification email, treat it as a distinct compromise and not simply a continuation of the Context.ai incident.
Fix
Rotate every environment variable stored in Vercel that was not marked as 'sensitive' - in practice, treat every database URL, API key, signing secret, and third-party credential as public and rotate it in place. Audit Google Workspace OAuth app grants and revoke any Context.ai 'AI Office Suite' integration. Review Vercel activity logs back to February 2026 for unexpected access to environment variable dashboards. Rotate Supabase, Datadog, and Authkit credentials if any Context.ai employee or integration ever had access to yours. Set a standing policy that no OAuth grant from an external AI tool gets 'Allow All' Workspace permissions.

Vercel confirms breach - attackers got in through Context.ai AI tool's Google Workspace OAuth, stole customer environment variables

Cloud development platform Vercel disclosed a security incident on April 19 after a threat actor claiming to be ShinyHunters posted stolen data for sale on a hacking forum. Vercel CEO Guillermo Rauch confirmed the initial access came through a breach at Context.ai, an enterprise AI platform one Vercel employee had signed up for using their Vercel enterprise account with 'Allow All' OAuth permissions. Attackers compromised Context.ai, stole the OAuth token, took over the employee's Google Workspace account, and pivoted into Vercel environments. Once inside, they accessed environment variables not marked as 'sensitive' - these are stored unencrypted at rest, unlike sensitive env vars which Vercel encrypts. The attacker posted 580 employee records (names, emails, account status, activity timestamps) as a teaser, plus screenshots of an internal Vercel Enterprise dashboard. They claim to also have access keys, source code, database data, and API keys, though Vercel characterizes impact as a 'limited subset' of customers. Mandiant is engaged. This is the cleanest real-world example to date of the AI supply chain risk pattern everyone has been warning about: a third-party AI tool with broad OAuth scopes becomes the initial access vector into your primary infrastructure.

Check
If you deploy apps on Vercel, rotate all environment variables immediately - especially any not marked 'sensitive'. Also audit every third-party AI/SaaS tool that has OAuth access to your Google Workspace or similar identity provider.
Affected
Any Vercel customer with environment variables not marked 'sensitive'. Vercel has directly contacted a 'limited subset' of customers whose credentials were compromised. If you weren't contacted, Vercel says it has no evidence of your data being accessed at this time. Separately: any organization using Context.ai with Google Workspace OAuth granted 'Allow All' permissions.
Fix
Rotate every Vercel environment variable and redeploy applications to pick up the new values. Mark any secret as 'sensitive' in Vercel's dashboard going forward - this encrypts at rest. In Google Workspace Admin, search for and revoke OAuth App ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Review Google Workspace audit logs between April 1-19 for unusual OAuth grants or token access. Audit every third-party tool connected to your Google Workspace - specifically those granted broad OAuth scopes - and remove any your team isn't actively using.

EvilTokens phishing kit commoditizes Microsoft device code attacks for business email compromise

A new phishing-as-a-service kit called EvilTokens is being sold on Telegram, turning OAuth device code phishing against Microsoft accounts into a turnkey attack. Victims receive emails with PDFs or HTML files containing QR codes or links to pages impersonating Adobe, DocuSign, or SharePoint. The kit captures Microsoft authentication tokens in real time - bypassing MFA - and gives attackers persistent access for business email compromise. The developer says Gmail and Okta support is coming next.

Check
Review your Microsoft Entra ID logs for unusual device code authentication flows, especially from unfamiliar locations or devices.
Affected
Any organization using Microsoft 365 with users who may click on phishing emails disguised as document-sharing notifications.
Fix
Restrict or disable the device code authentication flow in Microsoft Entra ID conditional access policies if your organization doesn't need it. Deploy phishing-resistant MFA (FIDO2 hardware keys). Train finance, HR, and sales teams to recognize fake document verification pages. Monitor for anomalous token grants in Entra ID sign-in logs.