Get best of the week

Une fois à un pentest, ou Comment tout casser avec l'aide d'un urologue et de Roskomnadzor


Cet article est basé sur un pentest très réussi, qui a été réalisé par des spécialistes du Groupe IB il y a quelques années: une histoire s'est produite qui prétend être une adaptation cinématographique à Bollywood. Maintenant, probablement, la réaction du lecteur suivra: "Oh, un autre article de relations publiques, encore une fois ceux-ci sont dessinés, à quel point ils sont bons, n'oubliez pas d'acheter un pentest." Eh bien, d'une part, ça l'est. Cependant, il existe un certain nombre de raisons pour lesquelles cet article est apparu. Je voulais montrer ce que font exactement les pentesters, à quel point ce travail peut être intéressant et non trivial, quelles circonstances amusantes peuvent se développer sur des projets, et surtout, montrer du matériel en direct avec des exemples réels.

Pour rétablir l'équilibre de la modestie dans le monde, après un certain temps, nous écrirons sur le penteste, qui n'a pas disparu. Nous montrons comment des processus bien établis dans une entreprise peuvent protéger contre toute une gamme d'attaques, même bien préparées, simplement parce que ces processus existent et fonctionnent vraiment.

Le client de cet article, aussi, tout allait bien en général, au moins mieux que 95% du marché en Fédération de Russie, selon nos sentiments, mais il y avait un certain nombre de nuances mineures qui ont formé une longue chaîne d'événements, ce qui a conduit d'abord à un long rapport sur le travail , puis à cet article.

Alors, faites le plein de pop-corn et bienvenue au détective. Je donne la parole à Pavel Suprunyuk , directeur technique de l'Audit and Consulting Group-IB.

Partie 1. Docteur Pochkin


Année 2018. Il y a un client - une entreprise informatique de haute technologie qui sert elle-même de nombreux clients. Il souhaite obtenir une réponse à la question: est-il possible, sans aucune connaissance et accès initiaux, via Internet, d'obtenir des droits d'administrateur pour un domaine Active Directory? Aucune ingénierie sociale n'est intéressante ( hein, mais en vain ), elles ne vont pas spécifiquement interférer avec le travail, mais elles peuvent recharger accidentellement un serveur étrange, par exemple. Une tâche supplémentaire consiste à identifier autant d'autres vecteurs d'attaque que possible par rapport au périmètre externe. La société effectue régulièrement de tels tests, et maintenant la date limite pour un nouveau test. Les conditions sont presque typiques, adéquates, compréhensibles. Descendre.

Il y a un nom de client - que ce soit "Entreprise", avec le site principal www.company.ru. Bien sûr, le client est appelé différemment, mais dans cet article, tout sera dépersonnalisé.
Je mène une veille réseau - je découvre les adresses et domaines répertoriés par le client, dessine un schéma de réseau, comment les services sont distribués à ces adresses. J'obtiens le résultat: plus de 4000 adresses IP en direct. Je regarde à travers les domaines de ces réseaux: heureusement, la grande majorité sont des réseaux destinés aux clients clients, et ils ne nous intéressent pas formellement. Le client est du même avis.

Il reste un réseau avec 256 adresses, pour lequel à ce stade il y a déjà une compréhension de la distribution des domaines et des sous-domaines par adresses IP, il y a des informations sur les ports scannés, ce qui signifie que vous pouvez regarder les services pour les plus intéressants avec vos yeux. En parallèle, toutes sortes de scanners sont lancés à des adresses IP accessibles et séparément - sur des sites Web.

Il y a beaucoup de services. C'est généralement une joie pour le pentester et l'anticipation d'une victoire rapide, car plus il y a de services, plus le champ d'attaque est grand et plus il est facile de trouver un artefact. Un rapide coup d'œil sur les sites Web a montré que la plupart d'entre eux sont des interfaces Web des produits bien connus des grandes entreprises mondiales qui disent qu'ils ne sont pas satisfaits de vous. Ils demandent un nom d'utilisateur et un mot de passe, à partir du seuil où ils secouent le champ pour entrer le deuxième facteur, ils demandent un certificat client TLS ou les envoient à Microsoft ADFS. Certains sont tout simplement indisponibles sur Internet. Pour certains, vous devez évidemment avoir un client payant spécial pour trois salaires ou connaître l'URL exacte à saisir. Nous allons omettre une autre semaine de découragement progressif dans le processus visant à "traverser" le logiciel par version pour les vulnérabilités connues, rechercher des contenus cachés dans les chemins Web et les fuites de comptes de services tiers tels que LinkedIn,tente de sélectionner des mots de passe pour eux, ainsi que de creuser des vulnérabilités dans des sites Web auto-décrits - à propos, selon les statistiques, c'est le vecteur le plus prometteur d'une attaque externe à ce jour. Immédiatement, je note le pistolet de cinéma, qui a ensuite tiré.

