Le parcours d’une attaque Golden SAML : SolarWinds, la suite

Pour résumer : dans cet article, nous allons voir ce qu’est le SAML, les nouveautés de ce protocole ancien et comment détecter et repousser les attaques SAML. Notre approche de la détection a pour but de vous mettre le pied à l’étrier, et non de fournir une solution utilisable par tous et dans toutes les installations. Nous n’allons pas nous attarder sur Sunburst ou Supernova mais plutôt nous concentrer sur certains enseignements afin de renforcer notre position face aux futures attaques.

Qu’est-ce que le SAML ?

Le SAML, pour Security Assertion Markup Language (langage balisé de vérification de sécurité), est une méthode d’échange d’authentification et d’autorisation entre deux parties de confiance. C’est essentiellement un schéma XML permettant le fonctionnement du SSO (Single Sign-On) en fédération. Du moins, c’est comme cela qu’il est le plus souvent employé aujourd’hui. Son principe de fonctionnement de base est le suivant : lorsqu’un client tente de s’authentifier auprès d’un fournisseur de service, il est redirigé vers un serveur d’authentification. Une fois authentifié, il reçoit une réponse signée et chiffrée qu’il retransmet ensuite au fournisseur de service. Une fois la réponse reçue, elle est validée grâce à la magie du chiffrement. En tout cas, c’est comme cela que c’est censé fonctionner et nous protéger (ainsi que nos données).

Si cela prête à confusion, jetez un œil à ce schéma de Sygnia :

^{(Crédits image : Sygnia)}

