Windows Commands Dla Analityków Bezpieczeństwa - Pełny Przewodnik Z Przykładami - Security Bez Tabu

Windows Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami

Komendy Windows jako pierwsza linia analizy incydentu

W codziennej pracy analityka bezpieczeństwa (SOC) umiejętność szybkiego korzystania z wbudowanych poleceń Windows bywa bezcenna. Gdy liczy się czas – na przykład podczas triage incydentu lub szybkiego forensics – dostęp do graficznych narzędzi może być ograniczony, a instalacja dodatkowego oprogramowania niemożliwa.

W takich sytuacjach to właśnie klasyczne komendy Windows oraz PowerShell stają się pierwszą linią obrony analityka Blue Team. Ten przewodnik w praktyczny sposób pokazuje, jak wykorzystać polecenia tekstowe Windows do wykrywania i analizy oznak włamania. Będziemy pracować na realistycznych przykładach z życia analityka SOC – od podejrzanych procesów, przez ruch sieciowy, aż po wpisy rejestru i harmonogram zadań.

Nie będzie tu miejsca na ogólniki. Zamiast tego zobaczysz krok po kroku, jak konkretne polecenia pomagają w realnych scenariuszach: windows servers under attack, podejrzane logowania, czy malware ukrywający się w systemie. Dzięki temu przewodnikowi nawet początkujący analityk bezpieczeństwa nauczy się praktycznych technik blue team i lepiej zrozumie, co dzieje się w głębi systemu operacyjnego.

Dlaczego to ma znaczenie?

Dlaczego znajomość poleceń Windows jest tak istotna dla analityka bezpieczeństwa? Powodów jest kilka:

  • Szybkość reakcji: W sytuacji incydentu liczą się sekundy. Otwieranie ciężkich narzędzi graficznych trwa, podczas gdy wpisanie komendy w CMD lub PowerShell daje natychmiastowy podgląd sytuacji. W krytycznym momencie możliwość błyskawicznego sprawdzenia procesów czy połączeń sieciowych to przewaga, która może zdecydować o powstrzymaniu ataku.
  • Brak dodatkowych wymagań: Wiele organizacji ogranicza instalację nowych aplikacji na serwerach produkcyjnych. Wbudowane komendy Windows działają wszędzie – nawet na zdalnej maszynie poprzez PSRemoting czy sesję SSH. Analityk SOC musi umieć wykorzystać to, co dostępne od ręki.
  • Głębsze zrozumienie systemu: Korzystanie z narzędzi tekstowych uczy, jak Windows „pod spodem” przechowuje informacje o procesach, usługach, logach czy autostarcie. To z kolei przekłada się na lepsze umiejętności forensics – łatwiej zauważysz anomalię, gdy wiesz jak wygląda norma.
  • Dowody i audytowalność: Polecenia generują wyniki, które łatwo zapisać do pliku i dołączyć do dokumentacji incydentu. Czy to lista procesów, czy eksport logu zdarzeń – masz twarde dowody na to, co działo się w systemie w danym momencie.

Krótko mówiąc: wbudowane komendy Windows to podstawa warsztatu analityka bezpieczeństwa. Teraz przejdźmy do konkretnych zastosowań – krok po kroku, z przykładami z realnych incydentów.

Monitorowanie procesów Windows (Tasklist)

Jednym z pierwszych kroków analizy podejrzanego systemu jest przegląd uruchomionych procesów. Tasklist to podstawowe narzędzie wiersza poleceń, które wyświetla listę aktualnie działających procesów na komputerze (lokalnym lub zdalnym). Dla analityka bezpieczeństwa ta lista to punkt wyjścia: szukamy procesów, które nie powinny się tam znaleźć.

Przykład z praktyki: Wyobraź sobie, że system EDR zaalarmował Cię o podejrzanym procesie na stacji roboczej. Logujesz się na hosta i odpalasz wiersz poleceń z uprawnieniami administratora, po czym wykonujesz komendę:

tasklist /v /fo table

Polecenie to wyświetla wszystkie procesy w formie tabeli, z informacjami dodatkowymi (/v – tryb verbose). Widzisz listę kilkudziesięciu procesów – wiele z nich to znane systemowe (svchost.exe, winlogon.exe, itp.). Jednak Twoją uwagę zwraca proces o nazwie svhost.exe (literówka „svhost” zamiast „svchost”) działający pod kontem zwykłego użytkownika. Co więcej, w kolumnie Mem Usage ma całkiem spory przydział pamięci, a w kolumnie Window Title figuruje „N/A” (brak okna). Taki proces to czerwona flaga – wygląda jak próba podszycia się pod legalny proces systemowy.

