Elévation de privilèges Windows

Pratique de gestion de la sécurité de l'information: pentest

Augmentation des privilèges utilisateur au niveau administrateur de domaine Windows

Présentation

Un bon système de gestion de la sécurité de l'information (SMSI) nécessite une évaluation régulière de son efficacité. Il existe différentes méthodes d'évaluation, dont l'une des variétés est la soi-disant. "Test de pénétration" ou pentest - une simulation autorisée d'une attaque de pirate informatique sur un système d'information afin d'identifier les vulnérabilités de sa protection avant qu'elles ne soient détectées par un véritable attaquant. Dans ce cas, tous les outils de piratage, exploits, méthodes, etc. disponibles dans la vie réelle peuvent être utilisés.

Cet article décrit l'une de ces pratiques anti-piratage, qui visait à augmenter les privilèges d'un utilisateur de domaine Microsoft Windows ordinaire au niveau d'un administrateur de domaine. L'article était basé sur un rapport sur les résultats d'un test mis en pratique. Pour des raisons de confidentialité, toutes les informations permettant d'identifier le lieu (noms de domaine et d'hôte, comptes, etc.) sont supprimées ou modifiées. L'article montre les techniques de base, pour une meilleure compréhension, j'ai donné les fondements théoriques et les vulnérabilités utilisés pour des versions spécifiques de systèmes d'exploitation, ainsi que des recommandations générales pour la protection. Et bien que la plupart de ces versions de Windows soient considérées comme obsolètes au moment de la publication, cet article peut être utile aux administrateurs système débutants pour mieux comprendre les méthodes de protection des informations d'identification dans un environnement Windows.

Description de l'objet de test

L'objet de test est assez standard - le système d'information d'une petite entreprise (moins de 200 employés) spécialisée dans le développement de logiciels. Le réseau interne de l'entreprise est également typique: Ethernet Gigabit par ligne commutée, domaine Microsoft Windows (nous l'appellerons CORP.LOCAL). Les hôtes internes sont divisés en sous-réseaux IP en fonction de leur affiliation fonctionnelle (tels que: un groupe de développeurs, des ingénieurs qualité, le service des ressources humaines, la comptabilité, le marketing, la direction, les installations, etc.), toute la segmentation est effectuée sur le commutateur L3 . Il existe également un parc de serveurs internes dédié à un sous-réseau IP distinct et contenant: deux contrôleurs de domaine Windows Server 2008 avec DNS intégré, un serveur de messagerie interne exécutant Exchange, un serveur de fichiers, un serveur de terminaux et certains autres serveurs auxiliaires exécutant Windows et Linux. Par ailleurs, il convient de noter un laboratoire de test avec une flotte de machines exécutant différentes versions de Microsoft Windows (à la fois de bureau et de serveur) et conçues pour tester le logiciel développé. L'accès aux hôtes du laboratoire de test est accessible à tous les employés. La version principale du système d'exploitation de bureau est Windows 7. Un logiciel antivirus mal configuré de différents fabricants est installé sur les ordinateurs de bureau et les serveurs (de Symantec, Kaspersky et Trend Micro, pourquoi un système mal configuré sera discuté plus tard).

Modèle d'intrus

Intrus - un employé interne qui possède un compte d'utilisateur non privilégié dans le domaine, un ordinateur de bureau, un accès physique aux ordinateurs de test (peut-être un ordinateur portable d'entreprise), mais qui n'a aucun privilège d'administrateur local sur aucun d'entre eux. De plus, le compte d'intrus n'a pas la possibilité de modifier les paramètres du logiciel antivirus. L'attaquant a pour objectif d'obtenir un accès équivalent à l'accès de l'administrateur au contrôleur de domaine et / ou au serveur de fichiers.

Comme nous le voyons, le modèle de l'intrus et la description de l'entreprise sont tout à fait typiques.

Implémentation d'attaque

Étape 0. Collecte d'informations sur le réseau interne

Donc, nous agissons au nom du contrevenant. À cette étape, nous devons collecter des informations sur:

• adressage interne et sous-réseau
• noms d'hôte et adresses IP, tout d'abord nous sommes intéressés par une liste de serveurs
• en utilisant le protocole NetBIOS.

Tout d'abord, en utilisant l'utilitaire ipconfig, nous obtenons les adresses IP des serveurs DNS: 192.168.12.1 et 192.168.12.2. Parce que DNS est intégré à Active Directory, ce qui nous donne des raisons de croire que nous connaissons les adresses IP des contrôleurs de domaine. Ensuite, en utilisant l'utilitaire nslookup en mode interactif, nous essayons d'obtenir une liste de tous les hôtes dans la zone corp.local:

> ls –d corp.local> fichier

En fait, cette commande lance un transfert de zone DNS complet, l'enregistrant dans un fichier. De nombreux administrateurs oublient de définir des restrictions sur le transfert de zone pour le réseau interne, ce qui permet à un attaquant potentiel de collecter plus facilement des informations sur l'infrastructure de l'entreprise, pour plus de détails, voir [12].

Résultat. Succès. Un transfert de zone non protégé nous a donné une liste complète des noms d'hôtes internes, y compris les serveurs, et leurs adresses IP. En utilisant les utilitaires nbtstat, telnet, ainsi que n'importe lequel des scanners de vulnérabilité courants, un attaquant peut collecter des informations sur la plate-forme, l'exécution des services, les versions du système d'exploitation sur les hôtes qui l'intéressent.

Étape 1. Obtention des privilèges d'administrateur local

Théorie Pour obtenir le mot de passe administrateur local, une attaque est appliquée à la valeur de hachage de ce mot de passe stocké dans le registre système. Malgré le fait que la fonction de hachage est mathématiquement irréversible, le calcul du mot de passe est possible par énumération directe de ses valeurs avec une attaque par dictionnaire. Windows a historiquement utilisé deux algorithmes pour calculer une fonction de hachage de mot de passe: l'algorithme LM hérité et l'algorithme NT plus récent (parfois aussi appelé NTLM). La fonction de hachage LM est vulnérable en raison de sa faible complexité de calcul, ce qui permet d'énumérer ses valeurs même sur un ordinateur faible. La présence de hachages de mot de passe LM et NT dans le registre système garantit que l'attaquant peut le casser dans un délai acceptable. La valeur de hachage LM aux paramètres par défaut est stockée dans le registre de Windows XP / 2003, ce qui rend ces systèmes particulièrement attrayants pour le pirate. La fonction de hachage NT est plus complexe sur le plan des calculs, cependant, l'énumération de ses valeurs est grandement simplifiée par le fait qu'il existe des tables de valeurs précalculées disponibles (appelées tables Rainbow) - elles réduisent le calcul de la valeur de hachage à la recherche du hachage souhaité parmi valeurs pré-calculées.

Objet d'attaque. Mot de passe haché dans la base de données SAM (registre). Dans notre cas, ce sont toutes des machines auxquelles nous avons un accès physique. Tout d'abord, il s'agit de notre bureau de travail et, deuxièmement, des hôtes pour effectuer des tests.

Mise en œuvre. Avec les machines qui ont un accès physique, nous effectuons l'opération suivante: démarrer à partir d'un support externe (à l'aide d'un CD d'environnement de préinstallation Windows ou d'un CD Linux Live), monter la partition système NTFS et copier les branches de registre HKLM \ SYSTEM et HKLM \ SAM (fichiers% WINDIR % \ System32 \ Config \ System et% WINDIR% \ System32 \ Config \ Sam respectivement). Nous accordons une attention particulière aux machines exécutant Windows XP \ Windows 2003, sur lesquelles le hachage LM est susceptible d'être trouvé. Pour vider les mots de passe des fichiers de registre copiés, nous utilisons les outils [1], [2] (tous les liens à la fin de l'article). Résultat:



