| CERT

INTRODUCTION

Après une première phase de reconnaissance, nous avons décidé de monitorer les menaces transitant par le service RDP. Il est maintenant temps de vous décrire nos méthodes, nos pré-requis, quels outils utiliser, et comment stocker les données afin de les exploiter au mieux.
Cette série d’articles a pour but de démystifier les honeypots et de fournir quelques idées pouvant vous aider dans vos projets.

Après un aperçu de nos méthodes de travail, nous présenterons une première phase de tests grandeur nature lancée sur une courte période.

Le RDP (Remote desktop protocol) est un protocole de prise de contrôle de Windows a distance. Celui-ci est énormément utilisé pour faire de la maintenance à distance.
C’est une cible très prisée par les attaquants car :

  • Souvent ce sont les entreprises et non les particuliers qui utilisent le RDP
  • Un accès RDP c’est un pied facile dans le LAN.
  • Un accès RDP est beaucoup plus simple à utiliser pour manipuler une machine qu’un shell ou une backdoor
  • Énormément de petits commerces utilisent aujourd’hui un ordinateur pour traiter la caisse du magasin. Ces petits commerces n’étant souvent pas familier avec l’informatique, la maintenance de ces caisses est sous traitée à des prestataires de services, qui, pour des des raisons de coûts, ne se déplacent pas et préfèrent faire la maintenance à distance… par RDP. Et malheureusement, de nombreuses sociétés de services n’ont pas les bases de la sécurité informatique et ont de mauvaises pratiques tels que les mots de passe faible et l’absence de 2FA etc. Ces caisses accessibles facilement RDP sont donc très recherchées par les attaquants.

L'INFRASTRUCTURE

L’objectif étant de faire un Honeypot robuste et le plus automatisé possible, notre infrastructure doit respecter certains pré-requis:

  • Elle doit permettre la mise sur écoute du réseau
  • Elle doit pouvoir récupérer les malwares automatiquement
  • Elle doit pouvoir se restaurer de manière automatique
  • Elle doit pouvoir recueillir les informations collectées
  • Elle doit être robuste et solide afin d’empêcher toute compromission non-maîtrisée.

 

Ce type de honeypot se décompose en 4 parties:

  • Le réseau
  • Les endpoints
  • La capture des données
  • Le stockage des données

A. Le réseau

Un schéma réseau classique est utilisé (192.168.0.x/24), les VM honeypots doivent pouvoir communiquer entre elles (pour nous permettre d’observer les propagations latérales vers des VM non exposées directement sur Internet) et ont un accès total à internet qui leur est fourni par leur gateway. Cette gateway est placée sur un bastion fait maison, qui est l’élément unique permettant la communication entre les attaquants et les machines vulnérables.
Le but principal du bastion est d’être un routeur sécurisé qui va orienter tout le trafic provenant des VM vers l’extérieur. Ce trafic est redirigé vers un tunnel à destination d’une de nos IP publiques FeedFarm.

B. Les endpoints

  • Système d’exploitation
    Nos honeypots sont des machines virtuelles Windows 7 et Windows 2008 R2 imitant au mieux l’usage dans un contexte professionnel : Les renommer, leur fournir un fond d’écran et une vie sur les navigateurs permet d’augmenter le réalisme de ces honeypots, et donc d’attirer et de garder l’attaquant sur la machine le plus longtemps possible.
    Les mots de passe et comptes utilisés sont des mots de passe simples à bruteforcer, parfois contenus dans des listes publiques.
    Nous essayons cependant de ne pas être dans les listes de bruteforce de worms comme Morto, afin d’éviter des infections déjà trop “connues” et déjà traquées comme sur http://benkow.cc/morto/ par exemple.

 

  • Sauvegardes et backups
    L’objectif principal de ces honeypots est évidemment de se faire compromettre. Rien de tel alors pour entraîner nos collaborateurs sur des cas réels de forensics.
    Nous sauvegardons alors régulièrement les machines virtuelles, pour permettre à la fois l’entraînement, mais aussi la conservation de preuves en cas d’utilisation de notre honeypot à des fins malveillantes.

 

