Détecter une activité suspecte zero-day d’HAFNIUM sur Microsoft Exchange dans Splunk

Si vous souhaitez seulement savoir comment déceler toute trace d’activité suspecte zero-day d’HAFNIUM sur Microsoft Exchange, rendez-vous directement aux sections « détections » ci-dessous. Sinon, continuez à lire pour découvrir un récapitulatif des faits, comment détecter l’attaque et les mappages MITRE ATT&CK.

Présentation du groupe HAFNIUM et de la faille zero-day sur Exchange

Le mardi 2 mars 2021, Microsoft a déployé un ensemble de correctifs de sécurité pour son serveur de messagerie Microsoft Exchange. Ces correctifs ont été publiés en réponse à une série de vulnérabilités affectant Exchange 2013, 2016 et 2019. Point important : une mise à jour de sécurité Exchange 2010 a également été déployée, même si les CVE n’indiquent aucune vulnérabilité pour cette version.

Bien que les CVE ne donnent pas vraiment de détails sur les caractéristiques des vulnérabilités ou des exploits, la première vulnérabilité (CVE-2021-26855) concerne un vecteur d’attaque de réseau distant qui permet aux malfaiteurs, un groupe de hackers baptisé HAFNIUM par Microsoft, de s’authentifier en tant que serveur Exchange. Trois autres vulnérabilités (CVE-2021-26857, CVE-2021-26858 et CVE-2021-27065) ont également été identifiées dans le cadre de cette activité. Lorsqu’elles sont associées à la vulnérabilité CVE-2021-26855 pour l’accès initial, le malfaiteur peut prendre un contrôle total sur le serveur Exchange, et notamment avoir la possibilité d’exécuter du code en tant que SYSTEM et d’écrire un fichier n’importe où sur le serveur.

Une solution provisoire d’atténuation de ces vulnérabilités face aux menaces externes est de restreindre l’accès à OWA (Outlook Web Access), par exemple en plaçant le serveur OWA derrière un VPN pour empêcher tout accès externe. Cependant, cela n’empêche pas un malfaiteur interne d’exploiter la faille. En bref, déployez les correctifs publiés le plus rapidement possible.

Ce que vous devez savoir

Vous vous dites peut-être : « encore un mardi passé à appliquer des correctifs, comme tous les mois… » Dans une certaine mesure, c’est peut-être vrai, mais il est crucial de signaler que, selon l’article de Volexity :

« Pour tous les cas de RCE (exécution de code arbitraire à distance), Veloxity a constaté que le malfaiteur déployait des webshells (fichiers ASPX) sur le disque et réalisait d’autres opérations pour extraire des identifiants, ajouter des comptes d’utilisateurs, dérober des copies des bases de données Active Directory (NTDS.DIT) et se déplacer latéralement sur d’autres systèmes et environnements. »

Je ne sais pas pour vous, mais dès que je vois un malfaiteur dérober des copies de ma base de données Active Directory (AD), j’ai des sueurs froides parce qu’à ce moment-là, dans le cadre de mes mesures correctives, je suis déjà en train de reconstruire ma base de données AD de zéro. Pour être plus précis, le vol de la base de données AD signifie que le malfaiteur dispose des privilèges d’accès d’administrateur, donc vous devez impérativement procéder à une investigation.

OWA ! Ça fait mal ! 

Certaines de ces vulnérabilités sont exploitées via Outlook Web Services (OWA), une fonctionnalité généralement activée sur Exchange Server 2013, 2016 et 2019. À la base d’OWA, vous retrouvez le vénérable serveur web de Microsoft, Internet Information Services (IIS). Et il se trouve justement que des traces de cette attaque peuvent être détectées en recherchant les bonnes requêtes POST dans les logs d’IIS.

Une petite minute ! Splunk est super pratique pour ingérer des logs de toutes les sources et pour déceler les motifs qui se répètent ! Nous avons juste à nous assurer que les logs sont correctement ingérés depuis nos serveurs OWA. 

