Monitorowanie wprowadzanych komend do wiersza linii poleceń (CMD) lub PowerShell) jest jednym z ciekawszych aspektów bezpieczeństwa IT. Pozwala kontrolować administratorów, ale także każdego użytkownika pracującego na systemie Windows. Jest też doskonałym źródłem informacji w przypadku monitorowania prób przeprowadzanych ataków na systemy, które w większości wykorzystują powłokę systemową do wprowadzania określonych komend.
Lecz zanim przejdziemy do opisywania możliwości auditingu poleceń najpierw uchylimy rąbka historii.
Tryb MS-DOS
Kto z Was pamięta te czasy, jak wkuwał na pamięć i testował komendy MS-DOS (ang. Microsoft Disk Operating System)? Jeśli je pamiętacie, to na pewno zaliczacie się do grona doświadczonych osób w IT Najbardziej używanymi i zapamiętywanymi wtedy komendami były „dir” „copy”, „mkdir”, czy słynny „format”. Oczywiście było ich o wiele więcej i z pewnością zdobyta wtedy wiedza jest przydatna aż do dziś. A propos komendy format, opublikowaliśmy ostatnio ciekawy artykuł o tym, jak można uruchomić malware za pomocą ukrytego w niej błędu.
Poniżej pokazujemy, jak uruchamiało się tryb MS-DOS w Windows 98.
A tak wyglądał on po uruchomieniu:
Łezka się kręci w oku jak się patrzy na te ekrany, prawda?
Wszystkie wersje systemu Microsoft Windows posiadają interfejs wiersza poleceń (CLI) podobny do systemu MS-DOS. Za jego pomocą możecie uruchomić wiele narzędzi wiersza poleceń DOS i różnych Win32, OS/2 1.x i Posix w tej samej sesji wiersza poleceń, umożliwiając przepływanie między poleceniami. Interfejs użytkownika i ikona były zgodne z natywnym interfejsem MS-DOS aż do Windows 2000.
Consumer Windows (do 3.11, Win9x, WinME) działał jako graficzny interfejs użytkownika (GUI) działający na szczycie MS-DOS. Z Windows 95, 98 i ME zintegrowano część MS-DOS, traktując oba systemy operacyjne jako kompletny pakiet. Wiersz poleceń uzyskiwał dostęp do wiersza poleceń DOS (zwykle command.com) za pośrednictwem modułu Windows (winoldap.mod).
Command Prompt – czyli wiersz linii poleceń
Niestety, wszystko przemija i tak MS-DOS umarł wraz z pojawieniem się na rynku systemu operacyjnego Windows XP. Od tego momentu nowsze systemy operacyjne nie działały w DOS ale posiadały coś co do dzisiaj nazywa się wierszem poleceń i ma podobny wygląd do DOS-u.
Współczesny system Windows posiada dwie powłoki wiersza poleceń: powłokę poleceń (cmd) i PowerShell. Każda powłoka to program, który zapewnia bezpośrednią komunikację między użytkownikiem a systemem operacyjnym lub aplikacją, zapewniając środowisko do automatyzacji operacji informatycznych.
CMD
Powłoka poleceń (w skrócie CMD) była pierwszą powłoką wbudowaną w system Windows, która automatyzowała rutynowe zadania, takie jak zarządzanie kontami użytkowników lub nocne tworzenie kopii zapasowych, za pomocą plików wsadowych (.bat). Host skryptów systemu Windows umożliwia uruchamianie bardziej zaawansowanych skryptów w powłoce poleceń. (np. cscript lub wscript). Za pomocą skryptów można wykonywać operacje wydajniej niż za pomocą interfejsu użytkownika. Skrypty akceptują wszystkie polecenia dostępne w wierszu poleceń.
PowerShell
Zaś PowerShell został zaprojektowany w celu rozszerzenia możliwości powłoki poleceń o uruchamianie poleceń PowerShell zwanych cmdletami. Polecenia cmdlet są podobne do poleceń systemu Windows, ale zapewniają bardziej rozszerzalny język skryptowy. W PowerShell można uruchamiać zarówno polecenia Windows, jak i polecenia cmdlet PowerShell, ale w powłoce poleceń można uruchamiać tylko polecenia systemu Windows, a nie polecenia cmdlet PowerShell.
Monitorowanie powłoki poleceń, a bezpieczeństwo
Wiele ataków na MS Windows wiąże się z użyciem wiersza linii poleceń CMD oraz PowerShell. W szczególności Powershell jest trudny do wykrycia, ponieważ potrafi wykonywać polecenia z pamięci i nie zapisuje niczego na dysku! Pisaliśmy o tym wielokrotnie na Hack’u.
Oczywiście, aby zapobiec złośliwemu atakowi PowerShell, można ograniczyć typy poleceń, które mogą być wykonywane w sesjach PowerShell. Tutaj ograniczenie użycia PowerShell przez zasady grupy, może być częścią rozwiązania.
Poza tym konieczne jest również wyłączenie PowerShell 2.0 Engine (brak funkcji logowania) i włączenie audytu tworzenia procesów w linii poleceń (w tym PowerShell) + logowanie modułu PowerShell i logowanie bloków skryptów. Poniżej pokazujemy, jak to wykonać w środowisku IT.
Włączenie audytu wiersza linii komend
System operacyjny Windows umożliwia skonfigurowanie audytu dotyczącego monitorowania komend wprowadzanych do wiersza linii poleceń. Możemy to zrobić na dwa sposoby:
1) Konfigurując natywny audyt poprzez polisę GPO
2) Wdrażając darmowy moduł SYSMON. O tym jak wdrożyć moduł Sysmon pisaliśmy w osobnym artykule tutaj.
Dzisiaj zajmijmy się jedynie konfiguracją natywnego audyty Microsoft, ponieważ o sysmon pisaliśmy wcześniej.
Załóżmy, że próbujesz chronić wszystkie komputery w zarządzanej domenie. W tym celu musimy włączyć opcje „sukcesu i niepowodzenia dla poniższych zasad (tj.. Tworzenie procesu audytu). Najlepiej do tego stworzyć dedykowaną politykę GPO i przypiąć ja w strukturze Active Directory do OU, w którym chcemy monitorować komendy na określonych komputerach.
W tym celu musimy przejść do edycji GPO i skonfigurować ustawienie:
Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Detailed Tracking > Audit Process Creation
Aby dołączyć informacje wiersza poleceń dla każdego utworzonego procesu, musimy włączyć ustawienie „Uwzględnij wiersz poleceń w zdarzeniach tworzenia procesu” w ustawieniu:
Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events
Należy również włączyć poniższe ustawienie, aby zapewnić, że ustawienia zaawansowanej konfiguracji zasad inspekcji nie zostaną zastąpione przez podstawowe ustawienia zasad inspekcji.
Od tej pory możemy cieszyć się monitorowaniem wpisywanych komend. Aby można było zobaczyć, co jest wpisywane w CMD musimy przejść do logów Security w dzienniku zdarzeń i wyszukać zdarzenia o identyfikatorze 4688. Poniżej zamieszczamy zrzut ekranu ze zdarzenia ID 4688, gdzie widzimy uruchomiona wcześniej na systemie komendę „hostname”
Powyższą opcją możemy także monitorować komendy wpisywane z PowerShell, lecz nie zobaczymy w niej wszystkich wywołań. Na przykład jeśli wpiszemy w PowerShell proste polecenie „$host.version” nie zobaczymy tej komendy w logach.
W tym celu musimy włączyć zaawansowanie audytowanie PowerShell. Lecz zanim to wykonamy napiszemy kilka słów o PowerShell 2.0.
Wyłączenie obsługi PowerShell 2.0
Jak wspomnieliśmy powyżej PowerShell 2.0 nie posiada możliwości logowania operacji w systemie, dlatego warto go wyłączyć. W celu sprawdzenia, czy w systemie używamy PowerShell 2.0 należy wykonać poniższe polecenie (jako Administrator):
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
Jeśli zwrócony wynik to „Enabled”, oznacza to, że PowerShell 2.0 jest technicznie dostępny. Ale ponieważ „Wersja v2.0.50727 .NET Framework” jest zależnością. Bez tej konkretnej wersji .NET Framework oznacza, że nie można użyć aparatu PowerShell 2.0.
Powershell 2.0 wyłączymy następującą komendą:
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Włączanie audytowania PowerShell i rejestrowania bloków skryptów
W przypadku monitorowania Powershell mamy dwie możliwości:
- Rejestrowanie modułów – zdarzenie o identyfikatorze 4103, które pokaże jakie polecenia zostały wykonane przez PowerShell
- Rejestrowanie bloków skryptów – zdarzenie o identyfikatorze 4104). Spowoduje to zarejestrowanie bloków kodu, które są wykonywane przez silnik programu PowerShell.
Powyższe może przynieść wiele korzyści zarówno w przypadku polowania na zagrożenia, jak i kryminalistyki.
W celu włączenia audytowania rejestrowania modułów należy skonfigurować poniższe ustawienie:
Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Module Logging (w oknie Module Names należy podać “*” w celu rejestrowania wszystkich modułów)
W celu włączenia audytowania rejestrowania bloków skryptów należy skonfigurować poniższe ustawienie:
Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging
Uwaga! Włączenie opci “Log script block execution start / stop events” nie jest zalecane, ponieważ potrafi wygenerować bardzo dużo zdarzeń.
Poniżej prezentujemy wynik w logach po wykonaniu poniższej komendy:
Invoke-Command -ScriptBlock { dism.exe /Online /Get-Featureinfo /FeatureName:’MicrosoftWindowsPowerShellv2′ }W logach operacyjnych PowerShell (ID 4104 oraz ID 4103).
