Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/stealing-credentials/credentials-protections.md

15 KiB
Raw Blame History

Protections des identifiants Windows

Protections des identifiants

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

WDigest

Le protocole WDigest a été introduit dans Windows XP et a été conçu pour être utilisé avec le protocole HTTP pour l'authentification. Microsoft a ce protocole activé par défaut dans plusieurs versions de Windows (Windows XP — Windows 8.0 et Windows Server 2003 — Windows Server 2012), ce qui signifie que les mots de passe en clair sont stockés dans le LSASS (Local Security Authority Subsystem Service). Mimikatz peut interagir avec le LSASS permettant à un attaquant de récupérer ces identifiants grâce à la commande suivante :

sekurlsa::wdigest

Ce comportement peut être désactivé/activé en définissant sur 1 la valeur de UseLogonCredential et Negotiate dans HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest.
Si ces clés de registre n'existent pas ou si la valeur est "0", alors WDigest sera désactivé.

reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

Protection LSA

Microsoft dans Windows 8.1 et versions ultérieures a fourni une protection supplémentaire pour le LSA afin de prévenir les processus non fiables de pouvoir lire sa mémoire ou d'injecter du code. Cela empêchera le fonctionnement correct de mimikatz.exe sekurlsa:logonpasswords.
Pour activer cette protection, vous devez définir la valeur RunAsPPL dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA à 1.

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL

Contournement

Il est possible de contourner cette protection en utilisant le pilote Mimikatz mimidrv.sys :

Credential Guard

Credential Guard est une nouvelle fonctionnalité de Windows 10 (éditions Enterprise et Education) qui aide à protéger vos identifiants sur une machine contre des menaces telles que pass the hash. Cela fonctionne grâce à une technologie appelée Virtual Secure Mode (VSM) qui utilise les extensions de virtualisation du CPU (mais ce n'est pas une véritable machine virtuelle) pour fournir une protection aux zones de mémoire (vous pourriez entendre cela désigné sous le nom de Virtualization Based Security ou VBS). VSM crée une "bulle" séparée pour les processus clés qui sont isolés des processus réguliers du système d'exploitation, y compris le noyau et seuls les processus de confiance spécifiques peuvent communiquer avec les processus (connus sous le nom de trustlets) dans le VSM. Cela signifie qu'un processus dans le système d'exploitation principal ne peut pas lire la mémoire de VSM, même les processus du noyau. L'Autorité de Sécurité Locale (LSA) est l'un des trustlets dans VSM en plus du processus standard LSASS qui fonctionne toujours dans le système d'exploitation principal pour assurer la compatibilité avec les processus existants mais agit vraiment comme un proxy ou un stub pour communiquer avec la version dans VSM en s'assurant que les identifiants réels fonctionnent sur la version dans VSM et sont donc protégés contre les attaques. Pour Windows 10, Credential Guard doit être activé et déployé dans votre organisation car il n'est pas activé par défaut. Depuis https://www.itprotoday.com/windows-10/what-credential-guard. Plus d'informations et un script PS1 pour activer Credential Guard peuvent être trouvés ici. Cependant, à partir de Windows 11 Enterprise, version 22H2 et Windows 11 Education, version 22H2, les systèmes compatibles ont Windows Defender Credential Guard activé par défaut.

Dans ce cas, Mimikatz ne peut pas faire grand-chose pour contourner cela et extraire les hachages de LSASS. Mais vous pourriez toujours ajouter votre SSP personnalisé et capturer les identifiants lorsqu'un utilisateur essaie de se connecter en texte clair.
Plus d'informations sur SSP et comment faire cela ici.

Credential Guard pourrait être activé de différentes manières. Pour vérifier s'il a été activé en utilisant le registre, vous pourriez vérifier la valeur de la clé LsaCfgFlags dans HKLM\System\CurrentControlSet\Control\LSA. Si la valeur est "1", alors il est actif avec verrouillage UEFI, si "2", il est actif sans verrouillage et si "0", il n'est pas activé.
Cela n'est pas suffisant pour activer Credential Guard (mais c'est un indicateur fort).
Plus d'informations et un script PS1 pour activer Credential Guard peuvent être trouvés ici.

reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags

Mode RDP RestrictedAdmin

Avec Windows 8.1 et Windows Server 2012 R2, de nouvelles fonctionnalités de sécurité ont été introduites. L'une de ces fonctionnalités de sécurité est le mode Restricted Admin pour RDP. Cette nouvelle fonctionnalité de sécurité est introduite pour atténuer le risque d'attaques pass the hash.