Jak potwierdzić podejrzenia? Możesz rozszerzyć polecenie, by poznać ścieżkę binarki. Tasklist niestety nie pokazuje bezpośrednio ścieżki pliku EXE, ale jest na to sposób: użyj Windows Management Instrumentation Command-line (WMIC) lub PowerShell. Na przykład, w PowerShell uruchomionym jako Administrator wykonaj:

Get-Process svhost | Select-Object Name, Id, Path

Jeśli proces jest złośliwy, często jego ścieżka zdradza prawdę. Załóżmy, że wynik pokazuje: C:\Users\Public\svhost.exe – plik uruchomiony z folderu Public, a nie z C:\Windows\System32. To niemal pewne, że mamy do czynienia z malware podszywającym się nazwą pod proces systemowy. W takiej sytuacji analityk Blue Team może podjąć decyzję o zakończeniu procesu (np. taskkill /PID <pid> /F) oraz zabezpieczeniu próbki pliku do dalszej analizy.

Tasklist umożliwia także filtrowanie wyników, co bywa pomocne przy setkach procesów. Przykładowo, aby wyświetlić tylko procesy uruchomione przez użytkowników (a pominąć systemowe), można użyć filtra:

tasklist /FI "USERNAME ne NT AUTHORITY\SYSTEM"

Polecenie to wyświetli wszystkie procesy, których właścicielem nie jest SYSTEM. W praktyce często tam kryją się aplikacje użytkownika i potencjalne malware działające z jego uprawnieniami. Innym przydatnym trikiem jest wyszukiwanie po nazwie lub fragmencie ścieżki. Jeśli podejrzewasz, że malware może działać z katalogu Temp, możesz wykonać:

tasklist /FI "IMAGENAME eq svhost.exe" /FI "STATUS eq running"

lub prościej, przekierować listę do findstr:

tasklist | findstr Temp

To ostatnie wypisze tylko te linie z listy procesów, które zawierają słowo „Temp” – czyli potencjalnie procesy uruchomione z katalogu Temp (gdzie często lądują złośliwe pliki). Gdy taki proces znajdziesz, następnym krokiem może być sprawdzenie jego parametrów uruchomienia (np. w rejestrze lub Harmonogramie zadań – o czym za chwilę).

Podsumowując, tasklist to szybki sposób na sprawdzenie “co żyje” w systemie. Dla analityka bezpieczeństwa kluczowe jest wychwycenie elementów odstających od normy: dziwne nazwy, nieznane ścieżki, procesy dzieci bez oczywistego rodzica. W połączeniu z wiedzą o typowych procesach Windows, tasklist daje mocne podstawy do dalszego śledztwa.

PowerShell alternatywa: Pamiętaj, że większość tego typu operacji z powodzeniem wykonasz też w PowerShell. Cmdlet Get-Process wyświetla listę procesów (choć domyślnie bez ścieżek), a Get-WmiObject -Class Win32_Process (lub w nowszych wersjach Get-CimInstance) pozwala pobrać szczegółowe informacje o procesach, w tym pełne ścieżki i parametry uruchomienia. W praktyce, wielu analityków SOC korzysta z mieszanki CMD i PowerShell – wybierając to, co wygodniejsze w danej chwili.

Analiza ruchu sieciowego (netstat)

Drugim filarem szybkiej oceny stanu systemu jest sprawdzenie połączeń sieciowych. Jeżeli nasz podejrzany proces faktycznie jest malware, istnieje duża szansa, że próbuje łączyć się ze światem – np. z serwerem C&C (Command & Control, z którego atakujący zdalnie steruje złośliwym oprogramowaniem). Do wglądu w takie połączenia służy klasyczne polecenie netstat, które wyświetla aktywne połączenia TCP/UDP, porty nasłuchujące i statystyki protokołów.

Najczęściej używane warianty dla analityka bezpieczeństwa to:

  • netstat -ano – pokazuje wszystkie połączenia i porty (-a), adresy w formie numerycznej (-n), oraz dopisuje identyfikatory procesów PID (-o).
  • netstat -bn – pokazuje aktywne połączenia wraz z nazwami uruchomionych plików binarnych (-b) i adresami numerycznie (-n). Uwaga: opcja -b wymaga uprawnień administratora i może działać wolniej.

Przykład z praktyki: Kontynuując scenariusz z poprzedniej sekcji – znaleźliśmy podejrzany proces svhost.exe. Teraz chcemy sprawdzić, czy i dokąd on się łączy. Wykonujemy w CMD polecenie:

netstat -ano | findstr ESTABLISHED

To polecenie wyświetla wszystkie aktywne połączenia TCP w stanie ESTABLISHED (nawiązane). Wśród wyników zauważamy wpis:
TCP 192.168.1.100:50076 185.44.85.202:443 ESTABLISHED 1234

W tej lini znaczenie kolumn jest następujące: lokalny adres z portem, zdalny adres z portem, stan połączenia, PID procesu. Widzimy, że proces o PID 1234 (przykładowo) ma otwarte połączenie do adresu 185.44.85.202 na porcie 443 (HTTPS). Taki obcy adres IP, jeśli nie należy do żadnego znanego serwera firmy, jest podejrzany – możliwe, że to serwer C&C. Sprawdzamy szybko, który proces ma PID 1234:

tasklist /FI "PID eq 1234"

Okazuje się, że to właśnie nasz svhost.exe. Mamy potwierdzenie: podejrzany proces nawiązuje połączenia sieciowe na zewnątrz, w dodatku na standardowy port 443 (szyfrowany ruch, co utrudnia zajrzenie do środka transmisji). Dla analityka bezpieczeństwa to cenny trop – wiemy już co (proces svhost.exe) i dokąd (IP atakującego). Następnym krokiem może być odpytanie Threat Intelligence o ten adres IP (czy był zgłaszany jako złośliwy) oraz zablokowanie go na zaporze, aby przerwać komunikację.

Netstat przydaje się również do wykrywania procesów nasłuchujących na nietypowych portach. Przykładowo, malware mogą otwierać ukryte backdoory nasłuchujące na wysokich portach. Polecenie:

netstat -ano | findstr LISTENING

pokaże wszystkie porty, na których coś nasłuchuje. W większości będą to adres 0.0.0.0 (nasłuch na wszystkich interfejsach) lub 127.0.0.1 (tylko lokalnie) z portami systemowymi (135, 445, itp.) oraz portami usług (np. SQL, RDP 3389, itp.). Jeśli jednak zobaczysz np. proces nasłuchujący na portach typu 4444, 9001 lub innych nietypowych – warto mu się przyjrzeć. Często narzędzia typu Meterpreter lub inne trojany wykorzystują stałe nietypowe porty. Dzięki kolumnie PID od razu możemy skojarzyć taki port z konkretnym procesem.

Wskazówka: netstat daje migawkę tego, co w danej chwili jest połączone. Atakujący mogą być przebiegli – ich malware może otwierać połączenia nieregularnie. Aby to wychwycić, można użyć parametru -b (pokazanie plików EXE) lub skorzystać z PowerShell: cmdlet Get-NetTCPConnection potrafi wyświetlić podobne informacje, a w Powershell 7+ można go łatwo filtrować, np. Get-NetTCPConnection -State Established | Where-Object RemoteAddress -like '185.44.85.*'. Ponadto, powtarzając netstat w odstępach czasu (np. netstat -ano 5 aby co 5 sekund odświeżać) zwiększasz szansę na zauważenie krótkotrwałych połączeń.

Analiza logów zdarzeń Windows (wevtutil i PowerShell)

Kolejnym kluczowym źródłem informacji dla analityka są logi zdarzeń Windows. Windows rejestruje ogrom zdarzeń systemowych, z których najważniejsze dla bezpieczeństwa znajdują się w dzienniku Security. To tam trafiają wpisy o udanych i nieudanych logowaniach, zmianach uprawnień, uruchomieniach usług itp. Podczas analizy incydentu warto przejrzeć logi pod kątem niepokojących zdarzeń – np. seria błędnych logowań może świadczyć o próbie brute force, a zdarzenia związane z kontami (tworzenie użytkownika, dodanie do grupy adminów) mogą wskazywać na działania intruza.

W warunkach ograniczonych (np. brak dostępu do przeglądarki zdarzeń GUI), z pomocą przychodzi polecenie wevtutil. Jest to tekstowe narzędzie do obsługi logów, pozwalające m.in. odpytwać dzienniki o konkretne wpisy. Składnia bywa nieco zawiła, bo wykorzystuje zapytania XPath, ale pokażemy prosty przykład.

Jeśli interesuje Cię wiecej informacji na temat analizy logów w systemach MS Windows to sprawdź koniecznie nasz artykuł Windows Event Log Analysis – Kompletny Przewodnik.

