Protection contre la reconnaissance interne en utilisant NetCease et SAMRi10

Qu'est-ce que la Reconnaissance Interne ?

La reconnaissance interne est l'une des premières étapes qu'un attaquant entreprendra une fois qu'il aura compromis un compte d'utilisateur ou d'ordinateur dans votre réseau. À l'aide de divers outils ou scripts, ils recensent et collectent des informations qui les aideront à identifier quels actifs ils devraient essayer de compromettre ensuite pour obtenir ce qu'ils veulent. Par exemple, BloodHound cartographiera les chemins d'attaque qui peuvent permettre à un adversaire d'escalader leurs privilèges d'utilisateur ordinaire à administrateur.

Presque toutes les méthodes d'énumération courantes peuvent être exécutées par un utilisateur sans privilèges, ce qui les rend extrêmement difficiles à détecter et à bloquer. Dans cet article, je vais expliquer comment utiliser pour se défendre contre deux types de reconnaissance interne :

• Énumération des sessions par des utilisateurs non privilégiés
• Requêtes au protocole MS-SAMR

Types de reconnaissance

Pour trouver des informations sur le réseau qu'ils ont pénétré, les attaquants énumèrent souvent les types de données suivants :

• Sessions — Pour découvrir qui est connecté où
• Utilisateurs — Pour comprendre tous les utilisateurs dans le domaine, idéalement avec leur appartenance à des groupes
• Groupes — Pour voir tous les groupes dans le domaine, idéalement avec leur appartenance
• Listes de contrôle d'accès (ACLs) d'Active Directory — Pour comprendre quels principes de sécurité (tels que les utilisateurs et les groupes) peuvent accéder à quelles ressources
• Appartenance au groupe local — Pour voir qui a des droits d'accès sur la machine (surtout qui a des droits administratifs)

Blocage de l'énumération des sessions avec NetCease

Cet article de blog se concentre sur l'énumération des sessions, qui permet à un adversaire de déterminer où les comptes d'utilisateurs et de services sont connectés. Ces informations les aident à prioriser quels hôtes tenter de compromettre en premier — tels que les hôtes qui ont un administrateur connecté.

Note : Les autorisations par défaut dans Windows 10 ont été modifiées pour empêcher les attaquants de réaliser une énumération de sessions ; cependant, il est toujours recommandé de vérifier.

NetCease est un court script PowerShell qui aide à prévenir l'énumération des sessions en modifiant la clé de Registre qui contrôle les permissions de la méthode NetSessionEnum. (La raison pour laquelle cela est réalisé à l'aide d'un script plutôt que manuellement est parce que la clé, SrvsvcSessionInfo, n'est modifiable que dans une valeur binaire reg.) Voici le chemin vers la clé SrvsvcSessionInfo :

Chemin : HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

La valeur par défaut de la clé de registre SrvsvcSessionInfo est la liste de contrôle d'accès qui autorise l'utilisation de la méthode NetSessionEnum. Ceci est attribué aux éléments suivants :

• Membre des Administrateurs
• Membre des opérateurs de serveur
• Membre des utilisateurs avec privilèges
• Utilisateurs authentifiés

La permission des Utilisateurs authentifiés permet aux attaquants de réaliser une reconnaissance de session en utilisant n'importe quel compte utilisateur compromis.

Ce que fait le script NetCease, c'est sauvegarder la valeur actuelle du registre puis modifier les permissions, de sorte que les ACEs suivants soient dans la liste de contrôle d'accès (ACL) :

• InteractiveSid
• ServiceSid
• BatchSid
• Administrateurs
• Opérateurs de serveur
• PowerUsers

Vérification de la liste de contrôle d'accès

Si vous souhaitez voir le descripteur de sécurité, vous pouvez utiliser l'extrait de PowerShell suivant, qui vous montrera la liste de contrôle d'accès :

      #Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize
      

Résultat avant d'exécuter NetCease :

Résultat après l'exécution de NetCease :

Note : Les informations concernant les SID bien connus sont disponibles ici.

Test de l'énumération des sessions

Une manière simple de tester si vous avez bloqué l'énumération de sessions par des comptes d'utilisateurs ordinaires consiste à utiliser l'outil NetSess de Joeware.net, mais il existe de nombreuses autres options, y compris SharpHound. Lorsque vous faites cela, assurez-vous d'utiliser un compte utilisateur qui n'est pas membre des Administrateurs, des Opérateurs de serveur ou des Utilisateurs avec pouvoir.

