Les entreprises antivirus, les experts en cybersécurité et simplement les passionnés mettent en ligne des systèmes leurres — des honeypots — pour « attraper à l'appât » de nouvelles variétés de virus ou découvrir des tactiques de hackers inhabituelles. Les honeypots sont si courants que les cybercriminels ont développé une sorte d'immunité : ils détectent rapidement qu'il s'agit d'un piège et l'ignorent tout simplement. Pour étudier les tactiques des hackers modernes, nous avons créé un honeypot réaliste qui, pendant sept mois, a vécu sur Internet, attirant les attaques les plus diverses. Nous avons relaté cette expérience dans notre étude «». Quelques faits de l'étude sont présentés dans cet article.
Développement du honeypot : liste de contrôle
L'objectif principal lors de la création de notre super piège était d'éviter que des hackers intéressés ne nous démasquent. Cela a demandé un travail considérable :
- Créer une légende réaliste sur l'entreprise, incluant noms, photos des employés, numéros de téléphone et adresses e-mail.
- Inventer et mettre en œuvre un modèle d'infrastructure industrielle correspondant à la légende sur les activités de notre entreprise.
- Déterminer quels services réseau seraient accessibles de l'extérieur, tout en veillant à ne pas ouvrir de ports vulnérables, afin que cela ne ressemble pas à un piège pour les naïfs.
- Organiser l'apparence d'une fuite d'informations sur un système vulnérable et diffuser ces informations parmi les attaquants potentiels.
- Implémenter une surveillance discrète des actions des hackers au sein de l'infrastructure du piège.
Et maintenant, passons à tout cela dans l'ordre.
Création de la légende
Les cybercriminels sont déjà habitués à rencontrer de nombreux honeypots, c'est pourquoi la partie la plus avancée d'entre eux effectue une recherche approfondie sur chaque système vulnérable pour s'assurer qu'il ne s'agit pas d'un piège. Pour cette raison, nous avons cherché à obtenir non seulement le réalisme du honeypot en termes de design et d'aspects techniques, mais aussi à créer l'apparence d'une véritable entreprise.
En nous mettant à la place d'un hacker hypothétique, nous avons développé un algorithme de vérification permettant de distinguer un véritable système d'un piège. Cela incluait la recherche des adresses IP de l'entreprise dans les systèmes de réputation, l'analyse inverse de l'historique des adresses IP, la recherche de noms et de mots-clés liés à l'entreprise ainsi que ses partenaires et bien d'autres éléments. Au final, la légende était tout à fait convaincante et attrayante.
Nous avons décidé de positionner la fausse usine comme un petit atelier de prototypage industriel, travaillant pour de très grands clients anonymes issus des secteurs militaire et aéronautique. Cela nous a épargnés des complications juridiques liées à l'utilisation d'une marque existante.
Ensuite, nous devions élaborer une vision, une mission et un nom pour l'organisation. Nous avons convenu que notre entreprise serait une startup avec un nombre restreint d'employés, chacun étant un fondateur. Cela ajoutait de la crédibilité à la légende sur la spécialisation de notre activité, permettant de travailler sur des projets délicats pour de grands clients importants. Nous voulions que notre entreprise ait un aspect faible en termes de cybersécurité, mais il devait également être évident que nous travaillions avec des actifs importants dans les systèmes cibles.
Capture d'écran du site honey pot MeTech. Source : Trend Micro
Nous avons choisi le mot MeTech comme nom de l'entreprise. Le site a été créé sur la base d'un modèle gratuit. Les images ont été prises dans des banques d'images, en utilisant les moins populaires et en les retravaillant pour les rendre moins reconnaissables.
Nous voulions que l'entreprise ait l'air réelle, il était donc nécessaire d'y inclure des employés ayant des compétences professionnelles correspondant à son activité. Nous leur avons inventé des noms et des personnalités, puis avons tenté de choisir des images à partir de banques d'images en fonction de l'appartenance ethnique.
Capture d'écran du site honey pot MeTech. Source : Trend Micro
Pour ne pas être découverts, nous cherchions des photos de groupe de bonne qualité, à partir desquelles nous pourrions sélectionner les visages dont nous avions besoin. Cependant, nous avons ensuite abandonné cette option, car un potentiel hacker pourrait utiliser la recherche d'image inversée et découvrir que nos "employés" n'existent que dans des banques d'images. Finalement, nous avons utilisé des photos de personnes inexistantes, créées par intelligence artificielle.
Les profils des employés publiés sur le site contenaient des informations importantes sur leurs compétences techniques, mais nous avons évité de mentionner des établissements d'enseignement spécifiques et des villes.
Pour créer des boîtes aux lettres, nous avons utilisé le serveur de l'hébergeur, puis nous avons loué plusieurs numéros de téléphone aux États-Unis et les avons intégrés dans un standard virtuel avec un menu vocal et un répondeur.
Infrastructure du honeypot
Pour éviter d'être détectés, nous avons décidé d'utiliser une combinaison de matériel industriel réel, d'ordinateurs physiques et de machines virtuelles sécurisées. Pour faire avancer les choses, disons que le résultat de nos efforts a été vérifié à l'aide du moteur de recherche Shodan, et il a montré que le honeypot ressemblait à un véritable système industriel.
Résultat du scan du honeypot avec Shodan. Source : Trend Micro
Comme 'matériel' pour notre piège, nous avons utilisé quatre PLC :
- Siemens S7-1200,
- deux Allen-Bradley MicroLogix 1100,
- Omron CP1L.
Ces PLC ont été choisis pour leur popularité sur le marché mondial des systèmes de contrôle. De plus, chacun de ces contrôleurs utilise son propre protocole, ce qui nous permettait de vérifier lequel des PLC serait attaqué le plus souvent et s'ils intéresseraient quelqu'un.
Équipement de notre 'usine'-piège. Source : Trend Micro
Nous n'avons pas simplement installé des appareils et les avons connectés à Internet. Chaque contrôleur a été programmé pour réaliser des tâches, parmi lesquelles figuraient
- mélangeage,
- gestion du brûleur et de la bande transporteuse,
- pallétisation à l'aide d'un manipulateur robotisé.
Et pour que le processus de production soit réaliste, nous avons programmé une logique pour modifier aléatoirement les paramètres de rétroaction, simuler le démarrage et l'arrêt des moteurs, allumer et éteindre le brûleur.
Notre usine comptait trois ordinateurs virtuels et un physique. Les machines virtuelles étaient utilisées pour gérer l'usine, le robot de palettisation et comme station de travail pour l'ingénieur programmeur PLC. L'ordinateur physique fonctionnait comme un serveur de fichiers.
En plus de surveiller les attaques sur les PLC, nous souhaitions suivre l'état des programmes chargés sur nos appareils. Pour cela, nous avons créé une interface permettant de déterminer rapidement comment les états de nos mécanismes d'exécution virtuels et installations avaient été modifiés. Déjà à l'étape de planification, nous avons découvert qu'il était beaucoup plus simple de réaliser cela avec un programme de gestion qu'en programmant directement la logique du contrôleur. Nous avons donné un accès à l'interface de gestion des appareils de notre honeypot via VNC sans mot de passe.
Les robots industriels sont un composant clé de la fabrication intelligente moderne. C'est pourquoi nous avons décidé d'ajouter un robot et un poste de travail pour le contrôler à l'équipement de notre usine-piège. Pour rendre l '«usine» plus réaliste, nous avons installé un véritable logiciel sur le poste de travail qui est utilisé par les ingénieurs pour le programmation graphique de la logique du robot. Étant donné que les robots industriels se trouvent généralement dans un réseau interne isolé, nous avons décidé de laisser l'accès non sécurisé par VNC uniquement au poste de travail de gestion.
L'environnement RobotStudio avec le modèle 3D de notre robot. Source : Trend Micro
Sur la machine virtuelle avec le poste de travail de gestion du robot, nous avons installé l'environnement de programmation RobotStudio d'ABB Robotics. Après avoir configuré RobotStudio, nous avons ouvert un fichier de simulation avec notre robot de manière à ce que son image 3D soit visible sur l'écran. Par conséquent, Shodan et d'autres moteurs de recherche, en découvrant un serveur VNC non sécurisé, obtiendront cette image de l'écran et la montreront à ceux qui recherchent des robots industriels avec un accès ouvert à la gestion.
Le sens d'une telle attention aux détails était de créer une cible attrayante et aussi réaliste que possible pour les attaquants, qui, l'ayant trouvée, y reviendraient encore et encore.
Poste de travail de l'ingénieur
Pour programmer la logique des PLC, nous avons ajouté un ordinateur d'ingénieur à l'infrastructure. Celui-ci a été équipé d'un logiciel industriel pour la programmation de PLC :
- TIA Portal pour Siemens,
- MicroLogix pour le contrôleur Allen-Bradley,
- CX-One pour Omron.
Nous avons décidé que le poste de travail de l'ingénieur ne serait pas accessible en dehors du réseau. Nous avons plutôt configuré le même mot de passe pour le compte administrateur que celui utilisé pour les postes de gestion de robot et de gestion de la fabrique accessibles via Internet. Cette configuration est assez courante dans de nombreuses entreprises.
Malheureusement, malgré tous nos efforts, aucun attaquant n'a réussi à atteindre le poste de travail de l'ingénieur.
Serveur de fichiers
Nous en avions besoin comme appât pour les attaquants et comme moyen de sauvegarde de nos propres « travaux » dans la fabrique-piège. Cela nous a permis d'échanger des fichiers avec notre honeypot à l'aide de dispositifs USB, sans laisser de traces dans le réseau du piège. Comme système d'exploitation pour le serveur de fichiers, nous avons installé Windows 7 Pro, où nous avons créé un dossier partagé, accessible en lecture et écriture pour tout le monde.
Au début, nous n'avons pas organisé de hiérarchie de dossiers et de documents sur le serveur de fichiers. Cependant, il s'est avéré que les attaquants étudiaient activement ce dossier, donc nous avons décidé de le remplir avec divers fichiers. Pour cela, nous avons écrit un script python qui créait un fichier de taille aléatoire avec une des extensions spécifiées, formant le nom sur la base d'un dictionnaire.
Script pour générer des noms de fichiers attrayants. Source : Trend Micro
Après avoir exécuté le script, nous avons obtenu le résultat souhaité sous la forme d'un dossier rempli de fichiers avec des noms très intéressants.
Résultat de l'exécution du script. Source : Trend Micro
Environnement de surveillance
Après avoir consacré tant d'efforts à créer une entreprise réaliste, nous ne pouvions tout simplement pas nous permettre de nous rater dans l'environnement pour surveiller nos « visiteurs ». Nous devions recevoir toutes les données en temps réel de manière à ce que les attaquants ne remarquent pas que nous les observions.
Nous avons mis cela en œuvre en utilisant quatre adaptateurs USB-Ethernet, quatre prises Ethernet SharkTap, un Raspberry Pi 3 et un grand disque externe. Le schéma de notre réseau était le suivant :
Schéma du réseau honeypot avec l'équipement de surveillance. Source : Trend Micro
Nous avons positionné trois prises SharkTap de façon à surveiller tout le trafic externe vers les PLC accessibles uniquement depuis le réseau interne. La quatrième SharkTap suivait le trafic des invités de la machine virtuelle vulnérable.
Prise Ethernet SharkTap et routeur Sierra Wireless AirLink RV50. Source : Trend Micro
Le Raspberry Pi effectuait une capture de trafic au quotidien. Nous avons organisé la connexion à Internet à l'aide d'un routeur mobile Sierra Wireless AirLink RV50, souvent utilisé dans les entreprises industrielles.
Malheureusement, ce routeur ne permettait pas de bloquer sélectivement les attaques qui ne correspondaient pas à nos plans, c'est pourquoi nous avons ajouté à notre réseau un pare-feu Cisco ASA 5505 en mode transparent pour effectuer des blocages avec un impact minimal sur le réseau.
Analyse de trafic
Tshark et tcpdump conviennent pour résoudre rapidement des questions courantes, mais dans notre cas, leurs capacités étaient insuffisantes, car nous avions des dizaines de gigaoctets de trafic, analysés par plusieurs personnes. Nous avons utilisé l'analyseur open-source Moloch, développé par AOL. En termes de fonctionnalité, il est comparable à Wireshark, mais offre plus de possibilités de collaboration, de description et de balisage des paquets, d'exportation et d'autres tâches.
Comme nous ne voulions pas traiter les données collectées sur les machines de honeypot, les fichiers PCAP étaient exportés chaque jour vers un stockage AWS, d'où nous les importions sur une machine avec Moloch.
Enregistrement de l'écran
Pour documenter les actions des hackers dans notre honeypot, nous avons écrit un script qui prenait des captures d'écran de la machine virtuelle à intervalles réguliers et, en les comparant à la capture précédente, déterminait s'il se passait quelque chose ou non. Lorsqu'une activité était détectée, le script lançait l'enregistrement de l'écran. Cette approche s'est révélée la plus efficace. Nous avons également essayé d'analyser le trafic VNC à partir du fichier PCAP pour comprendre quels changements s'étaient produits dans le système, mais finalement l'enregistrement de l'écran que nous avons mis en œuvre s'est avéré plus simple et plus clair.
Surveillance des sessions VNC
Pour cela, nous avons utilisé Chaosreader et VNCLogger. Les deux utilitaires extraient les frappes depuis le fichier PCAP, mais VNCLogger gère les touches telles que Backspace, Enter, Ctrl de manière plus précise.
VNCLogger présente deux inconvénients. Le premier : elle ne peut extraire les touches qu'en « écoutant » le trafic sur l'interface, c'est pourquoi nous avons dû simuler une session VNC pour elle à l'aide de tcpreplay. Le deuxième inconvénient de VNCLogger est commun à Chaosreader : elles ne montrent pas le contenu du presse-papiers. Pour cela, nous avons dû utiliser Wireshark.
Attirons les hackers
Nous avons créé un honeypot pour qu'il soit attaqué. Pour ce faire, nous avons simulé une fuite d'informations destinée à attirer l'attention des éventuels hackers. Les ports suivants étaient ouverts sur le honeypot :
Le port RDP a dû être fermé peu après le lancement en raison des problèmes de performance causés par l'immense quantité de trafic de scan dans notre réseau.
Les terminaux VNC fonctionnaient d'abord en mode « uniquement consultation » sans mot de passe, puis nous les avons « accidentellement » basculés en mode plein accès.
Pour attirer les attaquants, nous avons publié deux messages contenant des informations « divulguées » sur un système industriel disponible sur PasteBin.
Un des messages publiés sur PasteBin pour attirer des attaques. Source : Trend Micro
Attaques
Le honeypot est resté en ligne pendant environ sept mois. La première attaque a eu lieu un mois après la mise en ligne du honeypot.
Scanners
Il y avait beaucoup de trafic provenant de scanners de sociétés connues — ip-ip, Rapid, Shadow Server, Shodan, ZoomEye et d'autres. Ils étaient si nombreux que nous avons dû les exclure adresses IP de l'analyse : 610 des 9452 ou 6,45 % de toutes les adresses IP uniques appartenaient à des scanners tout à fait légitimes.
Fraudeurs
L'un des plus grands risques auxquels nous avons dû faire face était l'utilisation de notre système à des fins criminelles : pour acheter des smartphones via le compte de l'abonné, encaisser des miles d'aériennes avec des cartes-cadeaux et d'autres formes de fraude.
Mineurs
Un des premiers visiteurs de notre système était un mineur. Il a chargé un logiciel de minage Monero. Il n'aurait pas pu gagner beaucoup sur notre système en raison de sa faible performance. Cependant, si l'on combine les efforts de plusieurs dizaines, voire de centaines de tels systèmes, cela pourrait être assez rentable.
Rançongiciels
Au cours de l'activité du honeypot, nous avons été confrontés deux fois à de véritables ransomwares. Dans le premier cas, il s'agissait de Crysis. Ses opérateurs ont accédé au système via VNC, mais ont ensuite installé TeamViewer et ont utilisé ce dernier pour poursuivre leurs actions. Après avoir reçu un message de rançon exigeant 10 000 dollars en BTC, nous avons engagé une conversation avec les criminels, leur demandant de déchiffrer l'un de nos fichiers. Ils ont satisfait cette demande et ont répété leur exigence de rançon. Nous avons réussi à négocier à 6 000 dollars, après quoi nous avons simplement réinstallé le système sur une machine virtuelle, car nous avions obtenu toutes les informations nécessaires.
Le deuxième rançonneur était Phobos. Le hacker qui l'a installé a passé une heure à explorer le système de fichiers du honeypot et à scanner le réseau, avant d'installer finalement le ransomware.
La troisième attaque du ransomware s'est révélée être une farce. Un « hacker » a téléchargé sur notre système le fichier haha.bat, après quoi nous avons observé un certain temps ses tentatives pour le faire fonctionner. L'une de ses tentatives a été de renommer haha.bat en haha.rnsmwr.
Le « hacker » augmente la malveillance du fichier bat en changeant son extension en .rnsmwr. Source : Trend Micro
Lorsque le bat a finalement commencé à se lancer, le « hacker » l'a modifié, élevant la rançon de 200 à 750 dollars. Après cela, il a « chiffré » tous les fichiers, a laissé un message de rançon sur le bureau et a disparu, changeant les mots de passe de notre VNC.
Deux jours plus tard, le hacker est revenu et, pour se rappeler à nous, a lancé le bat qui ouvrait de nombreuses fenêtres sur un site pornographique. Apparemment, c'était sa manière d'attirer l'attention sur sa demande.
Résultats
Au cours de l'étude, il a été découvert qu'une fois que les informations sur la vulnérabilité ont été publiées, le honeypot a attiré l'attention, et l'activité a augmenté jour après jour. Pour que le piège attire l'attention, il a fallu permettre de nombreuses violations de la sécurité de notre entreprise fictive. Malheureusement, une telle situation n'est pas rare parmi de nombreuses entreprises réelles qui ne disposent pas de personnel dédié en IT et en sécurité.
En général, les organisations doivent appliquer le principe du moindre privilège, tandis que nous avons mis en œuvre son opposé complet pour attirer les attaquants. Plus nous observions les attaques, plus elles devenaient sophistiquées par rapport aux méthodes standard de test d'intrusion.
Et surtout : toutes ces attaques auraient échoué si des mesures de sécurité adéquates avaient été mises en place lors de la configuration du réseau. Les organisations doivent veiller à ce que leur équipement et les composants de l'infrastructure industrielle ne soient pas accessibles depuis Internet, comme nous l'avons soigneusement fait dans notre piège.
Bien que nous n'ayons enregistré aucune attaque sur le poste de travail de l'ingénieur, malgré l'utilisation du même mot de passe administrateur local sur tous les ordinateurs, il est préférable d'éviter cette pratique pour minimiser les risques d'intrusion. En effet, une sécurité faible constitue une invitation supplémentaire pour une attaque sur des systèmes industriels, qui suscitent déjà depuis longtemps l'intérêt des cybercriminels.
Source : habr.com