Il y avait donc deux sites qui se démarquaient de centaines de services. Ces sites avaient une chose en commun: si vous ne vous engagez pas dans une reconnaissance méticuleuse du réseau par domaine, mais que vous recherchez «sur le devant» des ports ouverts ou empoisonnez le scanner de vulnérabilité sur une plage IP connue, alors ces sites vont se passer de la vérification, ils ne seront tout simplement pas visibles sans connaître le nom DNS. Peut-être ont-ils été manqués plus tôt, du moins, et nos outils automatiques n'y ont pas trouvé de problèmes, même s'ils étaient définis directement sur la ressource.

Soit dit en passant, sur le fait que les scanners précédemment lancés ont été généralement trouvés. Permettez-moi de vous rappeler: pour certains, «pentest» équivaut à «numérisation automatisée». Et les scanners de ce projet n'ont rien dit. Eh bien, les vulnérabilités moyennes ont montré le maximum (3 sur 5 en termes de danger): certains services ont un mauvais certificat TLS ou des algorithmes de cryptage obsolètes, et la plupart des sites ont un détournement de clic. Mais là-dessus, vous n'atteindrez pas l'objectif. Les scanners seraient probablement plus utiles ici, mais permettez-moi de vous rappeler: le client lui-même est en mesure d'acheter de tels programmes et de se tester avec eux, et à en juger par les résultats ternes, il l'a déjà vérifié.

Retour aux sites "anormaux". Le premier est quelque chose comme un Wiki local à une adresse non standard, mais laissez wiki.company [.] Ru figurer dans cet article. Elle a également immédiatement demandé un nom d'utilisateur et un mot de passe, mais déjà via NTLM dans le navigateur. Pour l'utilisateur, cela ressemble à une fenêtre ascétique demandant un nom d'utilisateur et un mot de passe. Et c'est une mauvaise pratique.

. NTLM - . — Active Directory. company.ru, «» DNS-. , - , , - . — NTLM (, ?), «» , . , . — , . — . — , , . — pass-the-hash-. ADFS .

Il y a une mauvaise caractéristique des produits Microsoft: même si vous n'avez pas spécifiquement publié un tel NTLM, il sera au moins dans l'installation par défaut dans OWA et Lync.

Soit dit en passant, l'auteur de cet article a bloqué une fois de la même manière accidentellement environ 1 000 comptes d'employés d'une grande banque en une heure seulement, puis a eu un aspect un peu pâle. Les services informatiques de la banque étaient également pâles, mais tout s'est bien terminé et nous avons même été félicités d'avoir été les premiers à trouver ce problème et provoqué une correction rapide et décisive.
Le deuxième site avait l'adresse "évidemment-un-nom.company.ru". Trouvé via Google, quelque chose comme ça à la page 10. Le design commence au milieu des années 2000, et une personne respectable a regardé la page principale, quelque chose comme ceci:


Puis il a pris un cadre de "Dog’s Heart", mais croyez-moi, il était à peu près similaire, même la palette de couleurs dans des couleurs similaires. Que le site s'appelle preobrazhensky.company.ru .

C'était un site personnel ... d'un urologue. Il est devenu intéressant de voir ce que fait le site de l'urologue sur le sous-domaine d'une entreprise de haute technologie. Une brève fouille chez Google a montré que ce médecin était co-fondateur de l'une des personnes morales de notre client et a même contribué environ 1000 roubles de capital social. Le site a probablement été créé il y a de nombreuses années et les ressources du serveur du client ont été utilisées comme hébergement. Le site a depuis longtemps perdu sa pertinence, mais pour une raison quelconque, il est resté longtemps opérationnel.

En termes de vulnérabilités, le site Web lui-même était sûr. Pour l'avenir, je dirai qu'il s'agissait d'un ensemble de statistiques - de simples pages html avec des insertions d'illustrations sous forme de reins et de vessies. "Briser" un tel site est inutile.

