Ce SID est libre ? Le laboratoire de détection des menaces de Varonis découvre l’attaque d’injection de SID synthétiques

Les chercheurs du laboratoire de détection des menaces de Varonis ont découvert une technique dans laquelle les acteurs malveillants munis de privilèges élevés existants peuvent injecter des SID synthétiques dans une ACL Active Directory. Cela crée un scénario dans lequel des portes dérobées peuvent apparaître et des autorisations accordées de façon masquée, lorsqu’un nouveau compte est créé avec un SID légitime correspondant.

L’attaque est possible pour les raisons suivantes :

Les SID sont faciles à deviner car ils sont en grande partie attribués de manière consécutive
Active Directory ne vérifie pas si le SID appliqué à une ACL est valide ou non

Nous mettons fin aux SID qui respectent les règles de formatage des SID légitimes, mais qui ne font pas encore référence à un objet et sont donc « synthétique ».

Contexte

Le système d’autorisation d’Active Directory se compose de trois parties :

Tiers de confiance : des objets auxquels sont rattachées des autorisations. Il s’agit le plus couramment de comptes utilisateur, de groupes et de comptes d’ordinateur.
Identifiant de sécurité (SID) : dans Active Directory, les principaux de sécurité sont identifiés par un identifiant de sécurité (SID). Le SID est un identifiant unique qui représente toute entité pouvant être authentifiée sur le système d’exploitation. On peut comparer le SID à un numéro de sécurité sociale ou un numéro de carte d’identité, mais dans le cadre d’un objet de domaine. Le SID est émis par un contrôleur de domaine et est attribué à un objet au moment de sa création. Il ne peut être ni réutilisé ni utilisé pour identifier une autre entité.
Liste de contrôle d’accès (ACL) : il s’agit du mapping entre un objet (SID) et les autorisations au sein d’Active Directory.

Pas de vérification du SID

Lors de la création d’une ACL, on ne vérifie pas si le SID du tiers de confiance existe sur le domaine. En raison de ce manque de vérification, une personne munie des autorisations suffisantes serait en mesure d’ajouter un SID « synthétique » qui n’existe pas, à une ACL.

Ces SID (synthétiques) inexistants avec autorisations au sein de l’ACL persistent de manière inoffensive au sein des ACL, jusqu’à ce qu’un nouvel utilisateur ou ordinateur soit créé, et auquel on aurait attribué le SID auparavant synthétique. Ces nouveaux comptes héritent alors instantanément des autorisations ACL accordées au préalable.

Comment examiner une ACL

Pour accéder à l’ACL d’un objet, il suffit de se rendre sur l’onglet Sécurité :

Windows résout le SID de l’entrée et présente le nom d’utilisateur à des fins de lisibilité. Cependant, en arrière-plan, l’ACL identifie l’utilisateur via son SID défini au format SDDL (plus d’informations à ce sujet ici https://docs.microsoft.com/fr-fr/windows/win32/secauthz/security-descriptor-string-format).

Injecter un SID synthétique dans une ACL

Parce que Windows ne vérifie pas que les SID existent sur le domaine lors de la création d’une ACL, il est possible d’insérer notre SID synthétique dans l’ACL de n’importe quel objet sur lequel nous avons des privilèges.

Remarque : la partie du domaine du SID est modifiable, mais la partie « S-1-5-21 » ne l’est pas.
Le SID synthétique de cette capture d’écran :

Ne peut être résolu (« Compte inconnu ») car il n’est pas attribué
Est valide pour l’entrée de l’ACL

Mettre la main sur un SID existant n’est pas chose facile car les SID ne peuvent être pris à d’autres utilisateurs ni réutilisés. Cependant, en cartographiant la liste des SID actuellement existants sur le domaine, il est possible de savoir sous quels SID les nouveaux utilisateurs seront créés. Cela nous permet de créer un scénario dans lequel un compte nouvellement créé hérite de nos autorisations injectées.

Il est possible de mapper les SID existants avec PowerShell :

(([adsisearcher]"(objectSid=*)").FindAll()).Properties.objectsid | ForEach-Object {(New-Object System.Security.Principal.SecurityIdentifier($_,0)).Value}

Le SID de l’image ci-dessous n’est relié à aucun compte et est le SID suivant disponible sur le domaine. Il a reçu un accès « Full Control » sur l’objet « Remote Management Users » :

Nous avons créé un compte nommé « ThisIsMySID » et il a récupéré le SID en question :

L’utilisateur « ThisIsMySID » dispose désormais d’un contrôle total sur le groupe.

Il convient de noter que cette astuce fonctionne également pour attribuer des droits et privilèges Windows comme SeDebugPrivilege, SeRemoteInteractiveLogonRight ou d’autres constantes de privilèges.

EXPLOITATION

Ici, le vecteur d’exploitation principal est la persistance. Les acteurs malveillants possédant un contrôle sur le domaine peuvent ajouter des autorisations et des privilèges à de futurs SID et réapparaître en créant un nouvel utilisateur ou ordinateur.

La création d’un compte ne pose pas vraiment problème, si la personne est déjà en mesure de contrôler un compte utilisateur standard. Par défaut, les utilisateurs authentifiés peuvent créer jusqu’à 10 comptes d’ordinateurs. Ces derniers, comme les utilisateurs standard, doivent également recevoir un SID, ce qui rend cette attaque possible.

Scénario d’attaque DCSync

En ajoutant un SID à un objet du domaine et en lui accordant des privilèges de synchronisation (requis dans une attaque DCSync), l’acteur malveillant plante une porte dérobée. Bien évidemment, il est possible d’ajouter plus d’un SID pour s’assurer qu’il ne sera pas écrasé par les activités quotidiennes.

Pour repartir de plus belle, l’acteur malveillant doit réussir à contrôler un compte utilisateur standard (potentiellement par phishing) et utiliser ce compte pour créer un compte d’ordinateur :

Le tout nouveau compte remplacera l’un des SID disponibles et aura les autorisations DCSync.

Remédiation et surveillance

Microsoft ne considère pas cela comme un problème de sécurité, cependant, la surveillance est recommandée car l’attribution de SID synthétiques est un comportement inhabituel.

La surveillance des comportements suivants est conseillée pour atténuer ce risque.

Des alertes sur les changements anormaux de privilèges, d’attribution des droits et d’autorisations accordées dans les environnements Active Directory, qu’ils soient effectués automatiquement par des scripts ou des malwares, ou manuellement par une menace active.
Des modélisations basées sur les comportements (comme celles proposées par Varonis) sur les objets sensibles, et axées sur les changements au sein des ACL.
Des changements sur les objets de Directory Services dans votre organisation (événement Windows 5136)
Des modélisations basées sur les comportements (comme celles proposées par Varonis) pour être alerté lorsqu’un utilisateur reçoit des autorisations sur un objet sensible ou pour surveiller un tiers de confiance ajouté à l’objet et recevoir une alerte s’il n’existe pas.
Des attributions de privilèges directs (événement Windows 4704) peuvent indiquer la présence d’une injection de SID synthétiques.

Supprimer les SID orphelins

Mettre en place un processus permettant de repérer et de supprimer tout SID non attribué peut empêcher l’attaquant de récupérer les SID synthétiques.
Vous pouvez pour cela utiliser PowerShell, ICACLS ou des outils dédiés pour localiser les SID orphelins et les supprimer.

Sources

What should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:

Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.

See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.

Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

Eric Saraga