Utiliser Splunk pour détecter la backdoor Sunburst

Pour résumer : Cet article de blog contient des conseils immédiats sur l’utilisation de Splunk Core et Splunk Enterprise Security pour protéger votre réseau du malware Sunburst délivré via le logiciel SolarWinds Orion, et détecter les activités qui peuvent s’y dérouler. L’équipe de recherche sur les menaces de Splunk publiera des conseils supplémentaires au cours de la semaine prochaine. Veuillez noter également que la détection d'activités malveillantes sur votre réseau ne signifie pas forcément que votre réseau est compromis. Comme toujours, lisez attentivement. 

Présentation de la backdoor Sunburst

Dimanche après-midi, FireEye a publié un rapport sur ce qu’il appelle la « Backdoor Sunburst ». Je vous recommande chaudement de lire leur livre blanc phénoménal pour une analyse approfondie, mais en voici les bases : un adversaire sophistiqué a transformé un dll légitime du logiciel SolarWinds Orion en cheval de Troie et l’a inséré dans le cycle de mise à jour des clients de Solarwinds. Une fois le système infecté, ce cheval de Troie permet au malfaiteur de se déplacer latéralement dans le réseau de la victime et de voler ses données critiques.

Pour le moment, FireEye a détecté une activité globale remontant au moins au printemps 2020, et de nombreux secteurs verticaux sont touchés. Rapprochant les événements de la récente Directive d’urgence CISA 21-01, il nous a semblé essentiel d'apporter une réponse rapide et des conseils de haut niveau à nos clients afin de les aider à inspecter et protéger leur réseau. L'équipe de recherche de Splunk délivrera bien plus de détections personnalisées au fil de son étude du scénario dans nos laboratoires au cours des prochains jours.  

Ce que vous devez savoir

Le rapport de FireEye révèle que cette attaque a été perpétrée par un adversaire sophistiqué qui a soigneusement sélectionné ses cibles, modifié son infrastructure d'attaque en fonction de l’emplacement géographique et même nommé des hôtes d'attaque comme ceux de ses victimes pour mieux déguiser leur trafic. En exploitant un partenaire logiciel de confiance comme Solarwinds Orion, les malfaiteurs ont utilisé la position de Solarwinds sur le réseau pour se déplacer latéralement dans les infrastructures locales et cloud, afin de capturer et exfiltrer des données. 

Si la backdoor Sunburst est un vecteur sophistiqué, elle reste un cheval de Troie sur un réseau avec un déplacement latéral. Une grande partie des techniques classiques de défense du réseau et de réponse aux incidents peuvent être immédiatement utilisées. Si vous savez quels hôtes de votre réseau exploitent SolarWinds Orion, commencez votre chasse par ces hôtes car c’est là que l’adversaire s’installe en premier lieu. La backdoor Sunburst ne devrait être effective que sur ces hôtes. Il existe toutefois la menace d’un mouvement latéral au départ des hôtes Orion, à l'aide de techniques courantes ou d’identifiants récoltés dans Orion.

Détection dans Splunk Enterprise Security

Un événement comme Sunburst est une excellente occasion de relire notre article « Comment ajouter de la Threat intelligence COVID (ou autre) provenant d’Internet à Splunk Enterprise Security ? » sur l’ajout rapide de renseignements sur les menaces à Splunk Enterprise Security (ES). Il vous suffit de remplacer les listes de menaces « COVID » par les listes de menaces « SUNBURST ». Cet article vous aidera à mettre à jour votre SIEM Splunk en intégrant les IOC actuellement publiés par FireEye, et vous donne les résultats de détection en cas d’infection d’un hôte à l’avenir. 

Mon collège Shannon Davis a déjà réuni plusieurs fichiers de renseignements sur les menaces locales que vous pouvez importer dans ES à l’aide des techniques ci-dessus ! 

IOC : DNS, hashes et IP

Tout d'abord, examinons les IOC que FireEye a gracieusement publié dans son dépôt GitHub. Vous pouvez les parcourir et créer une collection de déclarations « OR » et inspecter votre DNS, mais j’ai créé quelques fichiers de lookups rapides que vous pouvez utiliser, en particulier quand ces IOC devient de plus en plus bavards. Suivez les conseils de mes précédents articles « Des lookups pour partir en chasse » et « Rechercher les attaques exploitant la thématique du COVID avec des IOC ». J’ai commencé à réunir quelques fichiers de lookup dans un dépôt GitHub, et vous pouvez explorer indépendamment. Veuillez noter que ces contenus s'appuient sur ce qui a été publié par FireEye ou d'autres fournisseurs, mais ils devraient vous aider à démarrer.

Par exemple, créez des tables de lookup comme indiqué dans les articles ci-dessus ou dans mon dépôt Github. Exécutez ensuite une recherche similaire à l’exemple ci-dessous pour trouver les hôtes qui ont communiqué avec les domaines qui ont été détectés jusqu'à présent.

index=main sourcetype=stream:*
| lookup sunburstDOMAIN_lookup Domain AS query
| search isBad=TRUE
| stats VALUES(query) AS "Sunburst" by src_ip