Mais le serveur Web en dessous était plus intéressant. À en juger par l'en-tête du serveur HTTP, il y avait IIS 6.0, ce qui signifie que Windows 2003 a été utilisé comme système d'exploitation. Le scanner a précédemment révélé que ce site Web particulier de l'urologue, contrairement à d'autres hôtes virtuels sur le même serveur Web, avait répondu à la commande PROPFIND, c'est-à-dire que WebDAV y avait fonctionné. Soit dit en passant, le scanner a émis ces informations avec la marque Info (dans la langue des rapports du scanner, c'est le danger le plus faible) - de telles choses sont généralement simplement ignorées. En combinaison, cela a donné un effet intéressant, qui n'a été révélé qu'après une nouvelle fouille dans Google: une vulnérabilité de débordement de tampon rare associée à un ensemble de Shadow Brokers, à savoir CVE-2017-7269, qui avait déjà un exploit prêt. En d'autres termes, ce sera un désastre si vous avez Windows 2003 et WebDAV s'exécute sur IIS.Bien que travaillant dans la production de Windows 2003 en 2018, c'est en soi une catastrophe.

L'exploit s'est retrouvé dans Metasploit et a été immédiatement testé avec une charge qui a envoyé une requête DNS à un service contrôlé - Burp Collaborator est traditionnellement utilisé pour intercepter les requêtes DNS. Étonnamment, cela a fonctionné la première fois: une secousse a été reçue dans DNS. Ensuite, il y a eu une tentative de création d'une connexion dorsale via le port 80 (c'est-à-dire une connexion réseau du serveur à l'attaquant, avec accès à cmd.exe sur l'hôte victime), mais un fiasco s'est produit. La connexion n'est pas venue et après la troisième tentative d'opération, le site, avec toutes les images divertissantes, a disparu pour de bon.

Habituellement, cela est suivi d'une lettre dans le style "client, réveille-toi, nous avons tout laissé tomber". Mais on nous a dit que le site n'a rien à voir avec les processus métier et y fonctionne en général, on ne sait pas pourquoi, comme l'ensemble du serveur, et que nous pouvons utiliser cette ressource à notre guise.
Après environ une journée, le site a soudainement commencé à fonctionner de lui-même. Après avoir construit un stand à partir de WebDAV sur IIS 6.0, j'ai constaté que le paramètre par défaut est de redémarrer les workflows IIS toutes les 30 heures. Autrement dit, lorsque le contrôle est sorti du code shell, le flux de travail IIS s'est terminé, puis il a redémarré plusieurs fois lui-même, puis s'est arrêté pendant 30 heures.

Depuis la première fois que bekconnect sur TCP a échoué, j'ai annulé ce problème sur un port fermé. Autrement dit, il a suggéré la présence d'un pare-feu qui ne laissait pas sortir les connexions sortantes. J'ai commencé à exécuter des codes shell qui trient à travers de nombreux ports TCP et UDP, il n'y avait aucun effet. La connexion inverse se charge via http (s) de Metasploit - meterpreter / reverse_http (s) ne fonctionne pas. Soudain, la connexion au même port 80 a été établie, mais a immédiatement été rompue. Il l'a déduit de l'action de l'IPS encore imaginaire, qui n'aimait pas le trafic métrique. À la lumière du fait que la connexion de TCP pur au port 80 a échoué, mais http l'a fait, j'ai conclu que le proxy http était en quelque sorte configuré dans le système.

Testé même mètre mètre via DNS (mercid00kiepour ses efforts, a sauvé de nombreux projets), rappelant le tout premier succès, mais il n'a même pas travaillé sur le stand - le code shell était trop volumineux pour cette vulnérabilité.

En réalité, cela ressemblait à ceci: 3-4 tentatives d'attaque dans les 5 minutes, puis attendez 30 heures. Et donc pendant trois semaines consécutives. J'ai même mis en place un rappel pour ne pas perdre de temps. De plus, il y avait une différence dans le comportement des environnements de test et de combat: il y avait deux exploits similaires pour cette vulnérabilité, l'un de Metasploit, le second d'Internet, refait à partir de la version Shadow Brokers. Ainsi, au combat, seul Metasploit a fonctionné, sur le stand - seulement le second, ce qui a compliqué le débogage et brisé le cerveau.

Au final, le code shell s'est avéré efficace, qui a téléchargé un fichier exe depuis un serveur donné via http et l'a exécuté sur le système cible. Le shellcode était assez petit pour tenir, et au moins cela a fonctionné. Étant donné que le serveur TCP n'aimait pas du tout le trafic et que http (s) a été inspecté pour meterpreter, j'ai décidé que le moyen le plus rapide était de télécharger le fichier exe qui contenait le DNS-meterpreter via ce shellcode.

