OAuth consent-phishing: hoe aanvallers uw Salesforce-data stelen terwijl MFA gewoon aan staat

MFA beschermt uw aanmeldscherm, maar niet uw OAuth consent. Aanvalsgroep ShinyHunters infiltreert Salesforce-omgevingen via nep-apps, supply chain-integraties en slecht geconfigureerde gasttoegang — zonder uw wachtwoord of MFA aan te raken. Wat er speelt en wat u nu doet.

Multifactorauthenticatie is inmiddels de norm bij de meeste organisaties. Het beschermt het aanmeldmoment effectief: zonder de tweede factor komt een aanvaller niet verder. Maar er is een aanvalsvector die buiten dat aanmeldmoment gaat. OAuth consent-phishing omzeilt MFA niet door het te kraken — het omzeilt MFA door het volledig irrelevant te maken.

Aanvalsgroep ShinyHunters, bekend van grote datalekken bij internationale consumenten- en zakelijke platformen, heeft de afgelopen twaalf maanden op grote schaal Salesforce-omgevingen gecompromitteerd via drie aanvalspaden die allemaal op OAuth consent steunen. Microsoft publiceerde daar deze week een gedetailleerde analyse over, inclusief de update van de Salesforce-connector in Defender for Cloud Apps om deze aanvallen beter te detecteren.

Wat OAuth consent is en waarom het een risico vormt

OAuth is het protocol dat applicaties namens een gebruiker toegang geeft tot een platform. Wanneer een medewerker een app koppelt aan Salesforce, klikt ze 'Toestaan' op een consent-scherm. Dat scherm toont welke data de app mag lezen of bewerken. Na die klik ontvangt de app een access token dat langdurig geldig blijft, soms weken of maanden, ook nadat de medewerker is uitgelogd.

Dat is het aanvalsoppervlak. Als een aanvaller een medewerker kan bewegen om een kwaadaardige app te autoriseren, heeft die aanvaller API-toegang tot alles wat de medewerker ook kan zien. Het platform — Salesforce, Microsoft 365, welk SaaS-systeem dan ook — ziet een legitieme, door de gebruiker verleende autorisatie. Er is geen gestolen wachtwoord, geen onderschept MFA-token, geen verdachte inlogpoging vanuit een onbekend IP.

De drie aanvalspaden van ShinyHunters

Microsoft bracht drie aanvalspaden in kaart die ShinyHunters de afgelopen periode heeft ingezet. Ze overlappen elkaar soms, maar elk pad werkt ook zelfstandig.

Het eerste pad is vishing gecombineerd met een nep-consent-scherm. Een medewerker wordt gebeld door iemand die zich voordoet als IT-support of Salesforce-partner. De beller begeleidt de medewerker door een OAuth-consent-scherm voor een applicatie die eruitziet als de officiële Salesforce Data Loader. Na de klik op 'Toestaan' heeft de aanvaller volledige API-toegang tot het CRM-account van die medewerker, inclusief alle klantdata, kansen en contacten.

Het tweede pad loopt via supply chain-integraties. Platforms als Salesloft en Gainsight zijn legitieme applicaties die bij veel organisaties al zijn gekoppeld aan Salesforce. Aanvallers compromitteren een account bij zo'n integratieleverancier of misbruiken gedeelde service-accounts met ruime rechten. Omdat de koppeling al bestaat en vertrouwd is, valt een uitbreid toestemmingsverzoek minder op. De bestaande vertrouwensstatus wordt als hefboom gebruikt om aanvullende scopes te verkrijgen.

Het derde pad is misbruik van slecht geconfigureerde gasttoegang in Microsoft Entra. Organisaties die externe partners of freelancers als gastgebruikers toelaten met te brede rechten, creëren een brug naar gekoppelde SaaS-applicaties. Via een Entra-gastaccount met onnodig hoge rechten kunnen aanvallers lateraal bewegen naar Salesforce en andere verbonden platformen die via de Microsoft-identiteit zijn gekoppeld.

Waarom MFA deze aanvallen niet stopt

Dit is het punt dat veel organisaties verrast. Bij klassieke phishing steelt een aanvaller een wachtwoord en probeert vervolgens in te loggen, waarna MFA de aanval stopt. Bij OAuth consent-aanvallen is de medewerker degene die inlogt, met hun eigen account, inclusief MFA, en vervolgens toestemming geeft aan een app. Het platform registreert een legitieme handeling door een geauthenticeerde gebruiker.

