Tre angrepsveier inn, null sårbarheter utnyttet. Microsoft publiserte 13. juli en kartlegging av kampanjer mot Salesforce som løp fra midten av 2025 til midten av 2026, og alle tre teknikkene de fant gikk inn gjennom tillit organisasjonene selv hadde delt ut. Aktørene knyttes til utpressingsgruppen ShinyHunters, og Microsoft så aktiviteten hos kunder innen varehandel, utdanning og industri.
De tre veiene inn:
- Telefonsamtaler der angriperne utga seg for å være IT-support og loset ansatte gjennom Salesforce sin OAuth-samtykkeskjerm, til de godkjente en angriperkontrollert app forkledd som Salesforce sitt eget Data Loader-verktøy.
- Stjålne OAuth-tokens fra programvareleverandører som allerede hadde tilgang til kundenes Salesforce-miljøer, brukt til å hente ut data fra mange instanser samtidig.
- Feilkonfigurert gjestetilgang på Aura-endepunktene bak Experience Cloud, der angriperne leste ut records uten å autentisere seg og paginerte forbi grensen på 2 000 per spørring.
«Ingen skadevare, ingen gjenbruk av stjålne passord. Bare en telefonsamtale og et klikk på godkjenn.» — The Hacker News
Vei nummer to treffer KI-byggere direkte
I august 2025 stjal angriperne OAuth- og refresh-tokens knyttet til Salesloft sin Drift-integrasjon, en KI-chatbot koblet på kundenes Salesforce-miljøer. Google anslo at tyveriet potensielt eksponerte over 700 organisasjoner, blant dem Cloudflare, Zscaler, Palo Alto Networks og Proofpoint. Salesloft sporte senere årsaken tilbake til at angriperne hadde tilgang til GitHub-kontoen deres allerede i mars 2025, og brukte den til å nå Drift sitt AWS-miljø. Vel inne kjørte operatørene SOQL-spørringer på jakt etter AWS-nøkler, Snowflake-tokens og passord.
Samme oppskrift gikk mot Gainsight i november 2025 og traff over 200 Salesforce-instanser. I juni 2026 gjaldt det Klue, der veien inn var en glemt legacy-nøkkel fra en testintegrasjon som aldri ble tatt i bruk. Mønsteret er det samme hver gang: en KI-tjeneste holder tokens på vegne av kundene sine, og når leverandøren faller, faller alle nedstrøms samtidig. Pulsen har dekket nøyaktig samme mekanikk da Vercel bekreftet innbrudd via KI-verktøyet Context.ai.
Mandiant sitt råd til forsvarere etter vishing-bølgen var kontant: samtalene utnytter helpdeskens instinkt for å være hjelpsom, vanlige identitetssjekker gjelder ofte ikke, og det trygge trekket er å legge på og ringe tilbake på en kjent kanal. (Gjengitt av The Hacker News.)
Hvorfor loggene dine ikke fanget det
Når tilgangen kommer fra en ekte bruker som har godkjent en connected app, ser trafikken ut som vanlig bruk, og autentiseringsovervåking registrerer den knapt. Signalet ligger i hva appen gjør etterpå: hvilke OAuth-scopes den har, hvor mye den spør om, og om det er normalt for akkurat den tenanten.
Microsoft har derfor jobbet med Salesforce om ny telemetri i Defender for Cloud Apps: aktivitet knyttes nå til en spesifikk app-identitet og scopene den har fått, apper som har stått ubrukt i 90 dager eller mer med levende rettigheter flagges, og hver app får en risikoscore fra 0 til 100.
Identitetskontrollene de fleste har bygget de siste ti årene er laget for mennesker som logger inn: MFA, betinget tilgang, sesjonspolicyer. OAuth-appene, integrasjonskontoene og tjenestenøklene som gjør selve jobben står stort sett utenfor alt dette, uovervåket og med for vide rettigheter. Det gjelder like fullt for agenten du selv har koblet på et CRM, en Slack-workspace eller et repo.
Hva bør du gjøre?
- Inventer alle connected apps og OAuth-integrasjoner du har koblet på SaaS-tjenestene dine, og fjern dem ingen bruker. Klue-innbruddet gikk gjennom en testintegrasjon som aldri ble deployet.
- Sett de gjenværende til minste nødvendige scope, og ha en prosedyre for å trekke tilbake og rotere tokens i det en integrasjon oppfører seg rart.
- Slå på hendelseslogger som viser hva appen gjorde etter innlogging, ikke bare hvem som logget inn.