Là encore, le problème s'est posé: lors du téléchargement du fichier exe et, comme les tentatives l'ont montré, quoi qu'il en soit, le téléchargement a été interrompu. Encore une fois, une sorte de dispositif de sécurité entre mon serveur et l'urologue n'aimait pas le trafic http avec exe à l'intérieur. Cela semblait être une solution «rapide» pour changer le shellcode afin qu'il obscurcisse le trafic http à la volée, afin que les données binaires abstraites soient transférées au lieu d'exe. Enfin, l'attaque a réussi, le contrôle est passé par le canal DNS fin:


Il est immédiatement devenu clair que j'avais les droits les plus simples sur le workflow IIS qui me permettent de ne rien faire. Voici à quoi cela ressemblait sur la console Metasploit:


Toutes les méthodologies pentest suggèrent fortement que vous devez augmenter les droits lors de l'accès. Habituellement, je ne le fais pas localement, car le tout premier accès est considéré simplement comme un point d'entrée réseau, et compromettre une autre machine sur le même réseau est généralement plus facile et plus rapide que l'augmentation des privilèges sur un hôte existant. Mais ce n'est pas le cas, car le canal DNS est très étroit et il ne permettra pas au trafic de se déplacer.

En supposant que ce serveur avec Windows 2003 n'a pas été réparé à partir de la vulnérabilité bien connue MS17-010, je tunnelise le trafic vers le port 445 / TCP via le tunnel DNS meterpreter vers localhost (oui, cela est également possible) et j'essaie d'exécuter un exe précédemment téléchargé via la vulnérabilité. L'attaque fonctionne, j'obtiens une deuxième connexion, mais avec les privilèges SYSTEM.