Lorsque vous vous connectez à un ordinateur distant en utilisant RDP, vos identifiants sont stockés sur l'ordinateur distant auquel vous vous connectez en RDP. Habituellement, vous utilisez un compte puissant pour vous connecter aux serveurs distants, et le fait d'avoir vos identifiants stockés sur tous ces ordinateurs constitue effectivement une menace pour la sécurité.

En utilisant le mode Restricted Admin pour RDP, lorsque vous vous connectez à un ordinateur distant en utilisant la commande, mstsc.exe /RestrictedAdmin, vous serez authentifié sur l'ordinateur distant, mais vos identifiants ne seront pas stockés sur cet ordinateur distant, comme ils l'auraient été par le passé. Cela signifie que si un logiciel malveillant ou même un utilisateur malveillant est actif sur ce serveur distant, vos identifiants ne seront pas disponibles sur ce serveur de bureau à distance pour que le logiciel malveillant puisse attaquer.

Notez que comme vos identifiants ne sont pas sauvegardés dans la session RDP, si vous essayez d'accéder aux ressources réseau, vos identifiants ne seront pas utilisés. L'identité de la machine sera utilisée à la place.

Depuis ici.

Identifiants mis en cache

Les identifiants de domaine sont utilisés par les composants du système d'exploitation et sont authentifiés par l'Autorité de sécurité locale (LSA). Typiquement, les identifiants de domaine sont établis pour un utilisateur lorsque un package de sécurité enregistré authentifie les données de connexion de l'utilisateur. Ce package de sécurité enregistré peut être le protocole Kerberos ou NTLM.

Windows stocke les dix derniers identifiants de connexion au domaine dans l'éventualité où le contrôleur de domaine serait hors ligne. Si le contrôleur de domaine est hors ligne, un utilisateur pourra toujours se connecter à son ordinateur. Cette fonctionnalité est principalement destinée aux utilisateurs d'ordinateurs portables qui ne se connectent pas régulièrement au domaine de leur entreprise. Le nombre d'identifiants que l'ordinateur stocke peut être contrôlé par la clé de registre suivante, ou via la stratégie de groupe :

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

Les identifiants sont cachés des utilisateurs normaux, même des comptes administrateurs. L'utilisateur SYSTEM est le seul utilisateur qui a les privilèges pour voir ces identifiants. Pour qu'un administrateur puisse voir ces identifiants dans le registre, il doit accéder au registre en tant qu'utilisateur SYSTEM. Les identifiants mis en cache sont stockés dans le registre à l'emplacement suivant :

HKEY_LOCAL_MACHINE\SECURITY\Cache

Extraction depuis Mimikatz : lsadump::cache
Depuis ici.

Utilisateurs Protégés

Lorsque l'utilisateur connecté est membre du groupe Utilisateurs Protégés, les protections suivantes sont appliquées :

  • La délégation d'identifiants (CredSSP) ne mettra pas en cache les identifiants en clair de l'utilisateur, même lorsque le paramètre de stratégie de groupe Autoriser la délégation des identifiants par défaut est activé.
  • À partir de Windows 8.1 et Windows Server 2012 R2, Windows Digest ne mettra pas en cache les identifiants en clair de l'utilisateur, même lorsque Windows Digest est activé.
  • NTLM ne mettra pas en cache les identifiants en clair de l'utilisateur ou la fonction à sens unique NT (NTOWF).
  • Kerberos ne créera plus de clés DES ou RC4. De plus, il ne mettra pas en cache les identifiants en clair de l'utilisateur ou les clés à long terme après l'acquisition du TGT initial.
  • Un vérificateur mis en cache n'est pas créé lors de la connexion ou du déverrouillage, donc la connexion hors ligne n'est plus prise en charge.

Après l'ajout du compte utilisateur au groupe Utilisateurs Protégés, la protection commencera lorsque l'utilisateur se connectera à l'appareil. Depuis ici.

Windows Server 2003 RTM Windows Server 2003 SP1+

Windows Server 2012,
Windows Server 2008 R2,
Windows Server 2008

 Windows Server 2016
Account Operators Account Operators Account Operators Account Operators
Administrator Administrator Administrator Administrator
Administrators Administrators Administrators Administrators
Backup Operators Backup Operators Backup Operators Backup Operators
Cert Publishers
Domain Admins Domain Admins Domain Admins Domain Admins
Domain Controllers Domain Controllers Domain Controllers Domain Controllers
Enterprise Admins Enterprise Admins Enterprise Admins Enterprise Admins
Enterprise Key Admins
Key Admins
Krbtgt Krbtgt Krbtgt Krbtgt
Print Operators Print Operators Print Operators Print Operators
Read-only Domain Controllers Read-only Domain Controllers
Replicator Replicator Replicator Replicator
Schema Admins Schema Admins Schema Admins Schema Admins
Server Operators Server Operators Server Operators Server Operators

Tableau depuis ici.

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :