Ce qui est arrivé à Marcus & Millichap
Marcus & Millichap, Inc. (NYSE : MMI), l’un des plus grands courtiers en immobilier commercial américains, a été listé sur le site de fuites de ShinyHunters le 12 avril 2026. Le groupe a revendiqué l’accès à plus de 30 millions d’enregistrements Salesforce contenant des informations d’identification personnelle et des données corporatives internes, et a fixé une date limite finale de rançon au 14 avril 2026 avant de publier ou vendre les données.
L’attaque a suivi la méthode désormais standard de ShinyHunters : exploiter un environnement Salesforce mal configuré ou un flux OAuth, exfiltrer les données CRM en utilisant l’outil Data Loader de Salesforce, et extorquer la victime sous menace de publication. Aucune vulnérabilité produit Salesforce n’a été requise — les attaquants ont exploité la manière dont le tenant Salesforce de Marcus & Millichap était configuré.
L’incident Marcus & Millichap s’inscrit dans une campagne bien plus large. En mars 2026, ShinyHunters avait déjà revendiqué les fuites de McGraw-Hill (45 millions d’enregistrements via mauvaise configuration Salesforce), Rockstar Games, et prétendument Cisco CRM. Au même mois, le groupe revendiquait 300 à 400 organisations compromises via Salesforce, dont environ 100 de haut profil.
Comment ShinyHunters pirate réellement Salesforce
Tiré des analyses forensiques de Help Net Security, Mitiga, Varonis, Safestate et Security Boulevard, ShinyHunters exécute trois principaux schémas d’attaque contre les tenants Salesforce :
1. Mauvaise configuration utilisateur invité Experience Cloud (Aura)
Les sites Salesforce Experience Cloud (anciennement Community Cloud) bâtis sur le framework Aura permettent un profil « Guest User » avec des permissions par défaut. Des profils invités mal configurés — spécifiquement, la permission API Enabled laissée activée — laissent tout visiteur non authentifié interroger des objets Salesforce via des appels API anonymes.
ShinyHunters a construit et utilisé un outil open-source appelé AuraInspector pour automatiser cette découverte à travers des milliers de sites Experience Cloud. Une fois un site avec un accès invité trop permissif trouvé, l’outil énumère les objets accessibles et extrait les enregistrements.
2. Abus du flux de dispositif OAuth via vishing
Pour les tenants sans profils invités exposés, le groupe pivote vers l’ingénierie sociale. Le flux de dispositif OAuth est conçu pour des appareils sans navigateur (TV connectées, outils CLI) — une victime visite une URL de vérification, entre un code court et autorise l’application.
ShinyHunters en abuse en :
- Exécutant Salesforce Data Loader localement, configuré pour initier un flux de dispositif OAuth.
- Générant le code de vérification de 8 caractères.
- Plaçant un appel de vishing à un administrateur Salesforce anglophone, se faisant passer pour le support IT ou un fournisseur.
- Dirigeant la victime vers l’URL de vérification de Salesforce et dictant le code.
- À l’approbation de la victime, Salesforce émet un jeton d’accès vers l’instance Data Loader de l’attaquant.
- Exfiltration silencieuse et cadencée des données CRM par petits morceaux pour éviter de déclencher la détection d’anomalies.
3. Abus d’applications connectées OAuth (Salesloft / UNC6040)
ShinyHunters et le cluster adjacent UNC6040 (selon Mitiga) ont compromis des applications tierces connectées à Salesforce via OAuth — notamment Salesloft — et ont utilisé ces jetons persistants pour interroger les tenants Salesforce en aval.
Publicité
Pourquoi la détection est en retard
La permission API Enabled Salesforce est visible dans chaque console admin de tenant. Les applications connectées OAuth apparaissent dans chaque liste d’audit Connected App. Pourtant, fuite après fuite atterrit sur le site de ShinyHunters parce que :
- L’abus de jeton OAuth est invisible aux SIEM hérités. Le CISO Report 2026 a trouvé que 84,8 % des RSSI considèrent leurs outils de sécurité inadéquats pour détecter l’abus de jeton OAuth ou de clé API.
- L’outillage de sécurité SaaS est fragmenté. CASB, SSPM et journaux natifs SaaS se corrèlent rarement dans une chronologie unique.
- L’ingénierie sociale bat les contrôles. Un appel vishing convainc un administrateur légitime d’autoriser l’attaquant. Chaque contrôle IAM en aval se comporte alors « correctement ».
- Data Loader est un outil légitime. L’exfiltration ressemble à un job d’intégration normal.
Le plan de verrouillage SaaS
Consolidé depuis Varonis, Help Net Security, Apex Hours et les orientations propres à Salesforce, priorisé pour action immédiate :
Immédiat (cette semaine)
- Désactiver « API Enabled » dans le profil Guest User sur chaque site Experience Cloud. Setup → Guest User Profile → System Permissions → décocher. C’est le contrôle le plus impactant contre les attaques de type AuraInspector.
- Auditer toutes les Connected Apps avec accès OAuth. Setup → Apps → Connected Apps OAuth Usage. Révoquez toute application non reconnue ou dormante. Ré-autorisez uniquement celles dont vous avez activement besoin.
- Imposer Salesforce API Access Control. Restreignez quels utilisateurs et quelles plages d’IP peuvent appeler les API Salesforce. L’accès admin production devrait être en allowlist sur les plages corporate et VPN.
30 jours
- Roter et raccourcir les durées de vie des jetons OAuth. Réduisez le TTL du refresh token au minimum toléré par vos intégrations. Forcez la ré-authentification sur les sessions suspectes.
- Imposer une MFA résistante au phishing pour tous les admins Salesforce. Clés matérielles FIDO2, pas SMS. Les attaques de vishing dépendent de parler à une cible à travers un code ; FIDO2 exige que l’attaquant possède la clé physique.
- Déployer SaaS Security Posture Management (SSPM). Des outils comme AppOmni, Obsidian, Grip ou Wing Security auditent continuellement la configuration Salesforce et signalent la dérive.
- Intégrer Salesforce Event Monitoring à votre SIEM. Surveillez les exécutions Data Loader inhabituelles, les tirages d’API en bulk et l’activité API hors heures.
Stratégique (90 jours +)
- Construire un runbook de réponse à incident SaaS. L’IR SaaS diffère de l’IR on-prem : pas de poste à isoler, journaux détenus par le fournisseur, et la victime ne peut « débrancher le câble réseau ». Répétez la révocation de jeton, le kill de session en masse et les chemins d’escalade fournisseur.
- S’entraîner contre le vishing. Exercices red team qui simulent un appel vishing d’administrateur Salesforce, avec l’administrateur comme cible blue team. Mesurez qui approuve la fausse requête OAuth.
- Consolider l’identité SaaS sous SSO avec accès conditionnel strict. Salesforce, HubSpot, Workday, ServiceNow — chaque SaaS derrière le même fournisseur d’identité avec posture de dispositif, géolocalisation et règles d’authentification renforcée.
Ce que cela signifie globalement
La campagne Salesforce de ShinyHunters est l’incident cyber le plus instructif de 2025-2026 parce qu’il attaque la réalité opérationnelle des entreprises modernes : le CRM est la source de vérité pour les données clients, et la sécurité SaaS est encore traitée comme le problème du fournisseur. Elle ne l’est pas. Configuration, identité et gouvernance OAuth sont la responsabilité du client.
Toute entreprise exploitant Salesforce — et par extension tout grand tenant SaaS — a la même surface d’exposition. Le cas Marcus & Millichap ne sera pas le dernier. Les organisations qui investissent maintenant dans SSPM, FIDO2 et la répétition IR SaaS seront sur la shortlist de celles qui éviteront le site de fuites en 2027.
Questions Fréquemment Posées
ShinyHunters a-t-il exploité une vulnérabilité produit Salesforce ?
Non. Chaque incident public retrace à une configuration côté client (permissions Guest User), ingénierie sociale (vishing flux de dispositif OAuth) ou compromission d’application tierce connectée (chaîne d’approvisionnement de type Salesloft). Salesforce a corrigé les problèmes liés à Aura mais le schéma exploitable est la permissivité par défaut conservée par les clients. C’est un échec du modèle de responsabilité partagée.
Comment les entreprises devraient-elles détecter une intrusion ShinyHunters active ?
Surveillez Salesforce Event Monitoring pour : lectures API bulk inhabituelles, sessions Data Loader depuis IP inattendues, nouvelles autorisations d’app OAuth et activité admin hors heures. Intégrez-les à votre SIEM avec des playbooks qui révoquent automatiquement les jetons et verrouillent les sessions. Sans Event Monitoring, la détection est quasi-impossible.
Payer la rançon empêche-t-il la fuite des données ?
L’évidence historique à travers les victimes de ShinyHunters suggère que payer n’empêche pas de manière fiable les fuites, et peut financer d’autres campagnes. Le FBI et la plupart des CERT nationaux déconseillent le paiement. Les organisations devraient planifier le scénario de divulgation publique indépendamment de la décision de paiement — notification client, dépôts réglementaires et réponse réputationnelle doivent être répétés.
Sources et lectures complémentaires
- Cisco CRM « Salesforce Data Breach » Claims Tied to ShinyHunters — Security Boulevard
- ShinyHunters Target Marcus & Millichap in Major Ransomware Attack — DeXpose
- ShinyHunters claims new campaign targeting Salesforce Experience Cloud sites — Help Net Security
- ShinyHunters and UNC6395: Inside the Salesforce and Salesloft Breaches — Mitiga
- What Salesforce Organizations Need to Know About ShinyHunters and Vishing — Varonis
- McGraw-Hill Salesforce Data Breach 2026 Analysis — Rescana