C. Captures

  • Tshark et IPTables
    L’autre objet de ce bastion est de capturer le trafic émanant de ces honeypots.
    Nous utilisons pour cela tshark, qui permet l’extraction de pcap au format csv.
    Cependant, ayant observé des problèmes de stabilité, nous nous sommes aussi tournés vers les journaux d’iptables pour pouvoir exploiter du log léger comme “source, dest, port, etc..”.

 

  • SplunkForwarder
    Une fois les logs acquis, ils sont forwardés directement à Splunk via un splunkforwarder installé sur le serveur. Cela nous permet d’avoir rapidement des logs correspondant déjà à un index.

 

  • Frappes claviers, screenshots RDP, clipboard
    L’objectif est de récupérer sur n’importe quel utilisateur de la VM honeypot, les frappes clavier, le contenu du clipboard, des screenshots de sessions RDP… , tout en restant invisible par l’attaquant. Nous avons ainsi, dans un premier temps, choisi d’utiliser des softwares réputés pour faire ce genre d’interceptions, des RAT comme darkcomet ou des keyloggers comme Cyborg.
    Malheureusement aucun de ces outils ne convenait totalement à nos besoins.
    Par exemple, aucun n’était en mesure de récupérer un fichier exécuté depuis un partage monté de type \\tsclient, les log exportés étaient de très mauvaise qualité, et comme la majorité des malwares, la stabilité du programme laissait à désirer..
    Nous avons alors dû passer un peu de temps à développer un outil de surveillance qui convenait plus à nos besoins, c’est-à-dire modulaire, et dont l’output de logs était hautement customizable.
  • Réseau
    La capture réseau quant à elle se fait exclusivement sur le bastion, qui voit tous les flux de paquets entrants et sortants, ainsi que ceux issus de machines non connectées directement à internet mais accessible par le réseau LAN du Honeypot que nous utilisons pour détecter des mouvements latéraux.

 

D. Stockage et visualisation

Les logs récupérés sur notre Splunk sont organisés en deux grandes parties :

1. Le trafic émis par les honeypots :

Cela nous permet d’avoir des statistiques sur les ports utilisés, les destinations, la bande passante utilisée, et donc savoir très vite lorsqu’un attaquant a mordu à l’hameçon.

2. Le trafic reçu depuis l’extérieur :
La deuxième partie contient des graphs nous permettant d’afficher des statistiques sur les IP nous “scannant” ou nous attaquant, ainsi que sur les ports utilisés, qui comme nous l’avons dit dans le premier article ne sont pas forcément le port standard 3389 de RDP.

DATAS

A. Actuellement capturé

Pour le moment les datas que l’on capture sont de plusieurs types :

  • logs de paquets (stats réseau)
  • logs des screenshots lors de clic/changement de focus etc.
  • logs des frappes claviers
  • logs du clipboard
  • logs machines :
    De manière périodique, un dump de la machine est effectué, pour pouvoir en cas de besoin effectuer une analyse post-mortem.

 

B. Volonté de capture dans les prochaines versions

A terme nous désirons aller plus loin dans la capture et l’analyse des datas. En effet la collecte actuelle se contente de points surfaciques.
Nous désirons mettre en place sous peu dans les prochaines versions :

  • Du full packet capture (afin de pouvoir reconstituer les malwares téléchargés en cas d’effacement du fichier sur le disque)
  • La récupération des events Windows (notamment les command lines exécutées)
  • La capture de l’exécutable de chaque processus lancé par l’attaquant sur la machine

PREMIERS RÉSULTATS

Dès la mise en place de nos honeypots, nous avons pu observer deux grandes phases

A. Une phase de reconnaissance :

On identifie clairement une évolution du nombre de paquets reçus vers notre RDP, mais aussi une évolution du type de connexion.

La reconnaissance se déroule en 3 étapes :
1 – Scans à la recherche de RDP ouverts
2 – Bruteforces du RDP trouvé
3 – Utilisation malveillante du honeypot

