A un historique SID
Description
Le principal de sécurité source détient le SID du principal de sécurité cible dans son attribut SIDHistory, ce qui signifie que la source a les mêmes droits que la cible.
L'historique des SID est un mécanisme légitime utilisé lors de la migration des principaux de sécurité entre des domaines pour conserver toutes les autorisations faisant référence à leur précédent SID fonctionnel.
Cependant, il s'agit également d'un mécanisme de persistance utilisé par les attaquants, car il permet à un compte de porte dérobée discret d'avoir les mêmes droits que la cible souhaitée, un compte administrateur par exemple.
Exploitation
Les attaquants qui compromettent le principal de sécurité source peuvent s'authentifier directement en tant que principal de sécurité cible puisque le SID de la cible est ajouté de manière transparente dans le jeton généré par les mécanismes d'authentification Active Directory (NTLM et Kerberos).
Remédiation
Si les principaux de sécurité source et cible sont liés à une migration de domaine approuvée, vous pouvez considérer que la relation est légitime et ne pas agir. Cette relation reste visible en tant que rappel de chemin d'attaque potentiel.
Si le domaine d'origine a été supprimé après la migration ou n'est pas configuré dans Tenable Identity Exposure, le principal de sécurité cible est marqué comme non résolu. Étant donné que le risque réside dans la cible et que cette cible n'existe pas, il n'existe pas de risque et donc aucune correction n'est requise.
En revanche, les relations d'historique de SID avec des utilisateurs ou des groupes avec des privilèges natifs sont très probablement malveillantes, car Active Directory empêche leur création. Ils ont donc probablement été créés à l'aide de techniques de piratage telles qu'une attaque « DCShadow ». Vous pouvez également trouver ces cas dans l'IoE lié à l'« historique des SID ».
Dans ce cas, Tenable Identity Exposure recommande d'effectuer une analyse contextuelle de l'ensemble de la forêt Active Directory, car les attaquants doivent avoir obtenu des privilèges élevés (administrateur de domaine ou équivalent) pour pouvoir modifier à des fins malveillantes l'historique des SID de la source. Cette analyse contextuelle permet d'analyser l'attaque avec les conseils de remédiation correspondants et d'identifier les portes dérobées potentielles à supprimer.
Enfin, Microsoft recommande de modifier tous les droits d'accès dans tous les services (partages SMB, Exchange, etc.) pour utiliser les nouveaux SID, et de supprimer les valeurs SIDHistory inutiles après la migration. Il s'agit d'une bonne pratique d'administration, bien qu'il soit très difficile d'identifier de manière exhaustive toutes les listes ACL et de les corriger.
Un utilisateur qui a le droit de modifier l'attribut SIDHistory sur l'objet source lui-même peut supprimer les valeurs SIDHistory. Contrairement à la création, cette opération ne nécessite pas de droits d'administrateur de domaine.
Pour ce faire, vous ne pouvez utiliser que PowerShell, car les outils graphiques tels que Utilisateurs et ordinateurs Active Directory échoueront. Exemple :
Set-ADUser -Identity <user> -Remove @{sidhistory="S-1-..."}Attention : il est très facile de supprimer une valeur SIDHistory, mais très compliqué d'annuler cette opération. En effet, vous devez recréer la valeur SIDHistory, ce qui nécessite la présence de l'autre domaine susceptible d'être mis hors service. Pour cette raison, Microsoft recommande également de préparer des instantanés ou des sauvegardes.
Voir aussi