Pierwszą rzeczą, którą chcemy sprawdzić, jest to, czy włączony jest moduł AMSI. Będzie to dobry wskaźnik tego, czy możemy używać dodatkowych narzędzi w pamięci bez ich zauważenia. Z poziomu wiersza poleceń programu PowerShell jako nasz użytkownik docelowy wydajemy następujące polecenia:
Pierwszy wiersz używa polecenia cmdlet Get-ChildItem, aby uzyskać dostawców z listy rejestru dostawców AMSI. Zawiera ona listę identyfikatorów klas (CLSID), które zarejestrowały się jako dostawcy AMSI. Kiedy sprawdzamy identyfikatory CLSID w rejestrze CLSID klas, widzimy, że identyfikator CLSID kończący się na 7AFE jest dostawcą dla programu Windows Defender. Poprzez zapytanie o identyfikatory CLSID, które zarejestrowały się jako dostawcy AMSI, możemy stwierdzić, czy cokolwiek korzysta z AMSI. Ponieważ otrzymujemy wynik (w tym przypadku program Windows Defender), oznacza to, że AMSI jest włączone. Następnie sprawdźmy, jakie zasady mogą być wdrożone. Zasady takie jak ScriptBlockLogging, która rejestruje zawartość uruchamianych przez nas poleceń, ModuleLogging, która rejestruje moduły ładowane przez program PowerShell, i TranscriptionLogging, która rejestruje wszystko, co dzieje się w sesji, oraz ciągi wyjściowe do pliku mogą zdradzić naszą obecność. Sprawdzając je, możemy od razu zobaczyć, co jest bezpieczne do uruchomienia, a co wymaga skonfigurowania obejść:
Gdy uruchamiamy polecenie, nie otrzymujemy żadnych informacji zwrotnych. To dobry znak, że nie ma żadnych specjalnych ustawień rejestrowania i że używane są domyślne opcje. Gdyby klucze rejestru istniały w tej lokalizacji, musielibyśmy ustalić, które z nich zostały ustawione, ale najbezpieczniejszą rzeczą do zrobienia w tym momencie byłby atak downgrade przy użyciu programu PowerShell 2.0 lub technika obejścia. Aby ustalić, czy możemy downgrade, sprawdźmy, jakie wersje programu PowerShell są zainstalowane:
Gdy uruchamiamy polecenie, nie otrzymujemy żadnych informacji zwrotnych. To dobry znak, że nie ma żadnych specjalnych ustawień rejestrowania i że używane są domyślne opcje. Gdyby klucze rejestru istniały w tej lokalizacji, musielibyśmy ustalić, które z nich zostały ustawione, ale najbezpieczniejszą rzeczą do zrobienia w tym momencie byłby atak downgrade przy użyciu programu PowerShell 2.0 lub technika obejścia. Aby ustalić, czy możemy downgrade, sprawdźmy, jakie wersje programu PowerShell są zainstalowane:
Widzimy, że jedyną lokalizacją, która ma prawidłowy system.dll do załadowania, co oznacza, że jest to jedyna pełna instalacja, jest v4 frameworka. Oznacza to, że nie możemy obniżyć wersji do 2.0, aby pominąć rejestrowanie. Gdyby rejestrowanie było włączone, musielibyśmy użyć techniki obejścia, aby je wyłączyć. Teraz, gdy wiemy, że dodatkowe rozpoznanie nie wywoła wykrywania opartego na rejestrowaniu, przyjrzyjmy się niektórym podstawowym informacjom o systemie operacyjnym. Aby wyświetlić informacje o samym komputerze, możemy użyć polecenia cmdlet Get-ComputerInfo. Zawiera ono wiele danych, ale najpierw przyjrzyjmy się informacjom o systemie Windows:
Pokazuje nam to, że używamy trybu Windows 2016 Datacenter i jesteśmy zarejestrowani w Amazon EC2. Mamy również datę instalacji systemu i lokalizację katalogu Windows. Daje nam to trochę świadomości sytuacyjnej, ponieważ wiemy, że jesteśmy w chmurze, a nie w lokalizacji lokalnej. Kolejną rzeczą, którą będziemy chcieli sprawdzić, jest to, czy DeviceGuard jest włączony. DeviceGuard to funkcja systemu Windows, która pomaga zapobiegać złośliwemu oprogramowaniu, zapewniając, że tylko znany dobry kod może być uruchamiany w systemie. Oznacza to, że każdy kod, który wykonamy, będzie musiał być binarnymi plikami Living-Off-The-Land (LOLBins). Na szczęście polecenie cmdlet Get-ComputerInfo może nam ponownie pomóc:
Widzimy, że DeviceGuard jest wyłączony, więc jeśli możemy ominąć AV, powinniśmy być w stanie uruchomić binaria nienatywne w systemie. Teraz, gdy mamy pewną świadomość tego, co możemy, a czego nie możemy zrobić, zdobądźmy więcej informacji o Seatbelt.
