Identifiants d'applications Entra ID volés : l'alerte qui vise les prestataires informatiques

L'essentiel en 30 secondes

Entre le 1er et le 3 novembre 2026, des connexions malveillantes à Microsoft Entra ID ont été observées dans plusieurs organisations sans lien entre elles, dont des prestataires informatiques (MSP) et des tenants clients qu'ils gèrent. Particularité : l'attaquant ne s'est pas connecté avec le compte d'un utilisateur, mais avec les identifiants valides d'applications, ce que Microsoft appelle des principaux de service.

• Indicateur publié : l'adresse IP 199.19.77[.]84.
• Ce qui n'est pas encore connu : comment les identifiants ont été obtenus, et l'ampleur exacte de la campagne.
• Pourquoi c'est sérieux : une application n'a pas de double authentification. Celui qui détient son secret dispose de tous ses droits, parfois sur des dizaines de tenants à la fois.

L'alerte nous a été transmise par le SOC partenaire avec lequel nous assurons la surveillance 24/7 de nos clients. Nous l'avons vérifiée le jour même sur notre propre tenant et sur ceux de nos clients : le résultat est détaillé plus bas. Cet article explique ce qu'est une identité d'application, pourquoi les prestataires sont visés, et les vérifications à faire, que vous gériez votre informatique en interne ou avec un prestataire.

Ce qui s'est passé : ce qu'on sait, ce qu'on ne sait pas

L'avis recommande aussi de vérifier qu'aucun fichier .env ou de configuration exposé publiquement ne contient de secret. C'est une source de fuite classique, mais ce n'est pas, à ce stade, une cause établie de cette campagne. Nous mettrons cet article à jour si l'enquête apporte des éléments nouveaux.

Une application qui se connecte toute seule : de quoi parle-t-on ?

Votre tenant Microsoft 365 n'est pas utilisé que par vos collaborateurs. Des logiciels s'y connectent aussi, en continu : la sauvegarde de vos boîtes mail, le filtrage antispam, l'outil de supervision de votre prestataire, un connecteur vers votre CRM. Chacun dispose dans votre tenant d'une identité propre, le principal de service, et de droits que vous, ou votre prestataire, lui avez accordés.

Pour prouver son identité, l'application présente :

• soit un secret, une longue chaîne de caractères qui joue le rôle d'un mot de passe ;
• soit un certificat, plus robuste : Microsoft rappelle qu'un certificat, contrairement à un secret, ne peut pas se retrouver collé par erreur dans du code.

Ces connexions n'impliquent aucun utilisateur. Elles apparaissent dans un journal à part, les « connexions de principal de service », que peu d'entreprises consultent. Et elles échappent aux protections pensées pour les humains :

• pas de double authentification : Microsoft le précise, une identité de charge de travail ne peut pas en faire ;
• pas de règles d'accès conditionnel « utilisateurs » : celles qui exigent un appareil géré ou bloquent certains pays ne s'appliquent pas ;
• des droits souvent larges : une application de sauvegarde lit toutes les boîtes mail, un outil d'administration peut créer des comptes ou modifier des règles de sécurité.

Un secret d'application volé, c'est donc un accès direct, silencieux et durable, tant que personne ne le révoque.

Pourquoi les prestataires informatiques sont en première ligne

Un prestataire qui administre des dizaines de tenants utilise souvent une application multitenant : une seule application, enregistrée chez lui, autorisée dans le tenant de chacun de ses clients. C'est pratique et légitime ; c'est aussi un point de concentration du risque. Un seul secret volé peut ouvrir la porte de tous les clients où l'application est autorisée, avec les droits qui lui ont été accordés.

Les éditeurs de logiciels que vous avez connectés à Microsoft 365 sont dans la même situation : leur application est présente chez des milliers de clients. La sécurité de votre tenant dépend donc aussi de la façon dont ces tiers protègent leurs secrets.

Une limite technique aggrave le problème. L'accès conditionnel pour les identités de charge de travail, qui permet de bloquer une application hors des adresses IP attendues, ne couvre que les applications à locataire unique enregistrées dans votre propre tenant. Microsoft l'indique explicitement : les applications multitenants et les applications SaaS tierces ne sont pas couvertes. Pour l'application de votre prestataire ou de votre éditeur, la protection repose sur lui : stockage des secrets, usage de certificats, surveillance des connexions.

Ce que nous avons vérifié le 4 novembre

Pour administrer les tenants de nos clients, nous utilisons nous-mêmes une application multitenant. C'est donc par nous que nous avons commencé. Le 4 novembre, nous avons interrogé :

Ces résultats valent pour l'indicateur connu à ce jour. Si l'enquête publie d'autres adresses, nous referons la recherche.

Le contrôle a aussi rappelé une évidence : en quatre jours, nos équipes ont créé ou autorisé plusieurs applications dans les tenants de nos clients, pour des projets tout à fait légitimes. Dans un journal d'audit, un ajout de secret fait par un technicien ressemble beaucoup à celui d'un attaquant. Seule une traçabilité rigoureuse (qui a fait quoi, pour quel ticket) permet de les distinguer rapidement.

Les six vérifications à mener

Que vous ayez un service informatique interne ou un prestataire, voici ce qu'il faut lui demander, dans cet ordre.

1. Chercher l'adresse IP dans les journaux, sans attendre

Dans le centre d'administration Microsoft Entra, Surveillance et intégrité > Journaux de connexion, il faut filtrer sur l'adresse 199.19.77.84 dans trois onglets : les connexions de principal de service, les connexions utilisateur non interactives et, par précaution, les connexions interactives. Le seul onglet ouvert par défaut ne suffit pas.

