In juli 2026 beschreef Microsoft hoe de afpersersbende ShinyHunters een jaar lang stilletjes Salesforce-tenants leegtrok in de detailhandel, de gezondheidszorg, de luchtvaart en de techsector — en dat deed zonder ook maar één wachtwoord te kraken. De ShinyHunters Salesforce OAuth-campagne misbruikte precies datgene wat multifactorauthenticatie nooit bedoeld was tegen te houden: een gebruiker die vrijwillig op „Toestaan“ klikt. Waar oudere inbraken inloggegevens stalen, stal deze vertrouwen, door medewerkers ertoe te verleiden een kwaadaardige connected app te autoriseren die daarna onbeperkt een geldig API-token in handen had.
Dat onderscheid doet ertoe voor iedereen die een SaaS-stack beheert. De aanvallers raakten het aanmeldscherm zelden aan, dus MFA-prompts, impossible-travel-regels en aanmeldwaarschuwingen bleven grotendeels stil. Als jouw beveiligingsmodel aanneemt „we hebben MFA, dus we zitten goed“, dan is deze campagne de casus die het tegendeel bewijst.
Wat er werkelijk gebeurde
Tussen medio 2025 en medio 2026 voerde ShinyHunters (door Googles Mandiant gevolgd als UNC6040 voor de vishing-activiteit en UNC6395 voor de tokendiefstal) een operatie op industriële schaal uit tegen Salesforce-klanten. De samenvatting van The Hacker News van Microsofts threat intelligence becijfert de claims van de affiliates op bijna 1,000 getroffen organisaties, al blijven er veel onbevestigd. De buit was CRM-data — klantgegevens, supporttickets, contactlijsten — die de groep vervolgens gebruikte voor afpersing, met de dreiging deze te lekken tenzij de slachtoffers betaalden.
Het slimme zat in de persistentie. Een gestolen OAuth-token verloopt niet wanneer een wachtwoord wordt gereset of wanneer de gephishte medewerker zijn MFA-apparaat wisselt. Zoals Microsoft opmerkte, was het meeste van Salesforce' logging „niet gebouwd om te tonen“ wat er na de autorisatie gebeurt, waardoor de kwaadaardige API-aanroepen wekenlang opgingen in het normale automatiseringsverkeer.
De drie manieren naar binnen
Microsoft en het threat-intelligenceteam van Google Cloud beschrijven drie afzonderlijke toegangsroutes, die alle op dezelfde plek eindigen: een door de aanvaller gecontroleerde OAuth-toekenning.
| Aanvalsroute | Hoe het werkte | Belangrijk detail |
|---|---|---|
| Voice-phishing (vishing) | Bellers deden zich voor als IT-support en loodsten medewerkers door het OAuth-toestemmingsscherm van Salesforce | Slachtoffers autoriseerden een kwaadaardige app die zich voordeed als Salesforce' Data Loader, soms hernoemd tot „My Ticket Portal“ |
| Tokendiefstal in de toeleveringsketen | Aanvallers braken in op vertrouwde integraties en hergebruikten hun OAuth-tokens tegen stroomafwaartse tenants | Salesloft/Drift (aug 2025), Gainsight (nov 2025) en Klue (juni 2026); berichtgeving stelt de stroomafwaartse blootstelling op respectievelijk 700+ en 200+ organisaties |
| Verkeerd geconfigureerde gasttoegang | Te ruim ingestelde gastrollen in Experience Cloud lieten niet-geverifieerde gebruikers data lezen | De actoren gebruikten GraphQL-paginering om langs de querylimiet van 2,000 records te glippen |
De vishing-route is de kop, omdat er helemaal geen softwarelek voor nodig is — enkel een overtuigend telefoontje en een afgeleide beheerder. De route via de toeleveringsketen is aantoonbaar erger: één enkele inbraak bij een leverancier als Salesloft gaf de aanvallers een sleutelbos naar honderden klantorganisaties die zelf nooit een fout maakten.
Waarom OAuth-misbruik pal langs MFA loopt
Dit is het detail dat de meeste berichtgeving overslaat, en het is de reden dat de campagne zo lang werkte. OAuth-toestemming is ontworpen om toegang te delegeren. Wanneer een medewerker een connected app goedkeurt, geeft Salesforce een langlevend token uit waarmee die app de API namens de gebruiker kan aanroepen — geen herhaalde aanmelding, geen nieuwe MFA-uitdaging. Dat is het hele doel van OAuth, en daarom is „zet gewoon MFA aan“ hier geen verdediging.
Zodra het token bestaat, opereert de aanvaller als een vertrouwde toepassing, niet als een verdachte aanmelding. Er is geen afwijkende geolocatie om te markeren, want de API-aanroepen komen van de eigen infrastructuur van de app. Beleid rond aanmeldrisico's slaat nooit aan, want er is geen aanmelding. Wachtwoordrotatie doet niets, want er is geen wachtwoord bij betrokken. Het token intrekken is de enige echte noodstop — en je kunt alleen intrekken wat je kunt zien, wat precies is wat Salesforce' standaardlogging bemoeilijkte. Dit is dezelfde les dat „identiteit de nieuwe perimeter is“ die achter zero-trust-migraties zit: de netwerkrand is irrelevant wanneer de aanvaller arriveert met een geldige credential in de hand.
Wie er werd getroffen
De slachtofferlijst leest als een corporate who's-who. Openbare berichtgeving en posts op leaksites koppelen de bredere ShinyHunters-Salesforce-activiteit onder meer aan Google, Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, Qantas, Allianz Life, Adidas, Chanel, Pandora en meerdere LVMH-merken. Beveiligingsleveranciers werden niet gespaard — Tanium, Huntress en Recorded Future komen eveneens in de berichtgeving voor, een scherpe herinnering dat het risico van OAuth-toestemming universeel is en geen probleem van kleine bedrijven.
De gezondheidszorg trok specifieke aandacht. Health-ISAC bracht mitigatierichtlijnen uit nadat de activiteit van de groep oversloeg naar de sector, en financieel toezichthouder FINRA publiceerde zijn eigen waarschuwing over Salesforce Experience Cloud die de route via de verkeerd geconfigureerde gasttoegang behandelt.
Hoe je OAuth-toestemming in je eigen organisatie dichttimmert
De oplossing is governance, geen patch — en ze geldt voor elk SaaS-platform dat autorisatie van apps van derden ondersteunt (Google Workspace en Microsoft 365 hebben dezelfde blootstelling). Een praktische checklist:
- Beperk wie toestemming mag geven. Schakel OAuth-toestemming door eindgebruikers uit en leid alle nieuwe goedkeuringen van connected apps via een beoordelingswachtrij van de beheerder. Vergrendel in Salesforce de instellingen „Connected Apps OAuth Usage“; gebruik in Microsoft 365 app-toestemmingsbeleid en conditional access.
- Inventariseer en snoei bestaande toekenningen. Bekijk elke geautoriseerde connected app en trek alles in wat ongebruikt, onbekend of slapend is. Een token van een app waarvan niemand zich de installatie herinnert, is je grootste risico.
- Houd de juiste logs in de gaten. Aanmeldlogs vangen dit niet. Monitor in plaats daarvan OAuth-autorisatiegebeurtenissen, het API-aanroepvolume van connected apps en patronen van bulkexport van data. Plotselinge massale leesacties vanuit een zelden gebruikte app zijn het verklikkersteken.
- Train personeel op vishing bij het toestemmingsscherm. De laatste klik is menselijk. Zorg dat medewerkers weten dat IT hen nooit zal bellen om hen door een OAuth-„Toestaan“-prompt te loodsen.
- Screen je integratieleveranciers. De inbraken bij Salesloft en Gainsight tonen dat je Salesforce-beveiliging maar zo sterk is als de derden aan wie je tokens hebt verleend — dezelfde les over de toeleveringsketen als uit de npm-Shai-Hulud-crisis.
Veelgestelde vragen
Heeft ShinyHunters een kwetsbaarheid in Salesforce uitgebuit?
Nee. Er zat geen fout in Salesforce zelf. De aanvallers misbruikten legitieme OAuth-toestemming en verkeerd geconfigureerde gasttoegang — een geval van functies die werken zoals ontworpen en tegen de gebruikers worden gekeerd.
Had MFA dit tegengehouden?
Niet op zichzelf. MFA beschermt de aanmelding, maar misbruik van OAuth-tokens gebeurt nadat een gebruiker een app al heeft geautoriseerd. De verdediging is governance van toestemming en tokenmonitoring, niet sterkere aanmeldfactoren.
Wat is een „connected app“ in deze context?
Het is een applicatie van derden die via OAuth API-toegang tot een Salesforce-organisatie krijgt. Legitieme (Data Loader, analytics-tools) zijn gangbaar, en dat is juist waarom een kwaadaardige kloon erdoorheen glipt.
Hoe weet ik of ik getroffen ben?
Controleer je geautoriseerde connected apps en OAuth-toekenningen, trek alles in wat onbekend is en bekijk de API-aanroeplogs op ongebruikelijke bulkexports. Als je Salesloft, Gainsight of Klue gebruikt, behandel hun bekendgemaakte incidenten dan als aanleiding om tokens te roteren.
Is dit alleen een Salesforce-probleem?
Nee. Elk SaaS-platform met OAuth van derden — Google Workspace, Microsoft 365, Slack, GitHub — draagt hetzelfde risico van consent-phishing. Het bovenstaande draaiboek is platformonafhankelijk.
Sources
- Microsoft Security — SaaS-gebaseerde applicaties verdedigen tegen OAuth-misbruik door ShinyHunters (13 juli 2026) — primaire threat-intel-bekendmaking en verdedigingsaanbevelingen.
- The Hacker News — Microsoft brengt een jaar aan ShinyHunters-activiteit in kaart — samenvatting van de aanvalsroutes, de schaal en de berichtgeving over slachtoffers.
- Google Cloud Threat Intelligence — Proactieve verdediging tegen SaaS-afpersing door ShinyHunters — tracking van UNC6040/UNC6395 en detectierichtlijnen.
- Varonis — Salesforce-vishingdreiging (UNC6040) — mechaniek van de Data Loader-imitatie.
- Mitiga — ShinyHunters en UNC6395: de inbraken bij Salesforce en Salesloft — detail over de tokendiefstal in de toeleveringsketen.
- Health-ISAC — Impact van ShinyHunters op de gezondheidssector — mitigatierichtlijnen voor de sector.
- FINRA — Beveiligingswaarschuwing over Salesforce Experience Cloud — route via de verkeerd geconfigureerde gasttoegang.
Waqas Ahmed Waseer
Waqas Ahmed Waseer is ontwikkelaar en automation-builder met meer dan 8 jaar ervaring in het bouwen van productiesystemen die door 100.000+ mensen worden gebruikt. Hij bouwt custom multi-tenant SaaS, AI-automatisering (n8n, LLM-workflows, WhatsApp-bots) en hostinginfrastructuur (WHM/cPanel, CloudLinux) — en is de maker van WaSphere, FlowMaticX en het hostingmerk WaseerHost. 100+ projecten opgeleverd voor mkb, bureaus en gefinancierde startups.
