W tym laboratorium przyjrzymy się różnym metodom kodowania i zaciemniania, których można użyć z msfvenom do ukrycia ładunków. W pierwszym przykładzie przyjrzymy się użyciu kodowania do zmiany wyglądu samego ładunku. Aby to zrobić, użyjemy powszechnego kodowania „shikata_ga_nai”, co w języku japońskim z grubsza oznacza „nic nie da się z tym zrobić”. Na początek przyjrzyjmy się niektórym ciągom znaków będącym częścią Meterpretera z naszego początkowego pliku msf1.exe. Te ciągi znaków są częścią funkcji manipulacji tokenami i możemy użyć tej funkcji do śledzenia ukrywania Meterpretera dla przyszłych plików binarnych:
Widzimy nazwy funkcji do otwierania tokenów procesów i wątków oraz dostosowywania uprawnień. Następnie dodajmy trochę kodowania, aby zobaczyć, jak to wygląda:
Określamy dodatkowe opcje -e z typem naszego kodera i -i z liczbą iteracji, które chcemy uruchomić. Widzimy, jak koduje trzy razy i zapisuje plik binarny. Jeśli chcesz użyć innego kodera, kodery msfvenom -l pokażą Ci opcje. Zauważ, że każdy z nich jest poprzedzony platformą typu kodera, a tutaj generujemy pliki binarne x86. Kiedy ponownie uruchomimy naszą komendę strings, nie otrzymamy niczego w zamian, co pokazuje, że tekst w samym ładunku Meterpretera jest zaciemniony:
Dzieje się tak, ponieważ szablony tych plików binarnych są identyczne. Nie jest to optymalne, ponieważ rozmiar jest dobrym wskaźnikiem. Jedną rzeczą, którą możemy zrobić, to wybrać plik binarny systemu Windows, którego moglibyśmy użyć jako szablonu, który byłby inny. Kali ma już w systemie kilka plików binarnych Windows, więc użyjmy pliku binarnego wget.exe jako naszego szablonu:
Błąd wynika z tego, że msfvenom próbuje wstrzyknąć ładunek do sekcji .text pliku binarnego, a jeśli ta sekcja nie istnieje, mamy problem. Rzućmy okiem na sekcje znajdujące się w pliku binarnym dla wget.exe:
Błąd wynika z tego, że msfvenom próbuje wstrzyknąć ładunek do sekcji .text pliku binarnego, a jeśli ta sekcja nie istnieje, mamy problem. Rzućmy okiem na sekcje znajdujące się w pliku binarnym dla wget.exe:
ednym z efektów ubocznych tej techniki jest to, że wget w rzeczywistości nie będzie próbował robić rzeczy, które robiłby normalnie, więc ktoś może nabrać podejrzeń. Możemy użyć flagi -k, aby zachować funkcjonalność w pliku binarnym. Utwórzmy nowy plik binarny z flagą -k:
Działało to z typem exe, ponieważ wstrzykiwał nowy nagłówek sekcji do przechowywania kodu. Przyjrzyjmy się wynikom objdump:
OK, więc teraz, gdy mamy już kilka plików binarnych, uczyńmy je wykonywalnymi i uruchommy msfconsole, aby przechwycić nasze powłoki:
Do naszego polecenia dodaliśmy dwa nowe aspekty. Pierwszym z nich jest ustawienie wartości ExitonSession na false (1) . Typowym zachowaniem jest zaprzestanie słuchania, gdy tylko odzyskamy pierwszą skorupę. W naszym przypadku chcemy przechwycić wiele powłok, aby wypróbować każdy z naszych plików binarnych. Innym zachowaniem, które chcemy naprawić, jest natychmiastowe przejście do sesji po ponownym nawiązaniu połączenia przez powłokę. Aby to zrobić, podajemy opcję -j (2) w poleceniu exploita, aby poinformować Metasploit, że chcemy, aby działał w tle jako zadanie. Teraz, gdy otrzymamy powłoki, zobaczymy komunikat informujący o podłączeniu nowej powłoki, ale nie będziemy musieli od razu z nią wchodzić w interakcję. Wróćmy teraz do naszego okna Windows i uruchommy kilka naszych nowych powłok:
Do naszego polecenia dodaliśmy dwa nowe aspekty. Pierwszym z nich jest ustawienie wartości ExitonSession na false (1) . Typowym zachowaniem jest zaprzestanie słuchania, gdy tylko odzyskamy pierwszą skorupę. W naszym przypadku chcemy przechwycić wiele powłok, aby wypróbować każdy z naszych plików binarnych. Innym zachowaniem, które chcemy naprawić, jest natychmiastowe przejście do sesji po ponownym nawiązaniu połączenia przez powłokę. Aby to zrobić, podajemy opcję -j (2) w poleceniu exploita, aby poinformować Metasploit, że chcemy, aby działał w tle jako zadanie. Teraz, gdy otrzymamy powłoki, zobaczymy komunikat informujący o podłączeniu nowej powłoki, ale nie będziemy musieli od razu z nią wchodzić w interakcję. Wróćmy teraz do naszego okna Windows i uruchommy kilka naszych nowych powłok:
Użyliśmy polecenia session, aby wejść w interakcję z otwartą sesją 2 i w miejscu wpisania exit pojawia się znak zachęty Meterpretera. Wracając do systemu Windows, kontrola powróciła. W naszym systemie Windows spróbujmy uruchomić plik binarny msf4.exe, który używa wget.exe z flagą -k, aby zachować funkcjonalność:
Kiedy po raz pierwszy uruchamiamy plik binarny, wyświetla się komunikat o błędzie wskazujący na konieczność określenia adresu URL. Jest to typowa funkcjonalność wget, ale nie odzyskujemy powłoki, ponieważ plik binarny nigdy nie dotarł do naszego kodu powłoki. Kiedy ponownie spróbujemy użyć adresu URL, zobaczymy, że wget próbuje pobrać plik do naszego udziału SMB, ale nie może zapisać. Na naszej konsoli Metasploit powinniśmy zobaczyć coś takiego:
Sesja natychmiast umarła, ponieważ kiedy plik binarny się zakończył, zabiła także naszą powłokę. Moglibyśmy poprosić o naprawdę dużą stronę, co zajęłoby dużo czasu, ale mamy dodatkowe opcje. W opcjach zaawansowanych (które można wyświetlić dla dowolnego ładunku poprzez –list-options) znajduje się opcja PrependMigrate, która doda migrację do nowego procesu na początku kodu, dzięki czemu nasza powłoka będzie działać dłużej niż sam proces . Zbudujmy jeden z nich i wypróbujmy go:
W naszym systemie Windows po uruchomieniu msf5.exe powinniśmy zobaczyć takie same dane wyjściowe jak msf4.exe, ale w Metasploit widzimy coś innego:
Proces, w którym działa nasz kod powłoki, to nie msf5.exe, ale rundll32.exe. Nasz plik binarny uruchomił nowy proces i wstrzyknął go, pozostawiając sesję nieaktywną, mimo że plik msf5.exe został zakończony. Dzięki tym technikom możemy lepiej ukryć ładunki Metasploit w innych plikach binarnych za pomocą dodatkowego zaciemniania, aby zapobiec ich wykryciu przez silniki antywirusowe oparte na sygnaturach. Mamy jednak więcej opcji niż tylko szablony dla msfvenom. Przyjrzyjmy się alternatywnym strategiom.