Modifiez simplement la requête de recherche et le fichier de lookup pour développer l’IOC que vous recherchez (domaines, IP ou hashes).

Si vous détectez du trafic vers ces IP ou ces domaines, examinez attentivement les alertes Snort publiées par FireEye. Si vous collectez des logs de pare-feu ou de trafic de proxy, vous pourriez avoir une meilleure idée de vos hôtes compromis en recherchant du trafic présentant les chaînes suivantes dans l’URL :

/swip/upd/SolarWinds.CortexPlugin.Components.xml
swip/Upload.ashx
/swip/upd/

Déplacement latéral

Une fois que l’adversaire a accès au réseau via le dll converti en troyen, on peut le voir se déplacer latéralement pour détecter et exfiltrer des informations. Sans avoir vu les logs, nous pouvons sans risque supposer qu’il obéit aux lois du trafic réseau. Grâce à l’outil Splunk Security Essentials (SSE), toujours pratique, j’ai exporté quelques recherches dans ce PDF. Vous pouvez utiliser ces recherches telles quelles ou comme source d’inspiration pour créer les vôtres. Je vous recommande de commencer par rechercher tout trafic suspect à destination ou en provenance de machines SolarWinds dans votre réseau.

Sysmon et tube nommé

Le rapport FireEye contenait un autre aspect intéressant : l’existence d’un tube nommé. Si vous utilisez Sysmon et Splunk, examinez les codes d'événement 17 et 18 et le tube nommé « 583da945-62af-10e8-4902-a8f205c72b2e ». Nous proposons l’exemple de recherche ci-dessous :

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" 
(EventCode=17 OR EventCode=18) PipeName=583da945-62af-10e8-4902-a8f205c72b2e

Nous voyons également que la communauté fait un excellent travail en matière de requêtes Sysmon et Splunk, mais nous n'avons pas encore pu les tester pour le moment. Faites une rapide recherche sur Google et vous trouverez sans doute de l’or !

Azure Active Directory

Microsoft a également identifié que les malfaiteurs exploitant la backdoor Sunburst ont ciblé l’Azure AD de leurs victimes dans le cadre de leur mouvement latéral. Pour ce faire, ils ont capturé des mots de passe administratifs ou contrefait des jetons SAML. Heureusement, Splunk (en l’excellente personne de Ryan Lait) a une solution ! Si vous avez importé les données Azure dans Splunk, vous pouvez obtenir de précieux renseignements sur les activités potentielles de votre adversaire. 

Les données d'audit d’Azure Active Directory, recueillies par l’extension Microsoft Azure pour Splunk, peuvent vous aider à détecter certaines techniques exploitées par les pirates. Ces logs d'audit capturent toutes les interactions entre les utilisateurs et les ressources au sein d’Azure. Voici quelques exemples de recherche de détection :

Supervision des modifications dans les enregistrements d'applications et les principes des services :
Nouveaux principes de service :

sourcetype="azure:aad:audit" activityDisplayName="Add service principal" 
| stats values(activityDisplayName) AS Action, values(initiatedBy.user.userPrincipalName) 
AS UPN, values(targetResources{}.displayName) AS Target,
values(targetResources{}.modifiedProperties{}.displayName) AS "Modified Resources",
values(targetResources{}.modifiedProperties{}.oldValue) AS "Old Values",
values(targetResources{}.modifiedProperties{}.newValue) AS "New Values" by correlationId 
| fields - correlationId

Ajout d’identifiants et de certificats à des applications ou des principes de services :

sourcetype="azure:aad:audit" activityDisplayName="Add service principal credentials"

Ajout de permissions et d'affectations de rôles à des applications ou des principes de services :

sourcetype="azure:aad:audit" activityDisplayName="Add app role assignment to service principal" OR 
activityDisplayName="Add delegated permission grant" OR activityDisplayName="Add application" 
| stats  values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName) 
AS Target, values(targetResources{}.modifiedProperties{}.displayName) AS "Modified Resources", 
values(targetResources{}.modifiedProperties{}.oldValue) AS "Old Values", 
values(targetResources{}.modifiedProperties{}.newValue) 
AS "New Values" by correlationId activityDisplayName
| fields - correlationId

Utilisez cette recherche pour repérer les utilisateurs qui ont ajouté des permissions sensibles à des enregistrements d'applications. #ReadMailInAllMailboxes

Applications modifiées pour autoriser un accès multi-locataires :

sourcetype="azure:aad:audit" activityDisplayName="Update application" operationType=Update 
result=success targetResources{}.modifiedProperties{}.displayName=AvailableToOtherTenants 
| table activityDateTime initiatedBy.user.userPrincipalName, 
targetResources{}.displayName additionalDetails{}.value

Modifications de domaines personnalisés Azure AD :

