Cześć! Publikuję ten artykuł by wyjaśnić zabezpieczenia wbudowanych strażników w nowoczesnych systemach rodziny Windows. Celem będzie udostępnienie narzędzia do zatrzymywania i uruchamiania Windows Defender na żądanie wraz z powiązanymi usługami. Nie chodzi o wyłączenie! W nowoczesnych systemach jak Windows 11/10 klasyczne metody zatrzymywania np. przez komendę „net stop WinDefend” czy nawet za pomocą powershell już nie działają. Strażnik ten stał się oczkiem w głowie firmy Microsoft. Włącza się jak niechciana Hydra lernejska. Ostrożność – matką porcelany, ale bez przesady! Otóż pisząc konsolowy soft do podniesienia uprawnień z poziomu wbudowanego administratora do TrustedInstallera o nazwie „cmdt.exe” ów defender wyciął mi skompilowaną wersję binarną. Tego już było za wiele do dzieła!
W załączniku udostępniam wersję skompilowaną x86 i x 64 z hasłem "IRFZ44N" W wersji spakowanej z plikami: StopDefender.exe oraz StopDefenderGui.exe (graficzna nakładka), oraz drugie narzędzie, które nie jest potrzebne do zatrzymywania defendera, ale posłużyło jako inspiracja do jego napisania: cmdt.zip (i cmdt_signed.zip). StopDefender jest całkowicie darmowy i otwarty. Narzędzie podnoszące uprawnienie do maksymalnych będzie działać do końca tego roku. W związku, iż napisałem go komercyjnie dla firmy zajmującej się wdrożeniami nie mogę wypuścić wersji publicznej, ale jeżeli ktokolwiek z tego forum poprosi to udostępnię prywatną kompilację na podany numer seryjny komputera by go nie rozpowszechniać. W tym celu można śmiało pisać podając swój S/N z poziomu cmd/powershell – polecenie „wmic bios get serialnumber” lub korzystając z załączonego 2kB sn.exe (sn.zip). Kompilacje prywatne robiłbym co 2 tygodnie. Takich narzędzi trochę jest, jedne działają inne mniej np. psexec z pstools nie dostaje praw TI, ale Nirsoftu czy Nsudo już tak, choć nie przechwytuje wszystkich tokenów jak u mnie. (Sprawdziłem to drogą reverse engineering)
Przejdźmy jednak do zatrzymywania Defendera. Nagrałem w tym celu film: https://youtu.be/6WqiULYbrh8
I nie chodzi w nim o oglądanie, gdyż niemal każdy forumowicz jest zaawansowanym użytkownikiem/ ekspertem, a o przeczytanie opisu i sprawdzenia choćby sum kontrolnych plików, wykluczeń i fałszywych alarmów o zagrożeniach.
To teraz jak już wszystko mamy i wszystko wiecie – trochę teorii:
Wbudowany domyślnie w systemy operacyjne Microsoft - Windows Defender, jak się zapewne ze mną zgodzicie mocno się poprawił, jeżeli chodzi o manipulację tj. zatrzymywanie czy nawet dłuższe wyłączenia. Niestety jako dodatkowa warstwa abstrakcji strasznie spowalnia mi kompilacje większych projektów, wycina niektóre „pseudo-hackerskie”, a przy operacji kopiowania dużej ilości małych plików nagłówkowych *.h na NVME/USB-C nie znoszę go. Czas kopiowania rośnie nawet 3 krotnie. Brakowało mi narzędzia do zatrzymywania usługi wraz z dowiązaniami, ale teraz już ją mam
Głównym składnikiem programu Windows Defender jest usługa „WinDefend”, odpowiedzialna za uruchamianie procesu ciągłego monitorowania „MsMpEng.exe” i ładowanie jego silnika „mpengine.dll”, dlatego jeśli jesteśmy w stanie zatrzymać tę usługę, dzierżymy władzę nad systemem.
Co prawda można go wyłączyć, choć nie można zatrzymać (usługa nadal działa) poprzez interfejs graficzny, ale ta opcja nas nie interesuje, jest niewygodna i nadal pożera zasoby
Wersja z zatrzymywaniem jet OK. teoretycznie zablokowana, ale…
Aby zrozumieć „wnętrze” akcji, którą zamierzamy przeprowadzić, musimy jasno określić dwie koncepcje: czym jest Token i czym jest TrustedInstaller (TI). Token w systemie operacyjnym Microsoft Windows jest elementem bezpieczeństwa, który zapewnia identyfikację procesów i wątków, gdy chcą one wykonać działania na sekuryzowalnych obiektach systemu (plikach, rekordach, usługach, kluczach rejestru..). Innymi słowy, to jak pokazanie paszportu, gdy chcesz wlecieć do innych krajów
Przechowuje między innymi: poziom integralności, użytkownika, do którego należy proces, uprawnienia oraz grupy. Nie będziemy wchodzić w szczegóły, ponieważ dla nas liczy się właśnie to drugie, czyli grupy, do których należy proces/wątek przedstawiający ten token bezpieczeństwa.
Zauważcie, że dany proces lub wątek, jeżeli tylko zdobędzie odpowiednie uprawnienia, może podszywać się pod innego użytkownika. Dlatego nasza aplikacja może kopiować i/lub używać tokena innego wątku/procesu, o ile mamy uprawnienia do otwarcia interesującego nas procesu i uzyskania jego obsługi Tokena z odpowiednimi uprawnieniami (Impersonate / DuplicateToken) .
Teraz, gdy wiemy, czym jest token i co możemy z nim zrobić, weźmy pod lupę, TrustedInstaller.
Może próbowaliście usunąć plik z systemu np. z WinSxS i nie byliście w stanie tego zrobić?, nawet będąc SYSTEMEM czy Administratorem. Właściciel pliku (TrustedInstaller) zwrócił waszą uwagę😊. Cóż, TrustedInstaller to fikcyjna grupa utworzona przez SCM (Service Control Manager) podczas uruchamiania komputera, tworząca tak zwaną „Grupę usług”. A propos - Narzędzie cmdt pozwala ominąć te ograniczenia.
Oznacza to, że każda usługa będąca częścią nowoczesnego systemu operacyjnego Windows ma fikcyjną grupę pasującą do jej nazwy. Ta funkcja jest przydatna, aby zapewnić dostęp do wszystkich obiektów podlegających sekuryzacji (plików, potoków, rekordów, tokenów, kluczy rejestru) systemu, z których może korzystać proces usługowy, zmniejszając w ten sposób narzut związany ze sprawdzaniem tokena pod kątem wszystkich list DACL . obiektów
TrustedInstaller to nie tylko grupa, ale także usługa, którą możemy znaleźć na liście usług na komputerze jako taką, zwykle zatrzymaną, ponieważ uruchamia się warunkowo, gdy wymaga tego „Windows Update” – wdrażanie aktualizacji.
Moi drodzy - ten proces i ta grupa mają wielką moc, nawet większą niż „SYSTEM” w systemie. Jesteście oczywiście taką „mocą” zainteresowani. Jako ciekawostkę, jeśli chcemy odróżnić rzeczywiste grupy/użytkowników od tych fikcyjnych utworzonych przez SCM, musicie spojrzeć na „Domenę”, która jest prefiksem, pojawiającym się przed użytkownikiem/grupą.
Zwykle te prawdziwe poprzedzone są przedrostkiem "NT AUTHORITY", natomiast syntetyk serwisowy - "NT SERVICE". Jedyną tożsamością bezpieczeństwa zdolną do zatrzymania usługi Antivirus (Full control) jest ona sama oraz usługa TrustedInstaller. Ma to sens, ponieważ aby się zaktualizować, TrustedInstaller.exe musi być w stanie zatrzymać antywirusa i skopiować nowe pliki. Zauważ, że nie jest w stanie tego zrobić nawet Administrator ani grupa SYSTEM.
Jako pierwsze podejście do naszego celu moglibyśmy pomyśleć o pożyczeniu tokenu od samego "MsMpEng.exe" i podszyciu się pod niego, ponieważ prezentuje on grupę "NT SERVICE/WinDefend", ale nie jest to możliwe, ponieważ proces ten jest procesem typu PPL (Protected Process Light) i dlatego nie będziemy w stanie uzyskać uchwytu procesu, który pozwoli nam ostatecznie odczytać jego token, nawet z uprawnieniami debugowania (SeDebugPrivilege).
Wiemy już zatem, że tylko jeśli uzyskamy token z zawartą w nim grupą TI, będziemy w stanie zatrzymać usługę WinDefend. Naszym kolejnym celem jest zatem usługa TI.
Najpierw uruchomimy usługę, będąc administratorami i skontrolujemy uprawnienia otwierające proces. Aby uzyskać dostęp do tokena wystarczy dostęp na poziomie otwarcia procesu zawierającego PROCESS_QUERY_INFORMATION, PROCESS_QUERY_LIMITED_INFORMATION lub PROCESS_ALL_ACCESS (Pełna kontrola).
Warto również zauważyć, że proces ten nie jest chroniony za pomocą PPL, co pozwoliłoby nam, a priori, na jego otwarcie. Jak to możliwe, że Microsoft nie chroni tak ważnego procesu w systemie? Przecież to jest cecha, a nie błąd!
Wymagamy użycia przywileju SeDebugPrivilege, ponieważ poziom integralności procesu TI to SYSTEM, a poziom integralności naszej aplikacji to High, więc jest poniżej. Pamiętajmy, że aby sprawdzić czy dany obiekt może uzyskać dostęp do innego, najpierw sprawdzamy Mandatory Integrity Control, a następnie Discretionary access control, w tym przypadku spełniamy drugi, ale nie pierwszy. SeDebugPrivilege pozwala nam pominąć obie, ale tylko dla OpenProcess.
Sprawdźmy teraz uprawnienia tokena podstawowego tokena procesu TI, ponieważ aby go użyć i podszyć się pod niego, musi on nam na to pozwolić za pomocą uprawnienia IMPERSONATE dla naszego użytkownika.
Jako Administratorzy widzimy, że to nie wystarczy, więc nie będziemy mogli odczytać i podszyć się pod token TrustedInstaller. Będziemy mogli to zrobić tylko wtedy, gdy jesteśmy SYSTEMEM, więc będziemy musieli wykonać krok pośredni i eskalować uprawnienia z Admina na SYSTEM.
Najprostszym sposobem na eskalację uprawnień z Admina na SYSTEM jest podszycie się pod token SYSTEM z już działającego procesu. Jednym z najlepszych kandydatów jest Winlogon.exe, ponieważ działa w tej samej sesji co użytkownik, a także ma luźniejsze ACL w tym zakresie (Administrator może otworzyć swój token w trybie IMPERSONATE).
Zostanie wyważenie ostatnich drzwi, które prowadzą nas do sposobu by zatrzymać Defendera 😊
Gotowy program w załączniku, a kod źródłowy „silnika” niżej:
W załączniku udostępniam wersję skompilowaną x86 i x 64 z hasłem "IRFZ44N" W wersji spakowanej z plikami: StopDefender.exe oraz StopDefenderGui.exe (graficzna nakładka), oraz drugie narzędzie, które nie jest potrzebne do zatrzymywania defendera, ale posłużyło jako inspiracja do jego napisania: cmdt.zip (i cmdt_signed.zip). StopDefender jest całkowicie darmowy i otwarty. Narzędzie podnoszące uprawnienie do maksymalnych będzie działać do końca tego roku. W związku, iż napisałem go komercyjnie dla firmy zajmującej się wdrożeniami nie mogę wypuścić wersji publicznej, ale jeżeli ktokolwiek z tego forum poprosi to udostępnię prywatną kompilację na podany numer seryjny komputera by go nie rozpowszechniać. W tym celu można śmiało pisać podając swój S/N z poziomu cmd/powershell – polecenie „wmic bios get serialnumber” lub korzystając z załączonego 2kB sn.exe (sn.zip). Kompilacje prywatne robiłbym co 2 tygodnie. Takich narzędzi trochę jest, jedne działają inne mniej np. psexec z pstools nie dostaje praw TI, ale Nirsoftu czy Nsudo już tak, choć nie przechwytuje wszystkich tokenów jak u mnie. (Sprawdziłem to drogą reverse engineering)
Przejdźmy jednak do zatrzymywania Defendera. Nagrałem w tym celu film: https://youtu.be/6WqiULYbrh8
I nie chodzi w nim o oglądanie, gdyż niemal każdy forumowicz jest zaawansowanym użytkownikiem/ ekspertem, a o przeczytanie opisu i sprawdzenia choćby sum kontrolnych plików, wykluczeń i fałszywych alarmów o zagrożeniach.
To teraz jak już wszystko mamy i wszystko wiecie – trochę teorii:
Wbudowany domyślnie w systemy operacyjne Microsoft - Windows Defender, jak się zapewne ze mną zgodzicie mocno się poprawił, jeżeli chodzi o manipulację tj. zatrzymywanie czy nawet dłuższe wyłączenia. Niestety jako dodatkowa warstwa abstrakcji strasznie spowalnia mi kompilacje większych projektów, wycina niektóre „pseudo-hackerskie”, a przy operacji kopiowania dużej ilości małych plików nagłówkowych *.h na NVME/USB-C nie znoszę go. Czas kopiowania rośnie nawet 3 krotnie. Brakowało mi narzędzia do zatrzymywania usługi wraz z dowiązaniami, ale teraz już ją mam
Głównym składnikiem programu Windows Defender jest usługa „WinDefend”, odpowiedzialna za uruchamianie procesu ciągłego monitorowania „MsMpEng.exe” i ładowanie jego silnika „mpengine.dll”, dlatego jeśli jesteśmy w stanie zatrzymać tę usługę, dzierżymy władzę nad systemem.
Co prawda można go wyłączyć, choć nie można zatrzymać (usługa nadal działa) poprzez interfejs graficzny, ale ta opcja nas nie interesuje, jest niewygodna i nadal pożera zasoby
Wersja z zatrzymywaniem jet OK. teoretycznie zablokowana, ale…
Aby zrozumieć „wnętrze” akcji, którą zamierzamy przeprowadzić, musimy jasno określić dwie koncepcje: czym jest Token i czym jest TrustedInstaller (TI). Token w systemie operacyjnym Microsoft Windows jest elementem bezpieczeństwa, który zapewnia identyfikację procesów i wątków, gdy chcą one wykonać działania na sekuryzowalnych obiektach systemu (plikach, rekordach, usługach, kluczach rejestru..). Innymi słowy, to jak pokazanie paszportu, gdy chcesz wlecieć do innych krajów
Przechowuje między innymi: poziom integralności, użytkownika, do którego należy proces, uprawnienia oraz grupy. Nie będziemy wchodzić w szczegóły, ponieważ dla nas liczy się właśnie to drugie, czyli grupy, do których należy proces/wątek przedstawiający ten token bezpieczeństwa.
Zauważcie, że dany proces lub wątek, jeżeli tylko zdobędzie odpowiednie uprawnienia, może podszywać się pod innego użytkownika. Dlatego nasza aplikacja może kopiować i/lub używać tokena innego wątku/procesu, o ile mamy uprawnienia do otwarcia interesującego nas procesu i uzyskania jego obsługi Tokena z odpowiednimi uprawnieniami (Impersonate / DuplicateToken) .
Teraz, gdy wiemy, czym jest token i co możemy z nim zrobić, weźmy pod lupę, TrustedInstaller.
Może próbowaliście usunąć plik z systemu np. z WinSxS i nie byliście w stanie tego zrobić?, nawet będąc SYSTEMEM czy Administratorem. Właściciel pliku (TrustedInstaller) zwrócił waszą uwagę😊. Cóż, TrustedInstaller to fikcyjna grupa utworzona przez SCM (Service Control Manager) podczas uruchamiania komputera, tworząca tak zwaną „Grupę usług”. A propos - Narzędzie cmdt pozwala ominąć te ograniczenia.
Oznacza to, że każda usługa będąca częścią nowoczesnego systemu operacyjnego Windows ma fikcyjną grupę pasującą do jej nazwy. Ta funkcja jest przydatna, aby zapewnić dostęp do wszystkich obiektów podlegających sekuryzacji (plików, potoków, rekordów, tokenów, kluczy rejestru) systemu, z których może korzystać proces usługowy, zmniejszając w ten sposób narzut związany ze sprawdzaniem tokena pod kątem wszystkich list DACL . obiektów
TrustedInstaller to nie tylko grupa, ale także usługa, którą możemy znaleźć na liście usług na komputerze jako taką, zwykle zatrzymaną, ponieważ uruchamia się warunkowo, gdy wymaga tego „Windows Update” – wdrażanie aktualizacji.
Moi drodzy - ten proces i ta grupa mają wielką moc, nawet większą niż „SYSTEM” w systemie. Jesteście oczywiście taką „mocą” zainteresowani. Jako ciekawostkę, jeśli chcemy odróżnić rzeczywiste grupy/użytkowników od tych fikcyjnych utworzonych przez SCM, musicie spojrzeć na „Domenę”, która jest prefiksem, pojawiającym się przed użytkownikiem/grupą.
Zwykle te prawdziwe poprzedzone są przedrostkiem "NT AUTHORITY", natomiast syntetyk serwisowy - "NT SERVICE". Jedyną tożsamością bezpieczeństwa zdolną do zatrzymania usługi Antivirus (Full control) jest ona sama oraz usługa TrustedInstaller. Ma to sens, ponieważ aby się zaktualizować, TrustedInstaller.exe musi być w stanie zatrzymać antywirusa i skopiować nowe pliki. Zauważ, że nie jest w stanie tego zrobić nawet Administrator ani grupa SYSTEM.
Jako pierwsze podejście do naszego celu moglibyśmy pomyśleć o pożyczeniu tokenu od samego "MsMpEng.exe" i podszyciu się pod niego, ponieważ prezentuje on grupę "NT SERVICE/WinDefend", ale nie jest to możliwe, ponieważ proces ten jest procesem typu PPL (Protected Process Light) i dlatego nie będziemy w stanie uzyskać uchwytu procesu, który pozwoli nam ostatecznie odczytać jego token, nawet z uprawnieniami debugowania (SeDebugPrivilege).
Wiemy już zatem, że tylko jeśli uzyskamy token z zawartą w nim grupą TI, będziemy w stanie zatrzymać usługę WinDefend. Naszym kolejnym celem jest zatem usługa TI.
Najpierw uruchomimy usługę, będąc administratorami i skontrolujemy uprawnienia otwierające proces. Aby uzyskać dostęp do tokena wystarczy dostęp na poziomie otwarcia procesu zawierającego PROCESS_QUERY_INFORMATION, PROCESS_QUERY_LIMITED_INFORMATION lub PROCESS_ALL_ACCESS (Pełna kontrola).
Warto również zauważyć, że proces ten nie jest chroniony za pomocą PPL, co pozwoliłoby nam, a priori, na jego otwarcie. Jak to możliwe, że Microsoft nie chroni tak ważnego procesu w systemie? Przecież to jest cecha, a nie błąd!
Wymagamy użycia przywileju SeDebugPrivilege, ponieważ poziom integralności procesu TI to SYSTEM, a poziom integralności naszej aplikacji to High, więc jest poniżej. Pamiętajmy, że aby sprawdzić czy dany obiekt może uzyskać dostęp do innego, najpierw sprawdzamy Mandatory Integrity Control, a następnie Discretionary access control, w tym przypadku spełniamy drugi, ale nie pierwszy. SeDebugPrivilege pozwala nam pominąć obie, ale tylko dla OpenProcess.
Sprawdźmy teraz uprawnienia tokena podstawowego tokena procesu TI, ponieważ aby go użyć i podszyć się pod niego, musi on nam na to pozwolić za pomocą uprawnienia IMPERSONATE dla naszego użytkownika.
Jako Administratorzy widzimy, że to nie wystarczy, więc nie będziemy mogli odczytać i podszyć się pod token TrustedInstaller. Będziemy mogli to zrobić tylko wtedy, gdy jesteśmy SYSTEMEM, więc będziemy musieli wykonać krok pośredni i eskalować uprawnienia z Admina na SYSTEM.
Najprostszym sposobem na eskalację uprawnień z Admina na SYSTEM jest podszycie się pod token SYSTEM z już działającego procesu. Jednym z najlepszych kandydatów jest Winlogon.exe, ponieważ działa w tej samej sesji co użytkownik, a także ma luźniejsze ACL w tym zakresie (Administrator może otworzyć swój token w trybie IMPERSONATE).
Zostanie wyważenie ostatnich drzwi, które prowadzą nas do sposobu by zatrzymać Defendera 😊
Gotowy program w załączniku, a kod źródłowy „silnika” niżej:
Code: c
Log in, to see the code
Cool? Ranking DIY
