Coraz więcej narzędzi pozwala nam zabierać ze sobą kod, dzięki czemu nie musimy zastanawiać się, jak wprowadzić go do systemu. Evil-WinRM oferuje nam dwa różne sposoby na przenoszenie kodu: pliki binarne, które wykona dla nas, oraz skrypty, które możemy uruchomić lokalnie. Zacznijmy od ponownego uruchomienia narzędzia z dwiema dodatkowymi opcjami: katalogiem plików binarnych i katalogiem skryptów.
Opcja -e określa lokalizację, z której pobierane są pliki binarne. Ten katalog zawiera szereg plików binarnych C#, które zostały zbudowane na maszynie Util, a następnie przeniesione do naszego komputera Kali podczas wdrażania. Flaga -s określa lokalizację katalogu skryptów. Będziemy mogli załadować dowolne skrypty z tego katalogu do Evil-WinRM. Możemy utworzyć własny katalog i umieścić w nim mnóstwo różnych skryptów, ale w tym przykładzie użyjemy tylko modułów PowerSploit Recon, które już istnieją w Kali. Skrypty nie ładują się automatycznie, więc gdy mamy już powłokę, możemy dowiedzieć się, które skrypty są ładowane, wpisując menu:
Widzimy cztery polecenia, które są domyślnie automatycznie uwzględniane w narzędziu. Dll-Loader, Donut-Loader i Invoke-Binary to różne sposoby wykonywania plików binarnych. Bypass-4MSI pomija AMSI (Windows Antimalware Scan Interface). AMSI umożliwia narzędziom zabezpieczającym systemu Windows uzyskanie dodatkowych informacji o programie PowerShell i innych lokalizacjach w celu wykrywania złośliwego oprogramowania w czasie wykonywania, w tym potencjalnie złośliwego kodu programu PowerShell. W przypadku niektórych narzędzi będzie to wymagane, ale w naszym przypadku program Windows Defender został już wyłączony, aby dane wyjściowe były spójne na wszystkich poziomach poprawek. Aby uruchomić skrypt, wpisujemy nazwę skryptu, a następnie możemy ponownie uruchomić menu, aby wyświetlić zaktualizowaną listę narzędzi. Tutaj uruchomimy skrypt PowerView.ps1:
Dane wyjściowe po uruchomieniu tych poleceń będą znacznie dłuższe, a ponieważ nie mamy pełnej sesji w systemie, nie będziemy mogli wykonywać niektórych działań w domenie. Niektóre polecenia wymagają, aby użytkownik miał bilety lub skróty buforowane w sesji. Możemy jednak uruchamiać polecenia lokalnie na maszynie. Spróbujmy pobrać dane użytkownika z AWS dla tego systemu:
Z danych wyjściowych wynika, że osoba, która wdrożyła ten system, skonfigurowała zmianę hasła, gdy urządzenie jest online. W tym przypadku hasło użytkownika Admin to „GrayHatHack1ng!”. Teraz będziemy mogli zalogować się jako użytkownik Administrator, nawet jeśli użytkownik docelowy zmienił hasło. Możemy również spróbować pobrać te dane bezpośrednio z systemu, używając jednego z naszych plików binarnych. Możemy je wywołać za pomocą polecenia cmdlet Invoke-Binary wbudowanego w Evil-WinRM.
Mimo że określiliśmy ścieżkę, w której znajduje się nasz plik binarny, nadal musimy użyć pełnej ścieżki, aby dostać się do pliku binarnego, z którego uruchomiono evil-winrm (w tym przypadku katalog Binaries). To narzędzie zrzuca skróty z pamięci, a my musimy określić jeden argument — host, z którym ma nastąpić połączenie. Gdybyśmy mieli wiele argumentów, rozdzielilibyśmy je w cudzysłowie przecinkami, aby program wiedział, który argument zostanie wywołany. Wynikowy wynik zawiera zarówno skróty z lokalnego systemu, takiego jak użytkownik Administrator, jak i buforowane dane uwierzytelniające w systemie dla użytkownika docelowego. Teraz mamy skróty, których możemy użyć, jeśli zajdzie taka potrzeba dla Administratora, a także hasło Administratora ustawione za pomocą danych użytkownika AWS i buforowany skrót użytkowników w systemie, który moglibyśmy spróbować złamać.