Résultat avant d'utiliser NetCease

      Netsess.exe [Computer]
      

Résultat après l'utilisation de NetCease avec un compte non privilégié

      Netsess.exe [Computer]
      

Résultat après l'utilisation de NetCease avec un compte d'utilisateur privilégié

      Netsess.exe [Computer]
      

Blocage de la reconnaissance en utilisant SAM à distance (SAMR)

Les attaquants peuvent effectuer une reconnaissance en utilisant le protocole SAMR, qui peut interroger à distance des appareils mais aussi interroger Active Directory. En utilisant SAMR, un attaquant sans aucun privilège administratif peut trouver des groupes et des utilisateurs hautement privilégiés, ainsi que des utilisateurs et des groupes locaux pour chaque système sur le réseau. Des outils tels que BloodHound peuvent ensuite cartographier automatiquement ces informations dans des chemins d'attaque pour compromettre Active Directory.

Microsoft a introduit des protections pour les requêtes SAMR avec Windows 10, et en 2017 a ajouté des mises à jour pour les systèmes d'exploitation antérieurs jusqu'à Windows 7 et Server 2008 R2 en utilisant la clé de registre RestrictRemoteSAM. Cette clé est une chaîne (REG_SZ) qui contiendra le SDDL du descripteur de sécurité qui protège les appels Remote SAM.

Dans l'édition anniversaire de Windows 10 (1607) et Windows Server 2016 et ultérieurs, le SDDL par défaut a été modifié pour permettre uniquement aux administrateurs locaux d'interroger le SAM distant.

Ci-dessous se trouve un tableau détaillant les exigences, le comportement par défaut et les options de protection pour tous les systèmes d'exploitation :

Il existe trois manières de configurer la clé de registre RestrictRemoteSAM :

• Registre
• Stratégie de groupe
• SAMRi10 (Samaritain)

Examinons chacun d'entre eux.

Option de registre

La clé de registre RestrictRemoteSAM est disponible pour que les administrateurs la mettent à jour comme ils le souhaitent :

Chemin d'accès : HKLM/System/CurrentControlSet/Control/Lsa

Nom : RestrictRemoteSAM

Valeur par défaut (SDDL) dans Windows 10 : O:SYG:SYD:(A;;RC;;;BA)

Composants du SDDL

Comme vous pouvez le voir, la valeur par défaut que Windows 10 définit est SYSTEM pour le Propriétaire et le Groupe principal et Contrôle en lecture pour les Administrateurs intégrés.

Vérification du SDDL avant de l'appliquer

Pour vérifier que le SDDL est correct avant d'appliquer le changement, vous pouvez utiliser la commande ConvertFrom-SDDLString dans PowerShell pour le convertir en un descripteur de sécurité plus facile à lire.

Option de stratégie de groupe ou de politique de sécurité locale