Sans le SAML, nos administrateurs systèmes devraient créer d’innombrables comptes pour chaque service que nous utilisons dans notre travail. Il nous faudrait mémoriser de nombreux noms d’utilisateur et mots de passe pour chaque service (parce que nous sommes bien d’accord que vous ne réutilisez jamais le même mot de passe, n'est-ce pas ?), et les modifier régulièrement. Ce serait un cauchemar pour les administrateurs système comme pour les utilisateurs. Heureusement, la technologie est là pour nous sauver et nous permettre de dormir sur nos deux oreilles.

Une brève histoire de Golden SAML

Tout allait pour le mieux dans le meilleur des mondes. Mais toute technologie a ses faiblesses que nos adversaires chercheront à détecter et à exploiter sans relâche. En 2017 déjà, CyberArk détaillait sur son blog une nouvelle technique d’attaque appelée Golden SAML. L’article présentait une technique permettant à un adversaire de générer sa propre réponse SAML avec le contenu et les autorisations nécessaires. Pour cela, l’adversaire doit toutefois surmonter quelques obstacles. Il doit avant tout accéder aux certificats utilisés pour signer les objets SAML. Cela signifie généralement qu’il doit avoir un pied dans le réseau et un accès privilégié pour extraire les certificats. Plusieurs outils peuvent aider le malfaiteur à extraire les certificats nécessaires, comme certutil.exe, PowerShell, ADFSDump et l’indétrônable Mimikatz (ne vous inquiétez pas, nous allons vous expliquer sous peu comment les détecter). Ensuite, il lui suffit d’utiliser son outil préféré pour extraire les certificats : il aura alors toutes les cartes en mains pour lancer son attaque Golden SAML.

Sygnia nous offre une autre excellente représentation graphique d’une attaque Golden SAML.

^{(Crédits image : Sygnia)}

Pourquoi est-ce un tel problème ? Une fois que l’adversaire a accès aux certificats extraits, il peut usurper l’identité de n’importe quel utilisateur de l’entreprise et exploiter ses privilèges. Il peut même le faire où qu’il soit dans le monde. Il pourra en outre contourner les protections de l’authentification multi-facteurs (MFA). Pourquoi, me direz-vous ? Parce que le serveur d’authentification est entièrement écarté du processus. L’adversaire a produit une contrefaçon de réponse valide du serveur d’authentification en contournant complètement la MFA.

Golden SAML et la cyberattaque SolarWinds 

Vous vous demandez sans doute quel est le rapport avec l’attaque contre SolarWinds. Pour résumer, la faille SolarWinds Orion a été la première utilisation connue de Golden SAML dans le monde réel. Près de trois ans après son signalement comme technique viable post-exploitation, c’est la première fois qu’elle a été détectée. Cela témoigne soit de l’efficacité, de la flexibilité et de la furtivité de cette technique, soit de la détermination et du savoir-faire de ce malfaiteur. C’est sans doute les deux.

De quelles données ai-je besoin ?

Nous allons prendre pour exemple un environnement Windows qui utilise les services de fédération d’Active Directory (ADFS) pour le SAML. Les logs de sécurité et d’audit d’ADFS nous apporteront des informations supplémentaires sur les attaques Golden SAML potentielles. Mais nous y reviendrons dans un instant. De plus, vous devrez sans doute personnaliser certaines requêtes en fonction de votre environnement, selon les extensions Splunk que vous avez installées et configurées. Une chose à garder en tête : si nos exemples se limitent à un environnement Windows et ADFS, ce n’est pas le cas de ce vecteur d’attaque. Les attaques Golden SAML sont possibles avec tous les fournisseurs SAML.

Mais avant tout, quelques mises en garde. Cette démarche n’a rien de simple. La détection de cette activité peut être extrêmement difficile et nécessite des données provenant de multiples sources internes et externes situées dans une enclave. Nous allons détailler des exemples qui vous aideront à détecter ce type d’attaque. 

Passons maintenant aux événements Windows dont nous allons avoir besoin pour détecter cette activité.

Codes d’événements Windows

Pour détecter les attaques SAML visant l’infrastructure Microsoft, vous aurez (sans surprise) besoin de logs Microsoft. Vous trouverez plus bas quelques liens et pistes pour activer la collecte des événements dont vous avez besoin pour détecter une activité Golden SAML. Voyez-les comme de la « Splunkspiration ». Ils ne s’appliqueront peut-être pas directement à votre cas mais vous mettront sur la bonne voie. Selon la méthodologie de détection, vous aurez besoin de plusieurs événements Windows. Gardez en tête que vous aurez peut-être besoin de la supervision d’un adulte (d’un administrateur système) si vous modifiez le système. Chaque système a ses particularités et vous devez remplir certaines exigences (comme avoir au minimum Windows 2016 et sysmon) pour les obtenir.

Et puisque c’est un article de blog Splunk, nous partons du principe que vous utilisez le forwarder universel Splunk Universal Forwarder pour importer des événements Windows dans Splunk.

ID d’événements ADFS

Ce sont sans doute les événements Windows les plus importants à recueillir, et malheureusement plusieurs d’entre eux ne sont pas activés par défaut. Vous trouverez des informations supplémentaires sur l’activation de ces événements dans cet article et dans PowerShell Gallery, ainsi que de la documentation à leur sujet ici et là.

• 1200 (AD FS-Admin) : le service de fédération a validé un nouvel identifiant
• 1202 (AD FS-Admin) : le service de fédération a émis un jeton valide
• 307 (AD FS-Admin) : la configuration du service de fédération a été modifiée
• 510 (AD FS-Admin) : complément d’informations
• 1007 (Microsoft-Windows-CertificateServicesClient-Lifecycle-System) : certificat exporté
   

Il faut savoir qu’on ne collecte pas par défaut les logs dans lesquels ces événements apparaissent, et il faut donc les ajouter à une configuration d’extension Splunk : vous pouvez par exemple les ajouter au fichier inputs.conf de l’extension Splunk pour Windows. Ajoutez d’abord une section pour activer le bon log de services de certificat (celui-ci ne rapporte que les événements 1007, vous devez retirer la directive de liste blanche pour obtenir les autres informations des services de certificat) :

[WinEventLog://CertificateServicesClient-Lifecycle-System/Operational]
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5
renderXml=true
whitelist = $XmlRegex=’(?:1007).+’

Et si vous pensiez que c’était le seul ajustement, détrompez-vous. Les services de fédération Active Directory ont leur propre log d’événements. Nous devons donc ajouter une autre section à inputs.conf (sur notre forwarder) :

[WinEventLog://AD FS/Admin]
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5
renderXml=true

Ces deux exemples d’inputs.conf ont été testés sur un serveur Windows 2019.

ID d’événements de contrôleur de domaine

Pour recueillir les événements utiles des contrôleurs de domaine, nous devons les activer via la stratégie de sécurité locale ou la stratégie de groupe. Vous trouverez des informations à ce sujet dans la documentation de Microsoft.

• 4769 (Security) : un ticket de service Kerberos a été demandé
  
  

ID d’événements de point de terminaison

Tous les ID d’événements ci-dessous vous aideront à identifier les exécutions de ligne de commande ou de PowerShell destinées à extraire des certificats. Vous avez besoin d’aide pour importer les événements PowerShell dans Splunk ? Vous trouverez ce qu’il vous faut ici (la documentation est celle d’UBA mais ne vous inquiétez pas, cela s’applique à tous les logs PowerShell).

• 4688 (Security) (et n’oubliez pas d’activer les arguments de processus.)
• 4103 (PowerShell) (diapositive 79 ici)
• 4104 (PowerShell) (voir plus haut)
• 18 (Sysmon)
   

Comment détecter un Golden SAML ?

Merci de m’avoir posé la question ! Nous avons quelques occasions de détecter une activité connexe. Examinons comment en trouver dans Splunk à l’aide de la méthodologie décrite par Syngia dans une note publiée récemment. Gardez également à l'esprit qu'il s'agit là d'exemples de requêtes faites pour vous guider. Détecter ce type d’activités dans une entreprise peut s'avérer difficile, et vous devrez sans doute adapter et peaufiner les requêtes ci-dessous pour les faire fonctionner correctement dans votre environnement. Notez qu’elles partent toutes du principe que vous utilisez des logs Windows au format XML (mais vous pouvez les ajuster au format classique).

1. Recherchez les exports de certificat dans les logs d’événements ADFS

Pour que cette attaque réussisse, l’adversaire doit exporter les certificats appropriés à partir d’un serveur ADFS. Cela doit être assez rare, car il existe peu de raisons légitimes d’exporter un certificat. Nous pouvons rechercher cette activité dans les logs d’événements Windows du serveur ADFS, en ciblant l’ID d’événement 1007.

sourcetype=xmlwineventlog 
source="xmlwineventlog:CertificateServicesClient-Lifecycle-System/Operational" 
EventCode="1007"

Nous pouvons également rechercher des signes d’exportation de certificat ADFS à l’aide de la ligne de commande ou de PowerShell. Ces commandes peuvent être exécutées depuis n’importe quelle machine, serveur ou client. Pensez donc à ne pas restreindre vos requêtes au serveur ADFS.

Examinons d’abord les exportations de certificats via PowerShell

index=main sourcetype=xmlwineventlog 
source="xmlwineventlog:Microsoft-Windows-PowerShell/Operational" 
EventCode IN (4104, 4103) ScriptBlockText IN 
("*Export-PfxCertificate*", "*certutil -exportPFX*" )

Nous pouvons également rechercher les traces d’utilisation de certutil.exe

index=main sourcetype=xmlwineventlog 
source="xmlwineventlog:Security" EventCode=4688 
CommandLine="*certutil.exe -exportPFX*"

Regardons enfin les méthodes employées par Mimikatz et ADFSDump. Notez que c’est une méthode courante : il faut donc rechercher les processus (images) peu utilisés pour les explorer.

index=main sourcetype="xmlwineventlog:microsoft-windows-sysmon/operational" 
EventCode=18 PipeName="\microsoft##wid\tsql\query" 
| stats count by Image 
| sort count

2. Identifiez les événements d’authentification anormaux

Remarque : cette technique ne fonctionne que sur Windows Server 2016 et ses versions ultérieures. Les ID d’événements 1200 et 1202 n’existaient pas dans les versions antérieures de Windows.

Les événements d’authentification SAML valides vont générer de multiples événements de sécurité sur les serveurs ADFS et DC ainsi qu’au niveau du service pour lequel nous nous authentifions. Nous allons examiner les trois ID d’événements suivants sur nos serveurs ADFS et DC dans les logs d’événements de sécurité Windows. 

• 1200 : le service de fédération a émis un jeton valide
• 1202 : le service de fédération a validé un nouvel identifiant
• 4769 : un ticket de service Kerberos a été demandé

Nous allons ensuite corréler ces événements avec les événements d’authentification du service auquel l’utilisateur a tenté de s’authentifier (le fournisseur de service). Dans ce scénario, nous allons rechercher les tentatives d’authentification dans les logs de connexion d’Azure AD.

Les attaques Golden SAML ne sont pas consignées dans les logs d’authentification ADFS (ni ceux de DC vraisemblablement) car l’adversaire contrefait la réponse SAML, et les écarte donc entièrement du processus d’authentification. Nous devrions toutefois voir une authentification « réussie » auprès du fournisseur de service qui a reçu une réponse SAML signée, même s’il s’agit d’une contrefaçon.

sourcetype=xmlwineventlog source="xmlwineventlog:Security" 
EventCode IN (1200, 1202, 4769) 
`comment("Rechercher ces trois codes d'événements dans les logs d'événements de sécurité Windows")`

   [ search sourcetype=ms:aad:signin status.errorCode=0

   | eval Account_Name=mvindex(split(userPrincipalName,"@"),0) 
`comment("Retirer la partie @domain de userPrincipalName")`

   | fields Account_Name ] 
`comment("Bâtir une liste de noms de comptes à partir des tentatives de connexion via AzureAD afin de les corréler aux logs d'événements de sécurité Windows")`

| eval Account_Name=mvindex(Account_Name,-1) 
`comment("Utiliser uniquement la dernière valeur Account_Name du log d'événements Windows, ce qui devrait exclure les situations où Account_Name est - ou une valeur d’hôte")`

| eval Account_Name=mvindex(split(Account_Name,"@"),0) 
`comment("Retirer la partie @domain de Account_Name")`

| transaction dest Account_Name maxspan=2s maxevents=3 
`comment("Créer un événement unique avec les mêmes dest et Account_Name se produisant sous 2 secondes, en limitant à 3 événements")`

| eval mcount=mvcount(EventCode) 
`comment("Compter le nombre de codes d'événement uniques pour chaque nom de compte")`

| where mcount<3 
`comment("Rechercher les événements où ces trois codes d'événements sont absents")`

| table _time Account_Name EventCode

3. Supervisez les modifications de confiance d’ADFS 
Plutôt que d’extraire les certificats requis d’un serveur ADFS de confiance, l’adversaire peut choisir d’ajouter un nouveau serveur ADFS de confiance sur lequel il aura le contrôle. Nous allons rechercher l’ID d’événement 307 (la configuration du service de fédération a été modifiée) et le corréler à l’ID d’événement 510 avec le même identifiant d’instance. Dans de nombreuses entreprises, il est rare que la configuration des fédérations soit modifiée, vous pouvez donc vous en servir comme point de départ et l’adapter à vos besoins.

sourcetype=xmlwineventlog source="xmlwineventlog:AD FS/Admin" 
EventCode IN (307, 510)

Recommandations d’atténuation

Comme pour toute technologie, les bonnes pratiques et les recommandations pointent toujours dans la bonne direction. Si vous utilisez les services de fédération Active Directory (ADFS), Microsoft fournit une excellente ressource pour les sécuriser. Étant donné le rôle stratégique que remplit ADFS pour de nombreuses entreprises, on recommande toujours de mettre en œuvre autant de mesures de sécurité que possible, et surtout d’utiliser un module de sécurité matériel (HSM) pour générer et stocker les certificats. Un HSM a l’avantage de combiner dans un dispositif physique le stockage sécurisé de vos clés et des fonctions de chiffrement. Pourquoi est-ce aussi important ? Il prive l’adversaire de tout moyen d’extraire cette précieuse clé privée, ce qui l’empêche de mener une attaque Golden SAML (ou, au minimum, en augmente considérablement la difficulté et le coût).

Conclusion

Aujourd’hui, nous avons vu ce qu’est SAML, comment fonctionne une attaque Golden SAML et quelques méthodologies de détection et sources de données utiles. Nous avons aussi brièvement abordé des recommandations perfectionnées pour repousser ce type d’attaque à l’avenir. Tout ce contenu a pour but de vous aider à ouvrir une voie et renforcer votre position de sécurité globale. Ce n’est pas la dernière fois que nous voyons un malfaiteur utiliser Golden SAML pour acquérir une position persistante dans le réseau de sa victime. À tout le moins, la forte visibilité de cette attaque aura indubitablement mis en évidence l’efficacité de cette technique, ce qui pourrait inciter d’autres acteurs malveillants à l’ajouter à leur arsenal.

Pour plus d’informations à ce sujet et plus de contenu associé à SolarWinds, consultez notre site de réponse à la cyberattaque SolarWinds.

Je tiens également à mentionner et à remercier particulièrement John Stoner, Lily Lee, James Brodsky et Ryan Kovar ici chez Splunk. Ils ont apporté une contribution décisive à cet article en créant les requêtes et en veillant à ce que la logique ait le dernier mot.

^{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}