Fait intéressant, le serveur essayait toujours de se protéger contre MS17-010 - il avait désactivé les services réseau vulnérables sur l'interface externe. Cela protège vraiment contre les attaques via le réseau, mais l'attaque de l'intérieur de l'hôte local a fonctionné, car vous ne pouvez pas simplement prendre et désactiver rapidement SMB sur localhost.
Ensuite, de nouveaux détails intéressants sont révélés:

  1. Avec les autorisations SYSTEM, vous pouvez facilement installer une connexion arrière via TCP. De toute évidence, l'interdiction de TCP direct est exclusivement un problème utilisateur limité IIS. Spoiler: le trafic des utilisateurs IIS était en quelque sorte enveloppé dans le proxy ISA local dans les deux sens. Comment cela fonctionne exactement n'est pas reproduit.
  2. Je suis dans une certaine «DMZ» (et ce n'est pas un domaine Active Directory, mais WORKGROUP) - cela semble logique. Mais au lieu de l'adresse IP privée ("grise") attendue, je suis plutôt "blanche", exactement la même que celle que j'ai attaquée plus tôt. Cela signifie que la société est tellement ancienne pour le monde de l'adressage IPv4 qu'elle peut se permettre de garder la zone DMZ à 128 adresses «blanches» sans NAT selon le schéma, comme cela a été illustré dans les manuels Cisco 2005.

Le serveur étant ancien, Mimikatz est garanti de fonctionner directement depuis la mémoire:


J'obtiens le mot de passe de l'administrateur local, je tunnel le trafic RDP via TCP et je vais dans un bureau confortable. Étant donné que vous pouvez faire quoi que ce soit avec le serveur, je supprime l'antivirus, je trouve que le serveur est accessible à partir d'Internet uniquement sur les ports TCP 80 et 443, et 443 n'était pas occupé. J'élève le serveur OpenVPN à 443, j'ajoute les fonctions NAT pour mon trafic VPN et j'obtiens un accès direct au réseau DMZ sous une forme illimitée via mon OpenVPN. Il est à noter que l'ISA, avec certaines fonctionnalités IPS non désactivables, a bloqué mon trafic avec une analyse de port, pour laquelle il a dû être remplacé par un RRAS plus simple et plus flexible. Les pentesters doivent donc parfois tout administrer.


Un lecteur attentif demandera: "Et quel est le deuxième site - un wiki avec authentification NTLM, sur lequel tant de choses ont été écrites?" À ce sujet plus loin.

Partie 2. N'êtes-vous toujours pas en train de chiffrer? Ensuite, nous allons à vous déjà ici


Il y a donc accès au segment de réseau DMZ. Vous devez vous adresser à l'administrateur du domaine. La première chose qui me vient à l'esprit est de vérifier automatiquement la sécurité des services à l'intérieur du segment DMZ, d'autant plus qu'ils sont désormais beaucoup plus ouverts à la recherche. Une image typique dans un test de pénétration: le périmètre externe est mieux protégé que les services internes, et lorsque vous obtenez un accès à une grande infrastructure, il est beaucoup plus facile d'obtenir des droits étendus dans un domaine uniquement parce que ce domaine commence à être accessible pour les outils, et deuxièmement, il y a toujours quelques problèmes critiques dans l'infrastructure pour plusieurs milliers d'hôtes.

Je charge des scanners sur DMZ via le tunnel OpenVPN, j'attends. J'ouvre le rapport - encore une fois rien de grave, apparemment quelqu'un a marché de la même manière vers moi. L'étape suivante consiste à examiner comment les hôtes communiquent au sein du réseau DMZ. Pour ce faire, pour commencer, un Wireshark régulier est lancé avec l'écoute des requêtes de diffusion, principalement ARP. Les colis ARP ont été collectés toute la journée. Il s'avère que plusieurs passerelles sont utilisées dans ce segment. Cela vous sera utile plus tard. En collant des données sur les données de réponse aux requêtes ARP et de numérisation de port, j'ai trouvé les points de sortie du trafic utilisateur à partir du réseau local en plus des services qui étaient auparavant connus, tels que le Web et la messagerie.

Comme pour le moment je n'avais pas accès à d'autres systèmes et qu'il n'y avait pas un seul compte pour les services d'entreprise, il a été décidé de récupérer au moins une partie du trafic à l'aide d'ARP Spoofing.

Cain & Abel a été lancé sur le serveur de l'urologue. Compte tenu des flux de trafic identifiés, les paires les plus prometteuses ont été sélectionnées pour l'attaque «homme au milieu», puis par un démarrage à court terme pendant 5 à 10 minutes, avec une minuterie pour redémarrer le serveur en cas de «gel», du trafic réseau a été reçu. Comme dans la blague, il y avait deux nouvelles:

  1. Bon: beaucoup d'informations d'identification ont été capturées et l'attaque dans son ensemble a fonctionné.
  2. Mauvais: toutes les informations d'identification provenaient des clients du client lui-même. Fournissant des services d'assistance, des spécialistes du client connectés à des services client qui n'ont pas toujours configuré le chiffrement du trafic.

En conséquence, je me suis emparé de nombreuses informations d'identification qui étaient inutiles dans le contexte du projet, mais certainement intéressantes comme démonstration du danger d'une attaque. Routeurs frontaliers de grandes entreprises avec telnet, transfert des ports http de débogage vers CRM interne avec toutes les données, accès direct à RDP depuis Windows XP sur le réseau local et autres obscurantismes. Il s'est avéré une sorte de compromis de la chaîne d'approvisionnement selon la matrice MITRE .

A également trouvé une occasion amusante de collecter des e-mails provenant du trafic, quelque chose comme ça. Ceci est un exemple d'une lettre finie qui est passée de notre client au port SMTP de son client, encore une fois, sans cryptage. Un certain Andrei demande à son homonyme de renvoyer la documentation, qui est disposée sur un disque cloud avec un nom d'utilisateur, un mot de passe et un lien dans une lettre de réponse:


Ceci est un autre rappel que vous devez crypter tous les services. On ne sait pas qui et quand lira et appliquera spécifiquement vos données - un fournisseur, un administrateur système d'une autre entreprise ou un tel pentester. Je suis silencieux que beaucoup peuvent simplement intercepter le trafic non chiffré.

Malgré le succès apparent, cela n'a pas été rapproché de l'objectif. Il était possible, bien sûr, de rester longtemps assis et d'obtenir des informations précieuses, mais pas le fait qu'elles y seraient apparues, et l'attaque elle-même est très risquée en termes d'intégrité du réseau.

Après une nouvelle fouille dans les services, une idée intéressante m'est venue à l'esprit. Il existe un tel utilitaire appelé Responder (il est facile de trouver des exemples d'applications de ce nom), qui, en «empoisonnant» les demandes de diffusion, provoque des connexions sur une variété de protocoles tels que SMB, HTTP, LDAP, etc. de différentes manières, chaque personne qui se connecte est invitée à s'authentifier et à s'ajuster pour que l'authentification passe par NTLM et dans un mode transparent pour la victime. Le plus souvent, un attaquant recueille ainsi des poignées de main NetNTLMv2 et d'eux, selon le dictionnaire, récupère rapidement les mots de passe du domaine utilisateur. Je voulais quelque chose de similaire ici, mais les utilisateurs étaient assis «derrière le mur», ou plutôt, ils étaient séparés par un pare-feu, et sur le WEB, ils étaient passés par le cluster proxy Blue Coat.

Rappelez-vous, j'ai spécifié que le nom de domaine Active Directory coïncidait avec le domaine "externe", c'est-à-dire était company.ru? Ainsi, Windows, plus précisément Internet Explorer (et Edge et Chrome), permettent à l'utilisateur de s'authentifier de manière transparente en HTTP via NTLM, s'il considère que le site se trouve dans une «zone intranet». L'un des signes de «l'intranet» est un appel à une adresse IP «grise» ou à un nom DNS court, c'est-à-dire sans points. Puisqu'un serveur avec un nom IP et DNS «blanc» preobrazhensky.company.ru était à sa disposition, et que les machines de domaine obtiennent généralement le suffixe de domaine Active Directory via DHCP pour simplifier la saisie du nom, elles n'avaient qu'à écrire l'URL preobrazhensky dans la barre d'adresseafin qu'ils trouvent le bon chemin vers un serveur urologue compromis, sans oublier qu'il s'appelle désormais "Intranet". C'est-à-dire, en même temps me donner l'utilisateur de la poignée de main NTLM à son insu. Reste à faire réfléchir les navigateurs clients sur l'urgence d'accéder à ce serveur.

Le merveilleux utilitaire Intercepter-NG est venu à la rescousse (merciIntercepter) Il vous a permis de modifier le trafic lors de vos déplacements et a parfaitement fonctionné sur Windows 2003. Il y avait même une fonctionnalité distincte pour modifier uniquement les fichiers JavaScript dans le flux de trafic. Il était prévu une sorte de Cross-Site Scripting massif.

Les mandataires Blue Coat par le biais desquels les utilisateurs ont accédé au contenu statique global du WEB mis en cache périodiquement. En interceptant le trafic, il était clair qu'ils fonctionnaient 24 heures sur 24, demandant sans cesse des statistiques fréquemment utilisées pour accélérer l'affichage du contenu pendant les heures de pointe. De plus, BlueCoat avait un agent utilisateur spécifique, qui le distinguait clairement d'un utilisateur vivant.

Javascript a été préparé, ce qui, avec l'aide d'Intercepter-NG la nuit, a passé une heure entière à implémenter chaque réponse avec des fichiers JS pour Blue Coat. Le script a fait ce qui suit:

  • Détecté le navigateur actuel par User-Agent. Si c'était Internet Explorer, Edge ou Chrome - cela fonctionnait.
  • Attendu que le DOM de la page soit formé.
  • J'ai inséré une image invisible avec l'attribut src du type preobrazhensky dans le DOM : 8080 / NNNNNNN.png, où NNN sont des chiffres arbitraires afin que BlueCoat ne cache pas.
  • Définissez une variable indicateur globale indiquant que l'injection a été effectuée et que vous n'avez plus besoin d'insérer d'images.

Le navigateur a essayé de charger cette image, sur le port 8080 du serveur compromis, il attendait le tunnel TCP vers mon ordinateur portable, où le même répondeur a été lancé, ce qui nécessite une connexion NTLM à partir du navigateur.


A en juger par les journaux du Répondant, le matin, les gens sont venus travailler, ont allumé leur poste de travail, puis ont commencé à visiter le serveur de l'urologue en masse et de manière invisible, sans oublier de «fusionner» les poignées de main NTLM. Des poignées de main ont plu toute la journée et ont clairement accumulé du matériel pour une attaque de récupération de mot de passe notoirement réussie. Voici à quoi ressemblaient les journaux du répondeur:

Visites massives et secrètes des utilisateurs sur le serveur de l'urologue

Vous avez probablement déjà remarqué que toute cette histoire est construite sur le principe "tout allait bien, mais il y avait une déception, puis il y avait du dépassement, et puis tout est arrivé au succès". Donc, il y avait une déception. Sur les cinq cents poignées de main uniques, aucune n'a été révélée. Et cela tient compte du fait que même sur un ordinateur portable avec un processeur mort, ces poignées de main NTLMv2 dépassent la vitesse de plusieurs centaines de millions de tentatives par seconde.

J'ai dû m'armer de techniques de mutation de mot de passe, d'une carte graphique, d'un dictionnaire plus épais et attendre. Après un long moment, plusieurs comptes avec des mots de passe de la forme «Q11111111 ... .1111111q» ont été ouverts, ce qui suggère que tous les utilisateurs ont été une fois contraints de proposer un mot de passe très long avec une casse de caractères différente, ce qui était censé être compliqué. Mais vous ne pouvez pas simplement échouer un utilisateur chevronné, et de cette façon, il a rendu la mémoire plus facile. Au total, environ 5 pièces ont été ouvertes, et une seule d'entre elles avait des droits précieux sur les services.

Partie 3. Roskomnadzor contre-attaque


Ainsi, les premiers comptes de domaine ont été reçus. Si à ce stade vous ne vous êtes pas endormi après une longue lecture, vous vous souviendrez probablement que j'ai mentionné un service qui ne nécessitait pas de second facteur d'authentification: il s'agit d'un wiki avec authentification NTLM. Bien sûr, la première chose qu'ils ont faite a été d'entrer. Creuser dans la base de connaissances interne a rapidement donné des résultats:

  • L'entreprise dispose d'un réseau WiFi avec authentification de compte de domaine avec accès à un réseau local. Avec l'ensemble de données actuel, il s'agit déjà d'un vecteur d'attaque efficace, mais vous devez vous rendre au bureau avec vos pieds et vous placer quelque part dans le bureau du client.
  • , , … « » , . «» «» . , DMZ.

Bien sûr, le «deuxième facteur» a été immédiatement ajouté au compte compromis en tant qu'application sur mon téléphone. Il y avait un programme qui pouvait envoyer à haute voix une demande push au téléphone avec les boutons «approuver» / «désapprouver», ou afficher silencieusement le code OTP à l'écran pour une entrée indépendante supplémentaire. De plus, la première méthode était censée être la seule instruction correcte, mais ne fonctionnait pas, contrairement à la méthode OTP.

Avec le "deuxième facteur" cassé, j'ai réussi à me connecter à la messagerie Outlook Web Access et à accéder à distance à Citrix Netscaler Gateway. Dans Outlook, une surprise attendait par la poste:


Dans cette photo rare, vous pouvez voir comment Roskomnadzor aide les pentesters.C'était

les premiers mois après le fameux verrou de ventilateur Telegram, lorsque des réseaux entiers avec des milliers d'adresses ont inexorablement disparu de l'accès. Il est devenu clair pourquoi le push n'a pas fonctionné tout de suite et pourquoi ma «victime» n'a pas sonné l'alarme car ils ont commencé à utiliser son compte pendant les heures d'ouverture.

Ceux qui connaissent Citrix Netscaler imaginent qu'il est généralement implémenté de telle sorte qu'il est possible de transmettre à l'utilisateur uniquement une interface d'image, en essayant de ne pas lui donner les outils nécessaires pour lancer des applications tierces et transférer des données, en limitant de toutes les manières possibles les actions via des coquilles de contrôle standard. Par ma profession, je n'ai obtenu que 1C:


Après avoir marché un peu sur l'interface 1C, j'ai trouvé qu'il y avait des modules de traitement externes. Ils peuvent être chargés à partir de l'interface et ils seront exécutés sur le client ou le serveur, selon les droits et les paramètres.

J'ai demandé à des amis programmeurs 1C de créer un tel traitement qui prendrait une chaîne et l'exécuterait. Dans 1C, le lancement du processus ressemble à ceci (extrait d'Internet). D'accord, la syntaxe du langage 1C frappe une personne russophone avec son immédiateté?



Le traitement a été parfaitement exécuté, il s'est avéré ce que les Pentesters appellent le «shell» - Internet Explorer a été lancé à travers lui.


Plus tôt, l'adresse du système a été trouvée dans l'e-mail, ce qui vous permet de commander des laissez-passer pour le territoire. J'ai commandé un pass au cas où je devrais utiliser le vecteur d'attaque via WiFi.


Sur Internet, ils disent que dans le bureau du client il y avait encore une restauration gratuite savoureuse, mais je préférais toujours développer une attaque via un site distant, c'est plus calme.

AppLocker a été activé sur le serveur d'applications avec Citrix, mais il a été contourné. Le même Meterpreter a été chargé et démarré via DNS, car les versions http (s) ne voulaient pas se connecter et je ne connaissais pas l'adresse proxy interne à ce moment-là. À propos, à partir de ce moment, le penteste externe s'est essentiellement transformé en penteste interne.

Partie 4. Droits d'administrateur pour les utilisateurs - c'est mauvais, p-nyatnenko?


La première chose qu'un Pentester fait lorsqu'il prend le contrôle de la session d'un utilisateur de domaine est de collecter toutes les informations sur les droits du domaine. Il existe un tel utilitaire BloodHound, qui vous permet automatiquement de télécharger des informations sur les utilisateurs, les ordinateurs, les groupes de sécurité via le protocole LDAP à partir du contrôleur de domaine, et des informations sur l'utilisateur qui s'est récemment connecté et qui est l'administrateur local via SMB.

Une technique typique pour capturer des privilèges d'administrateur de domaine semble simplifiée comme un cycle d'actions monotones:

  • Nous allons aux ordinateurs de domaine, où il existe des droits d'administrateur local, basés sur des comptes de domaine déjà capturés.
  • Mimikatz , Kerberos NTLM , . lsass.exe . Windows 2012R2/Windows 8.1 .
  • , . . - .

«Fin de cycle», comme l'écriraient les programmeurs 1C ici.

Ainsi, notre utilisateur s'est avéré être un administrateur local sur un seul hôte avec Windows 7, dont le nom était le mot "VDI", ou "Virtual Desktop Infrastructure", des machines virtuelles personnelles. Le concepteur du service VDI a probablement laissé entendre que, puisque le VDI est le système d'exploitation personnel de l'utilisateur, laissez-le ensuite modifier l'environnement logiciel, comme vous le souhaitez, de toute façon l'hôte peut être "rechargé". J'ai aussi pensé que, en général, l'idée est bonne, je suis allé chez cet hôte VDI personnel et j'y ai fait un socket:

  • J'y ai installé le client OpenVPN, qui a créé un tunnel via Internet vers mon serveur. Le client a dû passer à travers le très Blue Coat avec l'authentification de domaine, mais OpenVPN s'est débrouillé, comme on dit, hors de la boîte.
  • Installé sur VDI OpenSSH. Eh bien, vraiment, qu'est-ce que ce Windows 7 sans SSH?

Voilà à quoi cela ressemblait vivant. Je vous rappelle que tout cela doit être fait via Citrix et 1C:


L'une des techniques de promotion de l'accès aux ordinateurs voisins consiste à vérifier la correspondance des mots de passe des administrateurs locaux. Ici, la chance attendait tout de suite: le hachage NTLM de l'administrateur local par défaut (qui s'appelait soudainement Administrateur) a approché les hôtes VDI voisins, dont il y avait plusieurs centaines, via l'attaque passe-le-hachage. Bien sûr, l'attaque les a immédiatement dépassés.
Ensuite, les administrateurs VDI se sont tiré une balle dans le pied deux fois:
  • La première fois que les machines VDI n'ont pas été mises en action par LAPS, il a essentiellement enregistré le même mot de passe administrateur local à partir d'une image qui a été massivement déployée sur VDI.
  • — , pass-the-hash . , , — .
Pourquoi le service SSH sur ce Windows? Très simple: le serveur OpenSSH fournit désormais non seulement un shell de commande interactif pratique sans interférer avec le travail de l'utilisateur, mais également un proxy socks5 sur VDI. Grâce à ces chaussettes, je me suis connecté via SMB et j'ai collecté des comptes en cache de toutes ces centaines de machines VDI, puis j'ai cherché le chemin vers l'administrateur de domaine dans les graphiques BloodHound. Avec des centaines d'hôtes à ma disposition, j'ai trouvé ce chemin assez rapidement. Les droits d'administrateur de domaine ont été obtenus.

Voici une image tirée d'Internet, montrant une recherche similaire. Les liens indiquent qui est l'administrateur et qui a saisi où.


Soit dit en passant, rappelez-vous la condition dès le début du projet - «ne pas appliquer l'ingénierie sociale». Donc, je propose de réfléchir à combien tout ce Bollywood serait coupé avec des effets spéciaux, si l'on pouvait néanmoins appliquer un phishing banal. Mais personnellement, j'étais très intéressé à faire tout cela. J'espère que cette lecture vous a intéressé. Bien sûr, tous les projets ne semblent pas aussi intrigants, mais le travail dans son ensemble est très déroutant et ne stagne pas.

Probablement, quelqu'un aura une question: comment se protéger? Même dans cet article, de nombreuses techniques sont décrites, les administrateurs Windows n'en connaissent même pas beaucoup. Cependant, je propose de les examiner du point de vue des principes et des mesures hackneyed de sécurité de l'information:

  • n'utilisez pas de logiciels obsolètes (rappelez-vous Windows 2003 au début?)
  • ne laissez pas les systèmes inutiles allumés (pourquoi le site de l'urologue?)
  • vérifiez vous-même la force des mots de passe des utilisateurs (sinon les soldats ... les pentesters le feront )
  • Ne pas avoir les mêmes mots de passe pour différents comptes (compromis VDI)
  • et autre

Bien sûr, il est très difficile à mettre en œuvre, mais dans le prochain article nous montrerons en pratique que c'est tout à fait possible.

More articles:


All Articles