Writing
Anatomy of an Identity Incident

The App You Authorized Yourself

Anatomy of an Identity Incident — the UNC6040 Salesforce campaign, 2025. No password was stolen and no token was cracked. An employee was talked into authorizing a malicious app, and the app did the rest.

Michael AbramovichJune 25, 20256 min read

Forensic write-ups of public identity breaches, strictly at the identity layer. No vendor is the villain — the point is the structural class of failure, not the logo on it.

The 60-second version

In 2025 a financially motivated crew, tracked by Google's threat intelligence team as UNC6040, ran a campaign that emptied corporate Salesforce environments at a string of large companies — Google's own corporate instance among the confirmed. The technique used no exploit and stole no password. They phoned employees, posed as IT support, and walked them, live, to a Salesforce screen for connecting an application — the "enter this code to authorize an app" flow. The employee entered the attacker's code. That single action authorized a malicious app — a trojanized clone of a legitimate data-loading tool — and handed it standing, token-based access to the company's CRM data, which the attackers then bulk-exfiltrated.

This is a different beast from credential phishing. Nobody's password was captured. The victim didn't fail an MFA challenge; they passed every check, then consented. The breach was a legitimate OAuth authorization, granted to an illegitimate app, by a real employee who thought they were helping IT.

The identity timeline

Only identity-relevant events.

  • The call — An attacker phones an employee, impersonating internal IT or support, and builds enough rapport and urgency to direct the employee's next clicks.
  • The redirect to consent — The employee is guided to Salesforce's connect-an-app / device-authorization screen and told to enter a code the attacker provides.
  • The authorization — Entering the code authorizes a malicious connected app (a tampered "Data Loader"-style tool). Salesforce records a valid OAuth grant. The app now holds API access in its own right.
  • The standing access — Because the app's access is token-based and independent of the employee's session, it persists. Changing the employee's password does not revoke it.
  • The exfiltration — Using the app's API permissions, the attackers pull large volumes of CRM data.
  • Mid-2025 — Multiple major organizations are confirmed or reported as affected, with Google's corporate Salesforce instance among those confirmed.

The pivot point

The pivot is the consent itself — the instant the employee authorized the connected app.

Most of this series is about credentials and sessions being stolen. This one is about an authorization being granted, and that distinction is the whole lesson. OAuth consent was designed to let users delegate access to applications on purpose — "yes, this app may read my data." It is a feature, and a good one. The attack doesn't break it; it borrows it. By dressing a malicious app as a routine IT tool and coaching the user through a normal, sanctioned flow, the attacker turns the user's own legitimate authority to delegate into the breach.

What makes the pivot so durable is what the consent creates: a non-human identity with its own standing access. The malicious connected app is now an authorized application holding API tokens, living alongside the dozens of legitimate integrations every company runs. It doesn't need the employee anymore. It won't trip impossible-travel alerts, because apps don't travel. Resetting the human's password does nothing, because the human's password was never the point. You cannot remediate this by fixing the person; you have to find and revoke the app.

What would have caught it

Naming controls, not products.

Restricting who can authorize connected apps. The highest-leverage control is simply not letting an ordinary employee authorize an arbitrary application. Requiring admin approval for new connected apps, or allow-listing approved ones, removes the action the entire attack depends on.

Monitoring and alerting on new OAuth grants. A newly authorized app with broad API access is a high-signal event. If new connected apps and consents are reviewed and alerted, a malicious one stands out before it finishes exfiltrating.

Limiting app permissions and bulk-export capability. A connected app that can pull the entire CRM is far more dangerous than one scoped to what it actually needs. Tight permissions and limits on bulk data export shrink the blast radius of any single bad grant.

Training that names this specific play. "IT will never ask you to enter a code to connect an app" is a concrete, teachable rule. The attack relies on the consent screen feeling routine; making it feel alarming is cheap and effective.

Treating connected apps as identities to be inventoried. You can't revoke what you can't see. A current inventory of authorized apps and their permissions is what lets you find the impostor among the legitimate integrations.

The last mile

This incident is a clean view of a part of the last mile that is only getting bigger: the governance of non-human identities.

The platform did its job. Salesforce offers connected-app controls, consent policies, admin-approval options, and logs of OAuth grants. None of it was bypassed. The gap was that "these controls exist" and "an ordinary employee cannot authorize an arbitrary app, and someone reviews every new grant" are separated by a stretch of operational governance that the product does not perform for you. Configuring consent policy, allow-listing apps, inventorying the ones you already have, and watching for new grants is continuous day-2 work — and it is work aimed at identities that aren't people, which almost no one watches the way they watch human logins.

That is the ownerless span here. We have spent fifteen years hardening human authentication — MFA, conditional access, phishing-resistant factors — and an attacker simply stepped around all of it by getting a human to grant an app access through a sanctioned flow. The application identity inherited standing access that none of the human controls touch. The mile between "OAuth and connected apps are available" and "non-human identities are governed, inventoried, and consent is locked down" belongs to no product and, at most companies, to no one — which is exactly why the attackers went there.

And this is the direction the whole field is moving. Every company is wiring more apps, more integrations, and now more AI tools into its core systems, each one a non-human identity with delegated access. If human identity was the last mile of the last decade, the governance of these machine identities is the last mile of the next one — and, as this campaign shows, it is wide open.

For defenders

Five things you can check this week.

  1. Lock down OAuth consent. Require admin approval for new connected apps, or allow-list them. Remove the ability for any employee to authorize an arbitrary app.
  2. Inventory the connected apps you already have, with their permissions and owners. You can't spot the impostor without the list.
  3. Alert on new OAuth grants and high-permission apps, and review them like you'd review a new admin.
  4. Scope app permissions and cap bulk export so a single bad grant can't drain everything.
  5. Teach the specific rule: IT will never ask you to enter a code to "connect an app." Make that consent screen feel like a stop sign.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#salesforce #unc6040 #oauth-consent #vishing #nhi #last-mile