Rechercher

SIEM : détection d’une machine compromise par un malware

Pour notre second article sur l’avenir du SIEM, nous revenons sur un cas typique de détection d’une machine compromise par un malware, traité en avril 2019 par notre CyberSOC.

Contexte de compromission par malware

Si la plupart des SIEM (Security Information Management System) disposent de règles de corrélation par défaut, Orange Cyberdefense a fait le choix de développer ses propres mécanismes de détection. Ces règles ont pour objectif de couvrir de multiples scénarios décrits par différents référentiels dont celui de l’ETSI[1] (European Telecommunications Standards Institute) au sein duquel figure la détection de malwares.

Plusieurs règles de corrélation permettent de couvrir ce type de menaces. L’une d’entre elles a été développée par notre CyberSOC et consiste à rechercher des patterns particuliers dans les logs des proxy web. Dans le cas présent, la règle de corrélation a levé une alerte sur une requête web de type POST, un UserAgent associé au stealer Azorult ayant été détecté. C’est la combinaison de ces deux éléments qui a déclenché l’alerte avec un niveau de criticité différent en fonction du statut de la transaction (bloqué par le proxy, code d’erreur http, etc.). Cette fonction est assurée par le moteur de corrélation du SIEM.

Un ticket d’incident est créé afin d’informer le client et de tracer l’incident. Suite à cela, un analyste prend en compte l’incident et débute l’analyse. Les premières recommandations sont également proposées au client. Dans le cas présent, comme il s’agit d’une infection par malware, il faut notamment déconnecter la machine du réseau. Le malware remonté par l’alerte étant un stealer (vol d’informations d’authentification, numéros de cartes bancaires, etc.), la réinitialisation des credentials (identifiants de connexion) est une priorité.

Qualification de la menace et identification du vecteur d’infection

Notre objectif premier est de qualifier la menace : il s’agit notamment de confirmer qu’il s’agit bien d’une compromission par le malware Azorult mais également de savoir s’il n’y a pas d’autre logiciel malveillant sur cet équipement. Cette étape est cruciale car elle va déterminer en grande partie les propositions de remédiation qui seront adressées au client.

L’IOC (indicator of compromission) remonté par le SIEM était : hxxp://185.92.73[.]185/index.php ; il s’agit vraisemblablement du serveur Command and control (C2). A l’époque, cet IOC n’était pas connue des bases de Threat Intelligence publiques. L’une des premières actions de l’analyste est de rechercher si d’autres machines se sont connectées à cette adresse IP. Pour cela, les logs web et pare-feu sont interrogés, et ce, sur la période de temps la plus large possible. L’objectif est de qualifier cet IOC : il nous faut savoir s’il y a régulièrement des connexions vers cette IP, combien de machines s’y connectent, via quel type de flux réseau. Cette recherche permet de dresser un premier état des lieux. Pour cela, il est important que le SIEM puisse répondre à ces interrogations. Dans le cas présent, seule la machine précédemment identifiée a effectué une connexion web de type POST vers cette IP.

Notre second objectif est d’identifier le vecteur d’infection. Ce point est également très important pour éviter une éventuelle propagation du malware mais aussi pour identifier de potentielles autres machines.

Pour cela, les différents logs doivent être passés au crible. C’est la fonction « puit de logs » du SIEM qui est ainsi sollicitée. Il est important que le SIEM puisse supporter des requêtes complexes passées sur une volumétrie de données importantes et d’y répondre dans un temps acceptable. Pour cette investigation, nous cherchons notamment à identifier du « beaconing » (communication externe du malware à un intervalle de temps préétabli afin de récupérer de nouvelles instructions ou d’exfiltrer des données) émanant de la machine infectée. Ce type de recherche est particulièrement consommatrice car elle nécessite de calculer l’intervalle de temps entre chaque type (source destination) mais aussi la prévalence de la destination. La combinaison entre une prévalence faible de la destination, un intervalle de temps stable et court entre chaque requête et un flux émanant de la machine est particulièrement marquante. Un SIEM performant doit pouvoir permettre de répondre à cette interrogation. Dans le cas présent, aucun beaconing émanant de la machine infectée n’a été détecté.

Pour identifier la source, c’est une fois de plus la fonction puit de logs du SIEM qui est utilisée. Différents types de logs doivent être analysés car le vecteur d’infection du malware peut être multiple (mail, navigation web, clé USB, etc.). Chez ce client, seuls les logs antivirus des stations de travail sont envoyés au SIEM. Ce dernier n’a remonté aucune alerte pour cette machine. De même, rien d’anormal n’a été détecté dans les logs mails. En revanche les logs de navigation web remontent de nouveaux indices.

