Exercice de simulation d'adversaire : quand la vie réelle rencontre le monde des affaires

Qu'est-ce qu'une simulation d'adversaire ?

Contrairement aux tests d'intrusion standard qui ciblent généralement une solution, une application ou un réseau spécifique, un exercice de simulation d'adversaire est davantage axé sur une approche réaliste où seuls les objectifs (trophées) et les scénarios hors scope sont définis. Cela signifie que nous sommes autorisés, en tant qu'assaillant, à utiliser n'importe quel vecteur d'attaque qui semble prometteur pour atteindre notre objectif, comme par exemple l'attaque par hameçonnage, l'attaque physique et/ou l'attaque d'actifs exposés sur Internet, pour autant que les clients aient accepté de tels scénarios.

Les objectifs d'une telle mission sont également de mettre à l'épreuve les capacités de détection, les processus de réponse aux incidents et d'identifier les techniques, tactiques et procédures (TTP) susceptibles d'être utilisées par un acteur externe de la menace pour mener une attaque ciblée réussie contre l'infrastructure de nos clients sans en avoir connaissance au préalable.

Les exercices de simulation d'adversaire sont très appréciés des clients, car ils permettent de savoir s'ils peuvent être entièrement compromis demain par un assaillant, en mettant en évidence les faiblesses de la configuration actuelle, de leurs procédures et de leur infrastructure. À noter que jusqu'à présent, nous avons effectué de nombreux exercices de simulation d'adversaire, et nous avons toujours atteint les objectifs définis.

Introduction

Une entreprise internationale du secteur financier nous a mandatés pour effectuer une attaque ciblée à son encontre.

Seul le vecteur d'intrusion physique a été considéré comme hors scope pour cette mission, ce qui signifie que nous n'avons pas été autorisés à entrer physiquement dans le bureau de la cible afin de brancher le Raspberry sur leur réseau, de cibler l'ordinateur de l'entreprise ou d'essayer d'obtenir un accès Wi-Fi ou ce genre de scénarios.

Les objectifs suivants ont été définis :

• Obtenir un accès non autorisé au réseau interne du client.
• Augmenter les privilèges sur l'Active Directory sur site.
• Accéder à des données sensibles.
• Modifier des données ERP spécifiques (ex. : RIB) pour prouver la capacité de réaliser des fraudes financières.

Préparation de l'attaque

Infrastructure

Une infrastructure offensive dédiée complète a été mise en place avant le début de la mission. Cette infrastructure était composée comme suit :

• Redirecteurs : Actifs orientés vers l'Internet, chargés de transmettre la connexion de la victime aux serveurs de l'assaillant.
• Serveur SMTP : Serveur de messagerie utilisé pour envoyer des e-mails de phishing.
• Serveur HTTP : Serveur web utilisé pour diffuser des malwares et des outils offensifs + modèle de phishing web.
• Serveur C&C/C2 (Command & Control) : Panneau de malware pour contrôler les hôtes compromis.

Seuls les redirecteurs étaient accessibles à partir d'Internet, ce qui signifie qu'il ne devrait pas être possible d'identifier directement les IP de l'infrastructure de l'adversaire.
Chaque serveur a reçu une configuration spécifique telle que DKIM, SPF et DMARC pour le SMTP, qui permet de réduire le risque que nos e-mails de phishing atterrissent dans les spams, un certificat SSL valide pour le HTTP et le C2, sans oublier la classification du domaine pour le proxy web.

