Creuser dans les attaques DDoS (inclut les IP hostiles de plusieurs pots de miel)
J'ai retracé une série de tentatives DDoS et je me demande si quelqu'un d'autre a vu quelque chose comme ça.
J'ai téléchargé le script Powershell suivant qui supprime les journaux d'événements de Terminal Server (RDP) et les sauvegarde sur CSV. J'ai modifié le script pour l'exécuter sur tous mes serveurs et vider l'ensemble des résultats dans un CSV afin que je puisse voir une vue complète du réseau de ce qui se passe.
Script Powershell pour supprimer les journaux des événements Terminal Server
Section A: Modèles DDoS
(Basé sur les résultats du script PowerShell ci-dessus pour extraire les données du journal des événements TS\RDP):
Noms des machines\Connexion: WIN-XXXXXXXXXXX\Administrateur . Plus de 90% des attaques proviennent de machines avec ce format de nom, y compris
- WIN-8ROR2EODLHP\Administrateur
- WIN-NR0D8EUPULR\Administrateur
- WIN-FSIMHI55CBM\Administrateur
pour n'en nommer que quelques-uns (avec plus de 80 noms de machines différents suivant ce format depuis février 2011).
Chaque nom de machine effectue une série de tentatives de "reconnexion" et de "déconnexion" sur une gamme de mes serveurs sur une courte période (d'une durée allant de quelques secondes à environ 20 minutes maximum), puis ce nom d'ordinateur n'est jamais vu. encore. Les adresses IP affichent toutes "LOCAL" ou vide (rien). Datant de février 2011, ces attaques ont commencé à des mois d'intervalle, mais ont lentement augmenté. Aujourd'hui, je vois 3-4 groupes d'attaques par jour.
Sur le frontend de mon réseau, j'exécute un renifleur DDoS self-made qui détecte les connexions RD périmées (comme les attaques DDoS) et déconnectera automatiquement la session et mettra sur liste noire l'adresse IP. Cela empêche les attaques de faire tomber mes services RDP.
Section B: Mise en pot de l'attaquant
J'ai donc créé un "pot de miel" isolé VM sans domaine ni accès au réseau interne et redirigé le trafic réseau douteux vers lui, permettant à une seule attaque DDoS d'instancier avec succès une session distante à partir d'une tentative de reconnexion usurpée, pour cette machine.
Voici ce qui s'est passé:
- Ils ont tenté d'installer un cheval de Troie, cheval de Troie: Win32/Skeeyah.A! Rfn via le processus suivant:
C:\Users\{connectedinUser}\AppData\Local\Temp\5\cssrs.exe; processus: _pid: 12320, ProcessStart: 130880953025982534
Ils ont remplacé l'exécutable lié au "Remote Desktop Server Service" par une version modifiée de rdpwrap.dll (de GitHub), forçant ainsi toutes les nouvelles connexions à distance à s'exécuter via LEUR code.
Ils ont créé un nouvel utilisateur local appelé "WindowsUpdate", puis se sont connectés en tant qu'utilisateur et, étonnamment, ont installé Steam et Counter-Strike
- Ils ont également utilisé C:\Windows\System32\netsh.exe pour ajouter une nouvelle règle de pare-feu nommée "Bureau à distance" pour "TCP\Inbound\ALL" pour les réseaux privés, de domaine et publics et pour les prochains. 3 jours (se connecter et se déconnecter du serveur plusieurs fois en utilisant l'utilisateur WindowsUpdates nouvellement créé, à partir de plusieurs adresses IP [voir "Adresses IP connues", ci-dessous]) ont joué au jeu pendant un total de 15 heures .
J'ai également pu me connecter à leur compte Steam, qui était connecté en tant que [email protected].
J'ai recherché leurs informations de facturation, qui utilisent une carte AMEX appartenant à un "LB Stein" de Millford, AZ (première ligne d'adresse intentionnellement omise, mais sur fichier) - mais il n'y a pas Millford en AZ, et les cartes en ligne corrigent l'état de facturation à CT.
Une recherche inversée sur le numéro de téléphone de leurs informations de facturation Steam a en effet trouvé un Loribeth Stein à Millford, CT. Je l'ai appelée pour l'informer qu'il semble que quelqu'un utilise ses informations de carte de crédit - mais elle a clairement indiqué qu'elle n'avait aucune envie de parler ou de travailler avec moi, quelles que soient les informations dont je dispose. (Douteux? Pour le bien de ce post, je suppose qu'elle ne m'a tout simplement pas cru et/ou pensait que j'étais une arnaque)
J'ai également trouvé un seul événement "Validation des informations d'identification" dans le journal des événements sur mon serveur pot de miel, qui montre ce qui suit:
[MISE À JOUR 04/11/2015]
Avant de déconnecter la nouvelle machine virtuelle, j'ai récupéré une copie du répertoire Windows\Temp, le dossier de profil de l'utilisateur connecté (C:\Users\{LoggedInUser} \, y compris caché \ appdata) et une sauvegarde du registre de la machine. J'ai passé plusieurs semaines à parcourir les ruches ntuser.dat et IE cache, registre et tous les autres fichiers dans C:\Users\{LoggedInUser}\appdata et Windows\Temp et ont déduit les informations suivantes (précédentes non documentées):
- Un fichier .DER (certificat) malveillant a été téléchargé à partir de l'URL suivante:
AVERTISSEMENT: JE NE RECOMMANDE PAS DE VISITER CETTE URL!
hxxp://ocsp.omniroot.com/baltimoreroot/MEUwQzBBMD8wPTAJBgUrDgMCGgUABBTBL0V27RVZ7LBduom%2FnYB45SPUEwQU5Z1ZMIJHWMys%2BghUNoZ7OrUETfACBAcnqkc%3D
(le fichier descend sans extension et présente des ordures dans le bloc-notes, j'ai donc utilisé l'identificateur de fichier TrID , qui a confirmé le fichier en tant que fichier de certificat .DER et recherché l'URL dans Google a trouvé l'article suivant: OCSP.OmniRoot.com-Virus Removal Guide by Allen Ray @ pcinfectionskiller.com )
IE a été marqué, selon les journaux IEBrand, mais je ne sais pas dans quel but
Internet Explorer a été utilisé pour parcourir les sites suivants (et avec succès se connecter avec les e-mails associés):
match.com as [email protected]
gmail.com as [email protected] (Gabriel Chariton ***)
*** Gabrial Chariton est un escroc connu, selon YourITToday.com-1 et YourITToday.com-2
La sauvegarde du registre de Tweaking.com a été téléchargée, installée et les éléments suivants ont été sauvegardés sur C:\RegBackup
- Dossier de profil utilisateur local
- Registre d'utilisateurs local et fichiers ntuser.dat
- C:\Windows\ServiceProfiles\LocalService \
- C:\Windows\ServiceProfiles\NetworkService \
- C:\Windows\System32\Config ***
*** ce dossier est une collection d'informations sur le réseau et la machine générées par un script Microsoft @ C:\Windows\System32 \atherNetworkInfo.vbs
(ou 4.2) un fichier appelé dos_restore_renamed.cmd a été placé dans le répertoire C:\RegBackup. Le contenu du fichier peut être consulté ici: dos_restore_renamed.cmd.txt @ textuploader.com "
L'historique d'Internet Explorer a été effacé
Plusieurs journaux d'événements (y compris Security et Terminal Server) ont été partiellement effacés - ou ont en quelque sorte cessé de se connecter pendant plusieurs périodes allant de 40 minutes à plus de 2 heures.
Section C: IP hostiles connues et points communs entre plusieurs pots de miel
- IP utilisées pour accéder à mes pots de miel avec les informations d'identification créées par l'attaquant:
- 128.71.5.22
- 128.71.5.53
- 130.225.59.25
- 148.251.49.172
- 154.70.47.90
- 169.55.19.147
- 169.55.19.150
- 169.55.27.134
- 173.220.35.194
- 176.226.149.255
- 178.175.136.114
- 185.26.144.103
- 192.3.187.112
- 198.154.60.102
- 198.154.60.174
- 198.58.88.94
- 199.89.54.108
- 206.217.140.37
- 207.182.153.138
- 37.57.15.23
- 46.161.40.15
- 47.22.21.110
- 5.56.133.145
- 50.248.158.50
- 50.255.17.233
- 77.234.43.139
- 77.234.43.180
- 78.68.165.231
- 80.4.157.18
- 83.69.0.58
- 89.163.148.76
- 93.115.92.244
[MISE À JOUR 02/01/2016]
Depuis la création de mon pot de miel d'origine, j'ai créé et suivi plusieurs pots de miel supplémentaires dans le but de trouver des données plus significatives. Voici un résumé de ces constatations ...
Mes deuxième et troisième pots de miel ont vu l'attaquant créer un nouvel utilisateur appelé "temp" (par opposition à l'utilisateur "WindowsUpdate" du pot de miel d'origine). L'utilisation de ce compte, une fois connecté, était plus ou moins un ensemble entièrement différent d'activités malveillantes que le premier pot de miel, mais il y avait 2 adresses IP en particulier qui étaient utilisées pour accéder à chaque pot de miel que j'ai mis en ligne , en me connectant en tant qu'utilisateur créé par l'attaquant immédiatement après la création du compte.
- 5.56.133.145
- 176.226.149.255
De plus, l'adresse IP suivante (qui a été utilisée pour se connecter à mon pot de miel d'origine), partage tout sauf l'octet final avec 2 adresses IP qui ont été mises sur liste noire par mon pare-feu réseau pour DDoS:
- 46.161.40.15
IP sur liste noire, similaires:
- 46.161.40.11
- 46.161.40.20
FreeGeoIP.net conclut que 46.161.40.15 et 176.226.149.255 proviennent de Russie, tandis que 5.56.133.145 appartient à RIPE.net en Californie, États-Unis, mais peut avoir été donné à un client RIPE.NET selon whois.arin.net . www.RIPE.net/whois dit qu'il appartient à une adresse et un numéro de téléphone en Allemagne.
SECTION D: Configuration du réseau
En général, mes serveurs ont des ports FTP, Web Services et RDP ouverts.
RDP utilise NLA
La plupart ou tous les autres ports sont bloqués à plusieurs étapes, de la passerelle aux serveurs individuels, y compris les pare-feu, la stratégie de groupe et les pratiques de sécurité standard.
SECTION E: Aller de l'avant
Contacté le support Steam et ont été informés qu'ils étudieront le problème et je ne serai pas informé des résultats
Contacté Amex, mais ils ne peuvent pas faire correspondre les informations de facturation à un compte actif
Contacté [email protected] - pas encore entendu
Il s'avère que mon hypothèse précédente était correcte. Ces "attaques" DDoS sont en fait un effet secondaire d'un botnet Makost [dot] net - et ne sont PAS l'intention de l'attaquant (en fait , ils semblent spécifiquement conçus pour NE PAS provoquer une interruption de service qui nous rendrait conscients de leur activité). Les attaques tentent en fait d'accéder à mes serveurs afin de louer/vendre du temps de serveur à des tiers.
Le processus d'attaque (c'est-à-dire "DDoS non intentionnel")
Le processus d'attaque est quelque chose comme ceci:
Le botnet commencera à canaliser les tentatives de connexion échelonnées par lots vers un bloc aléatoire d'ip sous la forme de dictionnaire miniature Attaques et tentatives de reconnexion usurpées . Ces tentatives sont toujours échelonnées et semblent être automatisées ou exécutées selon une sorte de calendrier, éventuellement mises en file d'attente par une personne réelle.
Les tentatives de connexion commencent le plus souvent par une tentative de connexion avec ".\Administrateur " (ou " local\Administrateur ") comme domaine\nom d'utilisateur et" Administrateur "(identique au nom d'utilisateur) comme mot de passe.
Si " Administrateur " échoue, mais que le serveur répond sur les ports RDP par défaut, ils finissent par revenir (secondes, minutes, heures, jours ou semaines plus tard) avec la connaissance des noms d'utilisateur réels utilisés pour RDP dans mes serveurs et noms de serveurs dans lesquels ces utilisateurs ont RDP'd (vraisemblablement récoltés à partir de clients-machines compromis). Le plus souvent, il tente de se connecter avec le nom d'utilisateur en tant que mot de passe (c'est-à-dire " {nom d'utilisateur} "\" {nom d'utilisateur } ", comme jdoe\jdoe, owner\owner, etc.).Les tentatives de connexion échouées sont apparemment bloquées ou maintenues ouvertes par l'attaquant botnet \, le plus souvent suivies d'une sorte de tentative de reconnexion de session par force brute, laissant les sessions RDP périmées et dévorant les ports. C'est ce qui nous conduit à un déni de service lorsque plusieurs groupes d'attaques sont reçus à la fois.
- Il semble que ce botnet étale intentionnellement leurs attaques afin d'éviter d'être découvert pour ce qu'il est vraiment. Ils veulent ressembler à des tentatives de connexion incorrectes\non liées, éparpillées sur plusieurs serveurs. De multiples vagues entrant à la fois semblent indésirables pour l'attaquant, car un déni de service empêcherait leurs propres attaques par dictionnaire\force brute de se connecter et leur rendrait les serveurs inaccessibles, tout en nous informant d'une activité malveillante.
- Bien que nous ayons vu ce modèle nous attaquer depuis 2011, ce n'est que depuis 2013 que des lots d'attaques ont commencé à se chevaucher comme s'ils ne se connaissaient pas. Avant 2013, il était rare de voir plus d'un lot à la fois. Cela me dit que le réseau de zombies s'est divisé - de nouveaux sont exploités en utilisant le même malware, ou peut-être que les autres existent depuis un certain temps et qu'ils finissent par être alimentés par les mêmes données depuis 2013 par rapport à avant. Il convient également de noter que j'ai trouvé des traces d'attaques similaires datant de février 2009, mais elles ont un modèle de nom de machine différent, avec des noms de machine tels que "37L4247D25-07" et "37L4247D28-05. "(voir l'article d'origine, " Section A: Modèles DDoS " pour en savoir plus).
J'ai pu déduire les éléments suivants en faisant un croisement de mes informations existantes (message d'origine) avec mes journaux d'erreur IIS & http, les journaux de bande passante sortante et en regardant WireShark pendant la tentative) attaques et utilisation de pots de miel:
Les ordinateurs compromis sont utilisés comme hôtes de botnet et pour récolter autant d'informations que possible en utilisant une collection sophistiquée de logiciels malveillants, de virus, de rootkits, de détournement de navigateur et une longue liste de plusieurs milliers d'exploits de serveurs connus (php, phpNuke, phpMyAdmin, phpGallery, wordpress, IIS et asp.net configs pour n'en nommer que quelques-uns.) Ils analysent également les réseaux en utilisant les requêtes DNS locales WPAD et ont été vu tenter d'utiliser WPAD\Windows Update pour une attaque Man-In-The-Middle ainsi que de pirater des imprimantes réseau afin de compromettre le réseau Sécurité.
Je crois que le botnet a un référentiel centralisé croissant pour les informations sur les serveurs et les utilisateurs, des exploits connus et beaucoup plus de métadonnées qui les aident à compromettre les serveurs qu'ils attaquent. Ces machines collectent des données indépendamment, mais les attaques arrivent par vagues et suivent toujours les mêmes schémas.
Une fois qu'un serveur est compromis et "loué", on peut deviner à quoi sert la partie connectée, mais "illégal" semble une assez bonne conclusion compte tenu de ce que nous avons vu (voir l'article d'origine, " Section B: Honeypotting l'attaquant " pour plus d'informations).
Les IP les plus hostiles
Depuis la création de mon pot de miel d'origine, j'ai créé et suivi plusieurs pots de miel supplémentaires dans le but de trouver des données plus significatives. J'ai mis à jour mon message d'origine (Section C: Adresses IP) avec 2 points supplémentaires que je résumerai ici:
5.56.133.145 et 176.226.149.255 se sont tous deux connectés à PLUSIEURS pots de miel en utilisant les informations d'identification créées par l'attaquant immédiatement après la création du compte. 46.161.40.15 a été utilisé pour me connecter uniquement à mon premier pot de miel, mais partage ses 3 premiers octets avec au moins 2 autres adresses IP bloquées par mon pare-feu réseau pour DDoS.
J'ai vu une réduction immédiate des attaques DDoS depuis que j'ai posté cet article (curieux). Lorsque je contacte mes clients et (les fais) installer/mettre à jour leur sécurité et télécharger (important) les mises à jour Windows, les attaques apparaissent de moins en moins.
Je ne conclus pas que Makost [dot] net est derrière ces attaques. Je ne connais tout simplement pas un autre nom pour ce type de botnet, mais il suit les mêmes schémas d'attaque et d'utilisation que Makost est connu pour.
Pour plus d'informations sur Makost [dot] net, consultez ce lien:
http://krebsonsecurity.com/tag/makost/
J'espère mettre à jour cet article avec des informations supplémentaires au fur et à mesure que je le trouve. Questions\commentaires bienvenus. Les adresses IP dans mon message d'origine incluent à la fois les attaquants de botnet et les utilisateurs connectés à mon pot de miel après qu'il a été "compromis".
Vérifiez vos journaux de bande passante sortants, il se peut que l'attaquant utilise vos serveurs comme un botnet en quelque sorte. Cela semble très détaillé et j'appellerais les fantômes en ce moment (vous avez beaucoup d'informations). La désactivation de RDP est-elle complètement une option?