Une recherche sur les URL ayant une prévalence faible consultées quelques instants avant la remontée de l’alerte met en évidence une connexion suspecte. Quelques secondes avant la connexion vers le C2 d’Azorult, une requête web GET est passée depuis la machine infectée vers le site hxxp://yourbusiness4me[.]info/memorials/4804/Nonlives-Cardiagra/Twangy.html et ce via le UserAgent kbW0dUSynU31rPRS ; un fichier de 150Ko est ainsi récupéréBien qu’au moment de l’investigation cette URL ne soit pas connue des bases de Threat Intelligence, le caractère aléatoire de ce pattern est particulièrement marquant. Notre CyberSOC a en effet déjà été confronté à ce genre de cas, et l’investigation avait démontré que les connexions émanaient de scripts PowerShell malveillants dont l’objectif est de distribuer un malware.

Attaque par le ransomware GandCrab

Durant la phase d’investigation, le client nous informe que la machine identifiée par l’alerte est bien infectée par un malware. En effet, le propriétaire du PC a contacté son service informatique car ses données ont toutes été chiffrées, son fond d’écran a été modifié et indique que les données ne seront rendues qu’en échange d’un virement en crypto-monnaie. La capture d’écran fournie par le client confirme la présence d’un ransomware et suggère qu’il s’agit de GandCrab.

Fond d’écran du ransomware GandCrab ; Source : CyberSOC d’Orange Cyberdefense

Côté CyberSOC, l’URL hxxp://yourbusiness4me[.]info/memorials/4804/Nonlives-Cardiagra/Twangy.html est exécutée dans notre sandbox privée (P2A). Le résultat confirme le caractère malveillant de cette URL qui est normalement appelée par PowerShell car le fichier récupéré est ensuite passé en paramètre du compilateur C# (csc.exe).

In fine, deux malwares sont bien distribués sur la machine : Azorult et GandCrab confirmant ainsi la détection émanant de l’alerte. Notre laboratoire d’épidémiologie suit un acteur qui utilise ces deux outils. Sa volonté première étant le stealing, le ransomware est surtout utilisé pour masquer le vol de credentials. Une analyse post-mortem du poste de travail démontrera qu’il s’agit bien d’un script PowerShell. Celui-ci s’est connecté au site yourbusiness4me qui a distribué ces deux malwares. Ce script était contenu dans un fichier personnel de l’utilisateur.

Remédiation et capitalisation

La menace étant maintenant qualifiée, une remédiation peut être proposée au client. Azorult est capable de dérober de nombreux credentials dont ceux enregistrés dans le navigateur. Il est donc important de sensibiliser le collaborateur qui s’est peut-être ainsi fait dérober ses identifiants et mots de passe professionnels mais également personnels (messagerie, réseaux sociaux etc.).

Les IOC sont également ajoutés à notre base de Threat Intelligence (Datalake) et poussés dans les SIEM de nos différents clients afin de détecter tout accès à ces URL. Cependant, par défaut, la mise à jour des SIEM n’entraîne pas une recherche a posteriori de ces IOC. Pour combler ce manque, ils sont également envoyés à l’orchestrateur du CyberSOC qui, via l’API des SIEM, va lancer des recherches dans les logs de l’ensemble de nos clients.

Conclusion : les atouts et limites du SIEM sur ce cas d’usage

Si ce cas n’est pas particulièrement complexe, il illustre parfaitement les différentes fonctions (moteur de corrélation, alertes, puit de logs etc.) que doit proposer un SIEM tout comme l’intérêt d’un SOC. Dans le cas présent, sans SOC, le client aurait bien détecté la compromission par ransomware de la machine. Il n’est en revanche pas certain qu’il aurait détecté le vol de credentials, qui est l’objectif principal de cette attaque.

Ce cas illustre également les limites de l’outil. Pour des raisons bien souvent économiques, seule une partie des logs est collectée laissant ainsi des angles morts dans la détection et l’investigation. Dans le cas présent, aucun log endpoint n’est collecté, c’est pour cette raison qu’il n’a pas été possible de remonter jusqu’au fichier source de l’infection (le script PowerShell). L’utilisation accrue du chiffrement, notamment de TLS, complexifie également le travail de détection et d’analyse. Il n’aurait ainsi pas été possible d’identifier aussi aisément l’URL hxxp://yourbusiness4me[.]info/memorials/4804/Nonlives-Cardiagra/Twangy.html si elle avait été accédée en HTTPS.

Si le SIEM reste la clé de voute d’un SOC, il demeure donc très dépendant des sources de données collectées. L’émergence de nouveaux besoins, le développement du cloud et le nombre croissant de sources de données sont autant de facteurs qui vont contraindre les organisations et les éditeurs à revoir leur stratégie afin de s’adapter à ces nouvelles problématiques, faisant la part belle à l’innovation.