{"id":811,"date":"2026-05-05T13:16:03","date_gmt":"2026-05-05T13:16:03","guid":{"rendered":"https:\/\/thedigitalfortress.us\/?p=811"},"modified":"2026-05-05T13:16:03","modified_gmt":"2026-05-05T13:16:03","slug":"the-back-door-attackers-know-about-and-most-security-teams-still-havent-closed","status":"publish","type":"post","link":"https:\/\/thedigitalfortress.us\/?p=811","title":{"rendered":"The Back Door Attackers Know About \u2014 and Most Security Teams Still Haven\u2019t Closed"},"content":{"rendered":"
\n
<\/a><\/div>\n

Every AI tool, workflow automation, and productivity app your employees connected to Google or Microsoft this year left something behind: a persistent OAuth token with no expiration date, no automatic cleanup, and in most organizations, no one watching it. Your perimeter controls don’t see it. Your MFA doesn’t stop it. And when an attacker gets hold of one, they don’t need a password.<\/p>\n

OAuth grants don’t expire when employees leave. They don’t reset when passwords change. And in most organizations, nobody is watching them.<\/p>\n

The model made sense when a handful of IT-approved apps needed calendar access. It doesn’t hold up when every employee is independently wiring AI tools, workflow automations, and productivity apps directly into their Google or Microsoft environment \u2014 each one receiving a persistent, scoped token with no automatic expiration and no centralized visibility.<\/p>\n

That’s not a misconfiguration. It’s how OAuth is designed to work. The gap is that most security programs weren’t built to account for it at scale.<\/p>\n

CISOs know it’s a problem. Most aren’t solving it.<\/h2>\n

New research from Material Security<\/a> quantifies the gap between awareness and action. 80% of security leaders consider unmanaged OAuth grants a critical or significant risk. Most have said as much for years.<\/p>\n

\"\"<\/a><\/div>\n

But awareness doesn’t translate directly into capability.\u00a0 A substantial portion of organizations (45%) are doing nothing to monitor OAuth grants at scale. Many of the rest (33%) are running manual processes \u2014 tracking grants in spreadsheets, reviewing permissions on an ad hoc basis, relying on employees to flag unusual app behavior.<\/p>\n

\"\"<\/a><\/div>\n

Spreadsheets are not a threat response capability. They’re a record of how much exposure an organization doesn’t know it has.<\/p>\n

It’s not theoreticalrisk<\/h2>\n

The argument for OAuth visibility often gets framed as employees piping sensitive information into third-party tools without IT visibility. That’s a real problem, but it’s the smaller one. The more pressing issue is that OAuth grants are an active attack vector. The Drift incident<\/a> makes that concrete.<\/p>\n

Drift, a sales engagement platform acquired by Salesloft, maintained OAuth integrations with Salesforce instances across hundreds of customer organizations. A threat actor tracked by Palo Alto Unit 42 as UNC6395 obtained valid OAuth refresh tokens \u2014 likely through prior phishing campaigns \u2014 and used them to access Salesforce environments belonging to more than 700 organizations.<\/p>\n

<\/p>\n

The attack’s structure is a warning: the tokens were legitimate, the integration was legitimate. From the perspective of any perimeter control, nothing was wrong. MFA was bypassed entirely because the attacker wasn’t logging in \u2014 they were presenting a token that Drift had already been granted permission to use. Once inside, UNC6395 systematically exported data and combed through it for credentials: AWS access keys, Snowflake tokens, passwords.<\/p>\n

Cloudflare, PagerDuty, and dozens of others were affected. The full scope is still being assessed.<\/p>\n

The Drift incident wasn’t an attack from a suspicious, unknown app. It was an attack through<\/em> a trusted one. The lesson isn’t that organizations should restrict OAuth integrations \u2014 it’s that trusting an app at the time of installation doesn’t mean it stays trustworthy, and that OAuth grants need active, continuous monitoring rather than passive acceptance.<\/p>\n

What monitoring actually needs to look like<\/h2>\n

The current generation of OAuth security tools addresses OAuth risk at the point of installation. They check whether a requested permission scope is excessive. They may flag apps from vendors with poor reputations. That’s useful \u2014 but it’s not sufficient. For the Drift scenario, a legitimate app whose credentials were later stolen and weaponized \u2014 it catches nothing.<\/p>\n

To begin with, vendor trust levels and app scopes are important, but it only tells part of the story. Monitoring the actual behavior of the app\u2013the API calls it makes, the actions it takes\u2013is critical to understanding what the app is actually<\/em> doing, not just what it could do. And even then, without deep visibility into the account(s) the app is linked to, you\u2019re still operating half-blind. A risky app tied to an intern\u2019s account is one thing\u2013the same app being used by a VIP with access to countless sensitive emails, files, and systems is something else entirely.<\/p>\n

The Drift attack didn’t involve a suspicious app requesting unusual permissions at installation. It involved a legitimate app whose credentials were later compromised and weaponized. A tool that only evaluates the grant at the point of creation would have seen nothing wrong. The risk materialized later \u2014 when the token was stolen and used by a different actor entirely.<\/p>\n

Effective OAuth security requires:<\/p>\n