Comment j'ai collecté des statistiques sur la force brute de nos serveurs et les ai traitées



Nous avons placé 5 pots de miel, ci-après simplement "serveurs", pour collecter des statistiques sur la force brute RDP dans nos réseaux.



Un serveur était à Londres, l'autre à Zurich, un dans un réseau sécurisé dans M9, deux autres dans le centre de données Rucloud dans un réseau sécurisé et non sécurisé. Les adresses IP de chacun des serveurs sont sur des sous-réseaux différents, chaque adresse IP se distingue par le premier octet. Si vous essayez de mesurer la «distance» de balayage entre les adresses IP en utilisant la formule:



((Premier octet du sous-réseau # 1) - (Premier octet du sous-réseau # 2)) * (2 ^ 24),



Si vous recherchez 0.0.0.0/0, un attaquant devra parcourir au moins 771751936 adresses IP pour trouver les deux serveurs les plus proches l'un de l'autre. De plus, aucun des serveurs n'a répondu à ICMP et chaque adresse IP n'a été utilisée par personne pendant 3 mois, les 5 serveurs ont ouvert des ports en même temps. Tous les serveurs étaient connectés à AD.



Graphiques multicolores



Nous commençons par l'intéressant et finissons par l'important.







Le départ était bon. Le premier bruteforcer est arrivé sur le serveur de Rucloud la toute première heure d'ouverture du port. Sur tous les autres centres de données, le serveur n'a été découvert que dans la deuxième heure.



Comme vous pouvez le voir sur les graphiques, la force brute n'a pas beaucoup changé d'un jour à l'autre. Et si vous regardez l'heure de la journée? Voici les graphiques. Différentes couleurs sont des jours différents.





Horaire horaire dc ZUR1.





Graphique de l'heure dans le sous-réseau sécurisé M9.





Graphique de l'heure en DC LD8.





Graphique de l'heure dans le sous-réseau Rucloud protégé.





Graphique de l'heure à Rucloud.



Une photo plutôt ennuyeuse, on peut dire que l'image ne change pas selon l'heure de la journée.



Regardons les mêmes graphiques par heure de la journée, mais au total pour tous les centres de données.





Graphique d'heure empilé.





Graphique de l'heure du jour.



Le modèle de force brute ne change pas en fonction de l'heure de la journée. Autrement dit, les appareils qui ont participé à l'attaque par force brute sont probablement toujours allumés.





Statistiques des tentatives de connexion infructueuses pour chaque adresse sur un sous-réseau Rucloud non protégé.



Au total, 89 adresses IP ont participé à la recherche pendant une semaine entière sur l'un des sous-réseaux Rucloud non protégés. 10 adresses IP ont rempli 50% des 114809 tentatives.





Statistiques des tentatives de connexion infructueuses pour chaque adresse pour tous les centres de données.



La même chose, mais uniquement avec des statistiques pour tous les centres de données. 50% de toutes les statistiques ont rempli 15 adresses IP. Il y a eu plus d'un demi-million de tentatives sur les cinq serveurs. À quel point les assaillants étaient-ils différents?







143 adresses IP ont été vues sur tous les réseaux et seulement 29 adresses IP ont été vues sur les 5 serveurs. Moins de la moitié de tous les attaquants attaquaient 2 serveurs ou plus. Cela signifie que la distance de numérisation entre les adresses IP est importante. Cela signifie que les attaquants ont obtenu des informations sur les ports ouverts en utilisant nmap, en analysant les adresses IP une par une.



Nous comptons les botnets



En regardant les rapports et les noms d'utilisateur qui ont été utilisés pour la recherche, j'ai été frappé par les dictionnaires qui utilisaient différentes adresses IP, le nombre de connexions dans les dictionnaires.



Supposons que ce soient tous des botnets différents avec des dictionnaires différents, alors j'ai compté N botnets. Voici les dictionnaires pour chacun d'eux:



admin, administrator, administrador, administrateur, admin, administrator, administrador, administrateur, ADMIN, USER, USER1, TEST, TEST1, ADMINISTRATOR, USER1, USER2, USER3, USER4, USER5, USER6, USER7, USER8, USER9, HP, ADMIN, USER, PC, DENTAL



Ce botnet était le plus grand et utilisait le plus grand dictionnaire. Il y avait de nombreuses connexions dans différentes langues, y compris. Russe, français et anglais:



1, 12, 123, 1234, 12345, 13, 14, 15, 19, 1C, CAMERA, CAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATEUR, ADM, ALYSSA, ADMINISTRATOR, CAMERA, AT AMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, USR_TERMINAL, JEREMY, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA, SYSTEM, SERVICE, GVC, USTRATER ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA et ainsi de suite, y compris même les connexions chinoises.



Il y avait des dictionnaires qui n'utilisaient que des mots chinois et anglais. Je n'ai pas pu extraire les caractères chinois de la base de données à l'aide de Powershell. Voici juste une partie du vocabulaire des camarades chinois:



SHENZHEN, TIANJIN, MANDARIN, CHONGQING, SHENYANG, XIAN, CONS, CHINE, TECHNOLOGY, ISPADMIN, BEIJING, SHANGHAI



Il y avait également des adresses IP uniques essayant d'itérer sur ces connexions. Probablement, seuls les enfants jouent:



USR1CV8, ADMINISTRATEUR

ADMI, NIMDA, ADMS, ADMINS



Il y a juste une stupide attaque par force brute sur les mots de passe, une recherche par dictionnaire, mais il y a une attaque par force brute plus ou moins intéressante. Les attaquants ont la possibilité d'obtenir des noms d'utilisateur, des partages SMB, parfois même des hachages de mots de passe, des noms d'ordinateurs, des noms de domaine AD ou WorkGroup.



Les spécialistes de la sécurité connaissent BloodHound, et les pirates le savent. Si nous laissons AD dans son état par défaut, nous pouvons voler le nom de domaine, le nom de l'ordinateur, même les hachages des mots de passe des utilisateurs. Habré a déjà écrit sur les vecteurs d'attaque sur AD et sur cet outil. Je recommande de lire ce matériel brillant .



À propos, la première attaque utilisant le nom du serveur et le domaine a commencé 13 heures après l'ouverture des ports, mais l'attaquant a rapidement pris du retard, tentant de s'introduire par effraction seulement 138 fois. La deuxième attaque de ce type avec le même dictionnaire a été répétée 3 jours plus tard, mais n'a pas duré longtemps.



Un total de 5 botnets avec différents dictionnaires. Il sera nécessaire de collecter des statistiques plus détaillées sur les identifiants utilisés afin de comprendre ceux qui sont le plus souvent utilisés et dans quelles proportions. Il est très probable que le premier coup d'œil soit brouillé par une collecte peu précise de toutes les statistiques et la vraie image est un peu plus intéressante.



Est-ce un problème?



Dès le début de l'auto-isolement, nous avons commencé à enregistrer une indisponibilité de serveur très étrange. Au début, nous avons tout attribué à la surcharge du réseau des fournisseurs Internet à domicile, de Netflix et des torrents, parfois l'infrastructure n'était pas prête.



Les soupçons sur l'infrastructure ont rapidement disparu lorsque nos quelques clients sur Windows Server 2008, ils ne pouvaient pas passer en principe à RDP. Après avoir examiné le journal de sécurité, nous avons enregistré des taux record d'attaques, plus de 36 000 tentatives en 24 heures.



En fait, une force brute d'une intensité suffisante est capable soit de tuer complètement RDP, soit de provoquer des ruptures permanentes.



La genèse du problème n'est pas entièrement comprise. Soit RDP est mis par l'ensemble du pack, soit par un attaquant. Le script et mstsc.exe n'ont pas réussi à reproduire les déconnexions et l'image se fige.



Soit la force brute se transforme en DDoS, soit certains des attaquants ont une implémentation de force brute d'une manière particulière, ce qui pose également des problèmes. La seule chose qui soit claire est que l'heure de la déconnexion coïncide avec les tentatives de connexion infructueuses.



Les attaques les plus brutales ont eu lieu cet été en juin, lorsque notre soutien a enregistré le plus grand nombre de retards et de ruptures du RDP. Malheureusement, nous n'avons pas encore collecté de statistiques.





Source: Kaspersky



Décision?



Oui.

Tout ce que vous devez faire pour vous protéger est de vous couvrir d'un pare-feu. Mais je ressens la même paresse que vous, alors j'ai fait ces modules.



Les modules fonctionnent sur Windows Powershell 5.1 et Powershell Core 7. Le lien vers le github du projet est ici . Jetons maintenant un coup d'œil aux fonctions.



Protéger-Bruteforce



Jusqu'à présent, le module s'appelle ainsi. Modifie la règle de pare-feu en ajoutant à la règle toutes les adresses IP correctement connectées. Pratique pour une utilisation en conjonction avec une adresse IP statique, simplifie le déploiement de serveurs de bureau distants en conjonction avec une passerelle VPN.







Unprotect-Bruteforce



Réinitialise RemoteAddress pour les règles de pare-feu par défaut.







Stop-Bruteforce



Analyse le journal des événements pour les échecs de connexion et bloque les adresses IP de la liste avec une règle «Stop-Bruteforce» distincte.







Get-Bruteforce



Renvoie un tableau d'objets statistiques pour chaque adresse IP. Cette fonction a été utilisée pour collecter des statistiques pour les graphiques ci-dessus.







Entretien



Chez RUVDS, nous pensons que le système d'exploitation doit être livré à l'utilisateur dans un état extrêmement inchangé. Nous pensons que dans un monde idéal, le système d'exploitation devrait être présenté tel qu'il était dans son état d'origine lors de son lancement. Mais après tout, des fonctions, telles que la génération de mots de passe à partir du compte personnel, non seulement simplifient la vie, elles sont tout simplement nécessaires pour beaucoup de nos clients. Nous aimerions connaître votre opinion sur ce type de pièces de qualité de vie. Votez et commentez.












All Articles