La dernière ligne contient le hachage NT requis de l'administrateur local. Sur les hôtes du laboratoire de test (appelons ces hôtes LAB1 et LAB2), nous trouvons un hachage LM non nul:





Nous avons donc obtenu des hachages NT et LM. Mais comment récupérer le mot de passe d'eux? Pour ce faire, nous utiliserons les mêmes outils [1], [2] ainsi que les services inversés de hachage en ligne [8] - [11]:



Remarque: le vrai mot de passe était composé du nom de l'entreprise avec un petit modificateur et s'est rapidement cassé sous une attaque de dictionnaire).

Résultat. Succès. Les mots de passe (qu'ils soient «Pa $$ word1» et «Pa $$ word2») du compte administrateur local de notre bureau de travail et de deux ordinateurs de test ont été reçus. Mais aideront-ils à obtenir les droits d'administrateur de domaine? À ce sujet plus loin.

Étape 2. Obtention des informations d'identification d'administrateur de domaine

Théorie Dans la plupart des cas, il suffit d'obtenir la valeur du hachage NT du mot de passe pour l'administrateur de domaine. Cela est dû au fait que lorsqu'un utilisateur est vérifié à l'aide du protocole NTLM, le système authentifié présente uniquement le hachage NT à l'authentificateur et la vérification du mot de passe ne se produit pas. Le hachage NT peut être obtenu à partir du soi-disant Stockage LSA en se référant à la soi-disant Sessions de connexion de l'administrateur (la session de connexion est une zone de données spéciale créée par le processus Winlogon où le nom d'utilisateur, le domaine de connexion et la valeur de hachage du mot de passe NT sont stockés, collectivement, c'est ce qu'on appelle le LSA-secret). Ce hachage NT est utilisé par le processus NTLMSSP pour l'authentification NTLM. La session de connexion est enregistrée tout le temps pendant que le compte est connecté au système. Vous pouvez également intercepter un hachage NT à partir d'une session d'authentification d'administrateur NTLM. De plus, il est possible d'obtenir un mot de passe administrateur à partir du cache DCC (Domain Cached Credentials). DCC est un cache local qui se remplit lorsqu'un utilisateur ouvre une session avec succès sur un domaine. L'objectif du cache DCC est de pouvoir authentifier l'utilisateur lorsque le contrôleur de domaine n'est pas disponible.

Objets d'attaque:

• Hachage DCC (branche de registre HKLM \ Security).
• Session de connexion de l'administrateur de domaine (LSA-secret).
• Interception des sessions NTLM (non envisagée en raison d'une plus grande complexité pratique).

Pratique. De nombreux administrateurs Windows utilisent un compte d'administrateur de domaine pour effectuer différents types d'opérations sur les ordinateurs des utilisateurs. Dans le même temps, ses données tombent dans le cache DCC. Par conséquent, essayez d'abord d'obtenir le mot de passe à partir du cache DCC. Nous allons sur notre poste de travail, enregistrons la branche de registre HKLM \ Security et l'importons dans [1]. Parce que nous avons un mot de passe administrateur local, nous n'avons plus besoin de démarrer la machine à partir d'un support externe pour enregistrer le registre:



Le cache contient les données de mot de passe de trois comptes. Le dernier compte (*** utilisateur) ne nous intéresse pas, le deuxième compte n'a pas les privilèges requis, mais l'utilisateur shadmin ressemble à l'administrateur que vous recherchez. Malheureusement, l'algorithme MS-CACHE2 a une grande complexité de calcul et une attaque directe par force brute sur celui-ci est inefficace. La fonction MS-CACHEv2 contient un «secret de calcul» - sel (le nom du compte est utilisé comme «sel»), ce qui la rend protégée contre les attaques sur les tables Rainbow. Cependant, à l'avenir, des tables de valeurs de hachage peuvent apparaître pour les comptes standard - «Administrateur», «Administrateur», etc. Par souci d'intérêt, nous envoyons le «hachage de cache» trouvé au service cloud [8] - [11] (sur les résultats et l'efficacité de ces services à la fin de l'article). Pendant que le cloud réfléchit, nous essayons de trouver d'autres DCC. Nous analysons la liste d'hôtes obtenue à l'étape 0, vérifions à quels serveurs nous pouvons accéder sous l'administrateur local en utilisant les mots de passe obtenus à l'étape 1. Étant donné que l'administrateur local est bloqué sur le contrôleur de domaine et que le serveur de messagerie est généralement mieux protégé, vous devez expérimenter avec serveurs secondaires. Dans notre cas, un serveur avec le nom discret Upd a été trouvé dans la liste des serveurs. La connexion avec le mot de passe «Pa $$ word2» trouvée à l'étape 1 a réussi. Nous constatons que sur l'hôte Upd:

1. Aucun logiciel antivirus installé.
2. Il exécute Apache, qui est le serveur de gestion des antivirus d'entreprise (cela signifie qu'il existe également un mot de passe pour le compte utilisé pour installer le logiciel antivirus à distance et, théoriquement, vous pouvez le retirer).
3. L'hôte n'audit pas les tentatives de connexion ayant échoué.
4. Version du système d'exploitation - Windows 2008 R2.

Après avoir vidé le registre HKLM \ Security, nous obtenons le hachage DCC du compte CORP.LOCAL \ Administrator (et plusieurs autres):



Théoriquement, vous pouvez essayer de trouver le mot de passe de l'administrateur via un service cloud. Cependant, comme je l'ai mentionné ci-dessus, une attaque par force brute sur MS-CACHEv2 est inutile (bien qu'il soit possible que dans quelques années la situation change). Laissez DCC tranquille et passez à la recherche de sessions de connexion. Vérifiez quel utilisateur est connecté à l'hôte Upd:



Nous voyons que deux sessions inactives se bloquent sur la machine Upd - l'administrateur et l'utilisateur Shadmin, qui nous sont déjà familiers, ce qui signifie que nous pouvons obtenir des hachages NT de leurs mots de passe en volant le secret LSA. C'est la clé pour déterminer le succès de toute l'attaque. Pour voler un hachage, utilisez l'exploit Lslsass [3]. Pour l'exécuter, vous avez besoin des droits d'administrateur local (ou plutôt, des droits de débogage des processus), que nous avons déjà. Nous obtenons la liste des secrets LSA (au format "domaine \ compte: Hachage LM: Hachage NT :::"):

lslsass v1.0 - Copyright (C) 2010 Bjorn Brolin, Truesec (www.truesec.com) Found Lsass pid: 520 Lsass process open Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>::: Found possible primary token Found possible primary token Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token CORP.LOCAL\UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \Administrator::00000000000000000000000000000000: <b> c690e441dc78bc5da8b389e78daa6392 </b>::: Found possible primary token Found real token CORP.LOCAL \shadmin::00000000000000000000000000000000: <b> 5794cba8b464364eacf366063ff70e78 </b> ::: 

Les lignes surlignées en gras contiennent les hachages de mot de passe requis. Notez également le hachage en italique dans la sixième ligne. Nous l'avons déjà vu quelque part, non?

Résultat. Succès. Nous avons le hachage de mot de passe NT du compte d'administrateur de domaine entre nos mains. Mais à quoi sert un hachage si la restauration du mot de passe d'origine à partir de celui-ci dans un délai acceptable n'est pas possible? À ce sujet à l'étape suivante.

Étape 3. Trichez la session d'authentification NTLM

Théorie Windows n'utilise jamais un mot de passe pur pour l'authentification, le système authentifié présente toujours un hachage. Cela donne naissance à l'idée: en remplaçant le nom d'utilisateur, le domaine de connexion et le hachage NT dans la session de connexion de l'utilisateur connecté par les valeurs appropriées d'administrateur de domaine, nous pouvons nous authentifier en utilisant le protocole NTLM avant le système distant en tant qu'administrateur de domaine. Cette attaque [7] n'est possible qu'avec une authentification utilisant le protocole NTLM. Malgré l'utilisation répandue du protocole Kerberos, NTLM est le seul moyen possible d'authentifier un client lors de l'accès à un partage réseau n'est pas par nom symbolique, mais par adresse IP [13].

Objet d'attaque. Session d'ouverture de session de l'administrateur local.

Pratique. Il existe plusieurs exploits qui vous permettent de mettre en œuvre une attaque sur les plates-formes Windows Server 2008 x86 et x64. L'exploit principal est l'éditeur d'informations d'identification Windows [4]. Pour exécuter l'attaque, nous allons à l'hôte LAB2 en utilisant les informations d'identification "Administrateur" \ "Pa $$ word2". À l'aide de [4], nous remplaçons le nom de compte, le domaine de connexion et les données de hachage NT dans la session d'ouverture de session par les valeurs Shadmin correspondantes que nous avons obtenues à l'étape précédente:



Le nom du compte d'administrateur de domaine et son hachage NT sont passés à la commande wce comme argument à partir de la ligne de commande. Résultat - le hachage a été modifié avec succès. Je note que l'appartenance de l'utilisateur au groupe et le jeton d'accès ne changent pas pendant l'attaque:



Nous sommes toujours l'administrateur local, le nom d'hôte en vert dans la capture d'écran ci-dessus est enduit de vert - LAB2. Cependant, lors de l'authentification NTLM, le système distant recevra le nom de domaine CORP.LOCAL, le nom d'utilisateur Shadmin et le hachage du mot de passe Shadmin. Voici un vidage d'un seul paquet réseau contenant une session blob de sécurité NTLM:



Le nom de domaine (CORP.LOCAL) et le nom d'hôte (LAB2) sont grisés en vert), un compte est présenté - Shadmin. Maintenant, nous essayons de nous connecter à la partition racine du volume système sur le contrôleur de domaine avec la commande net use en utilisant l'adresse IP du contrôleur de domaine:



Avec succès. Pour vérifier l'accès, j'ai créé un fichier texte à la racine (trouvez-le dans la capture d'écran). Après avoir créé un fichier batch sur le disque du contrôleur de domaine avec la séquence de commandes dont nous avons besoin, nous pouvons, en utilisant [5], effectuer l'opération nécessaire sur le contrôleur de domaine (par exemple, ajouter l'utilisateur au groupe d'administrateurs de domaine). L'opération sera effectuée avec les droits du compte Shadmin. Pour illustrer, créez un fichier de commandes simple sur un hôte distant qui ajoute un utilisateur local:

utilisateur net TstUsr Pa $$ mot / ajouter

Exécutez-le à distance à partir de l'hôte LAB2:



Il sera exécuté sur le système distant 192.168.13.125 avec les privilèges de l'utilisateur de notre session actuelle - shadmin (c'est-à-dire, administrateur de domaine). Nous vérifions:



La deuxième sortie de la commande net user montre le nouvel utilisateur. Malgré l'impossibilité de lancer des applications qui nécessitent une interaction utilisateur interactive de cette manière (par exemple, des composants logiciels enfichables MMC), un large éventail d'actions peut être effectué à l'aide de scripts.

Résultat. Succès. Accès au système de fichiers et au shell du contrôleur de domaine.

Résumé

En bref, la chaîne d'attaque ressemblait à ceci: Collecte d'informations sur la structure du réseau -> Obtention d'un mot de passe administrateur local -> Utilisation de ce mot de passe pour se connecter à l'un des serveurs secondaires -> Vol des informations d'identification d'administrateur de domaine «laissé sans surveillance» -> Modification de votre session de connexion et élévation de privilèges.

Le succès de l'attaque a été facilité par:

1. Faible protection de la zone DNS contre le transfert vers des hôtes non approuvés.
2. Politique de mot de passe faible. La plupart des ordinateurs de domaine ont utilisé le même mot de passe pour le compte d'administrateur local, qui était vulnérable à une attaque par dictionnaire.
3. L'absence ou la faible configuration du logiciel antivirus sur les hôtes critiques.
4. Protection contre les hachages de mot de passe faible - deux sessions de connexion administrateur inactives sur l'hôte Upd, hachages LM dans la base de données SAM.
5. Mauvaise politique d'audit.

Sur cette base, des recommandations générales de protection peuvent être dérivées:

0. Cacher complètement la structure interne du réseau aux attaquants potentiels. Par conséquent, les utilisateurs ne devraient pas pouvoir obtenir le contenu complet du fichier de zone DNS. Utilisateurs non fiables (par exemple, stagiaires, employés qui n'ont pas terminé la période d'essai, etc.), il est logique de transférer vers un sous-réseau distinct en utilisant NAT pour usurper des adresses (y compris, par exemple, la modification des réponses DNS).

1. La stratégie correcte pour attribuer des mots de passe à l'administrateur local. Le mot de passe administrateur local doit être différent sur les hôtes qui ont différents degrés de protection contre les accès non autorisés. Compromettre le mot de passe administrateur local sur l'un des hôtes du domaine devrait minimiser la possibilité qu'un attaquant utilise ce mot de passe.

2. Le stockage du hachage LM dans SAM doit être interdit par les politiques de sécurité.

3. N'utilisez pas le nom de l'entreprise ou de son domaine dans le mot de passe administrateur). Il sera donc difficile pour un attaquant d'attaquer le dictionnaire. Mais même en utilisant un mot de passe complexe, ne vous oubliez pas et vérifiez régulièrement la durabilité de son hachage en utilisant les services en ligne.

4. Il n'est pas recommandé d'effectuer des opérations de routine sur des ordinateurs de domaine sous le compte d'administrateur de domaine. Cela empêchera le compte d'intercepter les données de session d'ouverture de session et d'obtenir le hachage du mot de passe dans le cache DCC.

5. Faites-en une règle pour ne pas laisser la session d'ouverture de session de l'administrateur de domaine sans surveillance. Meilleure pratique: travail terminé - déconnectez-vous.

6. Les utilitaires d'usurpation LSA sont assez petits. Il est logique de suivre leur évolution et de vérifier leur détection réussie par un logiciel antivirus d'entreprise.

7. Un utilisateur, même avec des droits d'administrateur local, ne devrait pas pouvoir modifier les paramètres d'un antivirus d'entreprise. La désactivation du service antivirus sur les postes de travail de domaine devrait entraîner une notification de l'administrateur de domaine (dans ce sens, Symantec Endpoint Protection a bien fonctionné pendant le test).

Annexe 1. Comportement antivirus

Les ordinateurs de la société utilisaient trois types d'antivirus: KAV, en vigueur au moment du test Symantec Endpoint Protection, et un produit obsolète de Trend Micro. Dans la plupart des cas, les outils utilisés pendant l'attaque ont été identifiés comme Hack Tool / Rootkit / Trojan. KAV les a supprimés sans avertissement, et SEP (même désactivé) a émis un avertissement et l'a déplacé en quarantaine l'empêchant de démarrer. Cependant, avoir des droits d'administrateur local vous permet de désactiver KAV, et la protection SEP a été contournée en définissant manuellement un chemin d'exception pour la vérification, en utilisant à nouveau le compte d'administrateur local. L'antivirus de Trend Micro installé sur certains hôtes n'a pas réagi du tout au lancement d'exploits.

Addendum 2. Efficacité de l'utilisation des services de vérification de hachage en ligne

De nombreux services en ligne sont disponibles pour tester la solidité des hachages de mot de passe. Ils vous permettent de travailler avec les hachages les plus courants - LM, NTLM, MD4, MD5, WPA, avec des hachages utilisant du sel, etc. Pour vérifier le hachage, l'énumération directe est utilisée en utilisant la puissance de traitement des GPU modernes, l'énumération des dictionnaires, les attaques hybrides, etc. Une fois ouvert, le hachage peut reconstituer la base de données et être utilisé à l'avenir. Le service peut être gratuit pour vérifier un mot de passe court (moins de 8 caractères) ou prendre un petit supplément. Pendant le test, j'ai utilisé quatre de ces services, les liens sont donnés à la fin de l'article. J'ai envoyé plusieurs hachages trouvés à l'étape 2 et après 15 mois, j'ai reçu une notification du service On-line Hash Crack [9] concernant la restauration réussie de l'un d'eux)

Les références

Outils utilisés

[1] Cain & Abel - un outil de récupération de mot de passe pour les systèmes d'exploitation Microsoft. Il permet de récupérer facilement plusieurs types de mots de passe en reniflant le réseau, en déchiffrant les mots de passe cryptés à l'aide des attaques Dictionnaire, Brute-Force et Cryptanalysis, en enregistrant les conversations VoIP, en décodant les mots de passe brouillés, en récupérant les clés de réseau sans fil, en révélant les boîtes de mot de passe, en découvrant les mots de passe mis en cache et en analysant le routage protocoles.
[2] Fissure L0pht.
[3] Exploitation Lslsass. Vide les hachages de mot de passe de session d'ouverture de session active du processus lsass.
[4] Post-exploit de Windows Credentials Editor . Outil pour modifier les informations d'identification de connexion.
[5] PsExec de PS Tools

Descriptions détaillées des vulnérabilités

[6] Série d'articles «Obtention effective d'un hachage de mot de passe sous Windows» sur www.securitylab.ru
[7] Pass-the-Hash, une description d'une attaque sur un système distant en lui fournissant un hachage compromis.

Services de piratage Cloud Hash
[8] Question-defense.com (semble être hors service au moment de la publication ()
[9] www.onlinehashcrack.com
[10] www.cloudcracker.com
[11] Tueur de hachage en ligne

Matériel supplémentaire

[12] Sécurité et optimisation DNS dans Windows Server
[13] Kerberos n'est pas utilisé lorsque vous vous connectez aux partages SMB à l'aide de l'adresse IP