Przykład z praktyki: Powiedzmy, że podejrzewasz próbę włamania przez logowanie RDP na konto administratora. Wiesz, że błędne logowanie wygeneruje zdarzenie o ID 4625 (Failure Audit – nieudane logowanie). Chcesz szybko sprawdzić, ile takich zdarzeń miało miejsce w ostatnim czasie. Uruchamiasz więc na podejrzanej maszynie wiersz poleceń jako administrator i wpisujesz:

wevtutil qe Security "/q:*[System/EventID=4625]" /f:text /c:5 /rd:true

Rozbijmy to polecenie: wevtutil qe Security oznacza query events z logu Security. Część "/q:*[System/EventID=4625]" to właśnie filtr XPath – pytamy o zdarzenia, których EventID równa się 4625. /f:text prosi o format tekstowy (czytelniejszy niż domyślny XML), /c:5 ogranicza wynik do 5 najnowszych zdarzeń spełniających kryterium, a /rd:true ustawia sortowanie malejące (czyli od najnowszych). W efekcie otrzymasz na ekranie 5 ostatnich błędnych logowań z Security log.

Analizujesz wynik i widzisz np.:

  • Account Name: Administrator
  • Workstation Name: 192.168.1.50
  • Failure Reason: Unknown user name or bad password

I takich wpisów jest kilkanaście w krótkim odstępie czasu. To oznacza, że ktoś próbował (i nadal próbuje) zgadywać hasło Administratora – klasyczna próba brute-force na RDP. Natychmiast zgłaszasz incydent i blokujesz źródłowy adres IP na zaporze sieciowej organizacji. Dzięki prostemu poleceniu w kilka sekund potwierdziłeś podejrzenie, zamiast klikać w GUI Event Viewer i ręcznie filtrować zdarzenia.

Oczywiście, wevtutil potrafi więcej. Możesz nim eksportować logi do pliku EVTX czy czyścić logi (to ostatnie bywa nadużywane przez atakujących w celu zacierania śladów – samo wyczyszczenie logu też generuje event 1102, co warto wiedzieć). W kontekście Blue Team, bardziej przydatne jest jednak filtrowanie i eksport. Jeśli chcesz np. przekazać kolegom 100 ostatnich zdarzeń logowania (ID 4624 – udane logowanie i 4625 – nieudane) w formie pliku, wykonasz:

wevtutil qe Security "/q:*[System/EventID=4624 or System/EventID=4625]" /f:csv /c:100 > LogonEvents.csv

To zapisze do pliku CSV sto najnowszych zdarzeń logowań (udanych i nieudanych). Taki plik da się potem łatwo przeglądać lub zaimportować do SIEM/Excel do dalszej analizy (np. posortować po czasie i adresie źródłowym).

PowerShell alternatywa: W PowerShell dostępne są cmdlety Get-EventLog (przestarzały, działa dla klasycznych logów) oraz Get-WinEvent (nowszy, wydajniejszy). Przykładowo, analogiczny do powyższego filtr da się uzyskać komendą:
Get-WinEvent -FilterHashtable @{LogName="Security"; ID=4625} -MaxEvents 5 | Format-List
Wynik będzie obiektem .NET z właściwościami zdarzenia (łatwo wyciągać konkretne pola). PowerShell doskonale nadaje się do skryptowego przerzucania logów, liczenia zdarzeń, szukania wzorców (np. wiele 4625 w krótkim czasie). Warto wspomnieć, że wiele nowoczesnych ataków zostawia ślady właśnie w logach (np. EventID 4720 – utworzenie nowego użytkownika, 7045 – instalacja usługi). Umiejętność szybkiego wyłowienia takich perełek z gąszczu logów to cecha skutecznego analityka SOC.

Sprawdzanie autostartu (Rejestr Run i inne)

Większość zaawansowanych malware po udanej infekcji próbuje zyskać persystencję, czyli uruchamiać się ponownie po restarcie systemu. Klasycznym miejscem, gdzie to realizują, jest autostart systemu Windows. Dlatego jako analityk bezpieczeństwa powinieneś zawsze sprawdzić, czy w typowych lokacjach autostartu nie pojawiły się nietypowe wpisy.

Najważniejsze z tych miejsc to:

  • Klucze rejestru Run/RunOnce – szczególnie:
    • HKLM\Software\Microsoft\Windows\CurrentVersion\Run (autostart dla wszystkich użytkowników)
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Run (autostart dla bieżącego użytkownika)
  • Foldery StartUp – np. C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp (oraz analogiczny folder w profilu każdego użytkownika).
  • Usługi systemowe – malware potrafi zarejestrować się jako usługa Windows.
  • Harmonogram zadań – o czym szerzej w następnym punkcie.