sourcetype="azure:aad:audit"  activityDisplayName="Add unverified domain" OR 
activityDisplayName=*domain* | stats values(activityDisplayName) AS 
Action, values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName) 
AS Target, values(targetResources{}.modifiedProperties{}.displayName) 
AS "Modified Resources", values(targetResources{}.modifiedProperties{}.oldValue) 
AS "Old Values", values(targetResources{}.modifiedProperties{}.newValue) 
AS "New Values" by correlationId 
| fields - correlationId

N’oubliez pas de consulter l’Application Microsoft Azure pour Splunk pour obtenir des recherches supplémentaires et du contenu de sécurité prédéfini pour les données Azure.

Hôtes VPS

Actuellement, on pense que les malfaiteurs ont utilisé des hôtes VPS (serveurs privés virtuels) géographiquement ciblés (dont les adresses IP appartiennent au pays de la victime) pour accéder aux réseaux des victimes. Bien qu’il n’existe pas de liste définitive de ces IP, nous recommandons aux clients d’examiner le trafic réseau externe vers interne afin de déterminer si des adresses IP inconnues ont accédé à leurs systèmes (en particulier des dispositifs SolarWinds) depuis le printemps 2020.

Recherches TSTAT (mises à jour !)

Tandis que les Splunkers du monde entier travaillent à découvrir et détecter l’activité Sunburst, beaucoup de nos clients se sont aperçus que les recherches rapides que nous donnons plus haut n'étaient pas applicables à grande échelle et se sont tournés vers TSTATS pour gérer le volume de leurs modèles de données. Mon collègue Don Slife a donc pris l’initiative de rassembler quelques requêtes à la fois utiles ET applicables à grande échelle. Veuillez noter que vos modèles de données doivent contenir des données conformes au CIM pour exécuter ces recherches.

Pour détecter les domaines malveillants dans le modèle de données de résolution réseau
Cette recherche examine les données DNS du modèle de données Résolution réseau à l’aide du fichier sunburstDOMAIN_lookup ci-dessus. Si vous préférez, retirez la sous-recherche et recherchez uniquement le domaine avsvmcloud[.]com pour détecter l’IOC primaire. 

| tstats summariesonly=true earliest(_time) as earliest latest(_time) as latest count as total_conn values(DNS.query) as query from datamodel=Network_Resolution where

    [| inputlookup sunburstDOMAIN_lookup

    | rename Domain as DNS.query

    | table DNS.query] OR DNS.query=*avsvmcloud.com by DNS.src DNS.vendor_product DNS.record_type DNS.message_type

| sort earliest

| eval earliest=strftime(earliest, "%c"), latest=strftime(latest, "%c")

Pour détecter les adresses IP malveillantes dans le modèle de données de trafic réseau
Cette recherche va examiner le modèle de données Trafic réseau à l’aide des fichiers sunburstIP_lookup référencés ci-dessus. 

| tstats summariesonly=true earliest(_time) as earliest latest(_time) as latest count as total_conn values(All_Traffic.dest) as dest from datamodel=Network_Traffic where

    [| inputlookup sunburstIP_lookup

    | rename IP as All_Traffic.dest

    | table All_Traffic.dest] by All_Traffic.src All_Traffic.vendor_product

| sort earliest

| eval earliest=strftime(earliest, "%c"), latest=strftime(latest, "%c")

MITRE ATT&CK

Nos confrères de FireEye ont eu la gentillesse de rapprocher leurs observations de MITRE ATT&CK. Comme dans le cas du mouvement latéral ci-dessus, j'ai parcouru Splunk Security Essentials et extrait tout le contenu potentiellement associé aux tactiques et techniques observées. Le PDF est finalement assez volumineux, mais nous espérons qu’il vous sera utile. Si vous préférez pivoter dans vos propres instances SSE, voici les recherches 1-1 à examiner (j'ai ajouté tout ce qui me semblait utile dans le PDF, donc jetez-y un œil si vous avez l’occasion) :

• Processus Powershell malveillants : commande encodée
• Détection d'activités anormale dans le suivi d'audit
• Trafic Tor
• Concentration d’outils d'attaque par nom de fichier
• Concentration d’outils d'attaque par hash SHA1
• Manipulation de services Windows par sc exe
• Détection de services interdits
• Détection de processus interdits
• Nouveau service anormal
• Nombre anormalement élevé de modifications de terminal par un utilisateur
• Première occurrence d’un service Windows en cours d’exécution
• Processus avec noms de fichiers similaires (faute de frappe)
• Autorisation de trafic SMB
• Nouveau processus anormal
• Nombre élevé de processus
• Détection de services interdits
   

Conclusion

Nous avons tenté de rédiger un article court, accessible et concis. Les informations ci-dessus proviennent de nos produits existants comme SSE et ESCU, de précédentes recherches et du SPL de talent délivré par d’excellents Splunkers tels que Shannon Davis et Ryan Lait. L’essentiel (sinon la totalité) de l’analyse et des IOC ci-dessus ont été dérivés des blogs de FireEye et de Microsoft sur le sujet. Toutefois, comme on l'a mentionné, notre équipe de recherche sur les menaces publiera de nouvelles informations mises à jour et des détections supplémentaires dès que nous aurons d'autres informations (et données).

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