AdminSDHolder jest jedną z metod planu “KILLCHAIN” w środowisku Microsoft umożliwiającą utworzenie w domenie tylnej furtki (ang.backdoor), dzięki której atakujący może posiąść stały dostęp do najbardziej wrażliwych obiektów, a tym samym posiadać kontrolę nad całym środowiskiem Active Directory. Ta metoda jest o tyle ciekawa, gdyż jest bardzo trudno wykrywalna w AD i wymaga głębokiej wiedzy administracyjnej oraz znajomości mechanizmów kontroli pozwalających wychwycić takie incydenty. Najczęściej obiekt AdminSDHolder pozostaje niewidoczny i niekontrolowany w wielu organizacjach. Backdoor może być założony na zwykłe konto użytkownika, któremu przypiszemy niskopoziomowe uprawnienia do odpowiednich obiektów bez konieczności przypisywania uprawnień na zasadzie członkostwa w grupach administracyjnych. Jak działa ta metoda, o tym poniżej.
Gdy atakujący uzyska już poświadczenia kont uprzywilejowanych w domenie Active Directory, wykorzystując różnego rodzaju exploit’y, czy kampanie phishingowe, chce za wszelką cenę nie utracić tej przewagi. Sprawca ataku doprowadza wtedy do sytuacji, że nawet jeśli konta, które zostały skompromitowane zostaną usunięte, wyłączone lub zostanie zresetowane im hasło, prawa administratora domeny będzie się dało odzyskać w łatwy sposób. Można to zrobić wykorzystując wewnętrzne mechanizmy Active Directory, takie jak: AdminSDHolder oraz SDProp. Dobra znajomość tych mechanizmów pozwoli atakującemu na stworzenie backdoor’a w Active Directory umożliwiającego ciągły dostęp do kont uprzywilejowanych, w tym także grup.
Omówmy najpierw pierwszy z nich. AdminSDHolder jest to obiekt typu kontener istniejący w każdej domenie Active Directory od Windowsa 2000 i posiadający specjalne zadanie. Lista kontroli dostępu (ACL) obiektu AdminSDHolder służy jako szablon do kopiowania uprawnień do wszystkich “grup chronionych” w AD oraz ich członków. Grupy chronione obejmują uprzywilejowane grupy wbudowane, takie jak: Administrators, Domain Admins, Schema Admins, Enterprise Admins i inne grupy posiadające prawa logowania do kontrolerów domeny. Usługa Active Directory pobiera listę ACL obiektu AdminSDHolder i okresowo propaguje ją do wszystkich chronionych użytkowników i grup, aby upewnić się, że dostęp do tych obiektów jest niezmienny i bezpieczny. W teorii mechanizm ten działa i spełnia swoje zadanie, ponieważ lista ACL dla obiektu AdminSDHolder jest bardzo restrykcyjna i granularnie przydziela uprawnienia dla wrażliwych grup. Jednak, jeśli atakujący może manipulować tą listą, wówczas uprawnienia te zostaną automatycznie przydzielone do wszystkich chronionych obiektów, a tym samym umożliwi to atakującemu zarządzanie najważniejszymi zasobami w domenie.
W momencie utworzenia takiego backdoor’a atakujący przy użyciu specjalistycznych narzędzi takich jak Mimikatz lub niskopoziomowych komend AD może przejmować uprawnienia administracyjne dodając się do uprzywilejowanych grup, czy nawet przejmować niezauważalnie konta administratorów domeny.
Poniższy przykład pokazuje dodanie nowego użytkownika (hacker) do listy ACL kontenera AdminSDHolder z uprawnieniami Full Control:
Mechanizm kopiowania uprawnień z ACL realizuje proces SDProp. Dzięki niemu uprawnienia z listy AdminSDHolder są co 60 minut propagowane do wszystkich chronionych obiektów – głównie grup uprzywilejowanych. Czas ten jest wartością domyślną i może być modyfikowany w rejestrze. Oznacza to, że jeśli administrator zauważy nieodpowiednie uprawnienia do chronionego obiektu i usunie je, to w ciągu godziny uprawnienia te zostaną automatycznie przywrócone przez SDProp. Ustawienie to jest domyślne w każdej domenie Active Directory i może powodować frustrację, gdy administrator nie rozumie tego mechanizmu.
Jak się chronić?
Aby skutecznie zapobiegać tego typu działaniom, należy pamiętać, że tylko użytkownicy z prawami administratora będą mogli modyfikować uprawnienia AdminSDHolder. Ochrona poświadczeń kont administracyjnych jest więc najlepszym sposobem prewencji. Jeśli jednak atakującemu udało się już skompromitować uprzywilejowane konto, to niezbędne jest wtedy monitorowanie zmian na obiekcie AdminSDHolder. Zmiany te nigdy nie powinny wystąpić, więc każdy alert wart jest natychmiastowej reakcji.
Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.