Nous avons relevé, sur une période de trois semaines, plus de 1200 IP différentes ayant effectué un scan de notre honeypot, avec plusieurs paquets de tentatives de connexion comme lors de bruteforce par dictionnaire.
Les personnes ayant réussi à bruteforcer nos mots de passe ont alors tous effectué la même procédure :
1 – Vérification de l’IP publique du honeypot via google (whatsmyip,whoer.net,…)
2 – Vérification des variables locales (clavier français, machine en français)
3 – Lecture des documents présents sur la machine (cet attaquant n’est certainement pas un bot)
4 – Déconnexion.

 

B. Une phase d’exploitation :

Après cette phase où nous n’avons eu que quelques véritables connexions sans installation de malware ni action malveillante, notre honeypot semble enfin présent dans les listes des hackers et avons pu voir des actions malveillantes à un rythme soutenus; en moyenne 2 attaques par jours.

a. Observation de différents modes opératoires

Miners
Nous avons pu observer une grande quantité de Miner de bitcoin, d’ethereum et d’autres crypto-monnaies.
Deux modes opératoires différents ont été identifiés:

1. Le script “one-clic”, qui installe le Miner, qui pousse la configuration etc. Plutôt rares, ils reviennent de manière périodique vérifier ou réinstaller le malware.

2. Le script-kiddie qui va jusqu’à lire de la documentation sur le net depuis la machine compromise puis installe le malware ou le miner et met en place la configuration à la main. Ce deuxième mode opératoire est rencontré beaucoup plus fréquemment.

Ransomwares

Fréquemment le Honeypot est la cible de Ransomwares en tout genre.
Nous voyons en ce moment fréquemment deux d’entre eux :

1. Nemesis

2. Blackout Ransomware.
Ce ransomware a été vu vers le 13 juillet 2017. Nous avons pu l’observer dans nos honeypots une dizaine de jours plus tard.

Plusieurs moyens d’infection ont été observés :

1. Le premier est le téléchargement du payload depuis un site malveillant contenant souvent plusieurs payloads différents, comme du ransomware, du keylogger, des infos stealer, etc..

– Comme exemple, Nemesis Ransomware, droppé depuis hxxp://3501.\ru/l.zip

2. Le second, est le lancement de l’exécutable au travers d’un partage RDP, le tsclient. (cf. schéma ci-dessous)

Le problème dans ce genre de cas est qu’il nous est impossible de récupérer le malware qui a été lancé par tsclient par des moyens usuels de forensics, à moins de récupérer le payload en mémoire. Cela demande donc une certaine réactivité suite à l’infection.

Nous sommes passés à côté de samples à cause de cette technique, et notamment lors de l’infection par Blackout Ransomware. Infectés via cette technique, nous n’avons pas pu récupérer le payload, puisque nous ne nous attendions pas à ce cas d’utilisation du tsclient.

Rebonds vers d’autres RDP ou ajout à des listes

Le clipboard, que nous capturons lors de la connexion au RDP, est une source importante d’informations. En effet nous avons observé plusieurs attaquants partageant leur clipboard entre l’hôte et le client.
Ce clipboard était quelques fois remplis de données comme des listes de RDP vulnérables.

Ces listes sont ensuite mises en vente sur des sites spécialisés de revente de machines RDP “vulnérables” (mot de passe faible souvent).

Ces listes sont parcourues par des attaquants pour y regarder le niveau d’intérêt de la machine, comme le pays de présence, la version de la machine ou autres. Cela permet entre autre de pouvoir choisir une machine en fonction de l’attaque qui va être menée (miner, ransomware, …). Par exemple sur un Windows 2008, la probabilité d’avoir un peu plus de CPU que sur un Windows 7 est relativement forte et donc permet de s’assurer qu’un Miner puisse tourner correctement. Mais cela peut aussi indiquer la présence d’un serveur d’entreprise, et devient donc une cible intéressante pour d’autres raisons.
Ci-dessous, nous pouvons voir un exemple de cette liste capturée, comprenant des lignes commes IP:PORT@domains\user:password .

Nous ne sommes pas surpris par la faible robustesse des passwords, et cela confirme nos observations : les bruteforces effectués sur nos honeypots sont relativement courts, et nous avons l’impression que des listes relativement petites de couples user/password sont utilisées. En effet nous n’avons eu qu’un seul réel bruteforce itératif en 1 mois de logs.