Notre recette miracle est d’utiliser le forwarder Splunk Universal Forwarder et d’y ajouter une pincée de l’add-on technique Splunk Add-on for Microsoft IIS. Ensuite, ajoutez cela à votre fichier inputs.conf pour pouvoir ingérer tous les supers logs dans le répertoire C:\inetpub\logs\LogFiles au format W3C. Cela vous permettra d’effectuer des recherches dans les logs d’accès IIS pour déceler des motifs de chaîne de user agent inhabituels liés à cette attaque, comme indiqué plus tôt dans la journée par nos amis de Red Canary. Nous vous recommandons également d’ajouter une entrée de supervision pour conserver un log d’activité dans C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy.

Reportez-vous à l’article de blog de Volexity pour découvrir d’autres user agents intéressants détectés avant et après l’exploit.

Eh oui, encore une fois, nous avons besoin des événements Windows et des audits des processus de ligne de commande

Puisque vous utilisez le forwarder universel, autant vous assurer de collecter les événements de sécurité Windows intéressants et les événements de démarrage de processus, car ils jouent un rôle important pour certaines détections HAFNIUM. Pour ce faire, nous vous recommandons d’utiliser l’add-on technique Splunk Add-on for Microsoft Windows et également de collecter l’événement 4688 (avec les arguments de ligne de commande) du log d’événement de sécurité, OU vous pouvez toujours utiliser Microsoft Sysmon et collecter l’événement 1. Vous pouvez examiner ces événements de démarrage de processus à la recherche de traces d’exécution anormale du service Exchange UM.

Vous pouvez également configurer un audit sur le processus UM de votre serveur Exchange puis examiner les événements 4663 Windows à la recherche d’événements FileCreated suspicieux (dans le cas présent, des webshells). Cependant, faites attention : il est possible de générer plusieurs milliers d’événements 4663 si vous ne configurez pas correctement vos règles d’audit !

Enfin, collectez le log Application de vos serveurs Exchange, une nouvelle fois à l’aide de Windows TA. Cela vous permet de rechercher les erreurs dans le log contenant des motifs spécifiques dans le champ « RenderedDescription » à propos de l’exécution du service Exchange UM.

Détecter une activité suspecte zero-day sur votre serveur Exchange et de HAFNIUM dans Splunk

Dans cette section, nous allons vous présenter quelques recherches toutes fraîches, inspirées de celles proposées dans les articles de Volexity et de Microsoft, afin de vous aider à déceler certaines des activités malfaisantes de HAFNIUM. Si ces recherches sont incluses dans ESCU (Splunk ES Content Update), nous y faisons référence un peu plus bas dans la section MITRE ATT&CK.

Veuillez noter que la preuve de concept (POC) de l’exécution de code arbitraire (RCE) pour ces CVE n’a pas encore été rendue publique. De ce fait, les détections ci-dessous sont toutes dérivées des articles de blog originaux de Microsoft et Volexity. Dès que nous aurons davantage d’informations, nous publierons des mises à jour !

Indicateurs de compromission (IOC)

Volexity et Microsoft ont publié des IOC, y compris les adresses IP des malfaiteurs observés, les hashes et les noms de fichiers des webshells ainsi que les user agents dans leurs articles. Nous avons converti ces indicateurs au format CSV afin que vous puissiez les utiliser en tant que tables de correspondance (lookup tables), les fichiers se trouvent ici. Mais qu’est-ce qu’une table de correspondance et en quoi peut-elle aider à la détection des failles de sécurité dans Splunk ? Là encore, nous avons ce qu’il vous faut.

Vulnérabilité de contournement de l’authentification

Dans l’article de Volexity, nous voyons que cet exploit permet de contourner l’étape d’authentification et d’avoir accès aux e-mails des utilisateurs avec un minimum d’effort. L’exploit nécessite d’envoyer une requête HTTP POST à des fichiers contenus dans un répertoire spécifique /owa/auth/Current/themes/resources/.

Nous pouvons détecter ce comportement à l’aide de la recherche suivante, qui nécessite l’ingestion des logs IIS sur le serveur OWA d’Exchange.

index=* sourcetype="ms:iis:auto" http_method=POST uri_path="/owa/auth/Current/themes/resources/*"| stats count by src_ip, http_user_agent, uri_path, http_method, uri_query

Framework Nishang PowerShell

L’un des outils utilisés par HAFNIUM dans le cadre de cette attaque était le framework Nishang PowerShell. Une méthode serait de rechercher des messages PowerShell où les commandlets Nishang indiqués dans l’article de Microsoft sont détectés :

