e-Xpert Solutions Lausanne
Auteur : David.R
Date de publication : 7 août 2018 - Dernière mise à jour : 9 août 2018
Vendredi 13 Juillet 2018 !
Une procédure de mise en accusation pour « Conspiration », a été émise par le Grand Jury américain contre plusieurs membres des services de renseignement Russe.
Un document de 29 pages* décrit de façon précise le déroulement d'une cyber-attaque visant à « pirater les ordinateurs des citoyens et d’entités liés aux élections américaines de 2016, de voler des documents et de les publier afin d’interférer dans le déroulement des élections ».
*Consulter le document de 29 pages
Cibles des pirates : les réseaux du Democratic National Committee (DNC) et le Democratic Congressional Campaign Committee (DCCC), les employés, les proches collaborateurs d’Hillary Clinton.
La suite a été le scandale « DCLeaks », opération durant laquelle de nombreux échanges emails et documents « compromettants » ont été publiés par les attaquants afin de tenter de déstabiliser le parti démocrate durant la campagne présidentielle.
Cette cyber-attaque a duré plusieurs mois (de Mars à Novembre 2016), et a été d’une grande ampleur, impactant les utilisateurs (sphère privée et professionnelle), les infrastructures (réseaux DNC & DCCC), certains fournisseurs (logiciel lié à la gestion des votes) etc…
Dans ce bulletin, nous nous concentrons sur les attaques ciblant les utilisateurs et les infrastructures et nous abordons la méthodologie et les techniques utilisées par les attaquants (Tactics Techniques and Procedures). De là, nous envisageons les mécanismes de réponses qui auraient pu contrecarrer cette attaque.
Attaque initiale du DNC (patient 0) : John Podesta (Directeur de campagne)
John Podesta (Directeur de campagne DNC)
Le 16 Mars 2016, John Podesta reçoit le mail ci-dessous :
Le mail invite la victime à changer son mot de passe en cliquant sur le lien vers un service d’ « URL Shortener ».
En analysant le lien « bit.ly » on découvre vers quelle URL finale la victime est en fait renvoyée :
Il s’agit de « myaccount.google.com-securitysettingpage.tk », le domaine de destination réel étant : securitysettingpage.tk. (Évidemment pas un service de Google).
Cette technique de Phishing est communément utilisée pour tromper la vigilance des victimes puisque si le nom du domaine est lu rapidement il est facile de se tromper pour un utilisateur non « averti ».
à noter : L’utilisation du domaine .tk est gratuite… limitant ainsi les traces de paiements potentiels...
Force est de constater que cette technique est toujours d’actualité…
Extrait d’une base Threat Intelligence (2017-07)
John Podesta n'a pas pressenti la ruse. Il s'est connecté au site en question et a saisi toutes ses information d'authentification. Le piège se referme ! Toutes ses informations sont désormais entre les mains des pirates !
Image d’illustration d’un Phishing
En moins de 2 jours plus de 50 000 emails ont été dérobés (au 21 Mars 2016).
DNC : Reconnaissance, Mouvement latéral, Exfiltration
Les attaquants veulent se rapprocher de la candidate, pour cela ils ont opéré plusieurs attaques de phishing successives ciblant plus de 30 employés de campagnes.
La première étape a été de s’appuyer massivement sur les réseaux sociaux ainsi que sur les mails récupérés pour étudier les relations entre les différentes personnes.
Le scénario diffère légèrement cette fois ci :
Le scénario le plus "classique » est d'inviter les utilisateurs à saisir leur identifiant et mot de passe pour télécharger un document.
Image d’illustration Phishing – Document downlaod
Intrusion dans le réseau DCCC & DNC : Reconnaissance, Scanning, Intrusion, Persistance, Mouvement latéral puis Exfiltration
Dans le même temps les attaquants ont également ciblé l’infrastructure utilisée par le DCCC et le DNC.
Pour cela ils ont procédé de façon « classique » :
La description de la méthodologie de cette attaque s'appuie en partie sur le rapport fourni par CrowdStrike (2) (mandaté pour effectuer les investigations).
L’étape de persistance est primordiale pour un attaquant, elle consiste à conserver l’accès après une intrusion dans un système.
Les éléments suivants font partie de l’attaque :
Techniques « anti forensique » : Ce type de mesures sont utilisées dans des attaques avancées pour rendre le travail d’un analyste plus difficile (en théorie). Le « contre-coup » de ces méthodes et qu’elles peuvent aider un analyste averti puisqu’il concentrera sa recherche / alerting sur la détection de mesures anti-forensique… (nous le démontrerons dans la suite de cet article).
Les méthodes utilisées :
Le mouvement latéral fait partie des étapes classiques d’une intrusion, cela consiste à tenter d’étendre ses accès sur un réseau à partir une intrusion initiale.
Méthodes utilisées
Mimikatz : C’est un outil développé par Benjamin DELPHY servant à récupérer le mot de passe d’un utilisateur Windows. En effet, les mots de passes lors d’une connexion (interactive, RDP…) sont stockés en clair dans une zone « cache ». L’outil va extraire ces informations. C’est un outil classique utilisé dans les tests d’intrusion.
Authentifications depuis la workstation initialement compromise : Une fois des mots de passes récupérés (avec Mimikatz) l’attaquant va essayer de se connecter à de nouveaux ordinateurs pour étendre son emprise sur le réseau.
Une fois bien établi sur les réseaux du DNC et du DCCC les attaquants cherchent des données.
Ils ont ensuite exfiltré ces données vers un serveur sous leur contrôle avant de les publier sur DCLeaks.
La publication contenait des emails en grand nombre ainsi que des documents volés.
Cette attaque même avancée par son ampleur et ses cibles démontre des défaillances dans les méthodes de protection et de détection.
Nous ne parlons ici pas de produits spécifiques mais de bonnes pratiques à adopter en matière de protection et de détection qui auraient permis d’empêcher ces attaques ou du moins d’en réduire fortement les impacts.
Le tableau suivant reprend les différents éléments liés à cette attaque et propose des réponses qui auraient pu être mise en place en amont afin de garantir la sécurité des données.
Ces réponses sont d’ordre humaines ou techniques, seuls les uses cases concernant cette attaque sont couverts dans cet article.
Pas d’utilisation de 0-day ou d’attaques hautement complexes pour les compromissions initiales, seulement du Phishing et l’exploitation de failles « humaines » !
Une sensibilisation adéquate aurait permis de limiter l’incident mais aussi d’avoir des utilisateurs avertis capables de reconnaître l’attaque et d'enclencher les bons moyens de réponses (renforcement de la surveillance, de la sécurité, assistance d’experts etc…).
Plusieurs attaques ont été perpétrées sur des mails « privés » ex gmail.com.
De même, un volume important de mails liés aux activités du parti a été volé sur ces environnements. Il est souvent déconseillé d’utiliser ses mails personnels à des fins professionnelles et pour cause…
Même si cette attaque peut paraitre complexe sur le plan technique plusieurs mesures auraient permis de prévenir ou à minima de détecter ces activités malicieuses.
Authentifications à double facteurs - prévention : L'avantage de ce process est de prévenir la connexion d’un utilisateur malveillant, puisque la personne qui s’authentifie doit « Connaître et Posséder quelque chose qui l’identifie».
Généralement on a un mot de passe, l’élément « connu » et un token (l’élément possédé) pour s’authentifier. Les tokens pouvant être un SMS envoyé par le système, un code généré sur le téléphone mobile de l’utilisateur légitime, une clé etc…
Ce procédé permet de contrer la majorité des attaques de Phishing.
à noter : Google propose gratuitement ce service aux utilisateurs de Gmail depuis 2012 !
“Malware Can Hide, But It Must Run”
Collecte des Windows (exécution de commandes) - détection : L’activation de stratégie d’audits Windows liées aux Exécutions de commandes permet de détecter l’utilisation de binaire non trustés (X-Agent X-Tunnel) ou le « détournement de binaires trustés à des fins malveillantes (ex powershell…).
Plusieurs uses cases de détection possibles (puisque l’antivirus a été inefficace) :
Les événements Windows utilisables pour cette détection sont :
Restriction des logiciels non approuvés - prévention :
L’utilisation d‘Applocker (inclus dans Microsoft Windows) aurait permis de détecter et de bloquer l’utilisation de logiciels non approuvés. Cette méthode très efficace contre les malwares reste marginale en termes d’implémentation dû au problématique de faux positifs.
Détection des implants WMI (collecte des logs Windows) – détection :
La technique de persistance utilisée est de type « fileless ».
Ce type d'attaques est connu depuis plusieurs années et déjà utilisé dans différents malwares ou frameworks d'attaques (ex : Metasploit, Nishang, Powersploit…).
De même ce type d’implant WMI n’est pas nouveau puisqu’il était déjà utilisé dans le malware Stuxnet (4) en 2010 ! De même il est décrit dans une présentation à la conférence BlackHat 2015 (3).
Il est possible de le détecter via les évènements Windows et/ou Sysmon :
sans Sysmon :
Avec le monitoring WMI (sans Sysmon) :
Exemple d’une search query Splunk dédiée à cette détection.
Détection de l’Event Log Clearing (via la collecte des logs Windows) – détection :
Cette mesure anti-forensique effectuée par les attaquants est en réalité un excellent moyen de détection d’une attaque, en effet, le fait de supprimer les entrées du journal des événements va générer un événement de sécurité !
Il suffit donc de collecter les events suivants :
Déclencher une alerte sur cet événement et le premier use case que nous implémentons, puisqu’il est justement facile à générer et permet de tester les méthodes d’alarmes.
Détection de communication vers un Command & Control (via la collecte d’information réseau) détection / prévention :
En utilisant par exemple une sonde IDS, il est possible de surveiller le trafic DNS afin d’identifier des connections vers des domaines connus comme malicieux. Cette opération est possible avec certains Firewall qui supportent également l’ « ingestion » d’Indicateurs de Compromission.
Dans le cas de l’attaque du DNC/DCCC une connexion sortante était effectuée vers « linuxkrnl.net » depuis un serveur Linux. Ce site était connu comme malicieux depuis 2015 sur des bases d’indicateurs publiques (Threat Intelligence) :
Architecture du réseau et des flux – prévention :
On ne connait pas l’état de la segmentation du réseau, nous rappelons qu’il est toujours recommandé de segmenter les réseaux pour améliorer la sécurité et si possible d’empêcher les communications entre machines / serveurs sans nécessité du métier.
Par ailleurs, la bonne pratique aurait voulu que les stations de travail n’aient pas accès direct à Internet mais passent par un proxy (qui par exemple aurait bloqué les sites connus comme malicieux ou non catégorisés…)
De même des serveurs ne devraient jamais pouvoir sortir sur Internet directement, la bonne pratique est d’utiliser un proxy avec une liste blanche uniquement vers les dépôts nécessaires aux updates systèmes/logiciels.
Détection de Mimikatz (via la collecte des logs Windows) – détection :
Même si le binaire de Mimikatz est obfusqué ou que ce dernier est exécuté en mémoire (via Powershell par exemple) il est possible de le détecter grâce au comportement qu’il va avoir sur le système.
L’utilisation de Sysmon est nécessaire…
Exemple via une search query Splunk
Détection du mouvement latéral depuis la Workstation source (via la collecte des logs Windows) – détection :
Lors d’une authentification Windows entre deux ordinateurs un évènement Windows de type 4624 est généré sur la machine de destination.
L’utilisation d’une approche statistique qui pourrait être résumée de la façon suivante permet une détection aisée de ce type d’attaque :
Détection de fuite de données (via un proxy) – détection / prévention :
Un proxy aurait pu filtrer l’envoi de documents internes vers des sites non autorisés.
Il est établi que si l’utilisation du Malware déployé par l’attaquant utilisait un protocole particulier sur du http, cela n’aurait pas été possible avec un proxy. (ce dernier aurait bloqué également le site de destination).
Couplé à une technologie de DLP, il aurait été possible de détecter des fuites tant au niveau Endpoint, qu’au niveau réseau (Mail/Http).
L’attribution de cette attaque à un gouvernement reste sujette à caution pour beaucoup d’experts, de même, le fait que la justice américaine ait pu produire les noms exacts des agents impliqués dans l’attaque sans indiquer les sources rajoute une part de mystère dans cette affaire.
Une hypothèse avancée par le journal Néerlandais « de Volkstraant » indique que des agents des services secrets Néerlandais surveillaient les services Russes en s’étant introduits dans leur infrastructure (5).
L’analyse de ces attaques (attribuées à un état) démontre que des attaques même « avancées » utilisent des méthodes finalement « classiques », ici pas de zero-day (failles exploitées non connues par l’éditeur), pas d’exploitation d’infrastructures à grande échelle (type attaque BGP etc).
En effet, la faille principalement exploitée a été la faille « humaine » via des campagnes massives de phishing, s’en est suivi un schéma d’exploitation très classique.
Par ailleurs, nous avons démontré que des moyens simples (collecte de logs sur les environnements Windows) auraient permis de détecter et d’alerter les administrateurs et le gouvernement dès les premiers signes d'attaques.
Events
Archives