Mules (blanchiment d’argent via achat et envoi d’objets)

Les RDP semblent être très prisés pour le blanchiment de numéro de carte de crédit et de compte paypal volés. Les attaquants semblent utiliser des RDP ouverts pour commander des objets sur Internet.
Il existe de nombreux moyens d’encaisser l’argent de CB volées, Comme la livraison de produits achetés sur Internet dans d’autres pays, la fraude au remboursements, la fraudes via Paypal… (cf screenshot) .

L’attaquant prend soin d’utiliser des sites de commerce de localisation proche de l’IP du RDP utilisé (en France les attaquants vont faire des achats sur des sites comme bonprix.fr , mais aussi sur des sites de commerce un peu plus “world-wide”, tel que wish.com, ou sarenza.com).
Paradoxalement, la livraison en Russie ne semble pas poser de problèmes lors de contrôles bancaires ou ceux censés être réalisés par les sites eux-mêmes.

La première étape est de vérifier si le compte PayPal est valide, et permet le paiement (par la présence de carte de crédit notamment).

Pour ce faire, l’attaquant teste des micro virements, en faisant des donsà http://chrispederick.com/ pour tester l’autorisation de paiements.
Il semble que ce soit une blague douteuse en référence au hack du plugin Web Developper de Chris Pederick, le développeur du plugin qui a avoué s’être fait compromettre son compte, ce qui avait permis l’upload d’une version hackée .

Enfin, des achats sont effectués avec ces comptes PayPal, et ce principalement dans le même pays que la personne s’étant faite voler ses credentials.

Lors de ce genre d’opération, les attaquant n’hésites pas à se mettre à l’aise sur la machine, notamment en changeant les mots de passe, en installant tout un ensemble d’outils qui semblent utiles à son environnement et à ses méfaits, avec l’installation custom de plusieurs navigateurs, d’Epic Privacy Browser, de MX5, et d’Opera. Les attaquants n’hésitent pas à se reconnecter sur les mêmes RDP encore et encore, utilisant les outils installé précédemment. On ne parle pas d’attaque one shot sur les RDP, les attaquants utilisent plusieurs fois des serveurs déjà utilisés.

Quelques ratés

Enfin nous avons vu beaucoup de scripts lancés automatiquement. Ces derniers étant configurés pour fonctionner sur des clavier qwerty ils échouent sur nos honeypots.

Le choix de la langue étant primordial sur notre type de honeypot, notre choix a été de se focaliser sur du français. La conséquence est donc de risquer de passer à côté de certaines attaques.

POINTS BLOQUANTS

Lorsqu’on se connecte en RDP, il est possible de partager un dossier et des fichiers entre l’hôte et le guest. Cette technologie s’appelle le tsclient.

Cette fonctionnalité est donc très utilisée par les attaquants pour dropper des payloads.

Cette fonctionnalité nous pose problème car l’attaquant lance le payload depuis le répertoire distant, sans le copier sur le disque. La souche étant sur le poste de l’attaquant, nous ne pouvons récupérer une trace de la souche sur la machine Honeypot qu’en mémoire.

Certains payloads, à la fin de leur action malveillante s’arrêtent proprement et il n’y a alors plus de traces en mémoire.

Nous travaillons sur un workaround, de nombreuses possibilités s’offrent à nous, comme par exemple le hook d’API de création de processus…

CONCLUSION

Ce type de projets peu coûteux en temps et en matériel permet l’exploitation de résultats pertinents très rapidement.
Ce projet a aussi une très forte plus value en training : entre le développement d’outils spécialisés, la mise en place réseau et système, l’analyse de malware et l’investigation forensic, toute une plateforme d’autoformation pour une équipe Blue-Team est ainsi disponible.

Si nos données vous intéressent ou que vous avez des suggestions ou des retours d’expérience, n’hésitez pas à nous contacter, afin que nous puissions améliorer notre projet et l’analyse de nos données.

LITTÉRATURE

HONEY !? WHERE IS MY POS ? Par Marc Doudiet
Beaucoup de publications disponibles sur http://cc.thinkst.com/searchMore/honeypot/
Divers projets comme https://github.com/citronneur/rdpy