Zacznijmy od rejestru. By sprawdzić zawartość klucza Run, użyjemy polecenia reg (edytor rejestru w trybie tekstowym) z opcją query. Uruchom wiersz poleceń (CMD) jako admin i wykonaj:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

To wypisze wszystkie wartości (wpisy autostartu) w tym kluczu. Podobnie sprawdź klucz bieżącego użytkownika:

reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Co szukamy w wynikach? Wszystkiego, co nie pasuje do znanego zestawu. W czystym systemie mogą tam być wpisy sterowników grafiki, oprogramowania drukarek lub innych legalnych aplikacji. Ale jeśli zobaczysz wartość o nazwie np. “Windows Update” wskazującą na plik C:\Users\%USERNAME%\AppData\Local\Temp\update.exe – to bardzo podejrzane. Atakujący często nadają złośliwym wpisom nazwy brzmiące wiarygodnie, ale drobne szczegóły (jak ścieżka do Temp albo dziwna lokalizacja .exe) zdradzają ich intencje.

Przykład z praktyki: Wracając do naszego scenariusza z procesem svhost.exe – udało się go ubić, ale chcemy mieć pewność, że nie wróci po restarcie. Sprawdzamy więc autostart. Po wykonaniu powyższych komend reg query okazuje się, że w HKLM…\Run istnieje wpis:
„Svchost”=”C:\Users\Public\svhost.exe”. Bingo! Malware dodał siebie do autostartu, maskując nazwę jako “Svchost” (licząc, że administrator przeoczy literówkę). Teraz wiemy, dlaczego proces pojawiał się po każdym restarcie. Rozwiązanie: usunąć ten wpis z rejestru (np. reg delete ... lub ręcznie w regedit) i oczywiście usunąć sam plik z dysku po uprzednim zabezpieczeniu go do analizy.

Warto również zajrzeć do wspomnianych folderów startup. Można to zrobić np. poleceniem dir:

dir "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"

oraz analogicznie dla %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup (startup aktualnego użytkownika). Jeśli zobaczysz tam skrót (.lnk) o podejrzanej nazwie prowadzący do dziwnego pliku .exe czy .vbs – to kolejny sygnał alarmowy.

Na marginesie: graficzne narzędzia takie jak Autoruns (Sysinternals) są złotym standardem do przeglądu autostartu, ale zakładamy, że chcemy poradzić sobie czystym Windows. WMIC oferuje też polecenie startup (choć bywa mniej kompletne), np.:

wmic startup get Caption, Command

Wypisze to niektóre wpisy autostartu (Run i folder Startup) – jednak nie zawsze pokaże wszystkie, więc manualna kontrola rejestru jest pewniejsza.

Podsumowując: Analiza autostartu pozwala wykryć próby persystencji. Każdy znaleziony nietypowy wpis Run w rejestrze lub plik w folderze Startup powinien być zweryfikowany. W razie wątpliwości, dobrze jest poszukać hash sumy pliku w bazach VirusTotal lub podobnych, by sprawdzić, czy inni zgłaszali go jako malware. Jednak samo istnienie takiego wpisu (zwłaszcza wskazującego na katalog Temp, AppData lub o losowej nazwie) to już podstawa do działania – usunięcia go i dalszego dochodzenia, jak się tam znalazł.

Wykrywanie złośliwych zadań (schtasks)

Harmonogram zadań Windows (Task Scheduler) to kolejny ulubiony mechanizm atakujących do utrzymania się w systemie. Umożliwia uruchamianie dowolnych programów o zaplanowanych porach lub przy określonych zdarzeniach (np. logowanie). Z punktu widzenia Blue Team, podejrzane zadania zaplanowane mogą wskazywać na malware próbujące przetrwać restart lub wykonywać okresowo niechciane akcje (np. codzienne pobieranie aktualizacji złośliwego payloadu, exfiltrację danych w nocy, itp.).

Do analizy zadań wykorzystamy polecenie schtasks. Samo schtasks /query wyświetla listę wszystkich zadań zarejestrowanych w harmonogramie. Warto dodać przełączniki dla czytelności:

  • schtasks /query /fo LIST /v – pełna, szczegółowa lista zadań (format LIST, tryb verbose).

Ta komenda wypisze dużo tekstu, bo w systemie Windows domyślnie istnieje wiele zadań systemowych (od aktualizacji, poprzez raportowanie błędów, po różne zadania Microsoftu). Twoim zadaniem jest wyłowić wśród nich ewentualne “cuckoo egg” – czyli zadanie, które zostało dodane przez intruza.