Het resultaat is een access token dat volledig los staat van de sessie en de MFA-verificatie. Dat token werkt via de API, niet via het inlogscherm. De aanvaller logt nooit in als de gebruiker. Ze gebruiken de API alsof ze de applicatie zijn die de medewerker heeft geautoriseerd.

Wat Microsoft Defender for Cloud Apps nu detecteert

Microsoft heeft de Salesforce-connector voor Defender for Cloud Apps uitgebreid met verbeterde detectiemogelijkheden. De vernieuwde connector biedt rijkere context over verbonden apps: welke OAuth-applicaties zijn geautoriseerd, door wie, met welke permissies en wanneer voor het laatst actief. Dit maakt anomaliedetectie mogelijk op basis van consent-gedrag.

Defender for Cloud Apps genereert nu alerts wanneer een gebruiker buiten werktijd een onbekende app autoriseert, wanneer een app scopes aanvraagt die ver buiten de organisatienorm liggen, of wanneer een verbonden app plotseling meer data opvraagt dan verwacht. De Salesforce-connector koppelt deze signalen aan de identiteitscontext uit Microsoft Entra, zodat het volledige aanvalspad zichtbaar wordt in Microsoft Sentinel of de Defender-portal.

Vijf maatregelen die uw organisatie beschermen

Geen enkele maatregel elimineert het risico volledig, maar de combinatie van de onderstaande vijf stappen verkleint het aanvalsoppervlak aanzienlijk.

Beperk gebruikersconsent in Microsoft Entra. Stel in dat eindgebruikers geen OAuth consent mogen verlenen aan apps buiten een goedgekeurde lijst. Apps zonder goedkeuring vereisen dan een admin consent request, die een beheerder beoordeelt voordat toegang wordt verleend. Deze instelling zit in Entra onder Enterprise Applications, User Settings.

Activeer de Salesforce-connector in Defender for Cloud Apps. Als uw organisatie Defender for Cloud Apps heeft maar de Salesforce-integratie niet actief is, is dat een blinde vlek. De connector geeft overzicht van alle verbonden apps, actieve tokens en afwijkend API-gedrag. Trek vervolgens de tokens in van apps die niet actief worden gebruikt.

Audit externe applicatie-integraties. Controleer periodiek welke permissions Salesloft, Gainsight, HubSpot en andere gekoppelde platforms hebben in uw Salesforce-omgeving. Service-accounts die worden gebruikt voor deze koppelingen mogen niet meer rechten hebben dan strikt noodzakelijk. Verwijder koppelingen van applicaties die uw organisatie niet meer actief inzet.

Verscherp de gasttoegang in Microsoft Entra. Controleer de instellingen voor External Collaboration en beperk wat gastgebruikers mogen doen. Gasten mogen standaard niet in staat zijn de gebruikerslijst te doorzoeken, teams te joinen zonder uitnodiging of apps te autoriseren namens de organisatie.

Train medewerkers op OAuth consent-schermen. Phishingbewustzijn richt zich traditioneel op e-mails met verdachte links. OAuth consent-aanvallen verlopen via telefoongesprekken en lijken op een gewone autorisatiestap. Een korte bewustwordingssessie over wat IT-support nooit telefonisch vraagt en hoe een legitiem versus verdacht consent-scherm eruitziet, maakt een concreet verschil.

Wat u deze week kunt doen

Begin met een inventarisatie van de OAuth-applicaties die momenteel actieve tokens hebben in uw Salesforce-omgeving en uw Microsoft 365-tenant. De meeste IT-teams weten hoeveel gebruikers ze hebben, maar niet hoeveel apps actieve API-toegang hebben. Die blinde vlek is precies wat ShinyHunters uitbuit.

Controleer daarna de gebruikersconsent-instellingen in Entra. Als gebruikers momenteel vrij applicaties mogen autoriseren zonder beheerdersgoedkeuring, is dat een laagdrempelige aanpassing met direct effect. De instelling is binnen vijf minuten te wijzigen.

OAuth consent-aanvallen illustreren dat beveiliging verder gaat dan het aanmeldscherm. Ze omvat ook welke apps toegang hebben tot uw data, hoe lang die toegang geldig blijft en wie dat bijhoudt. Wilt u hulp bij de inventarisatie van verbonden applicaties, het inrichten van Defender for Cloud Apps of het aanscherpen van uw Entra-beleid voor externe app-autorisatie? Neem contact op met Zarioh.