Reconnaissance de surface externe (services orientés vers l'Internet) et OSINT

Une fois l'infrastructure offensive mise en place, la première étape a consisté à identifier les services de l'entreprise accessibles à distance, à établir une liste et à vérifier les vulnérabilités potentielles.
Les données des employés ont également été collectées sur des plateformes de médias sociaux telles que LinkedIn, afin de compiler ultérieurement une liste d'adresses e-mail professionnelles à cibler et de lancer la campagne de phishing :

Des recherches sur le site shodan.io et les sous-domaines force brute ont également été effectuées afin de trouver la liste des serveurs exposés sur Internet :

Définition du scénario

Accès à Citrix protégé par 2FA

Dans la mesure où aucune vulnérabilité critique permettant d'obtenir une exécution de code ou de commande à distance (RCE) sur un actif interne de l'infrastructure ciblée n'a été décelée lors de la phase externe, il a été décidé de recourir à un scénario de phishing pour l'accès initial.

Ce scénario a été retenu parce que l'entreprise utilisait une solution d'accès à distance, en l'occurrence CITRIX NetScaler.

Ces solutions d'accès à distance (Citrix, VPN) sont des cibles de choix pour les assaillants, car si l'attaque est bien menée, et en fonction de la configuration de la solution à distance, elle peut représenter un point d'entrée idéal.

Dans la plupart des cas, il est en effet plus facile d'inciter les utilisateurs ciblés à remplir un formulaire de connexion avec leurs informations d'identification, que d'exécuter un malware qui, en outre, doit être exécuté avec succès et, dans certains cas, peut être détecté par les solutions antivirus ou EDR.

Deux options ont été envisagées :

• Diffuser un dropper dans l'e-mail (en pièce jointe ou via un lien externe) aux employés.
• Dérober les informations d'identification de l'entreprise et les répliquer sur la plateforme Citrix légitime pour générer une session valide et interagir avec elle manuellement.

Un mix des deux scénarios a été retenu afin d'augmenter le taux de réussite de la campagne.

Tout d'abord, pendant notre période de R&D, un script qui soumet automatiquement les informations d'identification Citrix dérobées, y compris le token 2FA, et génère une session valide, a été développé pour répondre à nos besoins.

Ensuite, en fonction du navigateur Web de l'utilisateur, un malware a pu être diffusé.
JavaScript a été utilisé pour prendre l'empreinte du navigateur Web de l'utilisateur et rediriger vers le dropper uniquement si « Internet Explorer » est détecté.

Cependant, une fois l'accès obtenu, une persistance doit être installée afin de conserver notre accès en cas de changement de mot de passe ou de dépassement du temps de session Citrix.

Dropper

Un fichier dropper HTA a été créé et fonctionne comme suit :

• Le fichier .HTA contient un script VB qui dépose une DLL malveillante et l'exécute avec rundll32.exe.
• Ce fichier .DLL est un binaire personnalisé permettant de se connecter au serveur de commande et de contrôle et de donner un accès à distance au client infecté (avec les privilèges de l'utilisateur actuel).

Persistance

Afin de persister sur les hôtes Citrix même après la fin de la session, un malware spécifique a été développé.

Le malware se connectait sur notre serveur C2 en utilisant HTTPS et son exécution était déclenchée par l'ouverture de n'importe quel document Word.

Cela était dû au fait que l'application Microsoft Word charge automatiquement n'importe quelle bibliothèque externe (DLL) se terminant par l'extension « .wll » présente dans le dossier %APPDATA%\Microsoft\Word\Startup de l'utilisateur qui ouvre Word.

La DLL avait pour mission de réaliser un Process Hollowing et d'exécuter un shellcode Cobalt Strike dans la mémoire du processus iexplore.exe (Internet Explorer).

Bien sûr, pour toutes nos charges utiles, nous avons utilisé plusieurs techniques d'évasion AV/EDR développées et testées pendant notre temps consacré à la R&D afin de ne pas être repérés par une quelconque solution.

L'injection de la charge utile a été effectuée dans un autre processus que WORD afin de ne pas perdre la session à distance si l'utilisateur venait à fermer l'application Microsoft Word.

Jeu d'outils

Pour résumer, nous avons créé les ressources suivantes avant d'exécuter le phishing :

• Un dropper HTA ;
• Une charge utile .DLL ;
• Une charge utile word .WLL pour la persistance ;
• Un modèle d'e-mail de phishing ;
• Une page web de phishing ;
• Une prise d'empreinte du navigateur JavaScript ;
• Un script python pour relayer les informations d'identification hameçonnées au véritable Citrix ciblé.

Par conséquent, comme vous pouvez l'imaginer, le succès d'une telle mission nécessite un important travail de préparation. Nous pourrions entrer dans les détails très spécifiques de la charge utile, du dropper et de la préparation du script de réplication des informations d'identification, mais cela mériterait certainement un article à part entière, et ce n'est pas le sujet de ce blog. Pourquoi pas dans le prochain article ? =) #teasing

Préparation du phishing

Comme mentionné précédemment, sur la base des hôtes identifiés et des e-mails collectés, nous avons décidé de lancer une campagne de phishing en utilisant le scénario Citrix. Pour ce faire, un e-mail de phishing et une page web de phishing (page d'accueil) similaire à la page originale du client Citrix ont été créés.

Exécution de l'attaque

Accès initial

Après avoir collecté un maximum d'adresses e-mail, préparé la page web et l'e-mail de phishing, il était temps de lancer l'attaque.

Le phishing a été lancé et a permis d'obtenir un accès initial en utilisant le script interne qui réplique automatiquement les informations d'identification dérobées, y compris l'OTP, sur la plateforme CITRIX cible légitime afin de recueillir des sessions Citrix valides.
Une bibliothèque de type Selenium peut également être utilisée afin d'automatiser la réplication des informations d'identification et la sauvegarde/le chargement des cookies.

Le script python combinant à la fois la capture des cookies Citrix et le rafraîchissement des cookies Selenium peut être trouvé sur notre GitHub ici : Offensive_tools/citrix_selenium.py at main · post-cyberlabs/Offensive_tools · GitHub

Figure 1 - Réplication automatique des informations d'identification Citrix (2FA) pour générer une session

Figure 2 – Accès Web Citrix (en utilisant la session)

La connexion à la session Citrix de l'utilisateur peut faire en sorte qu'il soit déconnecté, ce qui augmente le risque d'être détecté, surtout si l'utilisateur est déconnecté juste après avoir soumis ses informations d'identification sur notre page de phishing. C'est pourquoi nous attendons généralement la fin de la journée, et gardons le cookie de session valide jusqu'à la fin des heures de travail pour nous connecter.

Persistance

Une fois l'accès Citrix obtenu, une persistance a été mise en place sur les hôtes compromis pour s'assurer que l'accès ne serait pas perdu en cas de dépassement du temps de session, de réinitialisation des informations d'identification ou d'autres actions.
Il convient de noter qu'un redémarrage des hôtes infectés n'aurait pas permis de supprimer le malware, car l'infrastructure ciblée comportait des dossiers personnels d'utilisateurs mappés sur un partage réseau, y compris des données d'applications installées et donc, le malware situé dans le dossier Microsoft Word.

Cela signifie que le malware se trouvait sur un serveur de fichiers et qu'il ne se déclenchait que lorsque l'utilisateur ouvrait Word à partir de n'importe quel Citrix, même d'un hôte lancé récemment.

Figure 3 – Beacons Cobalt Strike (WLL et Process Hollowing)

Prise de contrôle de l'infrastructure

La prise de contrôle du domaine Active Directory était simple.

Le DFL (Domain Functional Level) étant assez ancien, il était supposé que les contrôleurs de domaine étaient autorisés à déclasser leurs mécanismes d'authentification pour permettre aux anciens systèmes de fonctionner correctement.

Cependant, ce type de scénario d'attaque nécessite d'avoir un listener effectuant le relais sur le port TCP 445 et dans notre cas, seul un malware fonctionnant sur un Citrix Windows a été obtenu sur l'infrastructure ciblée.

Comme Windows utilise le port 445 pour SMB et que l'arrêt de ce service ou la liaison sur ce port nécessitent des privilèges d'administrateur local, il n'était pas possible d'utiliser l'hôte compromis de ce point de vue.

Pour contourner cette limitation et réaliser l'attaque, un test a été effectué pour atteindre l'un de nos serveurs exposés à Internet sur le port 445 depuis l'hôte Citrix compromis. Si la connexion TCP réussit, cela signifie qu'aucun filtrage réseau n'a été effectué pour filtrer les connexions TCP sortantes sur des ports spécifiques.

Ainsi, une mise à niveau du protocole Net-NTLM a été tentée, ainsi qu'une coercition d'authentification utilisant à la fois PrinterBug et PetitPotam sur les DC via Internet, permettant de recueillir les hashes Net-NTLMv1 avec un défi-réponse spécifique.
Les faiblesses de Net-NTLMv1 sont notoires, des tables arc-en-ciel pour un défi-réponse prédéfini existent et pourraient permettre d'obtenir le hash NTLM de Net-NTLMv1 en quelques secondes.

Ensuite, en utilisant le hash NTLM craqué de DC et Pass-The-Hash, il a été possible de réaliser directement l'attaque DCSync et de prendre le contrôle de tout le domaine AD.

Figure 4 – Net-NTLMv1 par Internet

Une fois l'infrastructure réalisée, il a été facile de se déplacer latéralement sur le réseau interne en utilisant un hash NTLM utilisateur adéquat, notamment pour cibler la base de données de paiement Oracle, et modifier le RIB d'un employé afin de valider le 4e trophée.

Schéma de la simulation et de l'attaque

Nous avons été confrontés à de nombreuses erreurs de configuration de l'infrastructure qui nous permettent généralement d'obtenir des privilèges d'administrateur de domaine sur le réseau.

Qu'il s'agisse d'Active Directory ou de problèmes de configuration des machines, nous n'utilisons presque jamais les mêmes techniques afin d'élever nos privilèges lors de ces exercices.

C'est aussi pourquoi un tel exercice est intéressant pour les clients, car il apporte une approche plus réaliste et bien plus encore...