Przykład z praktyki: Analizując maszynę po incydencie, zauważasz w wynikach schtasks /query /v zadanie o nazwie „GoogleUpdateTask„. Brzmi niewinnie – wiele aplikacji (np. Chrome) tworzy swoje updatery. Jednak kilka rzeczy Ci nie pasuje: zadanie jest ustawione na uruchamianie co godzinę w nocy (dziwne dla aktualizatora, który zwykle działa raz na dobę), a w polu „Task To Run” widzisz komendę:

powershell.exe -ExecutionPolicy Bypass -File "C:\Users\Public\gupp.ps1"

To już wyraźny sygnał alarmowy. Legalny Google Update nie powinien uruchamiać PowerShella z jakiegoś skryptu o nazwie gupp.ps1 w folderze Public! Najprawdopodobniej atakujący utworzył to zadanie, aby co godzinę uruchamiać swój skrypt PowerShell (być może pobierający kolejne instrukcje z C&C lub utrzymujący dostęp). Nazwę “GoogleUpdateTask” dobrał celowo, by wtopiła się w tło. To scenariusz autentycznie spotykany podczas analiz – kreatywnie nazwane zadania (np. „System Check”, „Windows Update Scheduler”) odpalające ukryte polecenia.

Jak postąpić? Taki task należy natychmiast wyłączyć lub usunąć. Możesz to zrobić również komendą, np.:

schtasks /End /TN "GoogleUpdateTask"
schtasks /Delete /TN "GoogleUpdateTask" /F

Pierwsza komenda zakończy ew. uruchomione zadanie, druga je skasuje (parametr /F wymusza operację bez potwierdzenia). Oczywiście uprzednio warto jeszcze zabezpieczyć plik gupp.ps1 do analizy, o ile jeszcze istnieje.

Na co zwracać uwagę przeglądając zadania? Oprócz nazwy i akcji (co jest uruchamiane), istotny jest też Autor/Author zadania oraz Trigger (kiedy uruchamia). Jeśli widzisz zadanie utworzone przez użytkownika, który nie powinien tego robić, lub np. wyzwalane „At system startup” o nazwie naśladującej systemowe – to kandydat do dalszej analizy. W logach Windows (Microsoft-Windows-TaskScheduler/Operational) można też znaleźć zdarzenia tworzenia nowych zadań (ID 106/140), ale to już bardziej zaawansowane poszukiwania.

Wskazówka: Alternatywą do schtasks jest PowerShell: Get-ScheduledTask | Where-Object State -ne 'Disabled' pokaże aktywne zadania. Można je też filtrować po Author lub akcjach. Czasem złośliwe zadania są ukryte w podfolderach harmonogramu (mają w nazwie np. \Microsoft\Windows\ cośtam). Wtedy schtasks może wymagać pełnej ścieżki zadania. Polecenie schtasks /query /TN "\" (ze znakiem ucieczki) wyświetli też hierarchię folderów. Generalnie jednak schtasks /query /v wylistuje wszystko – tylko uważnie przejrzyj listę lub przekieruj do pliku i przeszukaj pod kątem podejrzanych ciągów (np. findstr /i "powershell.exe" lub findstr "Temp" w pliku wynikowym).

Poszukiwanie podejrzanych plików (katalog Temp)

Dopełnieniem powyższych kroków jest przeszukanie systemu plików pod kątem plików, które mogą być komponentami ataku. Często malware kopiuje się w nietypowe miejsca – wspomniany już katalog Temp (zarówno systemowy, jak i użytkownika) to popularny wybór, podobnie jak %ProgramData% czy ukryte foldery w profilach użytkowników. Jako analityk warto zajrzeć do tych lokalizacji, jeśli mamy podejrzenia co do konkretnej maszyny.

Najprostszym narzędziem będzie tutaj standardowe polecenie dir lub PowerShell z Get-ChildItem. Możemy na przykładzie Temp pokazać, jak szukać “igły w stogu siana”:

Przykład z praktyki: Mamy już podejrzenie, że na stacji użytkownika był malware (proces svhost.exe, zadanie w harmonogramie, wpis w Run – wszystko wskazuje na infekcję). Chcemy poszukać pozostałości, np. oryginalnego pliku droppera. Często ląduje on w %TEMP% z losową nazwą. Wchodzimy więc do wiersza poleceń w katalogu Temp:

cd %TEMP%
dir /OD /S

Parametr /OD sortuje listing po dacie (Oldest first, czyli od najstarszych – jeśli chcemy od najnowszych, możemy potem przewinąć do końca lub użyć /O-D dla odwrotnego sortowania). Parametr /S przeszukuje też podfoldery. Patrząc na wyniki, koncentrujemy się na ostatnio zmodyfikowanych plikach. Załóżmy, że widzimy coś takiego na końcu listy:

2025-11-04  08:17           532,480   FFD3.tmp.exe
2025-11-04  08:18           145,000   dump.dat
2025-11-04  08:19           1,024,000 malware.dll

Plik FFD3.tmp.exe z aktualną datą i dość losową nazwą wygląda podejrzanie. Podobnie malware.dll – nazwa wręcz jawna (może taką akurat miał, ale bywa i coś typu abc.tmp). Te pliki to kandydaci do analizy. Możemy sprawdzić ich właściwości (np. certutil -hashfile FFD3.tmp.exe MD5 żeby uzyskać hash i sprawdzić w bazach), albo choćby otworzyć w notatniku nagłówek (czasem widać ścieżki debug czy strings).

Inną metodą jest użycie PowerShell do znalezienia np. wszystkich plików .exe w Temp większych niż pewien rozmiar:

Get-ChildItem $env:TEMP -Recurse -Filter *.exe | Where-Object {$_.Length -gt 100KB}

To wylistuje pliki EXE większe niż 100 KB w katalogu Temp bieżącego użytkownika. Podobne zapytanie można skierować na C:\Windows\Temp i C:\ProgramData. Zwykle systemowe EXE nie będą się tam znajdować, więc większość wykrytych to dobry trop.

Oprócz Temp, warto zbadać lokalizacje takie jak:

  • *C:\Users<Nazwa>\AppData\Local* (i podfoldery, np. często malware tworzy własne foldery w Local lub Roaming)
  • *C:\ProgramData* (czasem tam się ukrywają pliki konfiguracyjne lub kopie malware)
  • *C:\Windows\System32* – jeśli podejrzewamy podmianę systemowych plików (to już zaawansowany scenariusz, raczej rzadziej spotykany bez pozostawienia innych śladów).

Kluczowe jest by wiedzieć czego szukać: nienormalne nazwy plików, rozszerzenia .exe/.dll/.bat/.ps1 które nie pasują do reszty, pliki utworzone bardzo niedawno lub w czasie korelującym z incydentem, ewentualnie pliki o nietypowych rozmiarach (np. dokładnie 1 048 576 bajtów jak powyżej – to może wskazywać na zaszyfrowane kontenery, itp.).

Uwaga: Zachowaj ostrożność – nie uruchamiaj przypadkowych plików znalezionych w tych katalogach. Jeśli to malware, uruchomienie go ponownie może ponowić infekcję. Analizy dokonuj na odizolowanym systemie lub przekazując próbki do sandboksa/laboratorium malware.

Checklist: szybka inspekcja bezpieczeństwa Windows

Na koniec zbierzmy to wszystko w formie technicznej checklisty. Poniżej znajdziesz listę kontrolną kroków i poleceń, które analityk bezpieczeństwa (Blue Team) może wykonać podczas szybkiej inspekcji podejrzanego hosta Windows:

  • Procesy: Uruchom tasklist /v i sprawdź listę działających procesów. Wypatruj nieznanych nazw i lokalizacji. W razie podejrzeń użyj tasklist /fi z filtrami lub Get-Process/Get-CimInstance w PowerShell, aby wydobyć szczegóły (PID, ścieżki). Każdy proces działający spoza C:\Windows lub Program Files (np. z Temp, AppData) zasługuje na podejrzenie.
  • Połączenia sieciowe: Wykonaj netstat -ano i powiąż aktywne połączenia z procesami (PID). Zanotuj wszelkie połączenia do obcych adresów (szczególnie na nietypowych portach). Jeśli możliwe, zidentyfikuj procesy utrzymujące te połączenia (tasklist /fi "PID eq <PID>"). Podejrzane adresy IP sprawdź w bazach reputacji, a jeśli potwierdzi się zagrożenie – blokuj je na firewallu.
  • Logi zdarzeń: Szybko przejrzyj ostatnie zdarzenia bezpieczeństwa. Użyj wevtutil lub PowerShell (Get-WinEvent) by wyszukać kluczowe Event ID: 4624/4625 (logowania), 4720 (nowy użytkownik), 4722/4723 (odblokowanie konta, zmiana hasła), 4670 (modyfikacja uprawnień), 7045 (nowa usługa zainstalowana) itp. Wszelkie nietypowe lub masowe błędy logowania, nagłe tworzenie kont, wyczyszczenie logów (Event ID 1102) – to sygnały ostrzegawcze.
  • Autostart (Run/Services): Sprawdź klucze rejestru Run dla HKLM i HKCU (reg query ... Run). Upewnij się, że wszystkie wpisy są legitymne. Wyszukaj w wartościach ścieżki wskazujące na Temp, AppData lub dziwnie nazwane pliki. Równolegle sprawdź listę usług (sc query type= service state= all lub w PowerShell Get-Service) pod kątem dziwnych, niespodziewanych usług (zwłaszcza takie, które są Running i mają nieznany Display Name).
  • Harmonogram zadań: Uruchom schtasks /query /v i przejrzyj zaplanowane zadania. Zwróć uwagę na te z niestandardowymi nazwami lub uruchamiające podejrzane akcje (np. skrypty PowerShell, pliki w dziwnych lokalizacjach). W razie znalezienia złośliwego zadania – zakończ je i usuń (schtasks /End oraz /Delete).
  • System plików – IOCs: Przeskanuj newralgiczne katalogi (Temp, ProgramData, AppData) w poszukiwaniu plików powiązanych z incydentem. Użyj dir /s /od by zobaczyć najnowsze pliki. Każdy świeży plik .exe/.dll/.bat/.ps1 o podejrzanej nazwie traktuj jako potencjalny artefakt. Zgromadź hash takiego pliku (certutil -hashfile <file> SHA256) i sprawdź w VirusTotal lub innym IOC repozytorium. Nie otwieraj plików produkcyjnie, zabezpiecz je do analizy offline.
  • Dowody i notatki: Dokumentuj wyniki każdego polecenia – przekieruj wyjścia do plików (>), rób zrzuty ekranu konsoli. To ważne dla późniejszego raportu z incydentu i ewentualnej analizy forensic. Dzięki temu nic nie umknie, a Ty będziesz mógł łatwiej dzielić się ustaleniami z resztą zespołu.

