Les administrateurs Salesforce reçoivent depuis plusieurs mois des emails alarmants mentionnant une mise à jour obligatoire de l’API SOAP sous peine de blocage. Ces messages, techniquement crédibles et urgents, contournent les filtres anti-spam et exploitent la confusion liée aux reports répétés du MFA renforcé. Nous analysons ici pourquoi cette campagne de phishing ciblant l’API SOAP rend l’authentification multifacteur inefficace si l’utilisateur tombe dans le piège, et comment vérifier la légitimité de ces demandes sans mettre en péril vos accès.

Pourquoi ces faux messages « Unsupported SOAP API » passent à travers les mailles

L’ingénierie sociale repose sur la crédibilité technique. Les attaquants ne vous demandent pas de vérifier un virement bancaire suspect, mais d’agir sur un composant infrastructurel précis : l’API SOAP. Ce protocole, bien que vieillissant, reste crucial pour certaines intégrations comme Microsoft Entra ou Data Loader en ligne de commande. En utilisant le jargon exact des développeurs et des administrateurs système, ces emails créent un sentiment d’urgence professionnelle immédiate.

Ces courriels sont conçus spécifiquement pour contourner les filtres anti-spam classiques. Ils n’utilisent pas de liens suspects évidents ni de fautes d’orthographe grossières. À la place, ils imitent le ton administratif des notes de version officielles de Salesforce, mentionnant des dates de déploiement futures (comme Summer ’27) et des permissions spécifiques (« Use Any API Auth »). Cette précision technique désarme la méfiance naturelle d’un profil IT habitué à recevoir ce type de communication.

Nous avons observé que beaucoup d’administrateurs, submergés par les changements constants de la plateforme, ont tendance à ignorer ces alertes par défaut ou à les traiter rapidement sans vérifier la source. C’est précisément cette fatigue décisionnelle que les attaquants exploitent. Ils savent que vous êtes pressé et que le terme « SOAP API » évoque pour vous une dette technique qu’il faudra bien résoudre un jour.

Le MFA ne bloque pas l’homme au milieu (Adversary-in-the-Middle)

Il existe une idée reçue tenace selon laquelle l’activation du MFA (Multi-Factor Authentication) immunise contre le phishing. C’est faux dans le cas des attaques de type « Adversary-in-the-Middle » (AiTM). Dans ce scénario, l’email de phishing redirige l’utilisateur vers une page de connexion clone, visuellement identique à celle de Salesforce.

Lorsque vous saisissez votre identifiant et mot de passe sur ce site frauduleux, celui-ci les transmet en temps réel aux serveurs légitimes de Salesforce. La plateforme répond alors en demandant le second facteur (code SMS, application authenticator ou clé de sécurité). L’utilisateur, voyant cette demande légitime, saisit son code. L’attaquant récupère ce code, le valide auprès de Salesforce, et vole le token de session actif. Une fois en possession de ce token, il peut accéder à votre instance sans avoir besoin de se reconnecter, rendant le MFA initial totalement inutile.

Selon les analyses de l’ANSSI sur les attaques AiTM, cette méthode permet aux cybercriminels de contourner les protections les plus robustes tant que l’utilisateur final interagit avec la page de fraude. Le problème n’est pas la faiblesse du MFA, mais le fait qu’il soit validé sur une infrastructure contrôlée par l’attaquant.

La confusion créée par les reports du MFA renforcé

Le contexte actuel amplifie la vulnérabilité des équipes. Salesforce a reporté à plusieurs reprises l’obligation d’utiliser un MFA résistant au phishing (comme les passkeys), créant une zone grise où les utilisateurs ne savent plus quelle norme s’applique. Comme le rapportent de nombreux administrateurs sur les forums spécialisés, ce délai répété dans l’application du MFA renforcé nourrit la confusion.

Cette incertitude est une fenêtre d’opportunité pour les phishers. Quand une organisation ne sait pas exactement quand une mesure de sécurité devient obligatoire, elle tend à croire que toute communication urgente concernant la sécurité est légitime. Les attaquants jouent sur ce flou : « Vous devez agir maintenant car la date limite approche », même si aucune date officielle n’a été fixée par l’éditeur.

Nous constatons également que les intégrations tierces compliquent la donne. Par exemple, la synchronisation des utilisateurs via Microsoft Entra ID utilise encore l’API SOAP pour le provisioning. Un administrateur qui reçoit une alerte sur l’API SOAP sait que son système d’identité est concerné, ce qui augmente la probabilité qu’il clique sur le lien fourni dans l’email pour « vérifier la configuration ».

Comment vérifier une alerte Salesforce sans cliquer

Face à ce type de menace, la règle d’or est de ne jamais utiliser les liens présents dans l’email, même s’ils semblent pointer vers salesforce.com. Voici la procédure que nous recommandons pour valider ou infirmer ces alertes techniques :

• Vérifiez dans Setup : Connectez-vous directement à votre instance Salesforce via vos favoris ou en tapant l’URL manuellement. Allez dans Setup > Company Information. Si une action critique est requête concernant les versions d’API ou les permissions, Salesforce affiche généralement une bannière d’avertissement directe dans l’interface d’administration.
• Consultez les Trust Updates : Les communications officielles majeures passent toujours par le statut de confiance de Salesforce (trust.salesforce.com) ou par les notifications in-app dans la section « Release Updates ». Un email isolé sans trace dans ces canaux officiels doit être traité avec scepticisme.
• Analysez les en-têtes de l’email : Regardez l’expéditeur réel. Les vrais emails de Salesforce proviennent de domaines vérifiés. Méfiez-vous des adresses qui utilisent des variations subtiles ou des services de mailing tiers non déclarés.
• Vérifiez vos intégrations : Si l’alerte mentionne l’API SOAP, identifiez quels connecteurs l’utilisent encore (Data Loader, outils de provisioning, anciennes applications métiers). Contactez les éditeurs de ces solutions pour savoir s’ils ont prévu une migration vers REST ou si une mise à jour de permission est effectivement nécessaire.

Pour aller plus loin sur les mécanismes de ces campagnes, nous avions détaillé dans un précédent article pourquoi les alertes SOAP API sont un piège massif. La vigilance reste votre meilleure défense, car aucun filtre automatique ne remplacera le jugement humain face à une ingénierie sociale aussi ciblée.

Notre verdict face au phishing ciblant l’API SOAP

Ne laissez pas la pression technique dicter vos réactions de sécurité. Ces campagnes de phishing profitent de la complexité croissante de l’écosystème Salesforce et de la fatigue des administrateurs. Le MFA est nécessaire, mais il ne suffit pas. Nous insistons sur la formation régulière des équipes IT à la reconnaissance des urls clonées et sur l’usage systématique des bookmarks pour accéder aux consoles d’administration. Ne cliquez jamais sur un lien d’urgence reçu par email, aussi technique soit-il. Prenez cinq minutes pour vérifier l’information directement dans votre instance.