{“lastseen”:”2026-05-05T11:59:30″,”description”:”\\n\\nEvery 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.\\n\\nOAuth grants don’t expire when employees leave. They don’t reset when passwords change. And in most organizations, nobody is watching them.\\n\\nThe 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.\\n\\nThat’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.\\n\\n## CISOs know it’s a problem. Most aren’t solving it.\\n\\nNew research from Material Security 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.\\n\\n\\n\\nBut awareness doesn’t translate directly into capability. 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.\\n\\n\\n\\nSpreadsheets are not a threat response capability. They’re a record of how much exposure an organization doesn’t know it has.\\n\\n## It’s not theoreticalrisk\\n\\nThe 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 makes that concrete.\\n\\nDrift, 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.\\n\\nThe 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.\\n\\nCloudflare, PagerDuty, and dozens of others were affected. The full scope is still being assessed.\\n\\nThe Drift incident wasn’t an attack from a suspicious, unknown app. It was an attack _through_ 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.\\n\\n## What monitoring actually needs to look like\\n\\nThe 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.\\n\\nTo 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_ 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.\\n\\nThe 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.\\n\\nEffective OAuth security requires:\\n\\n * **Continuous behavioral monitoring, not point-in-time review.** What is the app actually doing after it’s been granted access? Monitoring the API calls an OAuth-connected app makes over time reveals anomalies that no static permission review can catch \u2014 sudden spikes in data access, queries for unusual data types, andaccess at unexpected hours.\\n * **Blast radius assessment.** An OAuth grant connected to an account with read access to thousands of sensitive documents and years of email history is categorically different from the same grant on a freshly provisioned account with limited exposure. The reach of the user’s account determines the potential impact of a compromised or malicious OAuth connection. Risk scoring should reflect that.\\n * **Graduated response matched to organizational risk tolerance.** An obviously malicious app \u2014 unknown vendor, broad permissions, anomalous API behavior from day one \u2014 shouldn’t sit in the environment while a ticket works through a queue. It should be revoked immediately. A mission-critical integration from a major vendor showing mild anomalies warrants human review before any action is taken. The response layer needs to be intelligent enough to tell the difference.\\n\\n\\n\\n## Material’s OAuth Threat Remediation Agent\\n\\nMaterial Security’s OAuth Threat Remediation Agent is built around this more complete model of OAuth risk. The agent runs continuously across an organization’s Google Workspace environment, monitoring every OAuth-connected application \u2014 not just new ones at the point of grant.\\n\\nFor each connected app, the agent evaluates three factors together:\\n\\n * **Vendor trust and scope analysis** \u2014 the standard baseline that most tools stop at\\n * **Behavioral monitoring of actual API calls** made by the app over time, surfacing anomalies against expected behavior\\n * **Blast radius assessment** based on the access levels and data exposure of the accounts the app is connected to\\n\\n\\n\\nThese inputs combine into a risk signal that reflects both the probability of a problem and its potential impact. When the agent identifies a high-risk grant, it can act immediately \u2014 revoking the token before harm is done. For lower-certainty situations involving mission-critical applications, it surfaces the finding to the security team with full context: what the app is, what it’s been doing, what it has access to, and what the risk score is.\\n\\nOrganizations configure their own thresholds: how much risk triggers automated remediation, and where the line is for requiring human sign-off. The agent is designed to keep security teams in the loop for the decisions that matter, and out of the loop for the ones that don’t.\\n\\n## Closing the back door\\n\\nOAuth grants are the default way third-party apps and AI tools connect to the enterprise workspace. That’s not changing. The number of grants in most environments will continue to grow as AI adoption accelerates. Telling employees they can’t use AI tools isn’t a viable security posture for most organizations \u2014 and it wouldn’t address the threat posed by apps that are legitimate at installation and malicious later.\\n\\nThe answer isn’t fewer OAuth grants. It’s better visibility into the ones that exist, continuous monitoring of their behavior, and the operational capability to respond fast enough to matter and smart enough to avoid disrupting the integrations that keep the business running. \\n\\nFor security teams who want visibility into what’s actually connected to their environment \u2014 and the ability to respond when something changes, reach out to Material Security for a demo of the OAuth Threat Remediation Agent.\\n\\nFound this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.\\n”,”published”:”2026-05-05T11:58:00″,”modified”:”2026-05-05T11:58:00″,”type”:”thn”,”title”:”The Back Door Attackers Know About \u2014 and Most Security Teams Still Haven\u2019t Closed”,”source”:””,”references”:””,”id”:”THN:CCCDB0753E21F0219C340462B261ECBA”,”bulletinFamily”:”info”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/thehackernews.com\/2026\/05\/the-back-door-attackers-know-about-and.html”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-05T11:59:30″,”description”:”\\n\\nEvery AI tool, workflow automation, and productivity app your employees connected to Google or Microsoft this year left something behind: a persistent OAuth token with…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,13,33,7,11,43,5],"class_list":["post-51435","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-security","tag-tapic","tag-thn","tag-vulnerability"],"yoast_head":"\n