par Bhabesh Raj Rai, Associate Security Analyst Engineer
Les récentes vulnérabilités d’élévation de privilèges Active Directory (AD) permettent aux utilisateurs de domaine standard de se faire passer pour des administrateurs de domaine. Si l’attaque réussit, les administrateurs pourraient se retrouver dans une situation délicate qui les obligerait à nettoyer et reconstruire l’intégralité de leur AD. À l’aide de LogPoint SIEM et SOAR, les administrateurs peuvent détecter, investiguer et remédier les élévations de privilèges AD avec des détections de haute-fidélité et des playbooks prêts à l’emploi.
Le 9 novembre 2021, Microsoft a corrigé une série de vulnérabilités d’élévation de privilèges dans AD qui, lorsqu’elles s’enchaînent, permettent à un utilisateur de domaine standard de se faire passer pour un utilisateur à privilèges élevés, tel qu’un administrateur de domaine. Plusieurs Preuves de Concept (PoC) sont accessibles au public, permettant ainsi même à un acteur malveillant moins sophistiqué de compromettre facilement l’ensemble du domaine.
CVE-2021-42278 et CVE-2021-42287 sont toutes deux des vulnérabilités d’élévation de privilèges présentes dans les Services de Domaine Active Directory (AD DS) et ont un score CVSS de 8,8. Les deux vulnérabilités permettent à un attaquant d’usurper un contrôleur de domaine : CVE-2021-42278 usurpe le compte d’ordinateur sAMAccountName et CVE-2021-42287 utilise la confusion au niveau du PAC Kerberos (Privileged Attribute Certificate). Les administrateurs doivent s’assurer qu’ils ont bien appliqué KB5008102 de Microsoft pour CVE-2021-42278 et KB5008380 de Microsoft pour CVE-2021-42287 sur tous leurs contrôleurs de domaine.
L’expert en sécurité Charlie Clark a largement expliqué comment utiliser de manière malveillante ces vulnérabilités. En termes simples, la chaîne d’attaque commence par la création d’un nouveau compte d’ordinateur dans le domaine AD, suivie par la modification de ce compte en le renommant afin de faire apparaître le nom d’un contrôleur de domaine existant, mais sans le « $ » final. Ensuite, une demande Kerberos TGT est envoyée en utilisant ce nouveau nom d’ordinateur suivie du changement de nom du compte d’ordinateur créé avec une valeur arbitraire. Enfin, la chaîne se termine en demandant un ticket Kerberos S4U2self via le TGT récupéré. Si chaque étape réussit, l’attaquant obtiendra un ticket de service pour un contrôleur de domaine. L’attaquant obtient ce ticket car lorsque nous demandons un ticket S4U2self en utilisant le TGT d’un compte qui n’existe pas (puisque nous l’avons renommé), le KDC effectue automatiquement une nouvelle recherche en ajoutant un « $ » à la fin. Les PoC en python et EXE sont maintenant disponibles après la divulgation de Clark et même les novices en matière de scripts (script-kiddies) pourront facilement compromettre l’ensemble du domaine AD en utilisant ces derniers.
Les administrateurs doivent retenir que pour que la chaîne d’attaque démarre, un utilisateur non privilégié doit pouvoir ajouter un ordinateur à un domaine existant. Par défaut, AD permet aux utilisateurs de domaine standard d’ajouter jusqu’à 10 ordinateurs à un domaine AD via l’attribut MS-DS-Machine-Account-Quota. Nous conseillons aux administrateurs de modifier la valeur de l’attribut en la mettant à zéro au niveau de tous leurs domaines.
Les clients LogPoint peuvent utiliser notre package UseCases v5.1.1 qui contient des analyses concernant les vulnérabilités d’élévation de privilèges AD.
Détection des élévations de privilèges AD (Active Directory) à l’aide de LogPoint
Pour détecter les élévations de privilèges AD, les clients LogPoint doivent disposer de sources de log AD Domain Services. Comme décrit ci-dessus, la chaîne d’attaque se compose de plusieurs étapes, signifiant ainsi que plusieurs logs d’événements seront générés au fur et à mesure de la progression de l’attaque. Les analystes en sécurité peuvent utiliser les logs d’événements générés pour créer des détections de haute-fidélité. Nous pouvons rechercher la création d’un nouveau compte d’ordinateur (EID 4741) suivie d’un changement du nom de ce dernier (EID 4781) avec une nouvelle valeur qui n’a pas de « $ » à la fin.
[label=Computer label=Account label=Create] as s1
followed by
[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s2
within 5 second
on s1.computer=s2.target_user
| rename s1.computer as computer, s1.user as user, s2.new_user as new_computer_name
| chart count() by user, computer, new_computer_name
Recherche de la création de compte suivie d’une opération de changement de nom en utilisant une nouvelle valeur qui n’a pas de « $ » à la fin
Ensuite, nous pouvons rechercher le changement de nom d’un compte pour supprimer le « $ » final suivi d’une demande TGT Kerberos (EID 4768) utilisant ce compte renommé.
[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s1
followed by
[norm_id=WinServer event_id=4768 -user="*$"] as s2
within 5 second on s1.new_user=s2.user
| rename s1.target_user as old_computer_name, s1.new_user as
new_computer_name, s1.user as user, s2.source_address as source_address
| chart count() by user, old_computer_name, new_computer_name, source_address
Recherche d’un changement de nom de compte suivi d’une demande Kerberos TGT à l’aide d’un compte renommé
Alternativement, nous pouvons rechercher des demandes de ticket de service Kerberos suspectes (dans ce cas, S4U2self) qui spécifient un contrôleur de domaine dans les champs de service et d’utilisateur n’incluant pas le « $ » final.
norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$
| process compare(user, dc) as result
| search result=true
| chart count() by log_ts, user, dc, service, source_address
Recherche de demandes de ticket de service Kerberos suspectes
Pour trouver l’utilisateur dont l’identité a été usurpée dans la demande S4U2self, nous pouvons rechercher la demande de ticket de service Kerberos suspecte susmentionnée, suivie d’une connexion utilisateur à partir de la même adresse IP qui a effectué la demande de ticket de service suspect.
[norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$
| process compare(user, dc) as result
| search result=true] as s1 followed by
[norm_id=WinServer event_id=4624] as s2
within 5 second on s1.host=s2.host and s1.source_address=s2.source_address
| rename s1.log_ts as log_ts, s2.log_ts as login_ts, s1.host as host, s1.user as user,
s1.service as service, s1.dc as dc, s2.user as impersonated_user, s2.source_address as source_address
| chart count() by log_ts, login_ts, user, service, dc, impersonated_user, source_address
Recherche d’un compte usurpé
Le PoC python a une option pour ouvrir directement un shell après une exploitation réussie, ce que nous pouvons voir dans l’événement d’installation du nouveau service. Nous pouvons noter que le service a été créé par l’utilisateur usurpé.
label=Service label=Install path="%COMSPEC%*\\127.0.0.1\C$\*"
| chart count() by user, file, service, path
Recherche de chemins suspects dans les nouvelles installations de service
Les attaquants, après avoir obtenu le ticket de service d’un contrôleur de domaine (DC), peuvent facilement utiliser la technique DCSync pour récupérer les hachages de mot de passe de ce DC. Les clients LogPoint peuvent utiliser les alertes fournies avec le package Alert Rules pour détecter les attaques couramment utilisées par les attaquants.
Recherche d’artefacts d’une attaque DCSync
Investigation de l’activité post-compromission à l’aide de LogPoint SOAR
Les administrateurs peuvent utiliser LogPoint SOAR pour créer des playbooks qui effectuent des investigations liées à l’activité post-compromission des attaquants.
Certaines étapes importantes de l’investigation comprennent la vérification :
- De la création de nouveaux utilisateurs pour la persistance.
- De la trace de tous les shells SYSTEM sur le contrôleur de domaine affecté.
- SDes installations de service suspectes.
- De la récupération des identifiants par mimikatz.
- D’une attaque DCSync.
Playbook LogPoint SOAR pour investiguer l’activité post-compromission après l’élévation des privilèges AD
Après avoir exécuté le playbook dans LogPoint SOAR, nous pouvons afficher les cas créés par les composants de ce dernier dans la chronologie de l’investigation pour obtenir un aperçu de haut niveau des résultats de cette dernière.
La chronologie de l’investigation LogPoint SOAR rassemble les résultats de celle-ci
Remédiation de l’élévation des privilèges AD (Active Directory)
Si les attaquants ont réussi à compromettre l’ensemble du domaine, les administrateurs doivent nettoyer et reconstruire l’intégralité de leur Active Directory à partir de zéro. Il s’agit d’une tâche compliquée et manuelle qui ne peut normalement pas être complètement automatisée. Pour reconstruire AD, les administrateurs peuvent implémenter les étapes de remédiation suivantes :
- Création de nouveaux identifiants pour tous les comptes.
- Lancement des procédures de réinitialisation du mot de passe du compte KRBTGT.
- Vérification des modifications apportées à la stratégie de groupe (GPO) et aux scripts d’ouverture de session.
- Déploiement et promotion de nouveaux serveurs au niveau des contrôleurs de domaine et y déplacer les rôles FSMO afin que les anciens contrôleurs de domaine puissent être mis hors service.
Les administrateurs doivent faire attention aux vulnérabilités d’élévation de privilèges, car les acteurs malveillants peuvent facilement les utiliser pour minimiser le temps de déploiement de leurs ransomwares. Nous conseillons aux défenseurs de tester le PoC dans un environnement de laboratoire qui a la même configuration que leur environnement de production. Les défenseurs peuvent tester et ajuster leurs détections et s’assurer que les exigences des sources de log en matière de détection soient satisfaites plutôt que d’utiliser cette dernière aveuglément.