Ta checklista stanowi podstawę szybkiej oceny sytuacji na zainfekowanym (lub podejrzanym) hoście Windows. W zależności od wyników, analityk może rozszerzyć zakres działań (np. sprawdzić ruch sieciowy pakietowo, zrobić dump pamięci procesu, itp.), ale opisane wyżej kroki to fundament Blue Team w środowisku Windows.

Podsumowanie

Windows oferuje bogaty zestaw narzędzi wiersza poleceń i cmdletów PowerShell, które – odpowiednio użyte – pozwalają analitykowi bezpieczeństwa szybko wyłapać symptomy ataku i podjąć skuteczną reakcję. Przewodnik ten pokazał praktyczne zastosowania najważniejszych z nich: od tasklist i netstat po wevtutil, schtasks oraz zapytania rejestru. Każde z tych poleceń ma swoje miejsce w arsenale SOC i pomaga rzucić światło na inny aspekt potencjalnego incydentu.

Pamiętaj, że kluczem jest znajomość normy – kiedy wiesz, jak zwykle wygląda lista procesów czy zadań na danej maszynie, łatwiej wychwycisz anomalię. Dlatego zachęcamy: praktykuj te komendy na co dzień. Przeglądaj logi, procesy, autostart nawet gdy nie ma incydentu, by wyrobić sobie instynkt. Gdy zdarzy się prawdziwy atak, będziesz reagować odruchowo, nie tracąc czasu na przypominanie sobie składni.

Dlaczego to ma znaczenie? Bo w bezpieczeństwie czas reakcji i właściwa diagnoza to podstawa. Wykorzystując wbudowane narzędzia Windows, działasz niczym cyfrowy detektyw – tropisz ślady zostawione przez intruza w systemie. Im szybciej je znajdziesz, tym szybciej zatrzymasz atak i zabezpieczysz dowody.

Teraz Twoja kolej – weź tę wiedzę i sprawdź w praktyce. Usiądź przy dowolnym systemie Windows (nawet Twoim własnym PC) i przeprowadź mały audit bezpieczeństwa: czy w procesach wszystko gra? Czy nie masz dziwnych wpisów w autostarcie? Czy netstat pokazuje tylko znajome adresy? Taka ćwiczeniowa inspekcja pozwoli Ci nabrać wprawy. A jeśli kiedyś do Twojego SOC zadzwoni alarm o włamaniu – będziesz gotowy, by pewnie uderzyć w klawisze i sięgnąć po Windows Commands niczym po sprawdzony, niezawodny sprzęt detektywa. Powodzenia w Twoich dochodzeniach!

Bibliografia

Jeden komentarz do “Windows Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami”

  1. Pingback: Linux Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami - Security Bez Tabu

Możliwość komentowania została wyłączona.