index="*" sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4104 Message="* Invoke-PowerShellTCP*"

Une autre serait d’utiliser le code d’événement 4688 et de trouver une partie de l’activité spécifique exécutée :

index="*" sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4688 Creator_Process_Name="powershell.exe" System.Net.Sockets.TCPClient

Détection Powercat

Le malfaiteur a utilisé PowerShell pour télécharger et exécuter Powercat dans la mémoire. Cela fait des années que nous parlons de PowerShell et des cradles IEX chez Splunk (comme dans cet article et cette présentation .conf16). Une solution simple pour détecter si vous avez été touché par cette activité est de vous assurer de collecter les logs de l’événement 4104 et de chercher le terme « powercat » :

index="*" sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4104 Message="*powercat*"

Le service de messagerie unifiée d’Exchange utilisé pour créer du contenu exécutable

Le service de messagerie unifiée (UM) de Microsoft Exchange Server pourrait être détourné par HAFNIUM afin de créer du contenu exécutable dans des formats côté serveur courants tels que PHO, JSP, ASPX, etc. Il est peu commun et dangereux de créer du nouveau contenu exécutable avec un composant côté serveur tel que le service de messagerie unifiée. Si ce contenu est ensuite exécuté, il pourrait être utilisé pour réaliser une exécution de code arbitraire à distance. Cette recherche inspecte les logs d’audit du système de fichiers de l’événement 4663 à la recherche de preuves indiquant que le service de messagerie unifiée a été détourné pour créer du nouveau contenu exécutable sur le serveur.

index=* sourcetype=WinEventLog source="WinEventLog:Security" EventCode=4663 Object_Type="File" (Object_Name="*.php" OR Object_Name="*.jsp" OR Object_Name="*.js" OR Object_Name="*.aspx" OR Object_Name="*.asmx" OR Object_Name="*.cfm" OR Object_Name="*.shtml") (Process_Name="*umworkerprocess.exe*" OR Process_Name="*UMService.exe*") 

Le service de messagerie unifiée utilisé pour créer un processus fils

Le service de messagerie unifiée de Microsoft Exchange Server pourrait être détourné par HAFNIUM afin de lancer des processus fils. Être à l’affut de processus parents inhabituels est une technique de détection courante que nous pouvons adapter et appliquer à cette situation. Cette recherche Splunk tire profit des événements Windows 4688, également appelés événements de création de processus. Lorsque le processus parent est lié au service UM d’Exchange, le processus pourrait être suspicieux. Cette recherche utilise une clause NOT pour aider à réduire le bruit.

index=* sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4688 (Creator_Process_Name="*umworkerprocess.exe*" OR Creator_Process_Name="*UMService.exe*") NOT New_Process_Name="*UMWorkerProcess.exe*"

Dénicher les outils des hackers

Les fichiers zip, rar et 7z suspicieux créés dans C:\ProgramData\ peuvent suggérer le placement de données en transit (staging) en vue d’une exfiltration. Les recherches ci-dessous, pour Sysmon et les logs d’événements Windows respectivement, peuvent vous aider à identifier ces fichiers.

index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational") EventCode=11 (TargetFilename="C:\\ProgramData\\*.rar" OR TargetFilename="C:\\ProgramData\\*.zip" OR TargetFilename="C:\\ProgramData\\*.7z")

OU

index=* (sourcetype="WinEventLog" source="WinEventLog:Security"  OR sourcetype=XmlWinEventLog source="XmlWinEventLog:Security") EventCode=4663 AccessList="%%4417" (ObjectName="C:\\ProgramData\\*.rar" OR ObjectName="C:\\ProgramData\\*.zip" OR ObjectName="C:\\ProgramData\\*.7z")

L’utilisation de 7-Zip pour créer des archives afin de placer des données en transit en vue d’une exfiltration a également été remarquée. Pour déterminer si ce programme a été exécuté, les recherches suivantes, pour Sysmon et les logs d’événements Windows respectivement, peuvent être utilisées comme point de départ.

index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational") EventCode=1 CommandLine="C:\\ProgramData\\7z*"

OU

index=* (sourcetype="WinEventLog" source="WinEventLog:Security"  OR sourcetype=XmlWinEventLog source="XmlWinEventLog:Security") EventCode=4688 process="C:\\ProgramData\\7z*"