La stratégie de groupe et les paramètres de la Security Policy permettent aux administrateurs de définir cette clé facilement. Cela peut bien fonctionner pour les administrateurs qui souhaitent définir la même valeur sur tous les systèmes ou plusieurs groupes de systèmes (par exemple, autoriser les connexions SAM à distance pour tous les serveurs dans une OU spécifique ou un certain ensemble de serveurs d'applications).

Les détails concernant le paramètre sont les suivants :

Option SAMRi10 (Samaritain)

SAMRi10 est un script PowerShell qui offre un avantage clé par rapport aux options précédentes : il crée un nouveau groupe local et délègue l'accès pour que le groupe puisse effectuer des appels SAM à distance. Cela permet aux administrateurs de contrôler entièrement cette fonctionnalité dans les Préférences de stratégie de groupe, ou de l'accorder manuellement aux comptes lorsque nécessaire.

Le script SAMRi10 effectue les actions suivantes :

1. Crée un groupe local appelé « Remote SAM Users »
2. Modifie le SDDL pour inclure le groupe nouvellement créé :
   • S'il n'y a pas de SDDL par défaut, alors accordez l'accès aux administrateurs intégrés.
   • Si un SDDL existe, alors modifiez-le pour inclure la nouvelle ACE pour le groupe des utilisateurs SAM à distance.

Avantages de l'utilisation de SAMRi10

• Facile d'accorder un accès granulaire pour l'accès SAM à distance
• Aide les organisations qui souhaitent appliquer l'accès au moindre privilège
• Peut être utilisé conjointement avec une appartenance à un groupe local Group Policy pour accorder aux utilisateurs un accès centralisé en utilisant le ciblage au niveau de l'élément
• Peut être utilisé par un système de Privileged Access Management (PAM) pour accorder facilement un accès dynamique (juste-à-temps) si un compte ou un processus nécessite cette permission spécifique

Défense contre la reconnaissance avec les solutions Netwrix

Netwrix StealthAUDIT comprend un analyseur de chemins d'attaque qui fournit aux administrateurs un aperçu de leurs ACLs Active Directory afin qu'ils puissent combler les lacunes avant que les adversaires ne les exploitent. Netwrix StealthINTERCEPT peut surveiller les requêtes LDAP puis les transmettre à Netwrix StealthDEFEND, qui peut détecter plusieurs scénarios de reconnaissance et requêtes prédéfinies, y compris BloodHound, les requêtes pour tous les SPNs, et les requêtes pour tous les comptes avec password never expires.

FAQ

Qu'est-ce que la reconnaissance interne et pourquoi devriez-vous vous en soucier ?

La reconnaissance interne se produit lorsque les attaquants qui ont déjà obtenu un accès initial à votre réseau commencent à cartographier votre environnement pour trouver des cibles précieuses. Ils ne sont plus en train de forcer l'entrée – ils sont déjà connectés et regardent autour d'eux. C'est là que la plupart des stratégies de sécurité sont défaillantes, se concentrant sur les défenses périmétriques tandis que les attaquants se déplacent librement à l'intérieur en utilisant des identifiants légitimes.

La réalité est simple : vous ne pouvez pas protéger ce que vous ne pouvez pas voir, et vous ne pouvez pas contrôler ce que vous ne comprenez pas. La reconnaissance interne est la phase critique où les attaquants recueillent des renseignements sur la structure de votre Active Directory, identifient les comptes à haute valeur et tracent les chemins vers vos données les plus sensibles. Data Security That Starts with Identity commence par empêcher les attaquants d'énumérer votre infrastructure d'identité en premier lieu.

Comment implémentez-vous NetCease pour la protection de l'énumération des sessions ?

NetCease bloque les attaques d'énumération de sessions en empêchant les utilisateurs non autorisés de lister les sessions actives sur vos contrôleurs de domaine et serveurs. La mise en œuvre est simple mais nécessite de la planification. D'abord, téléchargez NetCease depuis le dépôt officiel et vérifiez que vous l'exécutez sur un système avec PowerShell 5.1 ou ultérieur.

Prérequis :

• Privilèges administratifs
• PowerShell 5.1 ou version ultérieure
• Système joint au domaine ou Windows Server

L'outil fonctionne en modifiant les paramètres du registre qui contrôlent la manière dont le service Windows Server répond aux demandes d'énumération de sessions. Exécutez NetCease avec des privilèges administratifs sur chaque serveur que vous souhaitez protéger, en commençant par des systèmes non critiques pour les tests. Les modifications prennent effet immédiatement sans nécessiter de redémarrage, mais vous devriez vérifier que les outils administratifs légitimes et les solutions de surveillance fonctionnent toujours correctement.

La meilleure pratique consiste à implémenter NetCease progressivement dans votre environnement plutôt que de le déployer partout en une seule fois. Commencez par les serveurs qui n'hébergent pas d'applications critiques pour l'entreprise, surveillez les éventuelles perturbations, puis étendez l'implémentation aux contrôleurs de domaine et autres cibles de haute valeur. Rappelez-vous que prévenir la reconnaissance ne consiste pas à rendre votre réseau invisible – il s'agit de rendre le travail des attaquants plus difficile et de donner à vos systèmes de détection plus de temps pour identifier l'activité malveillante.

Quelle est la différence entre SAMRi10 et les restrictions de Group Policy SAM ?

SAMRi10 et la stratégie de groupe restreignent tous deux l'accès à la base de données du Security Account Manager (SAM), mais ils fonctionnent à différents niveaux et répondent à différents cas d'utilisation. SAMRi10 est un script PowerShell qui modifie directement les paramètres du registre sur des machines individuelles, vous donnant un contrôle granulaire sur les restrictions d'accès SAM sur des systèmes spécifiques.

Les restrictions de stratégie de groupe SAM fonctionnent au niveau du domaine, vous permettant d'appliquer des politiques cohérentes sur plusieurs systèmes simultanément. L'approche de stratégie de groupe est préférable pour les déploiements à grande échelle où vous avez besoin d'une protection uniforme sur de nombreuses machines. SAMRi10 est idéal pour des serveurs spécifiques, des environnements de test ou des situations où vous avez besoin de configurations personnalisées qui ne correspondent pas aux modèles de stratégie de groupe standard.

L'implémentation technique diffère également. SAMRi10 modifie directement la clé de registre RestrictRemoteSAM, tandis que la stratégie de groupe utilise le système de modèle administratif pour obtenir le même résultat. Les deux méthodes sont efficaces, mais SAMRi10 vous offre plus de flexibilité pour le dépannage et les configurations personnalisées. Pour la plupart des organisations, une approche hybride fonctionne mieux : utilisez la stratégie de groupe pour les restrictions SAM de base à travers le domaine, puis utilisez SAMRi10 pour les systèmes spécifiques qui nécessitent un renforcement supplémentaire.

Comment vérifiez-vous que les mesures de protection contre la reconnaissance fonctionnent ?

Tester votre protection contre la reconnaissance nécessite une approche méthodique qui simule les techniques réelles des attaquants sans perturber les opérations. Commencez par des tests d'énumération de sessions de base en utilisant des outils comme NetSess ou les commandes Get-WmiObject de PowerShell depuis un compte non administratif. Si NetCease fonctionne correctement, ces tentatives devraient échouer ou retourner des informations limitées.

Pour les restrictions SAM, testez l'accès à distance à la base de données Security Account Manager en utilisant des outils comme enum4linux ou rpcclient depuis un système Linux, ou des commandes net use depuis Windows. Des restrictions SAM correctement configurées devraient bloquer les tentatives d'énumération non autorisées tout en permettant toujours l'accès administratif légitime.

La clé est de tester du point de vue de l'attaquant. Créez des comptes de test avec des privilèges d'utilisateur standard et tentez des techniques de reconnaissance courantes telles que l'énumération de domaines, la découverte de partages et le listing des comptes utilisateurs. Documentez ce qui fonctionne et ce qui ne fonctionne pas, puis ajustez vos mesures de protection en conséquence. Rappelez-vous qu'une sécurité efficace ne consiste pas à tout bloquer – il s'agit de contrôler quelles informations sont disponibles pour qui tout en garantissant que les fonctions commerciales légitimes continuent de fonctionner correctement.

Quand devriez-vous annuler les modifications de NetCease et SAMRi10 ?

Les scénarios de restauration impliquent généralement des problèmes de compatibilité avec des outils d'administration légitimes, des défaillances d'applications inattendues ou des perturbations de processus commerciaux qui n'ont pas été identifiées lors des tests. NetCease et SAMRi10 offrent tous deux des options de restauration, mais le processus diffère pour chaque outil.

Pour NetCease, l'annulation implique de revenir sur les modifications du registre qui contrôlent l'énumération des sessions. L'outil comprend des paramètres pour restaurer les paramètres d'origine, mais vous devriez toujours documenter la baseline configuration avant d'apporter des modifications. Testez le processus d'annulation dans un environnement de laboratoire d'abord pour vous assurer que vous comprenez les étapes et le timing impliqués.

Le retour en arrière de SAMRi10 est plus complexe car il implique plusieurs clés de registre et potentiellement des interactions avec les stratégies de groupe. Si vous avez mis en place des restrictions SAM via les stratégies de groupe, utilisez les outils de gestion des politiques pour annuler les modifications. Pour les modifications directes du registre, SAMRi10 comprend des fonctions de restauration, mais une vérification manuelle est essentielle pour garantir un retour en arrière complet.

La meilleure approche est proactive : mettez en œuvre des changements pendant les fenêtres de maintenance, documentez et testez les procédures de retour en arrière, et surveillez de près les systèmes affectés pendant au moins 24 à 48 heures après la mise en œuvre. La plupart des problèmes de compatibilité apparaissent rapidement, mais certains peuvent ne devenir apparents que lors de processus commerciaux spécifiques ou d'opérations systèmes.