Pour une équipe technique qui gère plusieurs tenants, la même recherche en une requête Microsoft Graph :

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-10-25T00:00:00Z and ipAddress eq '199.19.77.84' and signInEventTypes/any(t: t eq 'servicePrincipal' or t eq 'nonInteractiveUser' or t eq 'interactiveUser' or t eq 'managedIdentity')

Le temps presse : les journaux sont conservés sept jours avec Entra ID Free et trente jours avec Entra ID P1 ou P2, inclus dans Microsoft 365 Business Premium. Une activité du 1er novembre disparaît des tenants sans licence P1 dès le 8 novembre. En cas de résultat, exportez immédiatement les journaux concernés.

2. Bloquer au niveau de l'identité, pas du pare-feu

Bloquer l'adresse sur le pare-feu de l'entreprise ne sert à rien : l'attaquant ne traverse pas votre réseau, il s'adresse directement à Microsoft. Pour les applications enregistrées dans votre tenant, une règle d'accès conditionnel pour les identités de charge de travail peut bloquer toute demande de jeton venant d'ailleurs que des adresses IP attendues, ou présentant un risque détecté par Microsoft Entra ID Protection. Trois points à connaître :

• elle demande une licence Workload Identities Premium ;
• la seule action possible est le blocage, et le principal de service doit être ciblé directement dans la règle : l'ajouter à un groupe ne suffit pas ;
• elle ne protège pas les applications multitenants ni les applications SaaS tierces.

Le mode « rapport seulement » permet de mesurer l'effet avant d'appliquer la règle.

3. Contenir toute application compromise

Si une application s'est connectée depuis l'adresse suspecte : désactiver la connexion de son principal de service, puis supprimer et remplacer ses secrets et certificats. Avant de couper, il faut identifier ce qui dépend de cette application (une sauvegarde, un flux de facturation) et prévenir son éditeur, qui doit faire la même chose de son côté si l'application est la sienne.

4. Mesurer ce que l'application pouvait faire, et ce qu'elle a fait

Les droits de l'application (permissions sur les API, rôles d'administration, consentements accordés) indiquent ce que l'attaquant pouvait faire. Pour savoir ce qu'il a fait, il faut croiser les connexions avec le journal d'audit Entra ID et le journal d'audit unifié de Microsoft 365, qui sont deux journaux distincts. Microsoft publie un guide d'investigation des applications compromises qui détaille la démarche. Là encore, conservez les journaux avant leur expiration.

5. Chercher les portes laissées ouvertes

Un attaquant qui contrôle une application cherche souvent à s'y maintenir : ajout d'un nouveau secret ou certificat, ajout d'un propriétaire, nouvelles permissions, attribution d'un rôle d'administration. Ces changements figurent dans le journal d'audit Entra ID, catégorie « gestion des applications ». Ils doivent être examinés même s'ils proviennent d'une autre adresse IP que celle de l'alerte : rien n'oblige l'attaquant à n'en utiliser qu'une.

6. Réduire la valeur d'un secret volé

C'est le chantier de fond, et il ne dépend pas de cette campagne :

• inventorier les applications autorisées dans le tenant et supprimer celles qui ne servent plus, ainsi que les secrets expirés ou inutilisés ;
• préférer les certificats aux secrets, de courte durée : Microsoft recommande de désactiver les secrets d'application et de limiter la durée de vie des certificats à 180 jours ;
• stocker les secrets dans un coffre (Azure Key Vault ou équivalent), jamais dans un fichier .env, un script ou un dépôt de code, et vérifier qu'aucun fichier de configuration n'est accessible depuis Internet ;
• pour les éditeurs d'applications multitenants, verrouiller les propriétés sensibles de l'application (le verrouillage d'instance d'application), pour qu'aucun secret ne puisse être ajouté à son principal de service dans un tenant client ;
• réduire les droits au strict nécessaire : une application qui lit des rapports n'a pas besoin de pouvoir créer des comptes.

Les questions à poser à votre prestataire

Votre prestataire dispose presque certainement d'une application dans votre tenant. Quatre questions suffisent à savoir s'il a pris l'alerte au sérieux :

1. Avez-vous recherché l'indicateur dans notre tenant, et qu'avez-vous trouvé ? Une réponse précise, datée, avec les journaux consultés.
2. Quelles applications avez-vous installées chez nous, avec quels droits ? Il doit pouvoir en fournir la liste.
3. Comment leurs secrets sont-ils protégés ? Certificats ou secrets, coffre-fort, rotation, surveillance des connexions.
4. Nos journaux sont-ils conservés au-delà de trente jours ? Sinon, une compromission découverte tardivement ne pourra plus être reconstituée.

Ce sont des critères concrets pour choisir ou évaluer un prestataire de cybersécurité. Pour la protection des comptes utilisateurs, notre guide de l'accès conditionnel et notre article sur les connexions suspectes à Microsoft 365 complètent cette lecture.

Sources

• Avis de menace transmis par notre SOC partenaire aux MSP qu'il protège, novembre 2026 (diffusion restreinte)
• Microsoft : connexions de principal de service dans Microsoft Entra ID
• Microsoft : accès conditionnel pour les identités de charge de travail
• Microsoft : sécuriser les principaux de service dans Microsoft Entra ID
• Microsoft : bonnes pratiques de sécurité pour les propriétés des applications, verrouillage d'instance
• Microsoft : imposer des règles pour les secrets et certificats d'application
• Microsoft : durée de conservation des journaux Microsoft Entra
• Microsoft : guide d'investigation des applications compromises ou malveillantes