Webshells

Si vous n’avez pas de logs IIS, n’ayez crainte, les données de transfert (comme Splunk for Stream) ou les logs Zeek qui enregistrent le trafic web peuvent également servir à obtenir une certaine visibilité. Évidemment, nous devons rédiger un article « Hunting with Splunk » (chasser avec Splunk) sur le sujet ! En attendant, regardez cette vidéo YouTube incontournable de James Bower qui explique comment traquer les webshells avec Splunk.

Splunk Enterprise Security et ESCU

Connais-toi toi-même

Même si nous avons pris le temps d’expliquer l’ampleur de cette attaque et qu’il est nécessaire d’entreprendre des efforts d’investigation, il faut également garder les bases à l’esprit. La gestion d’actifs de base, avec un peu de chance par l’intermédiaire de votre framework d’actifs et d’identité, vous indiquera où vos serveurs Exchange se trouvent. L’exécution régulière de scans de vulnérabilité qui s’intègrent dans Splunk montreront quels serveurs Exchange sont vulnérables et peuvent vous aider à définir les priorités de votre calendrier de publication de correctifs et à mieux cibler vos efforts de détection.

Framework d’intelligence des menaces

Si vous utilisez Splunk Enterprise Security, les lookups d’IOC listés ci-dessus peuvent facilement être ingérés dans le framework d’intelligence des menaces. Vous ne savez peut-être pas comment procéder. Pas de problème, nous avons publié des conseils et un guide pratique sur l’intégration de listes d’IOC dans le framework d’intelligence des menaces d’Enterprise Security.

Enterprise Security Content Updates (ESCU)

Pour les personnes qui utilisent ESCU, notre équipe de recherche en sécurité a publié un nouveau guide de sécurité Splunk Analytic Stories intitulé « HAFNIUM Group » le 8 mars 2021, qui regroupe des détections pour cette menace. Cela étant dit, consultez le tableau MITRE ATT&CK ci-dessous. Si vous utilisez ESCU aujourd’hui, vous bénéficiez déjà d’une excellente couverture de sécurité !

MITRE ATT&CK

À l’aide des articles de Microsoft et Volexity, nous avons associé les différentes tactiques des malfaiteurs au framework MITRE ATT&CK. Chaque tactique est ensuite reliée au contenu de Splunk afin de vous aider à dénicher cette attaque. Attention, ces recherches vous sont proposées afin d’accélérer votre chasse, nous vous recommandons de les configurer via l’application Splunk Security Essentials. Vous devrez peut-être les modifier pour qu’elles fonctionnent dans votre environnement ! Beaucoup de ces recherches sont optimisées pour être utilisées avec la commande tstats.

Enfin, lorsque de nouvelles informations et TTP (tactiques, techniques et procédures) d’ATT&CK seront disponibles, nous mettrons à jour ces recherches.

Voici une liste de toutes les TTP de MITRE ATT&CK dont nous avons remarqué l’utilisation au cours de cette attaque : 
T1003.001, T1005, T1027, T1046, T1059, T1059.001, T1070, T1071, T1074.002, T1083, T1110, T1190, T1505, T1560.001, T1589.002 et T1590.002.

Conclusion

Nous sommes bien conscients qu’il s’agit d’une vulnérabilité importante et que les clients voudront la corriger dès que possible et déterminer s’ils ont été touchés par cette attaque. Si vous ne l’avez pas encore corrigée (on a tous connu cette situation), avec un peu de chance, ces recherches vous permettront d’avoir plus de visibilité sur votre environnement et les éventuelles activités malveillantes qui pourraient vous affecter. Si elles ne fonctionnent pas parfaitement, inspirez-vous-en ! Dès que nous en saurons davantage, nous mettrons cet article à jour et, comme indiqué précédemment, restez à l’affût des autres techniques de détection qui seront publiées par notre équipe de recherche sur les menaces sur Enterprise Security Content Updates.

Comme toujours, la sécurité chez Splunk est une affaire de famille. Auteurs et collaborateurs :

Mick Baccio
James Brodsky
Shannon Davis
Michael Haag
Amy Heng
Jose Hernandez
Dave Herrald
Ryan Kovar
Marcus LaFerrera
John Stoner

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