ShinyHunters : l'abus d'OAuth qui contourne la MFA sur Salesforce et M365

Le 13 juillet 2026, Microsoft a détaillé une série de campagnes attribuées à un mode opératoire associé à ShinyHunters, actif de mi-2025 à mi-2026, visant à contourner l'authentification multifacteur sur des applications SaaS en abusant de connexions OAuth de confiance. L'intérêt de ce cas est qu'il illustre une classe de menace encore mal couverte par beaucoup d'équipes : l'attaque ne casse aucun mot de passe et ne déclenche aucune anomalie de connexion, parce qu'elle n'utilise pas de connexion au sens classique. Elle s'appuie sur un jeton OAuth accordé par un utilisateur légitime.

Le mécanisme : le consentement fait tout le travail

Le schéma central est simple et redoutable. Une fausse application, présentée comme un outil Salesforce Data Loader, trompe un employé pour qu'il accorde un consentement OAuth. Une fois ce consentement donné, l'attaquant hérite de la session de l'utilisateur et contourne entièrement la MFA, puisque le jeton OAuth est une autorisation déléguée qui ne repasse pas par l'authentification. C'est la technique T1528 (Steal Application Access Token) suivie de T1550.001 (Use Alternate Authentication Material: Application Access Tokens).

À partir de là, l'attaquant interroge le CRM et procède à l'exfiltration en masse d'enregistrements sensibles, comptes, contacts, données de cas de service, sans générer d'anomalie de connexion traditionnelle. C'est précisément ce qui rend la menace discrète : les tableaux de bord d'identité, qui surveillent les connexions à risque, ne voient rien d'anormal, car aucune connexion à risque n'a lieu.

Une menace qui s'étend par la chaîne d'approvisionnement

Microsoft décrit plusieurs chemins d'attaque au delà du hameçonnage vocal direct. Des identifiants de connexion Salesloft Drift compromis en août 2025 ont exposé des secrets de connexion utilisés à travers plusieurs environnements Salesforce clients. Une campagne visant l'intégration Gainsight en novembre 2025 a permis de conserver un accès API persistant sans déclencher d'anomalie de connexion. Enfin, en juin 2026, un groupe suivi sous le nom de Storm-3138 a compromis la plateforme d'intelligence marché Klue et réutilisé ses identifiants Salesforce pour interroger et voler des données. Les campagnes ont touché des locataires Salesforce dans le commerce de détail, l'éducation et l'industrie.

Ce point est essentiel pour la défense : le jeton abusif ne provient pas nécessairement d'un consentement direct de vos utilisateurs. Il peut venir d'un partenaire ou d'un éditeur intégré à votre environnement dont les secrets ont été volés. La surveillance doit donc couvrir les applications tierces connectées autant que les consentements internes.

Détecter le consentement à une nouvelle application OAuth

Le point de détection le plus direct est le consentement à une application OAuth nouvelle ou peu connue. Entra ID et Salesforce journalisent ces événements. Une règle Sigma sur les journaux d'audit Entra ID peut alerter sur l'ajout d'une autorisation OAuth à une application qui ne figure pas dans une liste d'applications approuvées.

title: Consentement OAuth accorde a une application non approuvee
id: 5a2f8c14-9d63-4b07-8e1a-3c6f0b7d9e42
status: experimental
description: >
  Detecte l octroi d un consentement OAuth a une application, a correler avec
  une liste blanche d applications approuvees pour reperer un abus type ShinyHunters.
references:
  - https://www.microsoft.com/en-us/security/blog/2026/07/13/defending-saas-based-applications-against-shinyhunters-oauth-abuse/
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName|contains:
      - 'Consent to application'
      - 'Add OAuth2PermissionGrant'
      - 'Add delegated permission grant'
  condition: selection
falsepositives:
  - Adoption legitime d une nouvelle application, a filtrer par liste blanche
level: medium
tags:
  - attack.credential_access
  - attack.t1528
  - attack.persistence

Repérer les jetons dormants et l'accès applicatif anormal

Au delà du consentement initial, deux signaux méritent une surveillance. Le premier est l'activité soudaine d'un jeton OAuth resté dormant, un signe classique de réutilisation d'un accès obtenu de longue date. Le second est l'accès en masse à des données CRM par un jeton applicatif à des volumes ou à des heures inhabituels, sans connexion utilisateur correspondante. Corréler l'exfiltration à un jeton applicatif, plutôt qu'à une session interactive, fait ressortir précisément le schéma décrit par Microsoft.

Le contrôle qui coupe la racine du problème

La mesure préventive la plus efficace est d'exiger un consentement administrateur pour toute nouvelle application OAuth. En désactivant le consentement utilisateur libre, vous supprimez la possibilité qu'un employé accorde seul, sous l'effet d'un appel de hameçonnage, un accès délégué à une application malveillante. C'est un réglage de configuration, pas un produit à déployer, et il neutralise le vecteur d'entrée principal. Complétez-le par une revue périodique des applications tierces connectées et de leurs autorisations, en retirant celles qui ne sont plus utilisées ou dont vous ne pouvez pas justifier la présence.

Détecter l'abus d'OAuth demande de surveiller les bons journaux d'identité et de corréler consentement, activité de jeton et exfiltration. C'est ce que fournit le feed Sigma ThreatClaw : des règles pour les environnements cloud et SaaS, construites sur les journaux d'audit et pensées pour attraper les menaces qui ne déclenchent aucune anomalie de connexion.