En décembre 2020, FireEye a découvert une attaque sophistiquée à grande échelle ayant un impact sur le gouvernement américain et de nombreuses entreprises privées. Cela a entraîné la fuite de messages de Microsoft 365 (le nouveau nom d’Office 365). Début janvier, il a été signalé que 3 000 boîtes du ministère de la Justice des États-Unis avaient été compromises de cette manière.
Piratage Solarwinds : quelles sont les conséquences pour la sécurité de la gestion des accès ?
Ce qui a frappé dans l’affaire SolarWinds, c’est la capacité des attaquants à s’infiltrer en profondeur, jusqu’à compromettre le cœur de la gestion des accès de milliers d’organisations. Le logiciel Orion, pièce maîtresse de SolarWinds, a servi de cheval de Troie. La référence solaire dans le nom a inspiré une nuée de surnoms pour l’attaque : Solorigate, SolarStorm, Sunburst… Ici, on retiendra « Sunburst attack » pour désigner ce vecteur précis.
L’opération, complexe, s’est déployée au fil d’une longue succession de compromissions aboutissant au détournement des solutions d’accès Microsoft : ADFS et Azure AD. Ces outils, censés protéger les identités, se sont retrouvés au cœur du problème.
Mais la question se pose : ce type d’usurpation aurait-il pu viser d’autres solutions d’authentification ? Ou bien Microsoft est-il le seul point faible ? Pour y voir clair, il vaut mieux revenir pas à pas sur la façon dont les boîtes ont été piratées, à partir des éléments publics connus à ce jour.
Authentification Microsoft 365
Les attaquants ont pu accéder aux mails de leurs cibles sans jamais avoir leur mot de passe. Leur méthode : générer un jeton d’identité frauduleux, à l’image de la victime, et le présenter à Microsoft 365 qui, n’y voyant que du feu, l’a accepté. Pour comprendre, regardons d’abord le fonctionnement habituel (version simplifiée) : l’utilisateur, pour accéder à M365, est redirigé vers Azure AD pour l’authentification. Azure AD génère alors un jeton, signé avec sa clé privée, qui atteste de l’identité de l’utilisateur. Ce jeton est transmis à M365, qui vérifie la signature à l’aide de la clé publique Azure AD, puis autorise l’accès.
Authentification Microsoft 365
Accéder aux e-mails Microsoft 365 de quelqu’un d’autre
Dans cette affaire, les pirates ont su détourner le flux d’authentification pour générer un jeton Azure AD sans authentification réelle de l’utilisateur. Microsoft 365 a accepté ce faux jeton, ouvrant la porte à la messagerie ciblée. Deux méthodes se sont imposées :
Voici comment ils ont procédé :
- Dans les organisations équipées d’ADFS, ils ont volé la clé privée sur le réseau local, rendant l’attaque quasiment imparable et invisible.
- Pour les infrastructures sans ADFS, ils ont pris le contrôle d’un compte administrateur Azure AD et ajouté une fédération vers leur propre serveur d’authentification. Cette manipulation, plus visible car elle laisse des traces dans la configuration, n’en reste pas moins efficace.
Usurpation d’identité via la clé privée ADFS
ADFS permet à une organisation de faire reposer l’accès à Microsoft 365 sur son propre Active Directory interne. Azure AD ne vérifie plus les identifiants en direct : il délègue à ADFS, qui s’occupe de l’authentification, puis transmet le résultat à Azure AD, qui génère le jeton final pour M365.
Authentification M365 à AD avec ADFS
Avec Sunburst, la faiblesse du protocole SAML dans sa configuration standard a été exploitée. L’utilisateur, détenteur du jeton, peut le manipuler. En volant la clé privée ADFS, l’attaquant façonne un faux jeton SAML, y injecte l’identité qu’il cible, le signe avec la clé volée, puis le présente à Azure AD. Ce dernier lui fait confiance et génère alors un jeton final, reconnu comme légitime par Microsoft 365. Résultat : l’accès à la boîte mail de la victime, sans que personne ne s’aperçoive de la supercherie.
Accès à M365 après le vol de la clé privée ADFS
Tout repose ici sur le vol de la clé privée, opération réalisable en se connectant en tant qu’administrateur au serveur. Une fois ce niveau d’accès obtenu, récupérer la clé devient une simple formalité administrative. L’acteur malveillant doit toutefois déjà être sur le réseau local et disposer de droits élevés. Avant d’aborder la façon dont cet accès a été conquis, voyons la seconde technique utilisée pour compromettre une boîte mail, celle du courtage d’identité, qui exige aussi des droits administrateur.
Passer par le courtage d’identité
Le courtage d’identité réside dans la chaîne de délégation entre serveurs d’identités (IdP). Typiquement, une application délègue l’authentification à un IdP. Dans l’écosystème Microsoft, Office 365 demande à Azure AD d’authentifier l’utilisateur ; Azure AD peut alors demander le mot de passe ou, s’il est configuré ainsi, déléguer à un autre IdP, typiquement via une fédération ADFS. La relation de confiance entre les serveurs s’établit à l’aide de certificats et secrets. Si un attaquant s’octroie les droits d’administrateur Azure AD, il peut établir une fédération avec un serveur d’authentification sous son contrôle. Il définit ainsi l’identité de sa cible, choisit un mot de passe, s’authentifie, et le serveur génère un jeton usurpé. Azure AD fait confiance et délivre un vrai jeton, qui passe toutes les vérifications, mais dont l’identité a été détournée.
Ajout d’une délégation d’authentification frauduleuse
La principale différence avec la méthode de la clé privée, c’est que ces manipulations sont visibles dans la configuration pour les administrateurs vigilants. Mais la création d’une fédération reste un événement rare, souvent ignoré. Là encore, l’attaque requiert le mot de passe d’un administrateur Azure AD, obtenu, dans Sunburst, par compromission du réseau local.
Obtenir un accès administrateur
Dans ces deux approches, tout commence par l’obtention des droits d’administrateur sur le réseau local. Pour voler la clé privée, il fallait accéder au serveur ADFS et subtiliser un ticket Kerberos. Pour le courtage d’identité, un mot de passe administrateur non protégé par MFA suffisait pour la console Azure AD. C’est sur le réseau local que l’accès administrateur a été dérobé. Une fois une machine Windows sous contrôle, plusieurs techniques permettent de récupérer mots de passe (en clair), tickets ou hachages réutilisables. Ces méthodes tirent parti du fait que Windows garde ces secrets en mémoire. Ce sont des procédures avancées, à la portée de groupes très expérimentés. Après l’intrusion, les assaillants ont multiplié les mouvements latéraux et les stratégies d’évasion pour atteindre leurs cibles.
Entrer dans le réseau local
L’entrée initiale s’est faite via la chaîne SolarWinds : la plateforme Orion, outil de gestion des systèmes d’information, a été infectée par un code malveillant. Cette contamination s’est produite lors d’une mise à jour automatique, après l’introduction du malware dans le code source (le vecteur exact reste inconnu). Une fois la mise à jour installée, le programme malveillant s’est activé, a contacté le centre de commande des attaquants via des requêtes DNS, puis a déployé un second malware pour préserver l’accès, même en cas de découverte du premier.
Compromis par contamination des mises à jour logicielles
Des conséquences qui auraient pu être dévastatrices
Début 2021, l’ampleur réelle de l’attaque, attribuée à des acteurs russes, restait floue. Les effets semblent limités, sans doute parce que la cible prioritaire était le gouvernement américain. Pourtant, 18 000 organisations ont installé la version compromise d’Orion. Si la motivation avait été financière, l’impact aurait pu être autrement plus destructeur. Les pirates se sont concentrés sur des objectifs précis, récupérant des outils offensifs chez FireEye, du code source Microsoft ou Cisco, alors qu’ils auraient pu exploiter à grande échelle les ressources de toutes les entreprises touchées.
Microsoft 365 et Azure AD : un niveau de sécurité élevé
L’affaire pose de nombreuses questions sur la robustesse des systèmes d’information, mais concentrons-nous sur la gestion des accès. Ce que l’on observe d’abord, c’est l’ampleur des efforts nécessaires pour compromettre seulement quelques milliers de boîtes mail dans le cloud. La chronologie éclaire cette complexité : SolarWinds compromis en 2019, Orion modifié en mars 2020, attaque découverte en décembre. Les assaillants ont agi par étapes, sur plusieurs mois, pour voler des messages sans alerter personne.
Deux méthodes d’attaque ont dominé, chacune avec ses prérequis :
- Vol de clé privée SAML : exige que l’authentification soit déléguée à un ADFS utilisant une cinématique où le jeton transite par l’utilisateur.
- Connexion à la console d’administration Azure AD : la tâche aurait été bien plus ardue si l’authentification multifacteur (MFA) avait été active.
Les pirates n’ont pas eu recours à des techniques de brute force ou de pulvérisation de mots de passe sur Azure AD. Leur but n’était sans doute pas simplement d’accéder aux boîtes mail, mais de pénétrer plus loin dans les réseaux. L’accès aux e-mails a probablement été une opportunité, tandis que le déploiement massif de méthodes comme la force brute ou le spear phishing aurait été trop bruyant et difficile à industrialiser sans se faire repérer. Ces tactiques restent néanmoins d’actualité pour des attaques ciblées, notamment par accès à distance lors de l’impossibilité d’utiliser Sunburst.
L’accès administrateur, une clé sur les serveurs internes
Le point de bascule de l’attaque : obtenir des droits administrateur. Que ce soit sur les serveurs ADFS internes ou via l’interface d’administration Azure AD, cet accès a ouvert toutes les portes. Une fois le serveur ADFS compromis, la falsification des jetons SAML devient indétectable. Microsoft précise que la clé privée ADFS peut être récupérée via une requête LDAP sur Active Directory (entrée CryptoPolicy dans l’unité d’organisation ADFS). Or, la surveillance de cette entrée reste rare, voire inexistante. Une fois la clé subtilisée, aucune trace. Même une surveillance des connexions à Azure AD serait inutile : les pirates agissaient déjà depuis le réseau local. Seule une veille pointue des administrateurs aurait pu détecter la supercherie, mais rares sont ceux qui surveillent ce niveau de détail en continu.
Gestion des accès Microsoft compromise : quid des autres solutions ?
La Sunburst attack a ciblé ADFS et Azure AD, piliers de l’accès à Microsoft 365. Mais que se serait-il passé face à un autre fournisseur d’identité (IdP) ou si la fédération s’était faite via OpenID Connect plutôt que SAML ? Trois scénarios méritent qu’on s’y attarde :
- Prise de contrôle du serveur hébergeant un IdP
- Obtention de droits administrateur sur la console IdP
- Vol de la clé privée d’un IdP OpenID Connect/OAuth 2
Le rachat du serveur IdP : scénario noir
Dans Sunburst, le contrôle de l’ADFS interne a suffi. Mais la même logique s’applique à n’importe quel IdP : une fois le serveur compromis, on peut modifier la configuration, voler les clés privées, accéder aux journaux, récupérer identifiants et mots de passe, voire injecter du code malveillant. Il suffit d’ajouter un bout de code pour que, sur saisie d’un identifiant spécifique, l’authentification soit validée sans condition et qu’un jeton d’identité frauduleux soit généré.
Corruption du code source d’un IdP
Modifier le code source est souvent d’une simplicité déconcertante si l’accès en écriture est acquis. Certains IdP open source, développés en Perl ou Java, laissent la porte ouverte à des modifications à chaud. Il arrive qu’une simple retouche dans une page JSP suffise à permettre l’emprunt d’identité, comme l’a démontré l’équipe sur des déploiements Shibboleth.
Sécuriser l’accès à la console d’administration de l’IdP
Lorsque l’organisation ne disposait pas d’ADFS, les attaquants pouvaient utiliser un mot de passe Active Directory récupéré localement pour accéder à la console d’administration Azure AD, souvent synchronisée avec l’annuaire interne. Si la gestion des accès est installée sur site, le contrôle du serveur permet d’aller bien au-delà de la console d’administration, jusqu’à modifier le code source. Mais dans le cloud, avoir un mot de passe administrateur (si le MFA n’est pas déployé ou facilement contournable) reste la méthode la plus directe pour prendre la main. L’attaquant peut alors ajouter une délégation pirate, à condition que celle-ci passe inaperçue pour les utilisateurs finaux. Selon la solution, il sera plus ou moins facile de rester sous le radar. Avec une authentification en deux temps (identifiant puis mot de passe), il suffit souvent de saisir un identifiant lié au domaine pirate pour déclencher la redirection. Avec une page unique, un bouton invisible, réservé aux assaillants, permet parfois de détourner le flux vers leur propre IdP. Dans bien des cas, les attaques observées avec Sunburst pourraient être reproduites, sur d’autres solutions, sans éveiller les soupçons.
OpenID Connect et OAuth 2 : mieux armés ?
Petit rappel : OpenID Connect et OAuth 2 n’opèrent pas sur les mêmes terrains. Le premier sert à l’authentification des applications web ; le second, à l’autorisation d’accès aux API. Souvent utilisés ensemble, ils se complètent : OpenID Connect pour authentifier l’utilisateur, OAuth 2 pour accéder à ses données. Le jeton d’identité OpenID Connect concerne les applications dites « confidentielles », hébergées côté serveur. Les clients publics (SPA dans le navigateur, applis mobiles) ne peuvent pas garantir la sécurité de l’identité. Ce qui compte dans ce cas, c’est de protéger l’accès au backend. Avec OpenID Connect, le jeton d’identité s’échange directement entre serveurs, sans transiter par le navigateur, si la cinématique implicite est bien bannie. L’expérience SAML a permis de renforcer la sécurité du protocole. SAML proposait aussi une liaison d’artefact pour échanger les jetons entre serveurs, mais cette fonctionnalité reste rare.
OpenID Connect protège le jeton
OAuth 2 : la sécurité dépend de l’implémentation
OAuth 2, de son côté, présente des similitudes avec SAML dans son mode de validation des jetons. Pour les API réservées à des applications serveurs, les bonnes pratiques recommandent de limiter l’accès à des clients dûment autorisés, via authentification forte ou restrictions réseau. Un attaquant doit alors franchir ces obstacles pour présenter un faux jeton. Mais de plus en plus d’API sont ouvertes à des clients publics (SPA, mobiles). L’identification du client devient impossible. Un pirate peut alors soumettre n’importe quel jeton.
L’acceptation du jeton dépend uniquement de la façon dont il est validé. Si l’API ne fait qu’une vérification de signature, un jeton falsifié peut être accepté. Si, au contraire, elle pratique l’introspection auprès de l’IdP, seule la validité réelle du jeton comptera. Les meilleures pratiques recommandent d’utiliser des jetons opaques (non signés et illisibles), validés par introspection. Suivre cette recommandation neutralise le risque lié au vol de la clé privée.
Attention néanmoins : un jeton opaque reste vulnérable au vol et doit être protégé côté application. Sur mobile, c’est faisable. Pour les SPA, c’est quasi impossible.
Ce que nous apprend l’attaque Sunburst
L’affaire Sunburst dépasse le cadre habituel des intrusions : ampleur, durée, sophistication… Elle démontre jusqu’où un acteur déterminé, disposant de ressources et de temps, peut aller. Des points de sécurité jugés improbables se révèlent en réalité exposés.
Protéger les secrets : une gageure
La robustesse d’un système repose sur la protection de secrets : mots de passe, clés privées… Ces secrets, utilisés par des opérateurs ou par les systèmes eux-mêmes (connexion à une base, chiffrement…), doivent être partagés et protégés, idéalement dans un coffre-fort ou au minimum chiffrés. Mais si une application peut les extraire, un attaquant ayant les mêmes droits le pourra aussi. Par exemple, un mot de passe chiffré dans un fichier de configuration peut être déchiffré si l’assaillant a accès à la clé. Un acteur malveillant, maître du serveur, pourra signer ou déchiffrer tout ce que l’application est capable de traiter. Il existe des solutions matérielles (HSM) pour protéger les clés de signature et de chiffrement, rendant leur extraction impossible. Mais ces équipements restent coûteux (environ 1300 € par mois pour un HSM AWS à Paris) et ne protègent pas les mots de passe. Un mot de passe chiffré via HSM et stocké dans un fichier sera vulnérable si l’attaquant accède à l’API HSM. Pourtant, protéger les secrets reste nécessaire, ne serait-ce que pour éviter leur exploitation lors d’une fuite accidentelle (dépôt dans un Git, par exemple).
Et l’authentification MFA ?
L’authentification forte est souvent présentée comme la solution miracle. Mais la réalité est plus nuancée : elle n’est pas toujours généralisable ni adaptée à tous les contextes. L’attaque Sunburst invite à y réfléchir. Dans sa version ADFS, elle a contourné tous les mécanismes de sécurisation : la falsification du jeton SAML rend l’authentification elle-même superflue. À l’inverse, le MFA joue un rôle clé pour protéger les consoles d’administration cloud : s’il avait été activé, le vol d’un mot de passe administrateur n’aurait pas suffi pour accéder à Azure AD et en modifier la configuration. Notons cependant que les techniques ayant permis le vol de clés privées ADFS peuvent aussi servir à contourner le MFA en dérobant les secrets associés. On se souvient du remplacement forcé des jetons SecurID chez RSA après le vol d’une clé racine. Les enquêteurs de Volexity ont même observé que des boîtes aux lettres protégées par un dispositif Duo étaient accessibles via Outlook Web Access : les pirates avaient subtilisé une clé du serveur OWA, générant un cookie validant faussement une authentification forte inexistante.
Mettre en pratique les bonnes habitudes de sécurité
À l’heure où chaque semaine livre de nouveaux épisodes sur cette attaque, une chose s’impose : la persévérance paie, même face à des défenses robustes. Les organisations touchées avaient multiplié les audits et tests de pénétration, sans pour autant déjouer la patience d’adversaires installés dans la durée. Sunburst a mis en lumière la fragilité des mécanismes d’authentification si toutes les précautions ne sont pas prises. Les développeurs, notamment, doivent rester vigilants lors de l’intégration de protocoles comme OAuth 2 dans des applications SPA. Utiliser OAuth 2 pour protéger un backend peut, dans certains contextes, affaiblir la sécurité. Même si la falsification d’un JWT demande un effort considérable, le vol d’un jeton existant reste à portée. D’où l’intérêt de respecter scrupuleusement les recommandations de sécurité OAuth 2. Il ne faut pas perdre de vue que fermer une porte ne sert à rien si une fenêtre reste grande ouverte. Un exemple : dans une SPA, le jeton d’accès est plus facile à voler qu’un cookie de session. S’appuyer sur des sessions HTTP, parfois jugées dépassées, permet de sécuriser les jetons OAuth 2 sur le serveur. Un retour à la simplicité qui, parfois, protège mieux que les solutions dernier cri.
Auteur : Marc (Directeur technique)
