PRÉCONISATIONS DE DURCISSEMENT SOUS WINDOWS
Parce que tout casser c'est cool, mais sécuriser c'est mieux !
Voici quelques préconisations de durcissement expliquées simplement, pour bien comprendre leur usage :
Protected Users
Disponible à partir de Windows Server 2012 R2, pour sécuriser les comptes d'administration, l'Active Directory va modifier certains comportements sur les comptes ajoutés au groupe Protected Users :
- Les identifiants ne sont pas mis en cache dans LSASS sur les machines. Sur une machine déconnectée du réseau, le cache credential est désactivé, il n’est donc pas possible de récupérer le hash MSCacheV2 pour tenter de le bruteforcer.
- Le ticket Kerberos (TGT) est délivré à la connexion de l'utilisateur et il ne sera pas renouvelé automatiquement lorsqu'il devient invalide (4 heures, par défaut sur ces comptes).
- Impossible d'utiliser DES ou RC4 pour la pré-authentification Kerberos, d'utiliser NTLM pour s'authentifier, ni CredSSP, ce qui empêche l’utilisation de Pass-The-Hash.
Source : https://learn.microsoft.com/fr-fr/windows-server/security/credentials-protection-and-management/protected-users-security-group
LAPS
LAPS est un outil permettant de gérer automatiquement le mot de passe du compte « Administrateur » local de toutes les machines de votre domaine. Avec LAPS, le mot de passe est :
- Unique sur chaque poste de travail géré
- Généré aléatoirement
- Stocké de manière sécurisée dans l’annuaire Active Directory
Source : https://learn.microsoft.com/fr-fr/defender-for-identity/security-assessment-laps
AppLocker
AppLocker permet de créer des règles pour définir les applications autorisées à être exécutées par les utilisateurs sur les machines du domaine. Il est possible de restreindre l’utilisation des applications selon :
- Leur emplacement (par exemple les applications situées dans le répertoire « Program Files » ou dans le dossier natif « Windows »)
- Leur signature électronique (par exemple pour n’autoriser que les applications signées par Microsoft)
- Leurs attributs (par exemple pour n’autoriser que les applications disposant d’un attribut « Editeur » spécifique)
- Leur somme de contrôle (par exemple pour n’autoriser qu’une application dont la somme de contrôle MD5 est définie)
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
RunAsPPL
Activable en changeant simplement une valeur dans la base de registre, la protection LSA permet d’ajouter le processus LSASS au groupe des Protected Process Light (PPL). Mis en place à partir de Windows 8.1 / Server 2012 R2, cette protection a été conçue pour empêcher les applications normales, même avec des privilèges d'administrateur, d'accéder aux processus protégés.
De cette façon, il n’est pas possible pour une application standard (Mimikatz ou Procdump par exemple) d’accéder à la mémoire du processus LSASS de manière simple.
Source : https://learn.microsoft.com/fr-fr/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
Credential Guard
Cette protection permet d'isoler le processus LSASS dans un container virtualisé pour empêcher les autres processus d'y accéder. Disponible dans les éditions Enterprise 64 bits de Windows 10, la fonctionnalité utilise Hyper-V.
Lorsque Windows Defender Credential Guard est activé, NTLMv1, MS-CHAPv2, Digest et CredSSP ne peuvent pas utiliser les informations d’identification de connexion. Par conséquent, l’authentification ne fonctionne pas avec ces protocoles. Kerberos n’autorise pas non plus la délégation sans contrainte ni le chiffrement DES. L’activation s’effectue via une GPO.
Source : https://learn.microsoft.com/fr-fr/windows/security/identity-protection/credential-guard/credential-guard-how-it-works
LLMNR et NBT-NS
LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (Netbios Name Service) sont deux protocoles de résolutions de nom de broadcast/multicast qui sont activés par défaut, ils sont utilisés lorsque la résolution de nom DNS échoue. Lors d’une demande de résolution DNS via LLMNR, si une réponse est transmise, les informations d'identification de l'utilisateur courant sont directement envoyées au serveur spécifié.
Un attaquant peut donc écouter les requêtes LLMNR et transmettre de fausses informations de résolution afin de capturer une tentative de connexion, qui pourra être bruteforcée. La désactivation de LLMNR peut s’effectuer via une GPO. Concernant le protocole NETBIOS, il peut être désactivé dans les propriétés de la carte réseau.
Source : https://tmsecurity.fr/viewpost.php?X-n0=26
Signature SMB
La signature SMB est un mécanisme de sécurité dans le protocole de partage de fichiers SMB. Le principe de cette protection consiste à ce que lors d’un échange sur le protocole SMB, le client place un hachage de l’intégralité du message dans le champ de signature de l’en-tête SMB. Si une personne modifie un message pendant sa transmission, le hachage ne correspond pas, indiquant que les données ont été falsifiées.
Cette protection permet d’empêcher une retransmission d’une authentification sur le protocole SMB, plus connue sous le nom de « relai d’authentification SMB ». Une GPO permet d’activer cette protection.
Source : https://learn.microsoft.com/fr-fr/troubleshoot/windows-server/networking/overview-server-message-block-signing
Restriction des délégations Kerberos
La délégation d’authentification Kerberos permet à un serveur délégué de s’authentifier au nom d’un autre utilisateur auprès d’un ou plusieurs serveurs du domaine. Une délégation d’authentification Kerberos peut et doit être restreinte à un SPN précis pour assurer sa fonction, et ne doit donc pas être définie « sans contrainte », auquel cas un attaquant pourrait prendre le contrôle du serveur autorisé pour la délégation et usurper une identité sur l’ensemble des serveurs du domaine.
Source : https://learn.microsoft.com/fr-fr/troubleshoot/windows-server/identity/configure-kerberos-constrained-delegation
Stratégie de complexité de mots de passe
Il est possible via les stratégies de groupe de paramétrer une exigence de complexité pour la définition des mots de passe du domaine. Cette protection empêche un utilisateur d’utiliser les données contenues dans son nom (dans les champs samAccountName et displayName précisément) et force l’utilisation de chiffres et de caractères non alphanumériques.
Cette protection peut être combinée à une stratégie de longueur de mot de passe minimale à respecter pour assurer une complexité de mots de passe accrue (Notamment pour les SPN).
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements
Pré-authentification Kerberos
La pré-authentification Kerberos permet de s'assurer que l'utilisateur s’authentifie lors d'une demande de jetons TGT. Sans pré-authentification il est possible d'obtenir un jeton TGT chiffré avec une clé de session dérivée du mot de passe de l’utilisateur. Cette clé de session peut donc être bruteforcée par un attaquant pour tenter de trouver le mot de passe de l’utilisateur.
Par défaut, tous les comptes utilisateur imposent la pré-authentification Kerberos.
Source : https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#kerberos_properties_preauth_priv
Désactivation du protocole IPv6
Le protocole IPv6 peut être utilisé par un attaquant pour provoquer de manière triviale des dénis de service (RA attack) et/ou de l’interception de trafic réseau (MiTM6) pouvant permettre de récupérer ou de relayer des tentatives d’authentification. Souvent délaissé, il est préférable de désactiver ce protocole s’il n’est pas utilisé.
Source : https://www.youtube.com/watch?v=IMos_Z2SdEg
Désactivation du protocole WPAD
Également appelé « Autoproxy », ce protocole permet à un client de navigateur web de découvrir automatiquement le proxy à utiliser pour se connecter à Internet. Un attaquant pourrait annoncer une configuration de proxy lui permettant d’intercepter le trafic réseau d’un poste et potentiellement récupérer des tentatives d’authentification.
Source : https://learn.microsoft.com/fr-fr/windows/win32/winhttp/winhttp-autoproxy-support
Désactivation de Windows Script Host
Windows Script Host permet d’exécuter des scripts développés en Batch, en VBScript ou encore en Jscript. Il existe 2 versions de WSH : une version graphique (Wscript.exe) et une version en ligne de commande (Cscript.exe). Souvent utilisés par les groupes de Ransomwares (TeslaCrypt, Locky…) il est préférable de désactiver ces outils s’ils ne sont pas utilisés.
La désactivation de ces outils peut s’effectuer via la base de registre de Windows.
Source : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738350(v=ws.10)
Désactivation du protocole NTLM
Dans un environnement Active Directory, le protocole d’authentification NTLM peut être remplacé par le protocole Kerberos pour sécuriser les échanges. Ce remplacement peut s’effectuer selon plusieurs configurations : Remplacement complet, Remplacement pour les comptes du domaine, Remplacement pour les serveurs du domaine ou Remplacement pour les comptes de domaine vers les serveurs du domaine.
Les attaques ciblant le protocole d’authentification NTLM peuvent ainsi être éliminées, notamment les relais d’authentification NTLM et les interceptions d’authentification.
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
Désactivation du chiffrement RC4 dans Kerberos
Kerberos supporte plusieurs algorithmes de chiffrement pour stocker les condensats des secrets des comptes utilisateurs du domaine : RC4, AES128 et AES256. Il est possible de désactiver l’utilisation de l’algorithme RC4 afin de durcir le chiffrement et rentre les attaques par bruteforce beaucoup plus longues et complexes.
Source : https://learn.microsoft.com/fr-fr/windows-server/security/kerberos/preventing-kerberos-change-password-that-uses-rc4-secret-keys
Désactivation du protocole SMBv1
Une vulnérabilité dans le protocole SMBv1 au niveau d’une extension permettant la compression des flux, activée par défaut, permet à un attaquant de provoquer une exécution de code arbitraire à distance sans authentification (MS17-010 EternalBlue).
Il est conseillé de désactiver ce protocole sur l’ensemble de votre infrastructure.
Source : https://learn.microsoft.com/fr-fr/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3
Désactivation du spouleur d’impression
De multiples vulnérabilités non patchées dans le service spouleur d’impression permettent de forcer une authentification avec le compte machine d’un poste. Afin de réduire la surface d’attaque, il est conseillé de désactiver le service sur les serveurs qui n’interviennent pas en tant que serveur d’impression sur le domaine.
Source : https://learn.microsoft.com/fr-fr/windows/win32/printdocs/print-spooler
Désactivation de la lecture de l’annuaire LDAP
Par défaut les utilisateurs du domaine peuvent énumérer et lister l’ensemble des objets de l’annuaire du domaine. Afin d’éviter qu’un attaquant possédant ces privilèges ne puisse identifier des vulnérabilités de conception lui permettant d’obtenir plus de privilèges, il est possible d’appliquer des refus de permissions de lecture sur certains groupes et/ou objets pour un utilisateur ou un groupe défini.
Source : https://social.technet.microsoft.com/wiki/contents/articles/6130.how-to-hide-objects-in-active-directory-from-specific-users.aspx
Désactivation des anciennes versions de Powershell
Microsoft a implémenté la fonctionnalité AMSI, basée sur Windows Defender, dans les nouvelles versions de Powershell, permettant de détecter l’exécution de scripts malveillants. Dans les anciennes versions de Powershell, parfois encore présentes sur certains postes, cette protection n’est pas intégrée.
Source : https://learn.microsoft.com/fr-fr/windows/win32/amsi/how-amsi-helps
Activation de la transcription Powershell
Microsoft permet dans PowerShell de créer automatiquement une transcription de toutes les commandes saisies, afin de pouvoir auditer l’activité. Activable par une stratégie de groupe, cette protection permet de rapidement détecter des exécutions de commandes suspectes.
Source : https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_group_policy_settings
Restriction du mode de langage Powershell
Toutes les sessions PowerShell ont un mode langage, permettant d’utiliser différents éléments de langage dans la session :
- Dans le mode « FullLanguage », tous les éléments sont autorisés.
- Dans le mode « RestrictedLanguage », les utilisateurs peuvent exécuter des commandes (applets de commande, fonctions, commandes CIM et workflows) mais ne sont pas autorisés à utiliser des blocs de script.
- Dans Le mode « ConstrainedLanguage », toutes les applets de commande et tous les éléments de langage PowerShell sont autorisés, mais les types autorisés sont limités.
- Dans le mode « NoLanguage », seules les commandes de base sont autorisées.
Source : https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-7.3
Activation des stratégies d’audit
Afin de permettre une identification de la provenance plus rapide en cas de compromission, il est possible d’activer l’audit de plusieurs catégories d’évènements : La connexion aux comptes, la gestion des comptes, l’accès aux objets, les évènements système… etc.
En complément, un système de centralisation des logs peut être mis en place pour une durée de rétention plus longue (comme WinSyslog ou Graylog par exemple).
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/auditing/basic-security-audit-policies
Bloquer les appels de réplication de l’annuaire LDAP
Un attaquant disposant des privilèges d’administration sur un contrôleur de domaine pourrait effectuer des requêtes de réplication d’annuaire (DCSync) en intégrant un second contrôleur de domaine fantôme (DCShadow) afin de contourner les éventuels systèmes de détection.
Ces requêtes s’effectuent au travers du protocole RPC sur TCP en se connectant à des UUIDs spécifiques (DRSUAPI et DSAOP). Il est possible de créer des filtres de blocage au niveau du serveur RPC afin d’empêcher la communication au travers de ce canal (via la commande « netsh rpc filter »).
Source : https://learn.microsoft.com/fr-fr/windows/win32/rpc/load-balancing-best-practices
Activation de l’isolation du noyau
Cette protection permet d’utiliser la virtualisation matérielle (Virtualization-Based Security - VBS) pour isoler les processus systèmes et ajoute également une protection de l’intégrité de la mémoire.
Certains pilotes de matériel ou logiciel qui nécessitent un accès exclusif au matériel de virtualisation ne sont en revanche pas compatibles avec la fonctionnalité et peuvent causer des ralentissements ou des plantages.
Source : https://support.microsoft.com/fr-fr/windows/protection-des-appareils-dans-s%C3%A9curit%C3%A9-windows-afa11526-de57-b1c5-599f-3a4c6a61c5e2
Parce que tout casser c'est cool, mais sécuriser c'est mieux !
Voici quelques préconisations de durcissement expliquées simplement, pour bien comprendre leur usage :
Protected Users
Disponible à partir de Windows Server 2012 R2, pour sécuriser les comptes d'administration, l'Active Directory va modifier certains comportements sur les comptes ajoutés au groupe Protected Users :
- Les identifiants ne sont pas mis en cache dans LSASS sur les machines. Sur une machine déconnectée du réseau, le cache credential est désactivé, il n’est donc pas possible de récupérer le hash MSCacheV2 pour tenter de le bruteforcer.
- Le ticket Kerberos (TGT) est délivré à la connexion de l'utilisateur et il ne sera pas renouvelé automatiquement lorsqu'il devient invalide (4 heures, par défaut sur ces comptes).
- Impossible d'utiliser DES ou RC4 pour la pré-authentification Kerberos, d'utiliser NTLM pour s'authentifier, ni CredSSP, ce qui empêche l’utilisation de Pass-The-Hash.
Source : https://learn.microsoft.com/fr-fr/windows-server/security/credentials-protection-and-management/protected-users-security-group
LAPS
LAPS est un outil permettant de gérer automatiquement le mot de passe du compte « Administrateur » local de toutes les machines de votre domaine. Avec LAPS, le mot de passe est :
- Unique sur chaque poste de travail géré
- Généré aléatoirement
- Stocké de manière sécurisée dans l’annuaire Active Directory
Source : https://learn.microsoft.com/fr-fr/defender-for-identity/security-assessment-laps
AppLocker
AppLocker permet de créer des règles pour définir les applications autorisées à être exécutées par les utilisateurs sur les machines du domaine. Il est possible de restreindre l’utilisation des applications selon :
- Leur emplacement (par exemple les applications situées dans le répertoire « Program Files » ou dans le dossier natif « Windows »)
- Leur signature électronique (par exemple pour n’autoriser que les applications signées par Microsoft)
- Leurs attributs (par exemple pour n’autoriser que les applications disposant d’un attribut « Editeur » spécifique)
- Leur somme de contrôle (par exemple pour n’autoriser qu’une application dont la somme de contrôle MD5 est définie)
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
RunAsPPL
Activable en changeant simplement une valeur dans la base de registre, la protection LSA permet d’ajouter le processus LSASS au groupe des Protected Process Light (PPL). Mis en place à partir de Windows 8.1 / Server 2012 R2, cette protection a été conçue pour empêcher les applications normales, même avec des privilèges d'administrateur, d'accéder aux processus protégés.
De cette façon, il n’est pas possible pour une application standard (Mimikatz ou Procdump par exemple) d’accéder à la mémoire du processus LSASS de manière simple.
Source : https://learn.microsoft.com/fr-fr/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
Credential Guard
Cette protection permet d'isoler le processus LSASS dans un container virtualisé pour empêcher les autres processus d'y accéder. Disponible dans les éditions Enterprise 64 bits de Windows 10, la fonctionnalité utilise Hyper-V.
Lorsque Windows Defender Credential Guard est activé, NTLMv1, MS-CHAPv2, Digest et CredSSP ne peuvent pas utiliser les informations d’identification de connexion. Par conséquent, l’authentification ne fonctionne pas avec ces protocoles. Kerberos n’autorise pas non plus la délégation sans contrainte ni le chiffrement DES. L’activation s’effectue via une GPO.
Source : https://learn.microsoft.com/fr-fr/windows/security/identity-protection/credential-guard/credential-guard-how-it-works
LLMNR et NBT-NS
LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (Netbios Name Service) sont deux protocoles de résolutions de nom de broadcast/multicast qui sont activés par défaut, ils sont utilisés lorsque la résolution de nom DNS échoue. Lors d’une demande de résolution DNS via LLMNR, si une réponse est transmise, les informations d'identification de l'utilisateur courant sont directement envoyées au serveur spécifié.
Un attaquant peut donc écouter les requêtes LLMNR et transmettre de fausses informations de résolution afin de capturer une tentative de connexion, qui pourra être bruteforcée. La désactivation de LLMNR peut s’effectuer via une GPO. Concernant le protocole NETBIOS, il peut être désactivé dans les propriétés de la carte réseau.
Source : https://tmsecurity.fr/viewpost.php?X-n0=26
Signature SMB
La signature SMB est un mécanisme de sécurité dans le protocole de partage de fichiers SMB. Le principe de cette protection consiste à ce que lors d’un échange sur le protocole SMB, le client place un hachage de l’intégralité du message dans le champ de signature de l’en-tête SMB. Si une personne modifie un message pendant sa transmission, le hachage ne correspond pas, indiquant que les données ont été falsifiées.
Cette protection permet d’empêcher une retransmission d’une authentification sur le protocole SMB, plus connue sous le nom de « relai d’authentification SMB ». Une GPO permet d’activer cette protection.
Source : https://learn.microsoft.com/fr-fr/troubleshoot/windows-server/networking/overview-server-message-block-signing
Restriction des délégations Kerberos
La délégation d’authentification Kerberos permet à un serveur délégué de s’authentifier au nom d’un autre utilisateur auprès d’un ou plusieurs serveurs du domaine. Une délégation d’authentification Kerberos peut et doit être restreinte à un SPN précis pour assurer sa fonction, et ne doit donc pas être définie « sans contrainte », auquel cas un attaquant pourrait prendre le contrôle du serveur autorisé pour la délégation et usurper une identité sur l’ensemble des serveurs du domaine.
Source : https://learn.microsoft.com/fr-fr/troubleshoot/windows-server/identity/configure-kerberos-constrained-delegation
Stratégie de complexité de mots de passe
Il est possible via les stratégies de groupe de paramétrer une exigence de complexité pour la définition des mots de passe du domaine. Cette protection empêche un utilisateur d’utiliser les données contenues dans son nom (dans les champs samAccountName et displayName précisément) et force l’utilisation de chiffres et de caractères non alphanumériques.
Cette protection peut être combinée à une stratégie de longueur de mot de passe minimale à respecter pour assurer une complexité de mots de passe accrue (Notamment pour les SPN).
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements
Pré-authentification Kerberos
La pré-authentification Kerberos permet de s'assurer que l'utilisateur s’authentifie lors d'une demande de jetons TGT. Sans pré-authentification il est possible d'obtenir un jeton TGT chiffré avec une clé de session dérivée du mot de passe de l’utilisateur. Cette clé de session peut donc être bruteforcée par un attaquant pour tenter de trouver le mot de passe de l’utilisateur.
Par défaut, tous les comptes utilisateur imposent la pré-authentification Kerberos.
Source : https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#kerberos_properties_preauth_priv
Désactivation du protocole IPv6
Le protocole IPv6 peut être utilisé par un attaquant pour provoquer de manière triviale des dénis de service (RA attack) et/ou de l’interception de trafic réseau (MiTM6) pouvant permettre de récupérer ou de relayer des tentatives d’authentification. Souvent délaissé, il est préférable de désactiver ce protocole s’il n’est pas utilisé.
Source : https://www.youtube.com/watch?v=IMos_Z2SdEg
Désactivation du protocole WPAD
Également appelé « Autoproxy », ce protocole permet à un client de navigateur web de découvrir automatiquement le proxy à utiliser pour se connecter à Internet. Un attaquant pourrait annoncer une configuration de proxy lui permettant d’intercepter le trafic réseau d’un poste et potentiellement récupérer des tentatives d’authentification.
Source : https://learn.microsoft.com/fr-fr/windows/win32/winhttp/winhttp-autoproxy-support
Désactivation de Windows Script Host
Windows Script Host permet d’exécuter des scripts développés en Batch, en VBScript ou encore en Jscript. Il existe 2 versions de WSH : une version graphique (Wscript.exe) et une version en ligne de commande (Cscript.exe). Souvent utilisés par les groupes de Ransomwares (TeslaCrypt, Locky…) il est préférable de désactiver ces outils s’ils ne sont pas utilisés.
La désactivation de ces outils peut s’effectuer via la base de registre de Windows.
Source : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738350(v=ws.10)
Désactivation du protocole NTLM
Dans un environnement Active Directory, le protocole d’authentification NTLM peut être remplacé par le protocole Kerberos pour sécuriser les échanges. Ce remplacement peut s’effectuer selon plusieurs configurations : Remplacement complet, Remplacement pour les comptes du domaine, Remplacement pour les serveurs du domaine ou Remplacement pour les comptes de domaine vers les serveurs du domaine.
Les attaques ciblant le protocole d’authentification NTLM peuvent ainsi être éliminées, notamment les relais d’authentification NTLM et les interceptions d’authentification.
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
Désactivation du chiffrement RC4 dans Kerberos
Kerberos supporte plusieurs algorithmes de chiffrement pour stocker les condensats des secrets des comptes utilisateurs du domaine : RC4, AES128 et AES256. Il est possible de désactiver l’utilisation de l’algorithme RC4 afin de durcir le chiffrement et rentre les attaques par bruteforce beaucoup plus longues et complexes.
Source : https://learn.microsoft.com/fr-fr/windows-server/security/kerberos/preventing-kerberos-change-password-that-uses-rc4-secret-keys
Désactivation du protocole SMBv1
Une vulnérabilité dans le protocole SMBv1 au niveau d’une extension permettant la compression des flux, activée par défaut, permet à un attaquant de provoquer une exécution de code arbitraire à distance sans authentification (MS17-010 EternalBlue).
Il est conseillé de désactiver ce protocole sur l’ensemble de votre infrastructure.
Source : https://learn.microsoft.com/fr-fr/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3
Désactivation du spouleur d’impression
De multiples vulnérabilités non patchées dans le service spouleur d’impression permettent de forcer une authentification avec le compte machine d’un poste. Afin de réduire la surface d’attaque, il est conseillé de désactiver le service sur les serveurs qui n’interviennent pas en tant que serveur d’impression sur le domaine.
Source : https://learn.microsoft.com/fr-fr/windows/win32/printdocs/print-spooler
Désactivation de la lecture de l’annuaire LDAP
Par défaut les utilisateurs du domaine peuvent énumérer et lister l’ensemble des objets de l’annuaire du domaine. Afin d’éviter qu’un attaquant possédant ces privilèges ne puisse identifier des vulnérabilités de conception lui permettant d’obtenir plus de privilèges, il est possible d’appliquer des refus de permissions de lecture sur certains groupes et/ou objets pour un utilisateur ou un groupe défini.
Source : https://social.technet.microsoft.com/wiki/contents/articles/6130.how-to-hide-objects-in-active-directory-from-specific-users.aspx
Désactivation des anciennes versions de Powershell
Microsoft a implémenté la fonctionnalité AMSI, basée sur Windows Defender, dans les nouvelles versions de Powershell, permettant de détecter l’exécution de scripts malveillants. Dans les anciennes versions de Powershell, parfois encore présentes sur certains postes, cette protection n’est pas intégrée.
Source : https://learn.microsoft.com/fr-fr/windows/win32/amsi/how-amsi-helps
Activation de la transcription Powershell
Microsoft permet dans PowerShell de créer automatiquement une transcription de toutes les commandes saisies, afin de pouvoir auditer l’activité. Activable par une stratégie de groupe, cette protection permet de rapidement détecter des exécutions de commandes suspectes.
Source : https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_group_policy_settings
Restriction du mode de langage Powershell
Toutes les sessions PowerShell ont un mode langage, permettant d’utiliser différents éléments de langage dans la session :
- Dans le mode « FullLanguage », tous les éléments sont autorisés.
- Dans le mode « RestrictedLanguage », les utilisateurs peuvent exécuter des commandes (applets de commande, fonctions, commandes CIM et workflows) mais ne sont pas autorisés à utiliser des blocs de script.
- Dans Le mode « ConstrainedLanguage », toutes les applets de commande et tous les éléments de langage PowerShell sont autorisés, mais les types autorisés sont limités.
- Dans le mode « NoLanguage », seules les commandes de base sont autorisées.
Source : https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-7.3
Activation des stratégies d’audit
Afin de permettre une identification de la provenance plus rapide en cas de compromission, il est possible d’activer l’audit de plusieurs catégories d’évènements : La connexion aux comptes, la gestion des comptes, l’accès aux objets, les évènements système… etc.
En complément, un système de centralisation des logs peut être mis en place pour une durée de rétention plus longue (comme WinSyslog ou Graylog par exemple).
Source : https://learn.microsoft.com/fr-fr/windows/security/threat-protection/auditing/basic-security-audit-policies
Bloquer les appels de réplication de l’annuaire LDAP
Un attaquant disposant des privilèges d’administration sur un contrôleur de domaine pourrait effectuer des requêtes de réplication d’annuaire (DCSync) en intégrant un second contrôleur de domaine fantôme (DCShadow) afin de contourner les éventuels systèmes de détection.
Ces requêtes s’effectuent au travers du protocole RPC sur TCP en se connectant à des UUIDs spécifiques (DRSUAPI et DSAOP). Il est possible de créer des filtres de blocage au niveau du serveur RPC afin d’empêcher la communication au travers de ce canal (via la commande « netsh rpc filter »).
Source : https://learn.microsoft.com/fr-fr/windows/win32/rpc/load-balancing-best-practices
Activation de l’isolation du noyau
Cette protection permet d’utiliser la virtualisation matérielle (Virtualization-Based Security - VBS) pour isoler les processus systèmes et ajoute également une protection de l’intégrité de la mémoire.
Certains pilotes de matériel ou logiciel qui nécessitent un accès exclusif au matériel de virtualisation ne sont en revanche pas compatibles avec la fonctionnalité et peuvent causer des ralentissements ou des plantages.
Source : https://support.microsoft.com/fr-fr/windows/protection-des-appareils-dans-s%C3%A9curit%C3%A9-windows-afa11526-de57-b1c5-599f-3a4c6a61c5e2